This moves the key store initialization to the key manager
process itself.
It has been tested to work with signed images, and to also
protect the system in case of another process trying to access
the key data as well as in the case of developer keys being
used.
The -A1 stepping is going to tie the IFR access control
bits for data and key slots together. This is due to an RTL
bug where the key slot maps were typo'd and they ended
up mapping to the same IFR ACL.
We "could" continue to use key slots with a rule that
key and data slots would have to coordinate with each
other and not use the same slot number.
However, because of this linkage, and because there are
other bugs suspected in the keyslot implementation, an
executive decision was made to disregard the key slot
feature in the chip.
The main downsides of this are:
- fewer slots (2048 vs 4096)
- no key access linkage to HMAC auth on SCE
I *think* that's it.
Fewer slots - 2048 slots is still a lot of slots, about half are
used now, I think this is plenty.
Key access linkage to HMAC auth on SCE - I have reasons to
suspect this feature is broken anyways for subtle reasons
related to malleability of the HMAC round constants. Even
without that brokenness, it's hard to use HMAC auth to manage
the system because it requires per-device unique keys: so,
we're using a PKI scheme and no symmetric secrets to handle
access controls.
Removing the key slots also greatly simplifies the code
base analytically. This culling removes the key slot
abstraction the "simple" way, but without the weirdness
of the keyslots (in particular the key ID chaining which
makes them different from data slots) I could remove even
more abstractions and simplify the code.
One upside is now all elements can enjoy the write mode
behavior which can force the slot to be only 0->1 writeable,
which could be useful for other things down the road.
This was tested to not interfere with Dabao-Alpha 0
bootloaders.
this allows the OS to initialize the keys
note that including write access only gives it to the fw0 user,
which is the OS's secure user. thus any write primitive created
by this expansion of access should transitively also be a read
primitive (which is actually what the adversary desires).
In exchange the OS is allowed to initialize the keys, which
I think is the right place to do it given that it's too hard
at this point to nail down the exact key layout, etc.
Note that it is impossible for the OS to change ACLs - that is
a feature that can only be updated by the boot user - which
is why the boot user can change the ACL to gain access to
erase keys, but the OS user can't modify its own ACL.
Since in-system keying has to happen in the factory, it doesn't
add anything to burn it into the bootloader. Furthermore, the
access controls are already set up so that the keys can only
be accessed by the OS code.
