From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weidong Han Subject: Re: [PATCH] VT-d: improve RMRR validity checking Date: Fri, 22 Jan 2010 10:53:31 +0800 Message-ID: <4B59132B.40607@intel.com> References: <4B59098B.6000108@intel.com> <4B590FA4.4000008@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4B590FA4.4000008@jp.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Noboru Iwamatsu Cc: "xen-devel@lists.xensource.com" , "linux@eikelenboom.it" , "Cihula, Joseph" , "keir.fraser@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org Noboru Iwamatsu wrote: > Hi Weidong, > > I'm not sure why the security problem is caused by ignoring > the DRHD that has only non-existent devices. > > Could you explain details or where to read the spec? > It's requested from security experts. The device that is not pci discoverable may be re-enabled by malicious software. If its DRHD is not enabled, the re-enabled device is not protected by VT-d. It will cause security issue. > As you saying, security is the top-priority. > However, when iommu=force is specified, we should enable vt-d > if there are some potential issues. > Because users want to "force" anyway. > iommu=force was introduced to enable VT-d anyway for security purpose. I plan to still enable those DRHDs that includes non-existed device when iommu=force, otherwise ignore them. Regards, Weidong > Regards, > Noboru. > > >> Keir Fraser wrote: >> >>> If we want to keep iommu=1 as default, then it is unacceptable to fail to >>> boot on a fairly wide range of modern systems. We have to >>> warn-and-disable, >>> partially or completely, unless iommu=force is specified. Or we need to >>> revert to iommu=0 as the default. >>> >>> What do you think, Weidong? >>> >> Yes. I agree to warn-and-disable for these BIOS issues, and consider >> security more when iommu=force. Therefore I will implement a patch based >> on Nororu's patch. >> >> Regards, >> Weidong >> >> >>> -- Keir >>> >>> On 21/01/2010 14:17, "Sander Eikelenboom" wrote: >>> >>> >>>> Hello Weidong, >>>> >>>> The problem is most vendor's just don't fix it and ignore the problem >>>> completely. >>>> Most often hiding them selves behind: come back when it's a problem with >>>> Microsoft Windows, that the only single thing we support (and no other >>>> software, so no vmware, no xen, no linux, perhaps even no hypervisor) >>>> Well I don't know if the virtual pc in windows 7 supports an iommu >>>> now, but it >>>> didn't in the past as far as i know, so any complain bounces off, and >>>> there it >>>> all seems to end for them. >>>> >>>> Besides that i don't know if they do know what the problems with there >>>> implementation in BIOS is when someone reports it. >>>> I think some behind the scenes pressure from Intel to vendors might >>>> help to >>>> solve some of them. >>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for >>>> that) also >>>> suffers RMRR problem when another graphics card is inserted which >>>> switches off >>>> the IGD). >>>> >>>> Although i think in my case your patch will work around that for me. >>>> Perhaps a >>>> third option is needed, which does all the workarounds possible and >>>> warns >>>> about potential security problem when requested ? >>>> >>>> -- >>>> Sander >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote: >>>> >>>> >>>>> Noboru Iwamatsu wrote: >>>>> >>>>>> Hi Weidong, >>>>>> >>>>>> I re-send the DRHD-fix patch. >>>>>> >>>>>> If DRHD does not have existent devices, ignore it. >>>>>> If DRHD has both existent and non-existent devices, consider it >>>>>> invalid >>>>>> and not register. >>>>>> >>>>> Although you patch workarounds your buggy BIOS, but we still need to >>>>> enable it for security purpose as I mentioned in previous mail. We >>>>> needn't workaround / fix all BIOS issues in software. I think security >>>>> is more important for this specific BIOS issue. Did you report the BIOS >>>>> issue to your OEM vendor? maybe it's better to get it fixed in BIOS. >>>>> Regards, >>>>> Weidong >>>>> >>>>>> According to this patch and yours, my machine successfully booted >>>>>> with vt-d enabled. >>>>>> >>>>>> Signed-off-by: Noboru Iwamatsu >>>>>> >>>>>> >>>>>> >>>>>>> Keir Fraser wrote: >>>>>>> >>>>>>>> On 21/01/2010 10:19, "Weidong Han" wrote: >>>>>>>> >>>>>>>> >>>>>>>>>> Sorry this is typo. >>>>>>>>>> I mean: >>>>>>>>>> So, I think RMRR that has no-existent device is "invalid" >>>>>>>>>> and whole RMRR should be ignored. >>>>>>>>>> >>>>>>>>> looks reasonable. >>>>>>>>> >>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge >>>>>>>>> them to one >>>>>>>>> patch? >>>>>>>>> >>>>>>>> Merge them up, re-send with both sign-off and acked-by all in one >>>>>>>> email. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Keir >>>>>>>> >>>>>>>> >>>>>>> Sorry, I disagree with Noboru after thinking it again. If the RMRR >>>>>>> has >>>>>>> both no-existent device and also has existent devices in its >>>>>>> scope, we >>>>>>> should not ignore it because the existent devices under its scope >>>>>>> will >>>>>>> be impacted without the RMRR. so I suggest to print a warning >>>>>>> instead of >>>>>>> ignore it. Attached a patch for it. >>>>>>> >>>>>>> Signed-off-by: Weidong Han >>>>>>> >>>> >>>> >>> > > >