netdev - Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1hclgm7dr.fsf@ebiederm.dsl.xmission.com>
Date:	Thu, 27 Sep 2007 09:54:08 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Urs Thuermann <urs@...ogud.escape.de>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Oliver Hartkopp <oliver@...tkopp.net>,
	Oliver Hartkopp <oliver.hartkopp@...kswagen.de>,
	Urs Thuermann <urs.thuermann@...kswagen.de>,
	Daniel Lezcano <dlezcano@...ibm.com>
Subject: Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

Urs Thuermann <urs@...ogud.escape.de> writes:

> This patch adds the virtual CAN bus (vcan) network driver.
> The vcan device is just a loopback device for CAN frames, no
> real CAN hardware is involved.

I'm trying to wrap my head around the CAN use of IFF_LOOPBACK.

>  6.2 loopback
>
>  As described in chapter 3.2 the CAN network device driver should
>  support a local loopback functionality. In this case the driver flag
>  IFF_LOOPBACK has to be set to cause the PF_CAN core to not perform the
>  loopback as fallback solution:
>
>    dev->flags = (IFF_NOARP | IFF_LOOPBACK);
>

Currently IFF_LOOPBACK set in dev->flags means we are dealing
with drivers/net/loopback.c. 

In other networking layers loopback functionality (i.e. for broadcast)
is never expected to be provided by the drivers and is instead 
always provided by the networking layer.  Keeping the drivers
simpler.  Further you already have this functionality in the
generic CAN layer for doing loopback without driver support.

So at a first glance the CAN usage of IFF_LOOPBACK looks completely
broken, and likely to confuse other networking layers if they see
a CAN device.  Say if someone attempts to run IP over CAN or
something like that.

Do you think you can remove this incompatible usage of IFF_LOOPBACK
from the can code?

If I have read your documentation properly the only reason you are
doing this is so that the timing of frames to cansniffer more
accurately reflects when the frame hits the wire.  If CAN runs over a
very slow medium I guess I can see where that can be a concern.  But
the usage of IFF_LOOPBACK to do this still feels fairly hackish
to me. 

Eric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html