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.
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.
