| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change allows the RPC MUX daemon to use the same environment
variable scheme to configure the RPC device and line speed as the
stand-alone RPC client code does, the only difference being that the
daemon, being an independent program, still allows one to override
these settings from the command line.
|
|
obscure.
|
|
|
|
This is a hopefully temporary stopgap, in lieu of proper resource
management and/or sharing of cores between threads.
|
|
|
|
|
|
|
|
|
|
Find a suitable core, and mark it busy. Don't forget to release it as soon
as you're done. This has a knock-on effect of un-const'ing core arguments
and struct fields in a lot of places, and it moves some core checks around.
|
|
|
|
|
|
tcsetattr().
With this change, we appear to have working libhal client code on Mac OS X.
|
|
|
|
Too many recent tweaks to same few lines of this Makefile for a
straight merge to work; fortunately, the obvious simplification should
also work as a fix for the most recent problem.
|
|
|
|
|
|
client handle in all responses.
This simplies the daemon a little, and means that the directly-connected
serial client uses the same wire format as the daemon. The expense is some
redundant code in rpc_client and rpc_server to process (and throw away)
this extra stuff.
|
|
Includes preliminary support for the magic Mac-specific ioctl() to see
line speed, but has not yet been tested, that's waiting for some
supporting tweaks to the RPC code from Paul.
Includes some general cleanup which isn't really specific to Mac OS X
per se but which needed doing and which simplifies adding the Mac code.
|
|
|
|
|
|
can find tfm.h again.
|
