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, 4 Jun 2021 09:36:33 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Nikolai Zhubr <zhubr.2@...il.com>,
        netdev <netdev@...r.kernel.org>, Jeff Garzik <jgarzik@...ox.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: Realtek 8139 problem on 486.

On Thu, Jun 3, 2021 at 8:32 PM Maciej W. Rozycki <macro@...am.me.uk> wrote:
> On Tue, 1 Jun 2021, Heiner Kallweit wrote:
>
> > > Now I'd like to ask, is quality reliable fix still wanted in mainline or rather not?
> > > Because I'll personally do my best to create/find a good fix anyway, but if it is
> > > of zero interest for mainline, I'll probably not invest much time into communicating
> > > it. My understanding was that default rule is "if broken go fix it" but due to the
> > > age of both code and hardware, maybe it is considered frozen or some such
> > > (I'm just not aware really).
> > >
> > Driver 8139too has no maintainer. And you refer to "mainline" like to a number of developers
> > who are paid by somebody to maintain all drivers in the kernel. That's not the case in general.
> > You provided valuable input, and if you'd contribute to improving 8139too and submit patches for
> > fixing the issue you're facing, this would be much appreciated.
>
>  It's an issue in x86 platform code, not the 8139too driver.  Any option
> card wired to PCI in this system somehow could suffer from it.  Depending
> on how you look at it you may or may not qualify it as a bug though, and
> any solution can be considered a workaround (for a BIOS misfeature) rather
> than a bug fix.

I think it would be good though to reinstate the driver workaround in some way,
regardless of whether the x86 platform code gets changed or not.

>From the old linux-2.6.2 code it appears that someone had intentionally
added the loop as a hack to make it work on a broken or misconfigured BIOS.
It's hard to know if that was indeed the intention, but it's clear that the
driver change in 2.6.3 broke something that worked (most of the time)
without fixing it in a better way.

>  The question is IMHO legitimate, and I can't speak for x86 platform
> maintainers.  If I were one, I'd accept a reasonable workaround and it
> does not appear to me it would be a very complex one to address this case:
> basically a PCI quirk to set "this southbridge has ELCR at the usual
> location" (if indeed it does; you don't want to blindly poke at random
> port I/O locations in generic code), and then a tweak to `pirq_enable_irq'
> or `pcibios_lookup_irq' as Arnd has suggested.

(adding the x86 maintainers to Cc, the thread is archived at
 https://lore.kernel.org/netdev/60B24AC2.9050505@gmail.com/)

Changing the x86 platform code as well would clearly help avoid similar
issues with other PCI cards on these broken platforms, but doing it
correctly  seems hard for a couple of reasons.

It sounds like it would have been a good idea 20 years ago when the
broken i486 platforms were still fairly common, but now we don't even
know whether the code was intentional or not. I don't remember a lot of
the specifics of pre-APIC x86, but I do remember IRQ configuration
as a common problem without a single good solution.

There is a realistic chance that other combinations of broken hardware
and drivers rely on the x86 PCI code doing exactly what it does today.
If overriding the BIOS setting breaks something that works today, nothing
is gained, because the next person running into an i486 PCI specific bug
is unlikely to be as persistent and competent as Nikolai in tracking down
the root cause.

Doing a narrower change to a specific chipset, motherboard or BIOS
would be less risky, but would likely miss similar cases. Any x86
specific change would clearly also miss similar problems that may
or may not exist on other architectures.

     Arnd