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.
This adds some UX feedback in the edge case that a suspend could not
happen due to a blocking sever, e.g. a sha512 hash pending or
a SPINOR flash write/erase pending.
The UI will tell the user to retry again; usually the ops in
a normally functioning system for hashes or SPI are very short,
so we could almost just retry automatically but I think for now
I want to see if this edge case actually happens.
fully integrates wifi on and off commands. measured standby power
when wifi is off is "immeasurable" (0 mA), so probably < 1-2mA.
fix ui transitions so that the off request is respected, through
sleep/resume cycles as well.
this properly solves the issue of the keypress machine sending
notifications to a status thread that's not running: it creates
a dummy server that can drain the queue until the status thread
is ready to run properly.
Just remembered that the PDDB is *locked* to a given device.
To restore to a new device, you have to unlock all the Bases,
and re-encrypt them to the new device's DNA.
This commit adds the facilities to detect this condition, but
the actual code to do this is quite involved...let's handle that
after we've got a "simple" restore to the same device going.
Why do we lock to a device's DNA? the idea is to prevent
attacks where people are taking static blocks of crypto data
and just swapping it between devices to see if they can
get something to decrypt. It also makes it harder for
an adversary to replace the physical device -- e.g., an
evil maid prepared a replacement with implants in advance, and they
image your PDDB onto the replaced device, hoping that you don't
notice. Because the PDDB is device-locked, the "evil maid"
would have to forge the devices DNA to match yours:
possible, but would require kernel mods that patch over the
reported ID; that would trigger the line across the top of the
screen; or, somehow editing the FPGA itself to force
its device ID to report the same as yours. This last attack
vector would be successful, but afaik there is no known way
to modify an FPGA's DNA code. I'm sure there is some proprietary
secret know that Xilinx uses to set it, and if you were
a large government you may be able to coerce Xilinx into giving
you those codes plus some tool that could set the fuses
plus some unfused devices (the fuses are burn-once) but....
- do not try to create root keys if we just did an SoC update.
that's just too many things going on, we should definitely force
a clean reboot first.
- add a clean reboot step after a no-key soc update
- try to switch USB debug mode on if a backup was created
in order to trigger an update in early boot, all the security
sensitive servers have to have their connection tables occupied
(I guess the fancy term is the "capabilities" need to be allocated.
whatevs. #notanacademic).
This fixes the flow so those capabilities are occupied before
we get to the update check. Also fixes options to ignore updates.
