On Wed, 03 Feb 2021 17:26:11 +0900, Vincent MAILHOL wrote: > On Wed. 3 Feb 2021 at 15:42, Jimmy Assarsson <jimmyassarsson@xxxxxxxxx> wrote: > > > > > > Of course we might also provide some pump gun mode which just sends an error flag at some (any) time. > > > > As above. > > > > > But for what reason? > > > > Testing purpose, e.g if you develop software where you want to keep track of bus errors, this makes it possible to test such software in a controlled way. > > We also use this ourselves when testing the transitions ERROR_ACTIVE <-> ERROR_WARNING <-> ERROR_PASSIVE, for Rx. > > I think that there are two axes in this discussion: the attacker > point of view and the functional testing point of view. > > From the attacker point of view, you are mostly interested in > destroying the transmitter frames. > > For the functional testing, it is about covering the all the > aspects of the standard: make sure that all the TX and RX counters > are correctly incremented, test the transitions between the > different states and that for all offsets. And to confirm all > aspects, you might want to inject both the active and the passive > error flags and do it at all possible positions. > > That said, my vision on functional testing is an uneducated > guess. I never worked on that and my personal focus is more the > attacker point of view. Looking back to it, my first interest would be to fire N error frames, so to control other nodes' rx error counters. Controlling your own tx error counter makes less sense, I assume that if your chip is capable of triggering error frames on demand, then I also assume that the tx error counter detection is done right. destroying specific CAN frames sounds much like functional testing, and can be done much simpler by modifying the node that sends it and add some very ad-hoc test code to not send specific can frames at all. The attacker point of view indeed could require a more elaborate API, but I still doubt we can deliver what is required for attacking. Kurt
