linux-kernel - Re: [PATCH v4] x86, vt-d: enable x2apic opt out

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:	Thu, 26 May 2011 00:37:50 +0100
From:	"Woodhouse, David" <david.woodhouse@...el.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Ingo Molnar <mingo@...e.hu>,
	"Song, Youquan" <youquan.song@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"hpa@...ux.intel.com" <hpa@...ux.intel.com>,
	"Kay, Allen M" <allen.m.kay@...el.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"Sankaran, Rajesh" <rajesh.sankaran@...el.com>,
	"Mallick, Asit K" <asit.k.mallick@...el.com>,
	"Liu, Kent" <kent.liu@...el.com>,
	Youquan Song <youquan.song@...ux.intel.com>
Subject: Re: [PATCH v4] x86, vt-d: enable x2apic opt out

On Wed, 2011-05-25 at 23:01 +0100, Thomas Gleixner wrote:
> On Wed, 25 May 2011, Ingo Molnar wrote:
> > So why isnt the x2apic disabled in the CPUID? That's the canonical 
> > way to unsupport a particular non-working CPU hw feature.

A valid question. Rajesh?

> Because some committee decided to make it an ACPI feature.
> That's broken by design, but you can't change the stupid spec retroactively.

You can ask for clarification of the stupid spec though. :)

Is it *really* tied to interrupt-remapping, as the wording in the spec
implies?

In particular, what about the case where VT-d has been disabled in the
BIOS so there is *no* DMAR table at all, and hence nowhere for this 'opt
out' bit to be set?

Currently, it looks like we still enable x2apic in that case. We have a
*build* time dependency which means you can't build x2apic support
unless you also build interrupt-remapping support. But unless there's a
lot of dead code in our x2apic support, it looks like we still enable
x2apic at run time if we didn't enable IR for various reasons.

Is that going to make these broken BIOSes fall over too? If so, it
really does look like the placement of this bit in the DMAR table is
entirely wrong.

Rajesh, can you tell use *exactly* what is the BIOS brokenness that this
hack was invented to work around?

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

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6242 bytes)