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.
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.
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.
"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.
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
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.
The loader grew a lot of hair over the past few months as it
was abused as a baremetal environment for chip bring-up.
A baremetal environment was explicitly created to help with that,
so we don't have to pollute the loader with lots of unused features
and ancilliary code.
Furthermore, a decision was made to eliminate updates from the
loader code base - the loader is just for setting up Xous. This
allows the loader to be more platform-agnostic.
Boot1 instead contains all the platform-specific code for doing updates.
For completeness, we note that boot0 is a minimal piece of code that is the
first step in the chain of trust and is intended to be a read-only
segment of code that has public keys baked into it that are used
to bootstrap the rest of the ecosystem.
At this point, the loader is now slimmed down and runs. Still needs
testing to make sure the culling wasn't too aggressive, but I am
much happier with where this is landing as the loader is once again
just focused on getting Xous up and running.
The code base had evolved through several code names, interim
names, company names and chip names that alternatively did or did
not exist.
Baochip is the definitive name of the company, and the Baochip1x
(full part number BAO1X2S4F-WA) is the definitivey part number of
the SoC. For convenience, the part number is shortened to 'bao1x'
in most feature flags and variable references.
This commit fixes all of the odd names and removes some unmaintained
early targets.
