- code is merged into shellchat so there's less alignment overhead
and some library reuse
- server is not spawned until it's needed, so the RAM load is less
Saves a bit on resources and the RTC crate doesn't need
to be stand-alone now that the modals crate is a thing;
we are able to split the UX routine to manage the RTC out
of the code that actually manages the hardware.
The hardware code ended up in LLIO, and the UX ended up in the status
routine.
Each Cargo.toml now includes a comment which remnids maintainers
of the dependency policy for Xous (that is, nail down every dependency
to the minor number).
Versions are pinned down to the minor number. Yes, this means that
we don't automatically pull in features and bug updates from crates.io,
but it also means we don't pull in new attack surfaces and code that
hasn't been tested or reviewed. I'd like this process to be very deliberate
and not automatic for Xous.
The `rand` crate is almost pinned down to a single version, except
for an odd dependency that's pulled in by hosted mode that depends
on rand 0.8.4 via a subordinate dependency via the `tempfile` crate.
Pondering if it's worth it to try and eliminate that, because the
0.8.4 version doesn't get compiled into any version that touches
real hardware. It just makes it harder to analyze the Cargo.lock
file, mostly. I think I'll leave it as-is.
All the PDDB infrastructure is now in place. The core filesystem is
fairly well tested, but the server APIs are entirely untested. However,
this merge at least gets the clean build into the mainline and will
cause a Precursor to create and format a PDDB. Note: this takes about
15 minutes -- about 7 minutes to erase the memory, 9 minutes to fill it
with random data. This is primarily limited by the raw speed of the
FLASH memory itself.
probably should have split this into two commits. oh well.
first part introduces a check to see if root keys are initialized,
and if so, tries to mount the PDDB. If it can't mount, it asks
the user if they want to format it. It also updates the progress
of the fromatting.
the second part redoes the salt once again. After some discussion
SHA512/256 is also resistant to length extension attacsk so we
don't need to use the HMAC technique suggested. Would prefer to
reduce the number of algos to analyze, so we're going to a simple
SHA512/256 hash of the salt/basis name/plaintext password to generate
the salt that goes into the bcrypt routine that ultimately generates
the final key used by the system.
4s seemed like a long time but i found one board that can't quite finish reset in that time, about 70% of the time it needs just a half second longer.
open up the window to 6s, just to ensure we don't get any false negatives.
sleep killbounce wouldn't work because we started limiting the
number of connections to the LLIO.
This change makes connections to the LLIO unlimited, but perhaps later
on we should split out the I2C bus into a separate security domain,
so that the LLIO's unlimited connection policy doesn't introduce a
risk into a rogue process being able to overwrite the RTC contents.
- moved most ping state into the Net crate proper, since the smoltcp
implementation assumes a tightly bound set of objects and lifetimes
in its icmp abstraction
- created various convenience abstractions for handling single and
multiple pings, blocking and non-blocking.
- refactored the "net" command to use the new form
Initial testing indicates there are still some bugs (seems to be
with the way we are handling timestamping and doing pong retirement)
but at least we're not getting tons of async callback errors like
we were before, and we're not shuttling obscene amounts of state
using Arc-Mutex between the input and output of the ping operations.
Now that I understand how smoltcp does ping better I have regrets.
The demo example in smoltcp uses a funky macro that was a bit
misleading. I have gotten rid of that but I probably would have made
different decisions in implementing this had I understood the API better.
Anyways. It works, but has some trouble handling the cases of timeouts
sometimes.
not fully working yet, but the architecture is there and it builds.
smoltcp's ping implementation (or at least its demo code) was not
very amenable to splitting into modules, had to recode most of it.
the ipv6 is still a hack.
Multicast/Broadcast is not supported by smoltcp it seems, so those
calls are just unimplemented. But we are able to clone UdpSocket,
for the sick puppies who like to do that sort of thing.
Closes#76
The test vectors in wycheproof-import/x25519_test.json correspond to the upstream commit 4672ff74d6.
For details see wycheproof-import/README.md.
Signed-off-by: Fabian Weißberg <fabian.weissberg@tu-dortmund.de>
The function `as_slice_mut()` takes a `MemoryRange` and returns a
mutable slice. Previously, this could be called on a memory range that
was not defined as `mut`.
This will be fixed in `xous-rs` so that `as_slice_mut()` can only be
called on a region that is defined as `mut`.
Signed-off-by: Sean Cross <sean@xobs.io>
also add some bread crumbs on the more user-facing APIs to
help beginners out. Need to do a good spring cleaning of the
rustdoc tree, though. looks pretty terrible as it is.
This is for turning the WF200 wifi radio on and off, setting the
SSID and password, joining an AP, leaving an AP, and checking the
AP connection status.
Signed-off-by: samblenny
we are at least now only requiring users to use our patched
curve25519-dalek crate, which now builds cleanly in both
xous and std environments, but the higher-level crates can be
directly used from crates.io
this prevents less trusted processes from connecting to servers
after the kernel initializations are done.
this works so long as we don't have disconnects from the kernel
servers. In order to support disconnects we will also need a
way to re-enumerate the SID to guarantee that we don't have a re-use
problem. But for now, the kernel is not designed with any practical
disconnect mechanism; there is no code that calls the Quit mechanism
on any server.
the concurrency issues on I2C are getting hairy, and it was probably a
dubious decision from the start to merge I2C into the LLIO block; but
originally this was motivated by the idea of keeping all the
"miscellaneous slow stuff" in one process to keep the memory footprint
small and make code a bit more readable.
Keeping I2C in the same process space as the LLIO but splitting it
into its own thread and server splits the difference, by giving us
more options to deal with the concurrency, without inflating the size
of the kernel binary and allocating a lot of extra static data.
Here's an arcane bug for you:
When powering down, the Spartan 7 3.3V I/O drivers will
output a roughly 800us wide glitch as 3.3V falls below around
1.7V, if the 0.95V core voltage comes down first (which it does
because we have an active discharge on 0.95V, but not on 3.3V).
In this case, it's just wide and high enough to cause the
BOOST mode line to engage, which takes the BOOST output
and ties it to VBUS, which is just enough for the system to
think you're powering it back on again. Which is not what
you want when powering down.
The ultimate fix was to put a heftier pull-down on the BOOST
line so that it can't trip the BOOST output into the VBUS.
Another option could be more active discharge FETs, but that
would require a full board spin and we are already at certification,
so we'll stick with the stronger pull-down on BOOST. It seems to
be a robust fix in the worst corner cases we can find.
The downside is that when powering an external USB device,
you are burning an extra 30mW of power overcoming the pull-down,
but typically, any external USB devices plugged into Precursor
will burn far in excess of that, so the delta should be negligible.
There is an issue with the rtc commandline time checking
with respect to unhooking its callback, maybe related to
the new disconnect/destroy server code
This rewrites the entire project so that most runnable projects now use
`xous-ipc` instead of `xous::String` where possible.
This also removes `rkyv` from the list of dependencies in `xous-rs`.
Signed-off-by: Sean Cross <sean@xobs.io>
Bring the two branches up to date, while also laying the groundwork
for XousServerName to be used as a native index type in xous-names
so we aren't burdening xous::String with a hasher
