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

[Weidong Han <weidong.han@intel.com>]

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@eikelenboom.it> 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@jp.fujitsu.com>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Keir Fraser wrote:
>>>>>>>               
>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> 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@intel.com>
>>>>>>>               
>>>>
>>>>         
>>>       
>
>
>