- new api incantations
- KeyInit trait demotion into individual functions
- decomposition of Scalar derivations because the hasher
API changes and is no longer directly passable into Scalar
(this should probably get reverted if/when curve25519/ed25519
is bumped in API later...)
- notes about areas that should be hardware accelerated but are not
looks like about 9 crates will be affected by this. Point them
all to the latest version of the API, and specify the
"precursor" feature (which activates our patch)
formatted some pretty big blocks of either autogenerated
or copy/pasted blobs used for emulation.
I think I'll let the formatting stand because the autogen
code is "never" going to change (i.e. they are physical constants
tied to the properties of the hardware) or the pasted blobs
have no real meaning beyond the blob itself so if they were
regenerated it'd be another copypasta with format.
Now, we finally get to addressing the root cause of #472.
We can't map all of kernel memory anymore, because exclusivity of
ownership of pages is now properly enforced. This means that XIP
images, which run directly out of FLASH, map their code region of
FLASH into their processes. This disallows measurement of their
code spaces by the rootkeys crate; previously we had mapped all
of code space and could measure everyone's code but it also means
we had a double-ownership.
Having resolved that single-ownership is cleaner, we now have
a scheme where the loader, which sees all of the kernel anyways,
computes a hash and signature check of the kernel at boot time,
and pashes the unsigned hash on to the environment variables of Xous
(environment variables pending @xobs commits).
This commit fixes up all the kernel signing routines to work with
a now disjoint kernel memory space. In particular, the key signing
routine needs access to three parts of the FLASH region devoted
to storing `xous.img` (which is loosely and imprecisely referred
to as "kernel memory"; this does lead to confusion thinking that
we're referring to the RAM devoted to the kernel, but for this
discussion we are talking about the window of FLASH where `xous.img`
is written, along with other metadata related to it):
- the first page, where the signature is stored
- the end of the kernel, where the kernel length check is stored
- the end of the entire flash window, where the backup records
are stored
The first page is fairly self-explanatory, this is the signature,
some version information, and an unprotected length hint for the
kernel.
Because the length hint in the signature record is unprotected,
we have to repeat it at the end of the kernel data and include
it in the signed region. Thus, there is a window of memory
that is 2 pages large that captures the dynamically varying
(dynamically varying as in build-to-build this offset changes so
it can't be a `const`) location of the length data. 2 pages
are mapped because the region of interest can fall across a
page boundary, so we map the potential lower page and upper
page that captures the length field (although in most cases
the upper page is not used, it is harmless to map it pre-emptively).
A mask is provided so that we can use the previous compuattions
for offsets and just mask it to compute the offest within this
window.
The end of the flash window, the last page, contains the backup
records. This is a set of metadata that records information
about PDDB backups including the checksums of the regions and
encrypted access keys.
This patch attempts to find all accesses to kernel space and
bin them into their respective regions, while adjust their offsets.
Testing will require us to check signing, updating, and backups --
all aspects of the machine lifecycle are impacted!
this is a trait wrapper that allows us to take pre-hash as
a `[u8]` and wrap it into a thing that hase a finalize() method
and the requisite traits to satisfy Rust, allowing us to pass
our loader-generated, environment-variable-passed hash into
an otherwise unawares cryptography crate.
mea culpa.
a lot of re-import warnings have cropped up. While I appreciate
their studiousness on this, the problem is that removing some
of these exports in the API crate could mean that future users
who want access to some API features that aren't used in this
configuration are now unaccessible.
I think it's not a huge problem at the moment, just spam-cleaning
the warnings because there are too many to deal with carefully
at the moment.
Mark `MemoryRange::as_slice()` and `MemoryRange::as_slice_mut()` as
unsafe.
This is due to the fact that not all representable types can be cast to
an arbitrary value. For example, if Process A sends random values to
Process B, then Process B casts the memory to a slice of `bool`, then
any values that are not 0 or 1 are undefined.
Because these functions can leak UB into the program, they are marked as
unsafe.
This patch adds `unsafe {}` blocks to all instances where this function
is called. Additionally, all instances have been checked to verify that
they do not cast to any invalid types -- most use `u8` or `u32`.
Additionally, the long-deprecated `MemoryRange::from_parts()` call was
removed, since that causes UB without being marked as unsafe.
Signed-off-by: Sean Cross <sean@xobs.io>
