[Cryptech Core] about that agenda

[Rob Austein]

At Fri, 4 Aug 2017 12:41:44 +0000, Peter Stuge wrote:
...
> > 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?

No.  It was under development shortly after that workshop, and has
been the normal way to connect to the HSM since the 3.0 code.

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

The top-level UART is in sw/stm32/projects/hsm/hsm.c, using library
routines elsewhere in the stm32 library swamp.  Yes, it has a buffer,
and I think it's interrupt driven most days of the week, but Paul has
tried various approaches and would be a better source of information
for what it is today.

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

The MUX tags messages with a "client handle".   At the moment, that's
a 32 bit integer, the rough outline for a secure channel says that'll
likely turn into a key hash or some such.  In any case, the HSM just
knows that different client identifiers mean different clients.

> Is there a queue in the muxd?

In effect, although it's implemented by refusing to accept further
input from the client until the current request completes.

> Is there a queue in the STM32?

Not that I recall.

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

Yes, with the understanding that this is "cooperative multitasking"
(basically, co-routines with task swapping) rather than preemptive
multitasking.  There's a configured limit to the number of these we
support, but we run into problems long before we hit that limit.

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

Overall, the MUX actually simplifies the architecture, since it
isolates all the "how do I talk to the HSM?" voodoo in one place, so
we'd probably keep it.  But not worth worrying about at this point.

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

After http://www.worldcon.fi/