1
\$\begingroup\$

I have understood the CAN error handling but I am confused about whether these error handling mechanisms are implemented in software or hardware of CAN controllers.

More specifically I want to know where the overload frames part of CAN 2.0 specification is implemented. If a hijacked/re-programmed ECU wanted to DoS the CAN bus via overload frames but according to the CAN specification only 2 OFs can be sent by a node. So where is this counter implemented? If it is just a register then it can be overwritten the same way other DoS exploits using error frames on CAN bus have been doing till now right? But if it is some internal circuit seeing that 2 frames were sent and then turns off overload frame circuitry then we can't help it right?

Also if OF is implemented in hardware, does it mean we can't generate them using software directly?

Also what about this whole thing in MCUs with integrated CAN Controllers, is it a hardware based implementation there too?

In all, please just let me know what aspects of CAN Specification are implemented in hardware directly and what in software. Thank you.

P.S. I didn't find any code in open-source RTOS projects CAN drivers(MCP2515) that handle overload frames, but I am pretty bad at C programming too so I might have missed it, please help a fellow out.

\$\endgroup\$
4
  • \$\begingroup\$ In practice I don't think any modern CAN controllers utilize overload frames. According to Kvaser, only the nowadays ancient Intel 82526 controller ever used it. So the answer to your question "where the overload frames part of CAN 2.0 specification is implemented" is: nowhere. \$\endgroup\$
    – Lundin
    Commented Nov 26 at 9:54
  • \$\begingroup\$ And the general protection against "DoS" is to not connect your goddang safety-related CAN network to the bloody Internet... Anyone doing that needs to be fired from the system design job. \$\endgroup\$
    – Lundin
    Commented Nov 26 at 9:58
  • \$\begingroup\$ @Lundin Well, what about the error frames are they implemented in hardware too? Or are they controlled by software/firmware? \$\endgroup\$
    – suds4131
    Commented Nov 26 at 13:24
  • \$\begingroup\$ Everything the CAN controller does is implemented in hardware. No sane person would re-invent the wheel by attempting to implement a CAN controller in software by using "bit-banging". \$\endgroup\$
    – Lundin
    Commented Nov 26 at 13:32

1 Answer 1

Reset to default
0
\$\begingroup\$

Overload frames (i.e: "I'm too busy, try again in a bit") are quite uncommon in modern CAN networks, as devices are now fast enough to keep up. From what I understand, not many (any?) modern implementations will produce them...

I am confused about whether these error handling mechanisms are implemented in software or hardware of CAN controllers.

Almost all of the CAN interface is implemented in hardware - software can request that a message is sent, and will get an interrupt when an incomming message is available.

If a hijacked/re-programmed ECU wanted to DoS the CAN bus [...]

One of the major selling points of CAN, is that it's very hard for faulty firmware to negatively impact the bus... there's nothing to stop you from wiggling a GPIO pin in just the right way, but that's an egregious configuration error.

according to the CAN specification only 2 OFs can be sent by a node. So where is this counter implemented?

Specifically, the spec says "At most two OVERLOAD FRAMEs may be generated to delay the next DATA or REMOTE FRAME." ... i.e: upto 2x may be generated immediately one-after-another (if you're really, really overwhelmed by the influx of data), after which you'll just have to miss the next message. More may be generated at some later time.

The CAN peripheral will recieve data from the bus, place it into a buffer, and notify the firmware. If the firmware doesn't come and remove that data in time, then an overload frame might be produced, because it has nowhere to place any additional incoming data (check your specific documentation, modern devices are fast and have multiple mailboxes). The counter is deep in the CAN peripheral, and prevents an infinite series of overload frames (e.g: if the firmware never removed the data).

Also if OF is implemented in hardware, does it mean we can't generate them using software directly?

Correct. As above, it's not something the firmware cares about or needs any control over.

Also what about this whole thing in MCUs with integrated CAN Controllers, is it a hardware based implementation there too?

"This whole thing"? I'm not aware of any valid CAN controllers implemented in software...

\$\endgroup\$
8
  • \$\begingroup\$ Hey, by integrated CAN controllers I mean MCUs which directly have CAN Tx and Rx pins integrated into them. These types of MCUs specifically. Also there is some previous research describing these MCUs with integrated CAN controllers being used to DoS the CAN bus. Link1 Link2. Both of the linked papers use vulnerabilities in the CAN spec and need a MCU with integrated CAN \$\endgroup\$
    – suds4131
    Commented Nov 26 at 13:21
  • \$\begingroup\$ Ah, apoloiges - if you're comparing integrated CAN controller vs SPI (for example), then there is no real difference, aside from the potential to configure the pins as GPIO. \$\endgroup\$
    – Attie
    Commented Nov 26 at 13:29
  • \$\begingroup\$ Thanks for the links, I'll have a read... but this would almost certainly be a directed / malicious action, and should be protected against by correct / valid node implemetation. A CAN bus isn't designed to be a public network for people to connect random devices to, especially not in critical / safety systems like vehicles. \$\endgroup\$
    – Attie
    Commented Nov 26 at 13:31
  • \$\begingroup\$ @Attie The "clever" people in charge of the Machinery Regulation seem to disagree. They demand that everyone implements "cybersecurity-something-something" which they don't even know what it means themselves. But a consequence of this EU nonsense could be enforcing encryption of CAN traffic and similar. All thanks to the "clever" would-be engineers at Jeep who connected an Internet bootloader with firmware updates directly to a MCU on their safety-related CAN bus. And therefore all real engineers have to suffer nonsense EU requirements yet to be determined. \$\endgroup\$
    – Lundin
    Commented Nov 26 at 13:39
  • \$\begingroup\$ @Lundin sigh ... yes, fair point... I'm unsure how encrypted messages would help with DoS type attacks, but it would certainly make a lot of things harder! Lets hope there's some integrity validation paired with that encryption. \$\endgroup\$
    – Attie
    Commented Nov 26 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.