netdev - RE: Realtek 8139 problem on 486.

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:   Fri, 9 Jul 2021 12:43:32 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Nikolai Zhubr' <zhubr.2@...il.com>,
        Arnd Bergmann <arnd@...nel.org>
CC:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Heiner Kallweit <hkallweit1@...il.com>,
        netdev <netdev@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        "Ingo Molnar" <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: RE: Realtek 8139 problem on 486.

From: Nikolai Zhubr
> Sent: 08 July 2021 20:22
...
> 22.06.2021 14:12, David Laight:
>  > Typically you need to:
>  > 1) stop the chip driving IRQ low.
>  > 2) process all the completed RX and TX entries.
>  > 3) clear the chip's interrupt pending bits (often write to clear).
>  > 4) check for completed RX/TX entries, back to 2 if found.
>  > 5) enable driving IRQ.
>  >
>  > The loop (4) is needed because of the timing window between
>  > (2) and (3).
>  > You can swap (2) and (3) over - but then you get an additional
>  > interrupt if packets arrive during processing - which is common.
> 
> So in terms of such outline, the "poll approach" now implements 1, 2, 3,
> 5 but still misses 4, and my understanding is that it is therefore still
> not a complete solution for the broken triggering case (Although
> practically, the time window might be too small for the race effect to
> be ever observable) From my previous testing I know that such a loop
> does not affect the perfomance too much anyway, so it seems quite safe
> to add it. Maybe I've missunderstood something though.

The timing window (4) happens.
The next receive packet will usually clear it - but that might require a timeout.
I'm sure I got a trip to Sweden out of it.

I also think Linux requires the tx-reap be done in a timely manner.
If that is only done in response to an end of tx interrupt the delay
could be substantial.

	David

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