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.
- hosted mode uses an awful, horrific hack to simulate FLASH:
it makes a global singleton that is freely mutable. Oh but wait!
that's actually how the hardware behaves. It's up to the code
around the hardware to create those primitives. So, maybe it makes
sense that the simulation model for the hardware is terribly
unsafe and unprotected.
- the format routine at least doesn't crash and creates some
semblance of a result that looks right-ish. Need to write a
utility that helps to explore the "disk image" so we can
understand what's going on.
This is a "no good choice" situation but there is a problem with
progress bars.
You want progress bars to update quickly, and you don't want
to have to context switch out for the entire graphics stack to
come back to you to approve the drawing of your progress bar update.
On the other hand, you don't want to short-circuit all the checks
on drawing stuff to the screen for the sake of progress bars --
right now, there are a number of checks in place to make sure you
can't draw stuff on parts of the screen you shouldn't, to avoid
fake messages and dialog boxes.
I had managed to work out a way to get a dialog box to redraw without
violating the security rules -- each redraw is checked by the defacing
routine -- however, due to the way I was computing the height of
the modal I was causing the dialog box to be resized to its largest
size and then shrunk again to fit the text every iteration. This
in essence also caused the defacement routine to run repeatedly,
which caused the GAM to also issue repeated redraw requests to
the main loop.
These redraw requests can't be serviced until the task being tracked
by the progress bar is completed. As the progress bar gets redrawn
almost a hundred times as part of the task, roughly a hundred messages
arrive in the server's queue before it can handle a single one.
This results in a deadlock situation on completion of the progress
bar, because we want to fire off a message to ourselves to go to
the next state in the Ux routine.
There are a few possible solutions to this:
1. Multi thread the heck out of the routine doing the progress bar,
so the dialog box and the slider are each in their own threads
with their own responders and then the thing doing the computation
is doing some Mutex-guarded-Arc thing.
2. Do some very unsafe bodge to allow sliders to do direct draws
that are unchecked
3. Add a check so that if the size of the dialog box doesn't change,
defacement isn't recomputed and thus redraw messages aren't sent back.
(1) doesn't work for a number of reasons -- in a general case, it's
probably OK, but it does cause a lot more memory usage (and we are
lean on memory); but more importantly, for this use case, our routine
is interacting with CSRs and those don't implement Send so you can't
pass them into a thread via a closure. You could maybe put the dialog
boxes themselves into an Arc Mutex thing but because this routine
was heavily coded to re-use the heavyweight Ux resources this becomes
a bit cumersome to code.
(2) is terrible
(3) ended up working and what is in this commit. I think it's OK
because a progress bar generally doesn't require changing the
size of a window to update its state; therefore the redraw is
deface-safe (since you aren't changing the bounds of what you were
already approved to draw in). Of course, if you have some sort
of a progress bar implementation that changes the size of the messages
reported up top so that the dialog box has to change size over and
over again, you still end up in the deadlock situation!
The function `as_slice_mut()` takes a `MemoryRange` and returns a
mutable slice. Previously, this could be called on a memory range that
was not defined as `mut`.
This will be fixed in `xous-rs` so that `as_slice_mut()` can only be
called on a region that is defined as `mut`.
Signed-off-by: Sean Cross <sean@xobs.io>
This code was originally in https://github.com/betrusted-io/rom-locate.
However, the majority of that crate is concerned with creating the database
files necessary for the patching, and it pulls in a lot of dependencies.
Changing hardware targets is considered to be a "huge" change for this
project, so we're pushing the code generator directly into xous-core,
and commiting the generated code directly. The theory is that we would
probably never have to modify this code, since it's so intimately linked
to the hardware; it's a bit like committing an include file with
register offsets for a particular peripheral.
