the camirq is a perfectly good source of preemption,
and xous will run other threads when the handler is finished.
having both natural timer preemption and camera preemption running
at the sime time seems unnecessary and hurts performance.
this is done after critical setup is done. it doesn't guarantee
that it has an infinite time slice, but it makes the startup sequence
more deterministic.
this is a test stub that can be activated in baremetal that
confirms whether or not the bits blown to protect the boot0
region work or not.
This test should be run as part of the check-off process for the golden
image sent for production.
the snippet `attack_keystore()` is left in place along with hints
on how to attack the keystore. Nominally, the attack should fail,
but there are some critical pre-assumptions that can be violated.
I am interested in knowing how robust those assumptions are, so,
documentation and sample code is provided to would-be attackers.
Do me a solid and if you do find a vulnerability, open an issue
ASAP and let me know. Full well aware that some vulns may well
be unpatchable; it is what it is. Hardware is hard, but maybe
we can work together to make it better.
Setting these JTAG-only accessible locations will set
write protection on boot0. This effectively makes the public keys
used to establish the boot chain indelible.
- feature gate some unsafe-debug
- tie akey_id to 0xff which should disable key chaining, which
is not used in our scheme because authentication is not hmac-based,
uses public keys instead
the chunks match the size of the application buffer, eliminating
the possibility of an overrun (of the buffer at least)
there is a possibility still i think of overrunning USB itself
but i think the CPU can't produce data fast enough to actually
do that.
latest rev of the board seems to handle the heat load OK.
board gets a little warm to touch when the system is clocked
at max frequency, but not unpleasantly so.
- \r\n formatting is now consistent with the rest of the OS
- fixed buffer size assert failure when sending large strings
- removed 'cute' command - i love it but the UTF-8 doesn't render
on all terminals and will lead to more criticism than delight
- made usb serial a default option
the more i test things the less confidence i have.
this fixes up a missing table entry in the table definition,
and then also adds a bypass routine - this is not actually
a hidden vulnerability, it's an explicit vulnerability until
the protect() routine is called. But it looks like we may have
to exploit it in order to transform our userstate in
the bootloader to one that has write-access to keys in order
to erase them in case of a developer boot.
only some keys are marked as writeable to harden against
potential oracle attacks, i.e., if we made all keys
erasable and an oracle attack was found, then the entire
key region can be exposed by the oracle attack.
Instead, some key material always persists, but a sufficiently
large amount of seed material is erased such that the key is not
recoverable by guessing the key.
this accommodates the notion of erasing secret keys when
a developer key is detected. Some hackery in the API is
required, because I'm trying to use the same signature
routine for both boot0 and boot1, but coreuser settings
should not be set until boot1.
Boot0 has *no* coreuser settings, whereas boot1 starts
to lay them in - this interferes with key erasure, and
so the nice clean "boot or die" abstraction disappears
because we have to now just check if a key matches a criteria
and then return because we have to handle the environment
dependent case of coreuser settings.
