linux-kernel - Re: [discuss] Re: Please pull x86-64 bug fixes

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: <200610060121.01461.ak@suse.de>
Date:	Fri, 6 Oct 2006 01:21:01 +0200
From:	Andi Kleen <ak@...e.de>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Jeff Garzik <jeff@...zik.org>, discuss@...-64.org,
	linux-kernel@...r.kernel.org
Subject: Re: [discuss] Re: Please pull x86-64 bug fixes

> If we had the
> 
> 	void __iomem *cfg = mmiocfg_remap(dev);
> 
> interface, we could (fairly easily) blacklist known-bad motherboards if we 
> needed to,

With the bad Intel reference BIOS that's far too many.

I've considered using PCI-IDs but even with that it would be quite messy.

> For example, for some devices, maybe they'd lose some error handling 
> capability, but they'd still be able to work otherwise.

AFAIK that's always the case right now. Jeff's secret NDA device
is the only known exception so far.

> We _can_ do the same thing with checking the error return value from 
> "pci_read_config_xxxx()",

Problem is you get a hang at least on the Intel boards, not a -1

> I dunno. I'm not likely to care _that_ deeply about this all, but I do 
> think that machines that hang on device discovery is just about the worst 
> possible thing, so I'd much rather have ten machines that can't use their 
> very rare devices without some explicit kernel command line than have even 
> _one_ machine that just hangs because MMIOCFG is buggered.

Actually they don't hang at discovery, but at the verify step we early use
to decide if mcfg works or not (we go through a few busses and compare
type 1 and mcfg). This is currently separate from the normal discovery
to not burden the generic code with it.

To be fair one issue is that the verify step current ignores the ACPI
information about how many busses there are, but iirc the Intel board hung 
pretty early so it likely wouldn't have helped there anyways.

At some point there was hope if checking the MCFG against other
ACPI resources would catch it, but it didn't at least on the board
I tested on.

> (And we should probably have the "pci=mmiocfg" kernel command line entry 
> that forces MMIOCFG regardless of any e820 issues, even for normal 
> accesses).

Yes that would be a good change.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/