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.
This allows for `ditherpunk` config to have a much larger
stack size on select processes only.
The cost comes at a 4k fixed overhead for the sacrificial
wrapper thread, so we lose about 20k of runtime RAM, even
when ditherpunk is *not* activated (because we're
always wrapping the threads).
There is no impact on scheduling or CPU utilization, as the
wrapper thread blocks and is never scheduled once the real
main starts. However, it does subtract one thread from the
total available thread pool.
This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
change the notification modal to accept the primary message and an
Option of independent text to display as a qrcode
pub fn show_notification(&self, notification: &str, qrtext:Option<&str>) -> Result<(), xous::Error> {}
