[Cryptech Core] about that agenda

[Rob Austein]

Peter,

Taking this out of order:

At Sat, 29 Jul 2017 19:00:37 +0000, Peter Stuge wrote:
> 
> And should I make and bring more daughterboards, assuming firmware works?

Unclear, depends on what we decide about current vs different
hardware.  You are of course welcome to bring boards, IIRC even most
of the core team don't have them yet, I just don't want you to put a
lot of effort into this then feel afterwards that we wasted your time.

> My goal is to have a rewritten functional USB firmware for my daughterboards
> in Stockholm at the latest. That's still USB-serial. Maybe we want to talk
> about Host<->HSM USB protocols f2f?

Well, the big thing with USB on my priority list at the moment is that
Paul is still having trouble getting reliable behavior out of the USB
hardware we've already got.  Seems likely to be a driver problem.  We
never did really get your daughterboards running, which we all
(including you, I think) concluded was also likely a driver problem.

Current state as I understand it is that, having ditched the RTOS
(good riddance) in favor of cooperative multitasking, we can operate
reliably with two RPC clients talking through the MUX, which is good
enough to support OpenDNSSEC.  Once we push much past that point,
though, we start seeing data corruption again, and last I heard all
the available evidence still pointed towards a driver issue.

(The reason the number of clients matters in the above is simple: each
client has its own request/response queue, so with a single client the
HSM is basically just answering queries in lock step, and the HSM
isn't doing anything else while it's doing I/O.  With two or more
clients there can be I/O activity while the HSM is working on other
things, so the higher the number of clients, the more likely there
will be I/O while the HSM is busy, which is when we see problems.)

To me, resolving the corruption problem is more critical than (eg)
changing from the silly UART model to something that speaks more
native USB on the HSM.  I don't strongly object to considering changes
to how we handle USB on the HSM if doing so will solve this problem,
but changing the USB model for its own sake is not as high a priority
for me.

Off in userland on the client side, everything currently assumes it's
talking to something that acts like a UART.  We can change that, if
necessary, but it's not something to do lightly.  If we do go that
path, given our experience with client OS issues with UARTs, I'd
probably want to use something like PyUSB with whichever underlying
library you recommend, so that we can keep all the "how do we talk to
the HSM?" voodoo encapsulated in one piece of Python code (the MUX).

I realize that you have strong feelings about some of this, and that
our opinions on relative priorities may differ here.

I'm putting this onto the mailing list now because the corruption
problem seems like something on which we'd like to make progress
before the September meeting.  I'd suggest that you and Paul talk
about it ASAP, except I know he has a family holiday coming up Real
Soon Now, so I doubt he'll have time to do much about this until he
gets back.  But maybe the two of you can sync up before he leaves, if
there's time.  Up to you guys.

> (There's a simpler design for production; Atmel SAMD11C 14-pin Cortex-M0
> for <1EUR at 1qty with hard USB and clock recovery from USB host; no crystal.
> Different USB stack, but MIT licensed code exists. Only flashable via SWD,
> which is probably a feature. :)

Cool.