mount initiator is now back inside of the status thread
(woo, no more app-specific dependency) and there is now a
wait on "attempted to mount" inside the status thread which is
the signal to clear the "waiting on boot" message.
it's now in shellchat. In general, the program that is assigned
as the initial app context is responsible for ensuring the
PDDB is mounted. Thus, if `vault` were to become a stand-alone app,
it should include some code to make sure the PDDB is mounted as
part of its boot sequence.
The reason is that it allows the initial app to guide the
power-on experience, instead of delegating this to the `status`
bar, which is oblivious to the state of the app.
The rationale is that xous-rs should have only architecture
specific code, e.g.: riscv, arm, x86, etc. To make other
crates that depend on it not specify the features.
This could be useful when using xous-rs with `libstd`
for example.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
In general, hosted mode is assumed "by default" if the target
is not Xous. This allows packages to be built cleanly on command
lines that don't know to pass a --feature flag to specify a target.
However, an explicit "hosted" flag is still retained so that we
can confirm the build system intent. This saves us from the failure
mode that we thought we were building for target A, but accidentally
ommitted the flag, and instead we've been silently building for
"hosted" mode without any warning. The main consumer of the "hosted"
flag is now just the build.rs script inside of the utralib.
The implementation is a bit clumsy because the original
premise of the login loop is that it should be infalliable, and
because of the isolation of the password mechanism there isn't
a great way to pass number of failures back and forth across
that firewall (and I don't think there should be).
The application calling the password routine tracks failures
but the mounting routine has to kick that up to the main loop.
However, the PDDB main loop can't get stuck on the mount attempt
if you want to suspend, because it has to respond to the suspend
request.
So the failure message has to get kicked all the way back to the
status thread, which is what kicks off the mount, and then handled
there.
Because we unmount the PDDB and put the system in a semi-shutdown
state, backups are not abortable if you type in the wrong root password.
This patch retries the root password forever, but also adds a note
at the beginning of the process that the process cannot be stopped
once started.
every 1MiB block is checksummed with a sha512/256 truncated to
128 bits. This is used to confirm the media and transport integrity
only. It is not intended to be a cryptographic check, it just confirms
that the backup data was transferred correctly assuming no intentionally
malicious actors in the middle.
This will allow for e.g. xous on riscv32-imac but not a precursor
target, for example: by using feature selectors we get to have
a bigger range of targets that we support, such as for implementations
that haven't been upstreamed or have official target-triples.
The downsides are:
- patch override libraries don't absorb feature flags. so, for
example, the AES crate that is used to patch other crates won't
be aware of the target features without modifying the referencing
crates.
- features are normally meant to be additive, but target features
are mutually exclusive. The mutex is enforced by a check in
utralib that throws a panic on build if two targets are accidentally
selected at the same time.
