the more i test things the less confidence i have.
this fixes up a missing table entry in the table definition,
and then also adds a bypass routine - this is not actually
a hidden vulnerability, it's an explicit vulnerability until
the protect() routine is called. But it looks like we may have
to exploit it in order to transform our userstate in
the bootloader to one that has write-access to keys in order
to erase them in case of a developer boot.
only some keys are marked as writeable to harden against
potential oracle attacks, i.e., if we made all keys
erasable and an oracle attack was found, then the entire
key region can be exposed by the oracle attack.
Instead, some key material always persists, but a sufficiently
large amount of seed material is erased such that the key is not
recoverable by guessing the key.
the key setup seems to work correctly
but the data ACL setting doesn't "stick". The region
could be write-protected by some other element in the
CP/IFR config, need to dig a lot more. For now we need
to move on and crank out something to stick on the alpha
dabao boards...
add read/write specs as well to the slot definitions.
Not terribly happy with how this all worked out. The subtle
differences between Data and Keys is really irritating.
it's the sort of thing you would say "let's make a trait"
for it but then the two behave just differently enough
that I worry I can't make a trait generic enough to encompass
all the weird stuff that exists in the hardware.
The existing implementation definitely looks like trait
territory, but it currently hides the subtleties around
key/data chaining and secure crypto engine handling of
the two regions as distinct entities. so long as we don't
plan to use those things, traits are a good idea, but
i don't feel like I can reject using the crypto engine
features out of hand this early on just to make the
APIs nice and square.
'coreuser' is a slightly confusing term from the hardware
system because it's overloaded to mean some conceptually
related items that aren't implementation-wise essentially linked.
coreuser defines both some access protections on the main
array of the RRAM, and also some access protections on key
and data slots.
this patch includes some code that sets up the coreuser
functionality to a very simple scheme where just one PID
is trusted and the rest are not trusted. More complicated
schemes could be introduced with varying levels of trust
and dependencies but I like the analytical simplicity of
two states, so let's start there and complicate only when
absolutely necessary.
Data and key slots are hardware access-controlled areas that
can store sensitive data. Slot definitions come with a "spec"
field that defines what the access controls *should* be,
so that we can check them later.
In practice no user code should be manipulating these, but
there is an initial stage where a totally blank device needs
to be provisioned, hence the focus on correct specification
and checking of state, rather than convenient runtime manipulation
and update of the same.
on dabao targets the duart is unavailable, so, it's convenient to
have a uart-based debug option in the HAL. this patch creates a
flag that can allow either target.
- add range checking to control access to main array or secure
array. This is purely a software enforced check, but it is in
theory backed by hardware gating that is a back stop in case
an adversary can gain arbitrary code access
- rework the rram primitive to return an error type
- add a `std` implementation stub. It is still missing an IRQ
context handler which ensures that all RRAM writes are atomic,
e.g. you can't take an interrupt in the middle of an RRAM
write because it would screw up the buffer staging.
auth_data actually changes with each signing operation (ostensibly
to prevent replay of signatures coming from tokens) so it has
to be presented as data parallel to the signature, instead of
as a static filed baked into the key header.
This commit revises the header record to reflect this organizatio
of data and also revises the signature check to be in-line
with the protocol.
have to absorb a version change due to xous-semver change
might as well also update the utra/svd generator dependencies
since that's been held off for a long time now.
this is the agnostic version of all of the board targets, which
allows the boot1 to lookup based on the current configuration
which configurations to apply.
I think I've talked myself into giving away $0.20 of parts with
every dabao board so that everyone can run at full frequency.
Originally I thought I'd limit to the minimal configuration with
low frequency operation but since this is the main developer
platform all the benchmarks and first impressions will come
through this board. Crippling it with a slower clock frequency
by omitting the supplementary digital regulator seems
short-sighted, even if it means up slightly subsidizing things
with this extra cost.
this cleans up one unsafe step where we have to assume an
alignment of the data at the cost of the structure being copied
to stack. I think this is a fine trade-off.
this implements the API/HAL split on the HAL side, and also
reveals SPIM channel as a constant that can be just read out
so that spim accessors that need to build from raw parts
can do it without having to re-allocate IOs.
In the API layer, the boards aren't setup with convenience flags.
they are all laid out and the caller needs to know which board
it's trying to resolve. This is because the API layer is agnostic
to board and assumes the tool working with it knows what board
it's working with already.
The HAL layer tries to hide the board-specific stuff, and so
API defines are re-imported there in a board-transparent fashion.
Also add swap descriptors to the API crate, so that the image
generation tools can refer to the exact same structures as
are used inside the code, simplifying image creation maintenance.
this puts a domain separator in every signature block
a domain separator meaning, even though the same private key
maybe be used to sign multiple blocks, because a functional code
is embedded in the block that is tied to the block's function, you
can't take a pre-signed block and shove it into another block's slot
and expect it to work.
