If there is a gap > 4k in an incoming minielf, the swap offset
becomes desynchronized with the loading offset.
This patch catches that case and increments the swap offset. The
gap data is simply uninit and unused by the system.
the first check should *never* print a message because an attacker
can trigger a glitch off of the UART. this eliminates the diagnostic
print on the first check.
A particular edge case was finally reproduced & fixed. The edge
case occurs when a swap is triggered while handling an interrupt,
and an OOM happens during the context switch to/from the interrupt.
The background on this is that the hardware drivers for the swapper,
as well as much of the logical heavy lifting on e.g. what pages to
swap out, live in a userspace process known as xous-swapper.
The userspace process has to run free of interrupts - when you're
OOM'd or trying to swap, interrupts should not happen. The way to
do this in Xous is to run that code inside an interurpt context,
as interrupts are not interruptable.
Thus, the xous swapper userspace consists of two halves: a regular
userspace stub that provides some amount of control/debug over
the swapper, and a handler that gets run in a "pseudo-interrupt"
context.
Like all other interrupts, the handler "borrows" the stack of the currently
running thread - interrupt contexts don't have an explicit stack, they
just grow on top of the current stack of the current thread in the
current process at the time of the interrupt.
This is broken because when you have a swap event inside an interrupt
context, there are conditions where you might not have a stack. What
was in fact happening is that the stack pointer was being orphaned
as being the "exception stack" - which is a temporary location,
only accessible by the kernel, used for storing all the registers
going into and out of exceptions. Since no stack pointer is set up,
the moment the userspace starts to run and spill its registers to
stack, the system trips a "nested swap" event, which leads to a panic
because this is not allowed.
The fix to this is to devote two hard-wired pages, mapped in the
loader, to be the swapper's private stack area. Instead of behaving
like an interrupt and borrowing the caller's stack, the swapper instead
goes back to its hard-wired stack to do all the processing.
This should also improve the performance of swap handling in some
cases because we can now guarantee the stack is always in-memory
and doesn't need to be swapped in during swap processing.
One complication is that the "reserved memory" that the swapper
puts aside in case it *does* need to allocate extra pages during
handling can't be freed at the top of the OOM routine. Thus if
the swapper ends up using new pages, we should expect yet another
crash.
However, in practice, this doesn't seem to happen, because the
cases in which we hit needing a new page are typically related
to cases early on in boot where superpages/new page table entries
are being allocated, or if we're growing the heap that passes
data back and forth between swap and userspace. Because this call
triggers in such a specific condition, I hypothesize that actually
in practice it should generally be able to run without allocations.
One case where maybe it could hit an allocation is if the swapper
hit, for the first time, in an interrupt handler that was swapped
out, and never hit before, and the interrupt handler needed a
superpage to be allocated, thus triggering an allocation request
for a new PTE or two. I think this is probably pretty unlikely, but
if we do hit it, the fix would be to, for the purposes of targets
with "swap" enabled, to mark unmap_memory and map_memory to be
legal syscalls in interrupt contexts. These are normally illegal
because interrupts should always return - and these calls could
potentially fail or block. However, I think in this case it's
a trade-off between "we should be failing if we run out of memory"
and that failure being a potentially incorrect behavior that is guarded
against by a runtime check to discourage such calls.
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.
