[Cryptech Core] about that agenda

[Peter Stuge]

Hi,

Rob Austein 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.

Making a couple of boards isn't a lot of effort, so I think I'll do that,
to get most of the core team equipped.


> > 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.

Oh! Didn't know that. Yes, I would be happy to work with Paul on this.


> We never did really get your daughterboards running, which we all
> (including you, I think) concluded was also likely a driver problem.

I did limited testing and had no issues. I remember you reporting that
with "larger" amounts of data (>64 bytes or so) there was data loss
with my daughterboard. I believe this to be an issue in the
daughterboard firmware, which I want to rewrite before f2f.


> 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,

Hmm, I think I've missed this mux. Was it used in the Berlin workshop?

My last state was librpc.


> (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.)

This is indeed important to resolve!

I don't see why serial I/O on the STM32 should ever cause a problem,
assuming that the UART code is interrupt driven with some buffering.
Do you or Paul know if that is the case?


> 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.

I agree on the order of this, and that if one helps fix the other
then that's a good opportunity/reason to do both, but getting it
reliable is the top priority.

Let me ask this: How does the STM32 separate RPC calls from two (or more)
mux clients?

Is there a queue in the muxd?

Is there a queue in the STM32?

Are there no queues, and the STM32 starts a new "thread" for each
incoming call?


> 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).

Yes indeed, with a different USB protocol pyusb1 (I think it's called)
would be exactly right for Python code such as the mux.

But changing the protocol might also allow simply removing the mux.
It depends on how the STM32 code works at the moment. Note that I
don't want to change the STM32 too much, just to get reliable I/O,
but I also don't want to completely exclude the possibility before
knowing the code better.


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

I think we are well aligned.


> 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.

Cool, yes. I can easily do email, IRC, mumble (open source voice chat)
Paul - what's good for you?


//Peter