[Open Crypto Project] #63: RPC does not recover gracefully from lost synchronization

Open Crypto Project trac at cryptech.is
Thu Jul 7 17:03:31 UTC 2016

#63: RPC does not recover gracefully from lost synchronization
 Reporter:  sra     |       Owner:
     Type:  defect  |      Status:  new
 Priority:  major   |   Milestone:  Alpha board DNSSEC signer
Component:  HAL     |     Version:
 Keywords:          |  Blocked By:
 Blocking:          |
 If RPC client and server are not in lock step, we do not recover
 gracefully.  Eg, if one sends non-RPC bytes down the serial port before
 hooking up client and server (eg, because one is probing the serial port
 to find out which one it is), client and server get confused and do not
 recover without help.

 We're using SLIP framing, which should bracket any bogus bytes as an
 invalid packet, so client should just be able to check the opcode in the
 response to see if it matches what it was expecting, and, if not, discard
 the packet.

 Server (HSM) side seems to get confused too, though, haven't been through
 that with gdb yet to figure out exactly what's failing.  In experiments to
 date I've had to use the console to reboot the HSM to recover from this.

 Sample failed exchange, after using `cryptech_probe` to identify ports.
 Client sends:

 passing to serial port:
 00 00 00 03 00 00 00 05
 00 00 00 02 00 00 00 05
 66 6e 6f 72 64 00 00 00

 Client receives:

 serial port received response:
 40 00 44 00 20 01 36 3c
 00 00 00 1d

 Client fails to recover from this.  If one restarts client (sending same
 message again, see above), server never responds, so have to reboot HSM,
 after which everything works fine.

 Attaching to Berlin workshop milestone because this could be annoying
 during the workshop.

 First (easy) patch is to teach `cryptech_probe` to send more tailored
 nonsense down the RPC channel after identifying it, to clean up after the

 Second (probably still easy) patch is to teach RPC client code to check
 for the expected opcode and discard malformed or unexpected packets.

 Don't yet understand what's going on in the HSM well enough to know what
 the fix is there.

Ticket URL: <https://trac.cryptech.is/ticket/63>
Open Crypto Project <https://wiki.cryptech.is/>

More information about the Ticket-BCC mailing list