[Cryptech Tech] IO interface (was Re: Incremental digest outputs)
Russ Housley
housley at vigilsec.com
Tue Nov 18 21:10:31 UTC 2014
>> But what we could discuss is if the register based, memory like access
>> is what we want as API between SW and HW. Or if it instead should be
>> more command+data. It is quite possible that SW talks to the HW by
>> writing to a single address. And what is written is formatted into
>> packets with commands and data which then has to be parsed by the HW.
>
> Yeah, this is where I'm not really sure what is the right way to go.
>
> Eg, if we were just talking about what's most convenient for C code,
> the representation that might make the most sense for a memory-mapped
> implementation might be to map an entire block so one could just
> memcmp() complete blocks in one go, similarly map the entire output
> digest so one could memcmp() the result out. Control registers might
> be mapped directly; separating these into read-only and write-only
> might be easier to get right, as read-write control registers would be
> potential race conditions even when using C's "volatile" type
> qualifier. I would like to think that we can avoid byte swapping. :)
>
> But if it turns out that it's simpler to do some kind of command +
> data interface, that's probably OK too, and the semantics might be
> better. Still would prefer that the data in and out be simple byte
> strings, preferably complete blocks where that makes sense.
>
> If you think I'm nuts about the simple byte strings, say so. I'm
> trying to avoid a lot of complicated data shuffling that it sounds
> like the core Verilog code doesn't really need, but if it turns out
> that I'm just transferring pain from C to Verilog we may want
> something else.
I am most familiar with command+data interfaces. This maps easily to PKCS#11 and MS CAPI.
I am familiar with some command+data interfaces that allowed command chains so that the result of once command could be operated on bay another. This is especially useful for hash-and-then-sign, but it is often impossible to take advantage of these chains from above the PKCS #11 or MS CAPI where the real applications live.
Russ
More information about the Tech
mailing list