| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
* block_status is now a separate field from block_type, rather than
being a composite value.
* block_status is checked directly for allowed values in block_read(),
and is excluded from the CRC, simplifying the tombstone logic and
removing the need for a second CRC field.
* Added header fields to allow for objects too large to fit in a
single block (8192-bit RSA keys, any key with enough opaque
attributes attached). So far this is just the header changes, it's
not (yet) full support for multi-block objects.
|
|
Order of operations is tricky when updating flash blocks, because the
process is not atomic and we want to leave the index in a consistent
state if something fails.
|
|
|
|
|
|
block_read() no longer needs `fast` argument.
block_zero() now just zeros first page of block.
|
|
Running this check in constant time probably isn't necessary, but it
plugs a (somewhat far-fetched) timing leak and is easy enough. While
we're at this, we also skip the CRC check, which is irrelevant here.
|
|
|
|
Also bring error checking in line with other modules.
|
|
|
|
|
|
|
|
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.
|
|
This is an open source C99 CRC-32 implementation generated by pycrc,
see notes in source on copyright status and pycrc options used.
crc32.c contains two different implementations of the CRC-32 algorithm
with the same API, one optimized for speed, the other optimized for
much smaller code space at the expense of speed. We use the fast
implementation by default, but maybe the small implementation will be
useful, eg, in the bootloader. Remove the extra later if this turns
out to have been a waste of time.
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
Now that key names are UUIDs generated by the HSM, there's no real
need to specify type key type when looking up a key, and removing the
`type` argument allows a few simplifications of both the internal
keystore API and of client code calling the public RPC API.
|
|
|
|
New keystore code requires slightly different cleanup to avoid leaking
pkey handle table slots. Pricetag for reducing the amount of data
duplicated between pkey and keystore layers.
|
|
|
|
|
|
Includes a few cosmetic fixes to address gcc format string warnings
and git trailing whitespace warnings.
|
|
Fixes for various minor issues found while integrating with sw/stm32.
Moving the in-memory keystore (PKCS #11 session objects, etc) from the
client library to the HSM was on the near term to-do list in any case,
doing it now turned out to be the easiest way to solve one of the
build problems.
|
|
Changes to implement a revised keystore API. This code probably won't
even compile properly yet, and almost certainly will not run, but most
of the expected changes are complete at this point. Main points:
* Key names are now UUIDs, and are generated by the HSM, not the client.
* Keystore API no longer assumes that key database is resident in
memory (original API was written on the assumption that the keystore
flash would be mapped into the HSM CPU's address space, but
apparently the board and flash drivers don't really support that).
A few other changes have probably crept in, but the bulk of this
changeset is just following through implications of the above, some of
which percolate all the way back to the public RPC API.
|
|
|
|
Current design of the RPC protocol assumes that there is exactly one
client speaking directly to the HSM via the RPC channel, whether that
single client really is single or is a multiplexing daemon. PKCS #11
mutexes won't help here, so using flock(2) to grab an exclusive
"advisory" lock on the RPC file descriptor is the simplest solution.
|
|
|
|
|
|
|
|
PKCS #11 expects a DigestInfo rather than a raw digest when passing a
pre-computed digest for PKCS #1.5 signature or verification, so the
rpc_pkey signature and verification calls do too. This requires
special case handling of RSA when the user passes a digest handle in
mixed mode. Annoying, but PKCS #1.5 is weird enoug that there's no
way to avoid some kind of special case handling, this approach has the
advantage of not requiring us to parse and reconstruct the ASN.1, and
is probably what PKCS #11 has trained software to expect in any case.
|
|
err = hal_foo() || hal_bar() || hal_baz;
maps all errors to 1 (HAL_ERROR_BAD_ARGUMENTS).
|
|
See, reading from an unconfigured FPGA returns all-1, while reading from
empty cores on a configured FPGA returns all-0. The consequence of this is
that the HSM was probing the FPGA once on startup, filling its core table
with 0xff, rendering the FPGA useless.
Along the way, I put the FPGA core table in static memory, rather than
malloc'ing it, because that's not so good in an embedded environment.
But I kept the linked list, because that at least tells us what to do if
HAL_STATIC_CORE_STATE_BLOCKS is 0.
|
|
|
