netdev - Re: [PATCH net-next RFC 7/7] bnxt_en: Add bnxt_en initial port params table and register it

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]

Date:   Thu, 6 Dec 2018 03:00:12 -0800
From:   Michael Chan <michael.chan@...adcom.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Vasundhara Volam <vasundhara-v.volam@...adcom.com>,
        David Miller <davem@...emloft.net>,
        Jiri Pirko <jiri@...lanox.com>, Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next RFC 7/7] bnxt_en: Add bnxt_en initial port params
 table and register it

On Thu, Dec 6, 2018 at 2:37 AM Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
>
> On Thu, 6 Dec 2018 00:57:05 -0800, Michael Chan wrote:
> > On Wed, Dec 5, 2018 at 11:11 PM Jakub Kicinski wrote:
> > >
> > > On Wed, 5 Dec 2018 22:41:43 -0800, Michael Chan wrote:
> > > >
> > > > It will be in the BIOS only for a LOM, I think.  For a NIC, it should
> > > > be in the NIC's NVRAM.
> > >
> > > This is all vague.  Could you please clearly state the use case.
> > >
> > Well, the WoL setting's use case should be quite simple, right?  If
> > the card's NVRAM WoL setting is ON, when you plug the card in a slot
> > that has Vaux power, it will assert PME# when a magic packet is
> > received.  Again, the WoL setting in this context is similar to other
> > power up settings such as PCIe Gen2 or Gen3.
>
> If there was some configuration of PME# involved, maybe, but
> basic networking configuration has its APIs already.
>
> > Let's say the power up setting is ON and it boots up to Linux for the
> > first time after receiving a magic packet.  The Linux user can then
> > run ethtool -s to set the driver's non persistent WoL setting.  It can
> > be the same as the NVRAM's power up setting, or different.  Ethtool
> > may support additional WoL packet types that the power up setting does
> > not support.  Let's say the Linux user sets the ethtool WoL setting to
> > OFF and shuts down the system.  That card now will not wake up the
> > system.  But if there is a power failure and power comes back on
> > later, the card will lose the ethtool setting and go back to the power
> > up WoL setting, which is ON in this example.
>
> So in your example there is a machine with a 25/40/100G NIC that
> doesn't have any remote BMC control, and connected to a L2 network
> where a magic packet can be received.
>
> In my experience machines are either low end/embedded and they just
> boot on power on fully (to Linux), or they are proper machines which
> support IPMI etc.
>
> If you could illuminate the use case some more I'd really appreciate
> that.  In your hypothetical scenario you still have to get the link
> up, so if we apply this patch a logical extension would be to add all
> ethtool link settings as devlink parameters as well.  Florian recently
> added an option to wake based on a packet that matched an n-tuple
> filter.  If your use case is legit, doing the same thing with n-tuple
> filters instead of Magic Packets is very much legit, too.  So we will
> poke n-tuple filters via devlink params?

We only store a magic packet WoL bit in the NVRAM for basic power up
WoL setting.  I doubt that people will store the entire n-tuple WoL
pattern in NVRAM for basic power up WoL.  The whole idea is to have a
basic method to wake up the machine after power up with Vaux.  If the
cable is connected, the NIC will autoneg to some lower speed that Vaux
can support.  I think we've been supporting this since the tg3 days.