the loader is a little funky, and requires some maintainer hand-holding
due to the split of the page ownership between the root-keys
crate and the graphics-server crate.
Improved docs so I don't forget this detail in the future.
this allows for a quick readout of the version of each of these
artifacts, inside a signed region, by just inspecting the last
few words of the binary object.
this commits a script that will repeatedly rerun the `btest`
which creates several Bases, fills them with pseudorandom datat,
and goes through a lock/unlock cycle.
should be run with the disk size set to 4MiB for maximum stress
testing (the larger disk won't trigger an FSCB refill because its
hard to run out free space on the larger disk size)
The FPGA gateware region is blocked from trivial readout via USB:
this makes it a tiny bit harder to obtain the gateware image, which
contains the secret keys. This slightly aids users who haven't
burned any efuse keys and are using the default "null" key from
a trivial readout attack, and it also hampers a WBSTAR exploit.
This makes the most convenient path of attack to be loading
a custom xous.img (or otherwise exploiting the kernel) with
a gadget that is capable of reading the gateware region
through priveleged code, and then relaying it over USB through
some run-around of the firewall. This primitive isn't impossible
to create but it doesn't exist and has no use in a normal
operational flow, so, it's going to at least force an attacker
to write some code, as opposed to using off the shelf utilities
we provide.
The `xmas-elf` crate doesn't deal with `raw_data()` of sections that are
`NO_COPY`. These sections may point to data that is outside of the file.
In order to avoid hitting this assert, don't call `raw_data()` on
sections that are marked `NO_COPY`.
Signed-off-by: Sean Cross <sean@xobs.io>
use `usb kbdtest` to output a mapping assuming US-101 maps
it will then derive an appropriate keymap based on that mapping
doesn't support non-ascii characters (yet)
The next release will feature an access control on USB so that
root keys and the encrypted gateware cannot be read back and
transitively the writes would be guttered (but this is not a problem
because the write target address is not set by the memory location
of the write, it's actually set by the location specified in
the program command to the FLASH).
This means that the updating program has to be modified accordingly;
now, for writes, a single location is targeted (and as alluded above,
this is funneled to a write FIFO buffer, and then the actual address is
set with the page program command); and for readback, attempts to read
back the SoC area are flagged and noted as impossible due to security
precautions.
