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.
Swap can be "secured" in two ways:
1) it can be re-encrypted to a secure, locally generated key
2) it can be signature-checked with a public key.
(2) is provided as a path to receive updates. Updates are distributed
as "encrypted" (with the "0" key), but signed with a public key.
Once the update is validated, it's meant to be re-encrypted
with a per-device unique key.
A big reason for the re-encryption is because the swap is already
encrypted, we can rely on the AEAD for validation, and skip the
signature check (saves time on boot). Recall that the reason
we don't just do a sig-check and run is that is a TOCTOU:
it's pretty trivial to execute a mux that swaps out the FLASH
memory after the signature check with another version that has
malicious stuff in it. So we go with a sector-by-sector
AEAD that's ideally encrypted to a locally generated key.
It also offers the possibility to prevent malleability of the
swap data between devices, as many public-key signed images
could be floating around, including old versions that include
insecurities (e.g. prevents downgrade attack by replacing
an up to date image with an older signed image with an insecurity).
However, this latter possibility requires the user interface
to be correctly setup to prevent malleability by asking users
to opt-in to partition re-encryption. Need to consider this user
experience flow - kicking the can down the line, but that time
is coming soon.
previously we just panic'd (which is actually the right behavior
for this type of error) but because we now have a reason for it
to fail (e.g. testing the encryption key) we make this fallible.
in all other places we just unwrap() - there is no fallback if
decryption fails, boot should just halt.
but this allows us to check which decryption key is deployed
in phase 1.
- loader heap is now fixed in a "throw-away" region of memory.
this means the heap should only be used sparingly, and somewhat
dangerously, because the values can't persist beyond the lifetime
of the loader.
- signature validation moved earlier
- fixup swap structures to refer to the API so that image creation
is easier/consistent
the original rather unsafe version is replaced with a more readable
version that has a number of safety checks applied.
in the process of doing this, we now support merging of multiple
argument regions and a variable number of tags to merge.
tested to work on at least the base case of one swap region to
merge into the list.
this is a fairly complicated bit of legacy code that we're
trying to make slightly better/more readable.
some docs are added, as well as getting rid of a bunch of
"magic" constants, instead preferring to map things into
structured data where possible.
also fixed the location of the heap allocation relative to
the boot flow. It's now in a spot where I think we can
safely put dynamically allocated kernel arguments.
