netdev - Re: [PATCH ethtool] ethtool: Add support for WAKE

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: <56447ed2-c441-81e5-3219-b2f6329366d1@gmail.com>
Date:   Fri, 3 Aug 2018 10:57:13 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, linville@...driver.com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com
Subject: Re: [PATCH ethtool] ethtool: Add support for WAKE_FILTER

On 08/01/2018 09:32 AM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@...il.com>
> Date: Mon, 30 Jul 2018 15:26:24 -0700
> 
>> On 07/17/2018 08:36 AM, Florian Fainelli wrote:
>>> Allow re-purposing the wol->sopass storage area to specify a bitmask of filters
>>> (programmed previously via ethtool::rxnfc) to be used as wake-up patterns.
>>
>> John, David, can you provide some feedback if the approach is
>> acceptable? I will address Andrew's comment about the user friendliness
>> and allow providing a comma separate list of filter identifiers.
>>
>> One usability issue with this approach is that one cannot specify
>> wake-on-LAN using WAKE_MAGICSECURE *and* WAKE_FILTER at the same time,
>> since it uses the same location in the ioctl() structure that is being
>> passed. Do you see this as a problem?
> 
> Once again we are stuck in this weird situation, a sort of limbo.
> 
> On the one hand, I don't want to block your work on the ethtool
> netlink stuff being done.
> 
> However it is clear that by using netlink attributes, it would
> be so much cleaner.
> 
> I honestly don't know what to say at this time.  I wish I had
> a clear piece of advice and a way for everyone to move forward,
> and usually I do, but this time I really don't :-/
> 

That's fine, let me submit the first few patches that are per-requisite
but don't actually introduce the WAKE_FILTER support. Once Michal's
ethtool/netlink work gets merged I can quickly extend that in a way that
supports wake-on-LAN using configured filters.

Does the current approach of specifying a bitmask of filters looks
reasonable to you though?
-- 
Florian