UAVCAN/serial: issues with DMA friendliness and bandwidth overhead

[pavel.kirienko]

@VadimZ

a security metaphor breaks down here. Malicious attacker would be able to forge the CRC and slip in any bad data undetected in any protocol implementation short of PKI. Denial of service with intentionally large packets similarly out of the scope, and exists in stuffing option as well

I think this is incorrect. The extra CRC does protect against length corruption but it does not protect against malicious frames, unlike the transparent channel option.

Let us define a maliciously constructed frame as a frame whose payload is a valid frame itself which, if interpreted by the parser, may lead to undesirable consequences (such as a denial of service caused by a long length).

Any approach that does not offer strict separation of control symbols from data symbols is susceptible to this condition because one can trivially construct a frame and embed it into the payload knowing that the protocol will forward it verbatim. The approach based on byte stuffing is robust against this condition because it guarantees that a control-symbol cannot occur in the data section. Reception of a control-symbol forces the parser state machine to unconditionally begin a new frame, hence its behavior is simpler and easily predictable.

Let us review your DMA issues and see if there is a sensible way to implement the transparent channel while avoiding excessive computational load on the MCU. Could you please describe in detail what desirable aspects of the implementation are unattainable with the current approach?

Also, regarding the variable overhead: if Scott Dixon was here, he would have certainly said that the variable overhead inherent to the byte stuffing may cause undesirable control coupling because the temporal properties of data transmissions become dependent on their contents:

@scottdixon

@pavel.kirienko

Such augmentation allows one to reconstruct orthogonal dimensions without knowledge of the specific data type definition, thus eliminating the undesirable coupling.

The problem is we are trading data-coupling for control-coupling. In a hard-realtime system the latter is less desirable and even fatal.

I haven’t given much thought to that yet and I am not sure how critical this issue is but one possible way to mitigate this is to always enforce 100% overhead regardless of the payload. For example, one radical solution would be to make the protocol text-based like NMEA-0183, exchanging data in printable hexadecimal characters. This is not meant to be a proposal, I am aware of the performance-related costs, but we need to be aware of this option.