linux-kernel - Re: [PATCH] x86/pci: intel bus root res with IOH reading -v2

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:	Mon, 12 Oct 2009 22:34:53 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86/pci: intel bus root res with IOH reading -v2


* Bjorn Helgaas <bjorn.helgaas@...com> wrote:

> On Tuesday 06 October 2009 11:51:22 am Yinghai Lu wrote:
> > Bjorn Helgaas wrote:
> > > On Sunday 04 October 2009 10:54:24 pm Yinghai Lu wrote:
> > >> for intel system with multi IOH. we could read peer root resource from PCI conf,
> > >> and don't trust _CRS again for root bus
> > > 
> > > Ugh.  Are we going to end up with amd_bus.c, intel_bus.c, nvidia_bus.c,
> > > broadcom_bus.c, serverworks_bus.c, etc.?
> > only needed when you have muti ...
> 
> I think that translates to "yes, we will need all those bits as soon 
> as those vendors support larger systems with multiple IOHs."  And I 
> think that's the wrong answer.

Why is having cleanly separated per vendor information/driver wrong? I 
think it's the right answer in most cases. _Especially_ when the other 
option is to 'rely on the firmware'.

> > again we should trust HW conf than BIOS.
> 
> Certainly there's a tradeoff between a generic driver that relies on 
> the BIOS, and a platform-specific driver that uses only the hardware. 
> The first leaves us vulnerable to BIOS bugs, but the second leads to a 
> plethora of drivers that require updates as hardware changes.

We do that quite well in Linux - it's one of our main strengths.

Why should we have to rely on correct firmware? Why is it wrong to know 
about the hw's structure, to query the hardware and ignore the firmware 
if the hardware state tells us otherwise?

	Ingo
--
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/