[Cryptech Tech] cryptlib HAL for EIM

[Paul Selkirk]

The EIM version of the cryptlib HAL is done (the glue that lets cryptlib
talk to the cryptech cores over EIM). Actually, the first version was
done a couple weeks ago, but I neglected to post about it. It passes
'make test', which means it does some hashes and generates some RSA keys.

Yesterday I pushed a 'unimap' branch on the core/platform/novena and
sw/cryptlib repos. This does two things:

1) It unifies the EIM and I2C memory maps by giving up on the idea that
a register in a cryptech core should be represented by a physical memory
address in the API.

For instance, to get 4 bytes of random data from the CSPRNG, we go to
segment 2, core 0xb, register 0x20, or register number 0x4b20. In EIM,
this gets mapped to address 0x08022C80 (which is further translated to
an offset into a mmap'd memory page, down in the eim interface code).

There is an infinitesimal advantage in doing this register-to-address
translation in the preprocessor, but at the cost of maintaining two
separate memory map header files (one for eim, one for i2c), which in
turn means that applications need to conditionally include one or the
other header (or worse, maintain two divergent copies of the same app).

So, along with unifying the memory map, I've unified the APIs, so that
eim and i2c have exactly the same API, and there can be one copy of each
app that just links to the eim or i2c low-level code.

2) It builds and installs the interface code as a library (actually two
libs - one for eim and one for i2c). This is mainly for cryptlib, where
we had copies of the eim and i2c interface code.  This does create a
dependency between the core/platform/novena and sw/cryptlib repos, but
it was already there implicitly.

Questions:

(Mainly for Joachim and Pavel)
a) Does this unified memory map make sense to you? One thing that's lost
in the translation from 17-bit EIM addresses to 16-bit I2C addresses is
1 bit from the core selector (6 bits down to 5), but I don't forsee
having more than 32 cores in any given segment.

(Mainly for Rob)
b) Does the library build make sense to you? Note that this is a static
library with position-independent code for cryptlib, which is kosher AFAIK.
c) Since 'make test' only uses cryptlib's python interface, I hacked
GNUmakefile to patch build/bindings/setup.py. We might want/need a more
complete solution in the future, e.g. embedding libcryptech.a in
libcl.a, but I didn't want to go too far down that rat-hole on the first
pass.
d) The API functions are all tc_* (for "test case", from their origins
in hash_tester). It's probably time to rename them all to ct_* (for
"cryptech"), unless you have a better idea.

				paul