previously we just panic'd (which is actually the right behavior
for this type of error) but because we now have a reason for it
to fail (e.g. testing the encryption key) we make this fallible.
in all other places we just unwrap() - there is no fallback if
decryption fails, boot should just halt.
but this allows us to check which decryption key is deployed
in phase 1.
trying to condense most of the RPT API into the loader so
that the userspace can use a single dependency for this.
We can't condense the kernel API into the loader unfortunately,
because the kernel actually uses a different type for representing
a process. This is probably a mistake, and is something that
may be fixed later so we can merge the representations.
We had a "coincidence" before that allowed things to work,
where we had some data line up that we happened to think
was some other header data, so we "fixed" it by
subtracting the offset of the header data.
Actually, it wasn't.
Clarify that decrypt_src_page_at() offsets are relative
to the beginning of encrypted data, and not relative
to the absolute beginning of the disk.
Image creation is now fixed so that stuff lines up to what
this routine expects, and some asserts added to try and
save ourselves in the future as we try to fix other bugs
we discover over time.
loaders are hard.
- swap session key has to be stored so we can pass it on to
the kernel to access swap
- setup all PT maps necessary for swapper to be functional
before the swapper is started.
This is to break circular dependencies mapping pages inside the
swapper, especially during boot.
We might also need to statically map the LRU swap count structure,
not sure. We'll burn that bridge when we get there, right now,
let's just get a non count-managed swap even working...
traits are kind of awful in Rust...it's true, they don't
know how big they are at compile time, so they have to be dyn,
reference, lifetimes, etc...
lot of baggage for a static structure. I guess there's probably
some idk bounds I could put on the traits to make it less poopy
but also just as easy to make it a static structure and not deal
with traits.
RAM is assumed to be off-chip, and thus the data is encrypted
in the region. We also encrypt it in the Precursor case, even
though it's on-chip, because we want to capture this as a test case
in a known working environment.
Also incorporate some routines to generate the per-boot random
key for swap encryption.
