| Age | Commit message (Collapse) | Author |
|---|
|
Passes minimal unit-testing and the same minimal tests report that it
does deliver the desired performance speed-up. More testing and much
cleanup still needed.
Attribute API not quite stable yet, we're probably going to want to
remove all the singleton attribute operations from the RPC protocol,
and it turns out that ks_delete_attributes() has enough code in common
with ks_set_attributes() that it makes more sense to handle the former
as a special case of the latter.
|
|
This is not yet complete, only the ks_volatile driver supports it,
ks_flash will be a bit more complicated and isn't written yet.
At the moment, this adds a complete duplicate set of
{set,get,delete}_attributes() functions in parallel to the earlier
{set,get,delete}_attribute() functions. We will almost certainly want
to get rid of the duplicates, probably (but not necessarily) the
entire single-attribute suite. At the moment, though, we want both
sets so we can compare execution speeds of the two sets of functions.
|
|
|
|
|
|
Result of running all these timing tests is about what theory would
have predicted: read time does not vary significantly between RAM and
flash, but write time sure does.
|
|
|
|
|
|
|
|
Watching the pinwheel makes it clear that the painfully slow execution
of test_attribute_bloat_flash_many() isn't a single hidously long
delay anywhere, rather it's a long steady stream of slow operations
and it's the cumulative time that's hurting us. Most likely this is
entirely dominated by flash write time, and suggests that it may be
worth the additional API and implementation complexity to handle
setting a complete set of attributes in a single operation, so that we
only have to pay the flash write toll once.
Will probably require further testing before we can make an informed
decision.
|
|
New test class to thrash the keystore attribute mechanism.
Added wrapper classes to encapsulate the more obscure bits of the
multiple Python public key APIs we're using in a single uniform API,
which lets us simplify some of the tests considerably.
|
|
ks_set_attribute() was written before hal_ks_index_fsck(), and was
violating the latter's assumptions for no particularly good reason.
Writing out new chunks in the expected order is no more work, and
simplifies the consistency checks, so do it that way.
|
|
ks_name_cmp() was reporting inverted order when comparing two names
which differ only by chunk number.
hal_ks_index_fsck() was both broken and more complex than needed.
|
|
|
|
|
|
|
|
|
|
|
|
pkey_get_attribute() wasn't passing value_max, resulting in an XDR error.
XDR encoding of built-in types now uses isinstance() rather than
playing nasty games with the string names of base types.
|
|
Incidental minor refactoring of hal_rpc_server_dispatch().
|
|
PKey objects can now be used as context managers, in which case the
key handle will be closed when the block exits.
HSM.pkey_find() now returns a generator which will iterate through the
full set of results, making additional RPC calls as necessary.
NIST ECDSA test vector test refactored to remove duplicated code.
|
|
Old calling sequence didn't quite work, caller had no sane way to know
how large the buffer needed to be. Revised sequence is similar to
what the PKCS #11 C_FindObject() call does: return the next batch of
UUIDs, up to the number specified, end of data indicated by getting
back something less than a full block of UUIDs.
|
|
|
|
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 rpc_server code used to bypass the public API calls by using the
RPC dispatch vectors directly, but doing so bypasses various checks
for trivial argument errors. It's not safe for the HSM to trust the
client to check these, and duplicating the checks in the client and
server code is error prone, so the best solution is for the server
code to dispatch via the public API, as it was originally designed to
do, and not try to micro-optimize the dispatch calls.
|
|
|
|
|
|
This is very incomplete. Portions of it are still verbatim copies of
the PKCS #11 unit tests, and have not yet been pruned for relevance,
much less converted to the corresponding libhal tests.
|
|
|
|
Pure-remote-mode (where even the hashing is done in the HSM) did not
work, because XDR passes zero length strings rather than NULL string
pointers. Mostly, we use fixed mode, so nobody noticed.
|
|
|
|
This is more complicated than I'd have liked, because the PKCS #11
semantics are (much) more complicated than just "are you logged in?"
New code passes basic testing with libhal.py and the PKCS #11 unit
tests, but there are still unexplored corner cases to be checked.
Private token objects remain simple. Code which does not need PKCS
HAL_KEY_FLAG_TOKEN and avoid HAL_KEY_FLAG_PUBLIC.
|
|
In retrospect it's obvious that this never needed to be an
input/output argument, as its value will always be the same as the
last value in the returned array. Doh. So simplify the RPC and call
sequence slightly by removing the unnecessary output value.
|
|
Intent is to make it easier just to paste C enum definitions into
Python code and have the right thing happen, to simplify keeping C and
Python definitions in sync.
|
|
Using a context manager allows us to write the individual RPC methods
fairly legibly, while still enforcing xdrlib.Unpacker.done() logic.
Python doesn't really have enums in the sense that C does, and many
people have put entirely too much skull sweat into trying to invent
the Most Pythonic reimplementation of the enum concept, but an int
subclass with a few extra methods is close enough for our purposes.
|
|
|
|
|
|
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.
|
|
Mostly this is another checkpoint (still passes PKCS #11 "make test").
ks_volatile.c now contains support for per-session object visibility;
this may need more work to support things like a CLI view of all
objects regardless of session. Adding this required minor changes to
the keystore and pkey APIs, mostly because sessions are per-client.
ks_volatile.c also contains an untested first cut at attribute
support. Attribute support in ks_flash.c still under construction.
|
|
RPC calls which pass a pkey handle don't need to pass a session
handle, because the session handle is already in the HSM's pkey slot
object; pkey RPC calls which don't pass a pkey argument do need to
pass a session handle.
This change percolates down to the keystore driver, because only the
keystore driver knows whether that particular keystore cares about
session handles.
|
|
|
|
This is mostly to archive a commit where PKCS #11 "make test" still
works after converting the ks_volatile code to use SDRAM allocated at
startup instead of (large) static variables.
The attribute code itself is incomplete at this point.
|
|
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).
|
