Previously, we would unconditionally zero out the remainder of a page
when finished copying. We wrapped to PAGE_SIZE in order to avoid
corrupting another process' memory.
However, an issue was discovered under the following circumstances:
1. There are fewer than 4096 bytes of `.bss`
2. The `.bss` ends on a page boundary
Under these conditions, the loader would load the section before the
`.bss` into the page, then clear out the `.bss`, and finally clear the
entire page, overwriting the previous section.
Skip the remainder-of-page clearout when the `.bss` ends on a page
boundary, rather than clearing the entire page.
Signed-off-by: Sean Cross <sean@xobs.io>
Print out the current process ID when looping through values. This will
make it easier to identify which process is getting loaded when reading
through the tea leaves.
Signed-off-by: Sean Cross <sean@xobs.io>
this helps minimal configurations to be more useful without pulling
in com/llio crates. The trade-off is that KP's early in boot
(or during resume) are not visible, but, these are (thankfully??)
less rare these days.
Add the loader into the main workspace, removing it from its own
sub-workspace. We can do this now that we can specify the linker script
in `build.rs`.
This improves IDE support, and should shrink disk storage requirements.
Signed-off-by: Sean Cross <sean@xobs.io>
- bypass causes warnings to be emitted in compilation
- stark visual change on boot screen ("jail bars" instead of gray on bottom half)
- root keys are locked out permanently from readout
- devboot canary set
Add the loader into the main workspace, removing it from its own
sub-workspace. We can do this now that we can specify the linker script
in `build.rs`.
This improves IDE support, and should shrink disk storage requirements.
Signed-off-by: Sean Cross <sean@xobs.io>
Each Cargo.toml now includes a comment which remnids maintainers
of the dependency policy for Xous (that is, nail down every dependency
to the minor number).
these are secondary attack surfaces -- code that isn't directly
in the kernel, but involved in the manipulation, handling, grooming
and preparation of source and binary files
Versions are pinned down to the minor number. Yes, this means that
we don't automatically pull in features and bug updates from crates.io,
but it also means we don't pull in new attack surfaces and code that
hasn't been tested or reviewed. I'd like this process to be very deliberate
and not automatic for Xous.
The `rand` crate is almost pinned down to a single version, except
for an odd dependency that's pulled in by hosted mode that depends
on rand 0.8.4 via a subordinate dependency via the `tempfile` crate.
Pondering if it's worth it to try and eliminate that, because the
0.8.4 version doesn't get compiled into any version that touches
real hardware. It just makes it harder to analyze the Cargo.lock
file, mostly. I think I'll leave it as-is.
This is going to require users to update their devices before
doing a key initialization.
The problem is that we can't trust the length of data presented
to us to self-sign, so we sign the whole area. In v0.9.2 of the
loader, a check was introduced to check the putative length of
the signed area against the actual length of the signed area,
by encoding the length of the signed area within the signed
region.
This would require the rootkeys algorithm to also encode that
new length at the end of the signed area, but this was never
done. However, this bug was never found during testing probably
because I failed to completely erase the original key provisioning
(I was more fixated on checking that existing keys were not damaged by
firmware updates at the time), and thus did not trigger a full
rootkey provisioning cycle when I did the test. I had only just
caught it now while porting the PDDB from simulation to real
hardware.
the unsigned metadata in the signature header is used to compute
the signature, which contains a copy of the key metadata. We forgot
to make sure these match, which means the signed copy was worthless.
Until now.
