Hi Kurt,
On Tues 4 Feb. 2021 at 05:06, Kurt Van Dijck
<dev.kurt@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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.
It is slightly more complex.
Let's consider three nodes all on the same bus.
A: Test node, sends error flags
B: Normal node, send normal frames
C: Normal node, only receiving
___ ___ ___
| _ | | _ | | _ |
||A|| ||B|| ||C||
|___| |___| |___|
| | |
| Sends | Sends | Only
| error | normal | receives
| flags | frames |
| | |
--------------------------------------- CAN bus
A waits for B to start sending its frame and trigger the error
flag. This error flag will eventually overwrite one of B's recessive
bit into a dominant one and thus B has his TX error count increased.t
C who is a spectator will just have its RX error count increased.
The error count of node A is kind of undefined because the standard
does not expect you to generate your own errors. By default, I think
node A should *not* increase its counter if the error flag is generated
by itself on purpose so that it is free to mess on the bus as much as it
wants without going bus-off.
So sending error frames can increment either the TX or RX error
counters depending if the node is in transmitting or receiving at the
moment the error flag occurs.
> 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.
Any use cases toward your own chip (e.g. increasing your own TX
counter) is also not my interest. My idea of injecting the error flags
on your own frame is just to cover the error passive flag use cases in
order to see if *other* frames correctly handle the error passive
flag.
Passive error flags are indeed an edge case and if there is a
consensus that this feature is not needed (which seems to be the
case), I have no objection to not having it.
> 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.
This is interesting because we have an opposite view of the attacker
and functional testing approaches.
For the attacker, I am thinking of:
https://youtu.be/oajtDFw_t3Q
In a nutshell, it is an elaborate technique in which you first DoS the
target node by increasing its TX counter until it gets in bus-off
state. Once done, the attacker can send messages in place of
the genuine node. This way, contrary to an simple injection attack
on which the bus contains both the genuine and the attacker frames,
here, only the attacker speaks on the bus.
This attack does not really care when the error flag occurs as long as
the error counter increases.
My vision of the functional testing is more: does the controller
react correctly in all situations? You could imagine an implementation
issue that would cause the error count to not correctly behave only on
a specific field. How would you test for such implementation issues
other than injecting the error flag at each offset of the frame?
Yours sincerely,
Vincent
