netdev - RE: [PATCH v2] e1000e: Increase iteration on polling MDIC ready bit

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: <2f48175dce974ea689bfd26b9fc2245a@AcuMS.aculab.com>
Date:   Fri, 25 Sep 2020 08:50:30 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Kai-Heng Feng' <kai.heng.feng@...onical.com>,
        Andrew Lunn <andrew@...n.ch>
CC:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "moderated list:INTEL ETHERNET DRIVERS" 
        <intel-wired-lan@...ts.osuosl.org>,
        "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] e1000e: Increase iteration on polling MDIC ready bit

From: Kai-Heng Feng
> Sent: 24 September 2020 17:04
...
> > I also don't fully understand the fix. You are now looping up to 6400
> > times, each with a delay of 50uS. So that is around 12800 times more
> > than it actually needs to transfer the 64 bits! I've no idea how this
> > hardware works, but my guess would be, something is wrong with the
> > clock setup?
> 
> It's probably caused by Intel ME. This is not something new, you can find many polling codes in e1000e
> driver are for ME, especially after S3 resume.
> 
> Unless Intel is willing to open up ME, being patient and wait for a longer while is the best approach
> we got.

There is some really broken code in the e1000e driver that affect my
Ivy bridge platform were it is trying to avoid hardware bugs in
the ME interface.

It seems that before EVERY write to a MAC register it must check
that the ME isn't using the interface - and spin until it isn't.
This causes massive delays in the TX path because it includes
the write that tells the MAC engine about a new packet.

The code is completely broken though.
Interrupts and processes switches can happen between the
test for the ME being idle and the actual write.

AFAICT the only reliable way to get ethernet access on such
systems is to use a different ethernet interface.

Also, from what I remember, the broken workaround is missing
from some of the setup code paths.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)