the init check is a bit too broad, we can still accept an honest
devkey answer as devkey mode in the case that the security keys haven't
been set up yet.
The TL;DR is this now treats dabao exactly the same as
baosec in terms of keystore setup from the security flow perspective.
baosec & dabao were different originally because baosec would
rely upon the Avalanche generator TRNG as supplemental randomness
and dabao would not. This special case had to be handled in the
bootloader and propagated through.
However, in a previous commit, the keystore setup was moved to
the OS *anyways* - thus making this difference moot.
This patch backs out the one-way counters that would track the
dabao initialization state.
It also doesn't fail the boot on the erase key proof check
failing if the keystores aren't initialized yet. This creates
yet another condition that could be glitched over to bypass
the erase check but it is checked twice indepedently.
At this point, some of the keys are partially locked out
which makes reacting to an attack slightly less effective
(keys are now locked into a particular process space configuration
which is not available in the loader's default config).
The reaction at this point sums up to seeing if the image is
a developer image, and if so, ensuring that the developer mode
bit is set (which would indicate that the keys have been
erased). I suppose an attacker could get around this by glitching
to some code that sets developer mode without also erasing
the keys. This weakness needs to be explored and hardened against.
The loader is only lightly hardened at this point. Some minmal
random delay + bollards inserted. The signature check routine
inherits all the hardening of boot0 because it uses the same
code. PLL mode is checked at least once.
more loader hardening will happen in a future PR - at the
moment, we're focused on boot0/boot1 hardening.
this is randomly genverated on boot and inserted into the
environment. it is unique per-PID.
This is useful for seeding psuedorandom number generators,
especially in environments where syscalls are not possible.
bootwait allows automation to load the swap image after the
board type is set correctly
breaks the paradox that you can't init swap on a blank chip
because it doesn't know it has swap
Secret keys can't be erased after boot1 exits because the protection
bits are hardened from modification after that point.
thus it is not possible for the loader to switch the device
into developer mode.
Thus the only way to enter developer mode is through a dev-mode
signed loader. A system that has never been put into developer
mode will refuse to run any developer-mode xous kernel, app, swap
images.
Once a system has been exposed to a dev-mode signed loader,
the boot1 will flip the developer mode bit and erase the secret
keys.
Later on, if a production loader is replaced, it doesn't matter
that a production loader is loading dev-mode signed successors
because the secret keys are already erased.
Note that in all cases, the key revocations take precedence
so if the developer key is revoked, these cases should never
even be encountered.
Rust 1.91 (or perhaps, more accurately llvm?) changed how link
ordering works.
Previously, modules would be linked in the order they were referenced
(e.g. pub mod b; pub mod a; would result in b being at a lower address
than a in the resulting binary).
However, apparently, this has changed and now someone in their
infinite wisdom decided that modules should be alphabetized before
linking.
I'm really not sure why the arbitrary ordering of the human alphabet
is superior to any other system, and also, if you really wanted
things alphabetized, you could just alphabetize them in your
reference order.
Previously the fonts were laid out in a way that tried to minimize
cache thrashing by co-locating certain sets of fonts together.
Now they are just sprayed around through the arbitrary and not
terribly useful permutation funtion of the english alphabet.
Rant off.
This changes the specification of the fonts in the code generator
to be in alphabetical order, making the screen once again legible.
heap can't be initialized before suspend/resume is checked
bao1x doesn't have suspend/resume, and requires heap early
on to check signatures
so heap initializationg is now optionally included in two
locations to meet the conflicting requirements per platform.
loader was previously just accepting a dev key image and not
doing any countermeasures. now, kernel, detached-app, or swap
not being properly signed activates countermeasuers.
also select the swap key fallback for checking swap. this is
"half" of the solution, the other half will have to be implemented
in userspace - if we do it at all. i'm starting to think that
the swap encryption is not necessary, it was introduced
under the assumption that signature checking swap would be
too slow, but it's not. so maybe this feature will get dropped.
have to absorb a version change due to xous-semver change
might as well also update the utra/svd generator dependencies
since that's been held off for a long time now.
"detached-apps" are Xous applications loaded into a region
of memory-mapped FLASH (and thus memory-mapped applications)
that are separate from the main xous.img image.
This allows developers to work on "just their app" instead
of having to upload the whole Xous ball.
Currently the only configuration that supports this is the
dabao configuration.
Turns out we 'just got lucky' with our previous success
in getting arg extension to work (scary!!): the arg format
is pretty uhh...flexible...in terms of what it will accept
for arguments.
This fixes those bugs, the arg copy looks clean now, and
also removed the over-allocation problem by descending
the new argument list twice, once to sum the space needed,
and once to actually do the copy.
