- 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
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>
I decided to go back on the idea of not changing the modals
and now all modals use the new larger font as well.
This creates issue #396, which I will deal with later once
I have the time to do some more testing. I'm pretty sure
some other dialog boxes are broken now too.
This change is made with the intention of making the xous-rs crate a bit
more freestanding without depending on the xtask build system.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
In general, hosted mode is assumed "by default" if the target
is not Xous. This allows packages to be built cleanly on command
lines that don't know to pass a --feature flag to specify a target.
However, an explicit "hosted" flag is still retained so that we
can confirm the build system intent. This saves us from the failure
mode that we thought we were building for target A, but accidentally
ommitted the flag, and instead we've been silently building for
"hosted" mode without any warning. The main consumer of the "hosted"
flag is now just the build.rs script inside of the utralib.
Because we unmount the PDDB and put the system in a semi-shutdown
state, backups are not abortable if you type in the wrong root password.
This patch retries the root password forever, but also adds a note
at the beginning of the process that the process cannot be stopped
once started.
rkyv-derived enums throw warnings that they are unused.
Not sure how to get rid of them; I've tried surrounding them in
`#[allow(dead_code)]` directives, and also explicitly creating
each enum variant that I'm aware of through some dummy code and
some log prints of the dummy code calls to ensure the results are
used, and the warnings still persist.
Significantly, the warnings only happen for enums that take
a value. Simple rkyv enums do not throw a warning.
These warnings overwhelm the build logs, so they need to be isolated
in order for us to ensure that the build is clean of other more
important warnings.
The method chosen to isolate them is to take the enums that are
problematic, carve them into their own special file, and add
a file-wide `#![allow(dead_code)]` directive. This only happens
in 7 service crates, and this change commits all of the modifications
in a single big commit that could be undone later if this turns out
to be a compiler regression or something similar.
I also opened an issue with the rkyv maintainer to see what his
opinion is on the situation.
https://github.com/rkyv/rkyv/issues/318
every 1MiB block is checksummed with a sha512/256 truncated to
128 bits. This is used to confirm the media and transport integrity
only. It is not intended to be a cryptographic check, it just confirms
that the backup data was transferred correctly assuming no intentionally
malicious actors in the middle.
This will allow for e.g. xous on riscv32-imac but not a precursor
target, for example: by using feature selectors we get to have
a bigger range of targets that we support, such as for implementations
that haven't been upstreamed or have official target-triples.
The downsides are:
- patch override libraries don't absorb feature flags. so, for
example, the AES crate that is used to patch other crates won't
be aware of the target features without modifying the referencing
crates.
- features are normally meant to be additive, but target features
are mutually exclusive. The mutex is enforced by a check in
utralib that throws a panic on build if two targets are accidentally
selected at the same time.
- boot PIN is not requested on root password init. it's redundant,
as it is actually set when you format the PDDB
- boot key was mistakenly a copy of the encrypted private key
for ed25519 key signing. "oops". didn't catch that bug until now...
i don't think it has a big impact on existing user base, because
the key is never exposed outside the rootkey server, and the
ed25519 key itself is encrypted with the root password and then
used as the boot key. But still -- that's just not what was intended.
- root password is requested twice to check the validity of the password
this patch moves us off the branch we had to hop on for cipher
API compatibility to the one that's officially published by
RustCrypto. This closes#168.
