netdev - Re: [RFC PATCH] Ethtool style in kernel network driver configuration.

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: <4A335A8A.5080907@gmail.com>
Date:	Sat, 13 Jun 2009 09:51:38 +0200
From:	Martin Fuzzey <mfuzzey@...il.com>
To:	David Miller <davem@...emloft.net>
CC:	bhutchings@...arflare.com, nico@....org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] Ethtool style in kernel network driver configuration.

David Miller wrote:
> I misunderstood the problem, thanks for asking me to clarify
> this.
>
> I thought the issue was the "in the environment where his devices
> would be used" he wanted to force a certain link speed and duplex
> setting.  In that case, forcing the link via ethtool is appropriate
> because it's an attribute of where the device is connected.
>   
Well I thought my initial post (in the smc91x force speed thread before
this patch was written) was quite unambiguous as to my motivation :

I am using the SMC91x driver on a based ARM board that has a hardware
problem causing 100Mbps mode not to work (even though the PHY
negotiates to that speed).

That being said even if this is _my_ use case the facility is equally
useful for the use case you understood (and yes you could use ethtool
from userspace/initramfs/initscript to do that but you've already
accepted the idea of an in kernel ethtool for the "environment" case).
> But the situation is different, the physical hardware has a limitation
> and know of this belongs, or should be described, in the driver
> somehow.
>   
Theoretically I agree. However the only practical advantage I can see of
doing it in the driver is that it is then impossible to later re-enable
broken modes. The proposed patch would allow you to later mess up
networking but requires :
1) ethtool installed on the device
2) root access to the device

If you have root access there are all manner of ways you can mess up the
system and breaking networking probably comes quite a way down the list.

If you want to do it in the driver for this usecase either it's back to
everyone for himself quick hacks or we need to add an interface to _all_
the drivers. How long would that take? How long did ethtool take? Given
the trouble this very non intrusive patch is having would you really
accept a patch to all the network drivers for this? I for one wouldn't
do it as I don't have all that hardware to test.

Even if we did go the "purist" route and add an interface to all the
drivers this patch would still be useful for the other usecase (the one
you understood).

So my argument is that while this patch is not the purist solution for
my usecase I consider it an acceptable solution (better than hacks) and
a good solution for other usecases.

Martin

--
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