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

[Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>]

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?

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.

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>
>>>
>>>
>>>
>>
>>
>