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.
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>
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.
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 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>
this might want to get a more graceful feature option wrapped
around it but i'm hoping the unpleasantness of developing on
the FPGA board is...temporary??
- make the "base" field no longer public. It is accessible, but only
through an `unsafe` method, because, it is unsafe.
- add accessors to offest/mask fields. Because, it's not at all
unsafe to access these, and it can be useful for bit-ops that are
not part of the generic set of UTRA.
- add Arc to AtomicCSR, and require `std` for AtomicCSR types.
This should not break anything, I checked inside @foundation-devices
keyOS and they don't seem to be using AtomicCSR anywhere.
The Arc makes it a bit safer to clone the AtomicCSR base pointer
and share it between threads, but it will have an impact on performance.
The USB stack (which requires AtomicCSR) was regression testing and the
impact seems minimal.
Recall that the main purpose of AtomicCSR is to provide a CSR accessor
that does not require a mutable reference to the base object. This
can make certain Rust idioms a bit cleaner. We wrap the base accessor
in Arc+Atomic to try and improve the safety of throwing the borrow
checker under the bus, but it's still not perfect because hardware
mutable state can have side-effects within hardware itself that cannot
be modeled or checked by Rust's borrow checker.
When a block of data perfectly fits we fail to allocate the
next page, violating the loop invariant that there's data available
to write.
However, we can't always allocate a new page when we run out
because if we're at the end of the process we shouldn't allocate
a new page (I think). Thus we track if the last section was
a perfect fit, and if it was, we force a new page allocation
before copying more data.
This is an edit in phase 1 of the loader.
