- 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.
