Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking

[Weidong Han <weidong.han@xxxxxxxxx>]

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" <linux@xxxxxxxxxxxxxx> 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 <n_iwamatsu@xxxxxxxxxxxxxx>
> > > > > >
> > > > > >
> > > > > >             
> > > > > > > Keir Fraser wrote:
> > > > > > >               
> > > > > > > > On 21/01/2010 10:19, "Weidong Han" <weidong.han@xxxxxxxxx> 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 <weidong.han@xxxxxxxxx>
> > > > > > >               
> > > >         
> > >       
>   
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel