| Age | Commit message (Collapse) | Author |
|---|
|
The debugging code was for tracking down what turned out to be a race
condition in the Alpha's flash driver code (see sw/stm32); much of
this was temporary, and will be removed in a (near) future commit, but
some of the techniques were useful and belong in the repository in
case we need to pull them back for something similar in the future.
hal_ks_index_fsck() attempts to diagnose all the things I found wrong
in the ks_flash index after one long series of errors. As presently
written, it doesn't attempt to fix anything, just diagnose errors: the
intent is that we can call this, before and after every modification
if necessary, to poinpoint exactly which calls introduce errors. Once
things stablize a bit, we may want to crank down the number of calls
to this (it's a bit expensive, since it checks the entire index), and
perhaps add the ability to clean up whatever errors it might find; the
latter might be a good candidate for a CLI command.
|
|
The filtering code for this function has not been tested yet.
|
|
hal_rpc_pkey_match() still untested.
|
|
|
|
Passes PKCS #11 "make test" but nothing uses the new attribute code yet.
Refactored some of the flash block update code.
Attribute code is annoyingly verbose, might be possible to refactor
some of that.
|
|
The main reason for supporting multi-block objects is to allow the
PKCS #11 code to attach more attributes than will fit comfortably in a
single flash block. This may turn out to be unnecessary once we've
fleshed out the attribute storage and retrieval code; if so, we can
simplify the code, but this way the keystore won't impose arbitrary
(and somewhat inscrutable) size limits on PKCS #11 attributes for
large keys.
This snapshot passes light testing (PKCS #11 "make test" runs), but
the tombstone recovery code in ks_init() is a bit involved, and needs
more testing with simulated failures (probably induced under GDB).
|
|
|
|
|
|
|
|
Binary search of an array is a notorious example of a simple algorithm
which is hard to get exactly right. The variant we're using is nice
because it automatically computes the correct insertion point when a
key doesn't exist, but runs into one of the portability corner cases
of signed integer arithemtic in C. Rather than leave a landmine
waiting to explode if somebody builds this code on a platform where
(-1 >> 1) != -1, we test for the corner case explictly and accept the
miniscule performance hit (which will be lost in other noise anyway).
|
|
|
|
|
