linux-kernel - Re: [Intel-wired-lan] [PATCH 2/2] igc: wait for the MAC copy when enabled MAC passthrough

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:   Wed, 14 Jul 2021 12:13:25 +0300
From:   "Ruinskiy, Dima" <dima.ruinskiy@...el.com>
To:     Aaron Ma <aaron.ma@...onical.com>,
        "Neftin, Sasha" <sasha.neftin@...el.com>,
        <jesse.brandeburg@...el.com>, <anthony.l.nguyen@...el.com>,
        <davem@...emloft.net>, <kuba@...nel.org>,
        <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        "Edri, Michael" <michael.edri@...el.com>,
        "Shalev, Avi" <avi.shalev@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH 2/2] igc: wait for the MAC copy when
 enabled MAC passthrough

Hello, Aaron, Sasha,

On 13/07/2021 16:45, Aaron Ma wrote:
> 
> On 7/8/21 12:24 PM, Neftin, Sasha wrote:
>> I would to like suggest checking the following direction:
>> 1. principal question: can we update the netdev device address after 
>> it is already set during probe? I meant perform another:
>> memcpy(netdev->dev_addr, hw->mac.addr, netdev->addr_len) up to demand
> 
> Updating MAC addr may work.
> Even at the end of probe, it still got the wrong MAC address, delay is 
> still needed.
> 
> Aaron
> 
>> 2. We need to work with Intel's firmware engineer/group and define the 
>> message/event: MAC addressis changed and should be updated.
>> As I know MNG FW updates shadow registers. Since shadow registers are 
>> different from RAL/RAH registers - it could be a notification that the 
>> MAC address changed. Let's check it.

There is an interrupt which the FW can issue to the driver to indicate 
that MAC address has been changed. At that point the driver can update 
the MAC in its internal structures.

The important question is - is there away to update the OS structures at 
that point so that the MAC address change propagates through all the 
network stack. Some network stacks do not support such an update, except 
during device initialization (probe), so in such environments a delay is 
the only workaround, and it is a problematic one as we know.

If we find a mechanism by which the device driver can tell the Linux 
network stack - "My MAC address has changed; please update it", we can 
implement it differently, and not need this delay. Who can help us with 
this inquiry?

Thanks,
--Dima
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.