linux-kernel - Re: Misc fixes for 2.6.27

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:	Tue, 02 Sep 2008 09:23:10 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: Misc fixes for 2.6.27

On Tue, 2008-09-02 at 08:19 +0200, Andi Kleen wrote:
> On Mon, Sep 01, 2008 at 04:16:39PM -0700, Arjan van de Ven wrote:
> > On Tue, 02 Sep 2008 01:01:19 +0200
> > Andi Kleen <andi@...stfloor.org> wrote:
> > 
> > > Arjan van de Ven <arjan@...radead.org> writes:
> > > 
> > > > On Tue, 02 Sep 2008 00:32:16 +0200
> > > > Andi Kleen <andi@...stfloor.org> wrote:
> > > >
> > > >> David Woodhouse <dwmw2@...radead.org> writes:
> > > >> > +
> > > >> > +static struct dmi_system_id __initdata intel_iommu_dmi_table[]
> > > >> > = {
> > > >> > +	{	/* Some DG33BU BIOS revisions advertised
> > > >> > non-existent VT-d */
> > > >> 
> > > >> Are you sure it's non existent? A G33 chipset should have it in
> > > >> hardware I thought.
> > > >
> > > > nope they don't/
> > > > later ones and some other models do though, but not the G33
> > > 
> > > I see. But presumably that chipset will be in other motherboards
> > > too and that BIOS bug might be also wider spread. So it would be
> > > still better to key off an PCI-ID or similar.

It's certainly possible that the same BIOS bug could show up elsewhere.
I was expecting that we could add new motherboards to the DMI table if
that happens.

> > it would be nice, no doubt, unfortunately this code runs (and needs to
> > run) before the PCI subsystem is initialized...
> 
> early quirks handles these cases. Check out early-quirks.c

That might work, I suppose -- although the iommu probe happens early, it
looks like the early-quirks are handled even earlier. Unfortunately the
last attempt at flashing a BIOS on my DG33BU has turned it into a brick
and even the recovery procedure doesn't work, so I can't test any more
-- I'm more inclined to stick with what I'd tested, but if you feel
strongly and someone can test this version, then perhaps we could go
with that instead...

I made it check for this:
00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev 02)

Are we sure that device never going to appear on a board which really
_does_ have an IOMMU? And we should probably get it into pci_ids.h too.


diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 4353cf5..f51f61b 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -95,6 +95,20 @@ static void __init nvidia_bugs(int num, int slot, int func)
 
 }
 
+#ifdef CONFIG_DMAR
+static void __init intel_g33_dmar(int num, int slot, int func)
+{
+	struct acpi_table_header *dmar_tbl;
+	acpi_status = status;
+
+	status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
+	if (ACPI_SUCCESS(status)) {
+		printk(KERN_INFO "BIOS BUG: DMAR advertised on Intel G31/G33 chipset -- ignoring\n");
+		dmar_disabled = 1;
+	}
+}
+#endif
+
 #define QFLAG_APPLY_ONCE 	0x1
 #define QFLAG_APPLIED		0x2
 #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -114,6 +128,10 @@ static struct chipset early_qrk[] __initdata = {
 	  PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
 	{ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB,
 	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config },
+#ifdef CONFIG_DMAR
+	{ PCI_VENDOR_ID_INTEL, 0x29c0,
+	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, intel_g33_dmar },
+#endif
 	{}
 };
 


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation



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