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.
Add link commands to the cargo config so that the loader can be built
for the `riscv32imac-unknown-xous-elf` target.
Signed-off-by: Sean Cross <sean@xobs.io>
By vendoring this package, we can avoid causing a rebuild unnecessarily.
This will be removed when Rust 1.55 is released and we can bring the
`loader` package back into the main workspace.
Signed-off-by: Sean Cross <sean@xobs.io>
The stack must be 16-byte aligned in order for `u32` to work properly,
as the compiler assumes these values are aligned.
Signed-off-by: Sean Cross <sean@xobs.io>
