- 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...
The check of mapping sanity happens after the VA mapping, so this
undoes that. I think this is a good idea, because we're also
checking the PA->VA mapping of the PTEs as well now.
The addresses put into the swapper's page table are physical
addresses, which are unusable by the swapper itself. This
patches the PTEs with the repsective virtual address, so we
don't have to do a PT walk inside the swapper when handling
a swap event.
Also fix an off-by-one on the processes count. This is sort of
an old architectural bug in the loader that would be nice to fix
someday.
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.
kernel load last isn't necessary
add some asserts to help sanity check things. In particular,
the kernel mapped memory can't exceed 0xA000 in length, otherwise
it bumps into hard-coded constants in the kernel for where hardware
mapped pages should go (i.e., panic framebuffer, debug UART, etc.)
Page mapping just can't be done during the phase 1 loading, because
we move the loading point by an unpredictable amount which messes
up phase 2. I mean, we could try to predict the amount, but it's easier
if we just stick with the current algorithm instead of trying to
do both at once. Basically, phase 1 must be "no-alloc" entirely
as it copies.
Phase 2 can allocate page table entries, because all the data
is copied to RAM and you know where that starts; and you can start
to append data to the end of that without affecting the loading
points of programs.
Undo a previous patch to force kernel to load last. Turns out
this is legal, it was only problematic because of other bugs.
Also, reflect swap_root in the BootConfig structure and not
in InitialProcess structure.
+ Various other debug fixes
this is more robust, and should work across all architectures.
Note that the reliability of the check is slightly impacted
since we're now checking for a subset of valid numbers, so
the number of bytes checked is doubled.
In swap configuration, the loader does a lot more: it has
to decrypt full pages of RAM and hold them temporarily;
up to two pages at once, once for the decrypt of the source
swap image, and one for the encrypt to swap memory.
This causes a lot more stack to be used than the original loader.
Add some debugging for this, and an assert based on a heuristic
that the RPT (runtime page tracker) last few entries ought to
be 0. This I think is probably true on most platforms. If this
fails to be true, then, we can probably modify the assert to
fail if any number in the RPT is greater than the number of
processes: this should be true in *all* cases, but a stack smash
is very likely to write something in there that's larger than
the number of allowable processes in the system.
load checking is aware of all three types of sections, and
can natively call the encrypt/decrypt ops to ensure that
the encrypted swap is set up correctly.
The argument appending code in copy_args() is truly abominable.
Suspect more latent bugs in there. Definitely some deep technical
debt in this routine, it's basically just a pile of unsafe pointers
jammed together with no checks. This has to do in part with the
underlying implementation of the argument iterators, which
understandably try to do a lot with no allocations, but it's
brittle and does not play nicely with the idea of extending
the argument records.
we're not passing pages around like I thought I would. svae
the stack space, so in the future if we do stuff with e.g.
suspend/resume we don't have to reserve such a huge
chunk of RAM for boot.
