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.
>>
>> 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¹m quite tempted to require Œiommu¹ 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
--
vt-d: Disable VT-d if parsing ACPI DMAR fails
Signed-off-by: Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>
diff -r b80d6639cad4 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Mon Jul 14 12:54:37 2008 +0100
+++ b/xen/drivers/passthrough/vtd/dmar.c Mon Jul 14 14:12:40 2008 +0100
@@ -82,6 +82,29 @@ static int __init acpi_register_rmrr_uni
{
list_add(&rmrr->list, &acpi_rmrr_units);
return 0;
+}
+
+static void __init disable_all_dmar_units(void)
+{
+ struct acpi_drhd_unit *drhd, *_drhd;
+ struct acpi_rmrr_unit *rmrr, *_rmrr;
+ struct acpi_atsr_unit *atsr, *_atsr;
+
+ list_for_each_entry_safe ( drhd, _drhd, &acpi_drhd_units, list )
+ {
+ list_del(&drhd->list);
+ xfree(drhd);
+ }
+ list_for_each_entry_safe ( rmrr, _rmrr, &acpi_rmrr_units, list )
+ {
+ list_del(&rmrr->list);
+ xfree(rmrr);
+ }
+ list_for_each_entry_safe ( atsr, _atsr, &acpi_atsr_units, list )
+ {
+ list_del(&atsr->list);
+ xfree(atsr);
+ }
}
static int acpi_ioapic_device_match(
@@ -436,6 +459,12 @@ static int __init acpi_parse_dmar(struct
/* Zap APCI DMAR signature to prevent dom0 using vt-d HW. */
dmar->header.signature[0] = '\0';
+ if ( ret )
+ {
+ printk(XENLOG_WARNING "Failed to parse ACPI DMAR. Disabling VT-d.\n");
+ disable_all_dmar_units();
+ }
+
return ret;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home