WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table

Agreed.  Something like an 'iommu=required' parameter makes sense in
some circumstances.

        eSk


-----Original Message-----
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Subject: RE: [Xen-devel] Workaround for the corrupted Intel X48 DMAR table
Date: Tue, 15 Jul 2008 09:33:06 -0700

Espen,

For users that do care about the security provided by an IOMMU,
especially when used in conjunction with something like Intel(R) Trusted
Execution Technology, it is important not to just disable expected
protections.  In these cases, it is better just to halt or crash Xen. 
And the thing to keep in mind is that from a security perspective, a
buggy BIOS is not the only possible cause for a corrupted ACPI table;
malicious bootloader or post-bootlaoder and pre-tboot/Xen code could
also corrupt the tables if it could be used to circumvent protections.

But I agree that the default case should be to gracefully handle these
types of failures.  So perhaps allow the 'iommu' command line option to
take a value (e.g. '2') that indicates that the user wants the strict
(i.e. crash or halt) behavior.  This would only be specified by users
that really want the added security.

Joe

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Espen
Skoglund
Sent: Monday, July 14, 2008 6:21 AM
To: Keir Fraser
Cc: Zhao, Yu; xen-devel@xxxxxxxxxxxxxxxxxxx; Han, Weidong; Neo Jia; Jean
Guyader
Subject: Re: [Xen-devel] Workaround for the corrupted Intel X48 DMAR
table

[Keir Fraser]
> On 14/7/08 07:47, "Neo Jia" <neojia@xxxxxxxxx> wrote:
>> In line:  0100: 00 00 00 80 00 00 00 00 ff ff ff 7f 00 00 00 00, the
RMRR
>> reserved memory region starting address is even higher than its limit
address.
>>=20
>> Is there anyway to do a software workaround for this issue? I tried
>> to simply ignore that entry in the "acpi_parse_one_rmrr" function,
>> but I hit a panic in function "iommu_enable_translation".


> This kind of thing makes me quite uneasy about enabling VT-d by
> default in Xen 3.3. I=B9m quite tempted to require =8Ciommu=B9 on the
> command line to enable it.

I've had ACPI problems with the Dell T7400 as well.  Using an
unpatched Xen caused the system to hangup during startup.  Dell only
managed to release a BIOS upgrade that fixed the problem less than two
weeks ago.

Anyhow, the very least one should do is to disable VT-d if parsing the
ACPI DMAR fails.  I've attached a patch which does this.  It's then
only a matter of returning an error if any of the DMAR tables look
suspicious.

        eSk

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel