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.
we actually do have a `std` now in Xous, it wasn't there before
because we made this crate before we had `std`.
However, I'm not quite sure what apis we should be adding if we
have `std`...probably something else should be added, we'll probably
trip over it when someone tries to compile against a crate that
actually uses the `std`-specific APIs.
xous targets use the Precursor hardware engine for hashing
all others use a software-only implementation. Not the most
performant but the code is vendored in
directly from the rustcrypto crate.
this is necessary because we are doing ed25519-dalek on the local
machine and the original signing crate used to implement signatures
("ring") does not support pre-hash mode.
maybe could do with cleaning up the build to eliminate "ring" and
just go with ed25519-dalek for all signings now, but we already
have "ring" as a dependency for other reasons so let's go
with conservative small changes for now.
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.
Regenerate the font files after adjusting the template to generate files
that will not get changed by rustfmt.
Signed-off-by: Sean Cross <sean@xobs.io>
Generate code that can be put through rustfmt without being altered.
This removes an issue where the font tables can be rearraged by simply
running `rustfmt` on the repository.
Signed-off-by: Sean Cross <sean@xobs.io>
The `codec` seems to hang sometimes during `Setup8kStereo` at boot.
Did not get to the bottom of it, but suspect that the RTC I2C init
sequence is interfering with the codec init sequence. This might
be resolved while also fixing #467, but for now, a short delay
on boot works around the problem.
we need to tag out a release, so we're temporarily forking
`smoltcp` at its current head, testing it, and holding it
there until a full release is tagged out that captures all
of the good stuff that has been going on in that repo since
June.
by marking the EC as ready after all the update checks are done
we can ensure that the PDDB mount dialog does not attempt to come
up during an EC update.
The nominal purpose of this is to allow other services to delay
interactions that could interfere with an EC update.
Note that anyone could call this routine and mark the EC as not
ready, since the llio block is not secured and the API is public.
I don't think it's a security problem, but is a DoS vector.
