[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |