| Age | Commit message (Collapse) | Author |
|---|
|
This forces each hal_mkmif_* function to alloc/free the core, which is a
miniscule performance hit, but the only sane thing to do in a tasking
environment. Otherwise (with a stored/shared core pointer), one task will
initiate a read, yield in hal_io_wait, another task will initiate a read,
and both will be unhappy.
|
|
Static code analysis (Doxygen call graph) detected a low-probability
race condition which could have triggered a deadlock on the keystore
mutex if the mkmif code returns with an error like HAL_ERROR_CORE_BUSY
when we're trying to fetch the KEK.
This is a knock-on effect of the awful kludge of backing up the KEK in
the keystore flash as an alternative to powering the MKM with a
battery as called for in the design. This code path should not exist
at all, but, for now, we avoid the deadlock by making it the caller's
responsibility to grab the keystore mutex before looking up the KEK.
|
|
|
|
Whack masterkey code to meet libhal coding standards, such as they
are.
Started layout of new ks_flash data structures but no changes to
functions or flash usage yet.
MKM initialization from flash placed under compile-time conditional
with warning because it's a dangerous kludge that should go away.
Started getting rid of obsolete keystore code; ks_mmap.c kept for now,
until I get around to merging the useful bits into ks_volatile.
|
