Convert the fs_prehash into a hex ascii string, suitable for environment variables
The initial loader environment is hard-coded, so we use a hard-coded offset for the string
destination. It was a deliberate decision to not include a generic environment variable
handler in the loader because we want to keep the loader compact and with a small attack
surface; a generic environment handling routine would add significant size without much
benefit.
Note that the main purpose for environment variables is for test & debug tooling, where
single programs are run in hosted or emulated environments with arguments passed for fast
debugging. The sole purpose for the environment variable in the loader's context is to
this computed hash onto the userspace environments.
While ideally we'd be as light-fingered as possible on the cryptographic
APIs, unfortunately the reality is we have exactly one hardware
hash engine and we can't just leave the context laying around.
Given that the verification routine would consume the hash, that
would make it unavailable for use later on to pass to the system.
So, this patch set causes the pre-hash algorithm to take a simple
slice-u8 instead of a whole hash context.
The downside of this is it erases the type information about
needing a 64-bit hash to go into the context. This is partially
mitigated with an assert that gives us a run-time check of this
property.
Support passing process arguments in register 2 as part of arguments to
a process.
This requires updating the `InitialProcess` struct that is received from
the loader, and so requires modeifications to be made in tandem.
Signed-off-by: Sean Cross <sean@xobs.io>
Load environment variables to processes by placing the value onto the
stack. This will support additional data in the future such as command
line arguments.
Note this is a breaking change and requires a kernel modification.
Signed-off-by: Sean Cross <sean@xobs.io>
these are just sync'd to the asm.S and checked in.
Eventually, we should migrate that .S file into using
in-line assembly macros, but now that I look at it, I remember
why it hasn't been done yet -- there are some fancy conditionals
used to enable compatibility with different architectures that
I don't know off the top of my head how to translate into
in-line assembly syntax.
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.
most of them are just shifting existing dependencies around but
somehow we're also now depending on pem-rfc7468. This slipped in
because we now use a `der` method to interpret a pkcs-8 query.
You know, this is kind of silly in the end because in practice,
the key file is like literally 64 bytes and we're pulling in net about
four orders of magnitude more code to make sure we parse those
64 bytes in exactly the right way -- because we have the *whole*
spec pulled in as crates even though we only ever use a tiny section
of it.
otoh, just vendoring in code or hard-coding an offset in a key file
seems "broken". But maybe that's a false economy because I can
point to the one sin I commit in doing a trivial interpretation
of the key file (e.g. hard-coding an offset with some minimal
format checking), whereas probably in the tens of thousands
of lines of code pulled in to interpret the pkcs-8 format "correctly"
which I actually didn't review explicitly, there are many more
sins, but because I've externalized them into crates I can say
I can sleep well at night thinking I did the right thing by
avoiding that one sin. It's like buying index funds and yet not
feeling remorse about the actions of the corporations within
the fund because you didn't explicitly endorse their actions but
you still get to participate in their gains.
Somehow, this has turned into a commentary on the human condition.
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.
The loader image uses the original signing method, because changing
that would require us to modify the gateware ROM, which is a huge
pain in the ass, and doesn't buy us anything.
Thus only the kernel signing uses the pre-hash method.
This requires us to modify our dependencies to have dalek-ed25519
as one of our dependencies.
Which requires another patch in this commit set to implement
sha512 for hosts, since we patch the sha2 crate for all targets
to our local version.
This applies to the *kernel* image.
The loader itself is still signed with the conventional signature.
Version number of the loader is also incremented.
we only have one hash engine in hardware, and we want to use
hardware hashing at boot to speed things up as much as possible
and reduce code size of the bootloader.
This patch causes the pre-hash to finalize before a new hash
is initialized which folds in all the other key parameters.
passing this flag causes the loader to print debug output.
This slows down the loading process but gives you some visibility
into what's going on (maybe also an idea for the future to add
VDBG flags for verbosity, they exist in the code but not exposed
as command line options).
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.
Add "_zicsr_zifencei" to "rv32imac" when describing the CPU core. This
is required by newer versions of the spec, and will eventually be a
requirement of Renode.
Signed-off-by: Sean Cross <sean@xobs.io>
The riscv foundation changed the descriptor of riscv cores. We must now
add "_zicsr_zifencei" to the "rv32i" designation in order to ensure we
have access to CSRs and the "FENCE.I" instruction.
Signed-off-by: Sean Cross <sean@xobs.io>
Add the pid as the page owner to `map_page()` calls. This ensures pages
are owned by their respective processes, and removes a lot of
`change_owner()` calls that immediately follow page mapping.
It also allows for superpages to be owned by their respective processes.
Signed-off-by: Sean Cross <sean@xobs.io>
The "susres" page should be owned by the "susres" server and not the
kernel. Avoid mapping this page to the kernel to prevent it from getting
double-mapped.
Signed-off-by: Sean Cross <sean@xobs.io>
When enumerating processes, the `find_process()` process didn't consult
whether a process was actually free. This resulted in a crash,
particularly when attaching a debugger to a crashed process.
Signed-off-by: Sean Cross <sean@xobs.io>
This command ensures memory is all owned by the correct process and is
unique in its ownership.
It takes a long time to run, so ensure the watchdog timer is disabled.
Signed-off-by: Sean Cross <sean@xobs.io>
Add a function to ensure mappings are unique across the whole system.
This takes a very long time and can crash if the watchdog timer isn't
paused.
Signed-off-by: Sean Cross <sean@xobs.io>
Add "_zicsr_zifencei" to "rv32imac" when describing the CPU core. This
is required by newer versions of the spec, and will eventually be a
requirement of Renode.
Signed-off-by: Sean Cross <sean@xobs.io>
The riscv foundation changed the descriptor of riscv cores. We must now
add "_zicsr_zifencei" to the "rv32i" designation in order to ensure we
have access to CSRs and the "FENCE.I" instruction.
Signed-off-by: Sean Cross <sean@xobs.io>
