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>
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.
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>
The graphics server has been observed to explode stack. This increases
the start size of the stack to prevent this from happening.
Signed-off-by: Sean Cross <sean@xobs.io>