Hardware Compatibility List for Qubes OS

1034 views
Skip to first unread message

7v5w7go9ub0o

unread,
May 2, 2012, 10:38:20 AM5/2/12
to qubes...@googlegroups.com
Hurrah! Thanks! ( <http://wiki.qubes-os.org/trac/wiki/HCL>

Presuming that most future Qubes users would also want to install
AEMaid, perhaps you could include Anti Evil Maid in the evaluations? e.g.

Lenovo Thinkpad T420 w/ Intel graphics.
Qubes installed easily and provided complete functionality.
AEMaid installed and functioned properly with the standard ( xxxx ) BIOS.

Thanks

Marek Marczykowski

unread,
May 2, 2012, 10:55:38 AM5/2/12
to qubes...@googlegroups.com, 7v5w7go9ub0o
AEM should work with all machines (if TPM is present). Perhaps we should
include some info about VT-d.

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

signature.asc

Zrubecz Laszlo

unread,
May 2, 2012, 4:54:12 PM5/2/12
to qubes...@googlegroups.com, 7v5w7go9ub0o
On 2 May 2012 16:55, Marek Marczykowski <marm...@invisiblethingslab.com> wrote:
> On 02.05.2012 16:38, 7v5w7go9ub0o wrote:
>> Hurrah! Thanks! ( <http://wiki.qubes-os.org/trac/wiki/HCL>


> AEM should work with all machines (if TPM is present). Perhaps we should
> include some info about VT-d.
Yeah lots of vendor hide the vt-d switch in BIOS :( We should know
that... at least.

for the same reason we should include the BIOS version as well...

And how should we contribute?

finally I got a new laptop (Fujitsu S751) for testing qubes... The
experience is TOTALLY different now :)
but VT-d is switched off and hided from my bios - Thansk to Fujitsu.
but we are Fujitsu vendors, so I will complain about this for sure... ;)

--
Zrubi

Radoslaw Szkodzinski

unread,
May 4, 2012, 12:20:04 AM5/4/12
to qubes...@googlegroups.com
On Wed, May 2, 2012 at 10:54 PM, Zrubecz Laszlo <ma...@zrubi.hu> wrote:
> On 2 May 2012 16:55, Marek Marczykowski <marm...@invisiblethingslab.com> wrote:
>> On 02.05.2012 16:38, 7v5w7go9ub0o wrote:
>>> Hurrah! Thanks! ( <http://wiki.qubes-os.org/trac/wiki/HCL>
>
>
>> AEM should work with all machines (if TPM is present). Perhaps we should
>> include some info about VT-d.


About Intel CPU support:
K - overclockable - Core do *NOT* support VT-d/TXT.
UE, LE, QE - embedded - Core do *NOT* support VT-x/VT-d/TXT.
Sandy Bridge E CPUs (Core i7-3820) do *NOT* support VT-d/TXT.
Core i3 and mobile Core i3 do *NOT* support VT-d/TXT.

All the following (with the above exceptions) support VT-d/TXT if the
chipset and mainboard don't prevent it:
Core i5 6xx, 2400, 2400S, 2500. 2500S, 2500T, 3450 and 3450S.
Core i7 8xx, Core i7 Sandy Bridge and Core i7 Ivy Bridge (all with the
above exceptions) have support.

Mobile Core i5 5xx and 25xxM.
Mobile Core i7 except the following:
Core i7-2630QM, Core i7-2635QM, Core i7-2670QM, Core i7-2675QM, Core
i7-3610QM, Core i7-3612QM

Xeon E3, E5 and E7 support VT-d/TXT.

About Intel mainboard support, things are more in the air. I can
specifically confirm Asus P8B WS as working (C206 chipset).

I'd suspect most H67, P67, X68 and Z78 chipset mainboards will have
VT-d support, but it quite depends on a particular mainboard to have
the TPM header.
Xeon Sandy Bridge (e.g. C20x) are more likely to support TPM.

Mobile support is quite shaky due to various cut down firmware and
needs to be evaluated separately on model/series basis.

--
Radosław Szkodziński

Joanna Rutkowska

unread,
May 4, 2012, 5:23:04 AM5/4/12
to qubes...@googlegroups.com, Marek Marczykowski, 7v5w7go9ub0o
On 05/02/12 16:55, Marek Marczykowski wrote:
> On 02.05.2012 16:38, 7v5w7go9ub0o wrote:
>> > Hurrah! Thanks! ( <http://wiki.qubes-os.org/trac/wiki/HCL>
>> >
>> > Presuming that most future Qubes users would also want to install
>> > AEMaid, perhaps you could include Anti Evil Maid in the evaluations? e.g.
>> >
>> > Lenovo Thinkpad T420 w/ Intel graphics.
>> > Qubes installed easily and provided complete functionality.
>> > AEMaid installed and functioned properly with the standard ( xxxx ) BIOS.
> AEM should work with all machines (if TPM is present). Perhaps we should
> include some info about VT-d.

As noted in a paragraph at the top of the page:

"Unless otherwise noted, all the systems have support for Intel VT-d"

joanna.

signature.asc

Joanna Rutkowska

unread,
May 4, 2012, 5:26:38 AM5/4/12
to qubes...@googlegroups.com, 7v5w7go9ub0o
On 05/02/12 16:38, 7v5w7go9ub0o wrote:
> Hurrah! Thanks! ( <http://wiki.qubes-os.org/trac/wiki/HCL>
>
> Presuming that most future Qubes users would also want to install
> AEMaid, perhaps you could include Anti Evil Maid in the evaluations?
> e.g.
>

Right now (as of 1.0 release) AEM is considered an optional component.

Generally, evaluating whether a platform has a correct support for
Static RTM (what TPM relies on) is non trivial. It might seem that it
works fine, but it might be screwed up in the BIOS. Again, a reason to
treat this as an optional feature right now.

joanna.

signature.asc

Joanna Rutkowska

unread,
May 4, 2012, 5:27:56 AM5/4/12
to qubes...@googlegroups.com, Zrubecz Laszlo, 7v5w7go9ub0o
On 05/02/12 22:54, Zrubecz Laszlo wrote:
> On 2 May 2012 16:55, Marek Marczykowski <marm...@invisiblethingslab.com> wrote:
>> > On 02.05.2012 16:38, 7v5w7go9ub0o wrote:
>>> >> Hurrah! Thanks! ( <http://wiki.qubes-os.org/trac/wiki/HCL>
>
>> > AEM should work with all machines (if TPM is present). Perhaps we should
>> > include some info about VT-d.
> Yeah lots of vendor hide the vt-d switch in BIOS :( We should know
> that... at least.
>
> for the same reason we should include the BIOS version as well...
>
> And how should we contribute?

Just send as much details about your system to this list, and one of us
will update the wiki HCL page accordingly, including a link to your post.

Thanks,
joanna.

signature.asc

Danny Fullerton

unread,
May 4, 2012, 9:49:32 AM5/4/12
to qubes...@googlegroups.com
The Sony VIAO Z2 (2011 version) w/ Intel graphics (HD 3000) works fine but requires some BIOS mod to enable VT-d. See http://forum.notebookreview.com/sony/641483-sony-vaio-z2-2011-advanced-menu-bios-hack.html

- This ultraportable features 2 SSD in RAID 0 which seems to help a lot with the performance.
- The chipset is intel HM67.
- It also has a TPM but I still did not test Anti Evil Maid.
-- 
Danny Fullerton
Mantor Organization

signature.asc

Joanna Rutkowska

unread,
May 4, 2012, 10:04:39 AM5/4/12
to qubes...@googlegroups.com, Danny Fullerton
On 05/04/12 15:49, Danny Fullerton wrote:
> The Sony VIAO Z2 (2011 version) w/ Intel graphics (HD 3000) works fine
> but requires some BIOS mod to enable VT-d. See
> http://forum.notebookreview.com/sony/641483-sony-vaio-z2-2011-advanced-menu-bios-hack.html
>
> - This ultraportable features 2 SSD in RAID 0 which seems to help a lot
> with the performance.
> - The chipset is intel HM67.
> - It also has a TPM but I still did not test Anti Evil Maid.
> <http://forum.notebookreview.com/sony/641483-sony-vaio-z2-2011-advanced-menu-bios-hack.html>
>
>
Ok, thanks, I just updated the HCL page to include also Danny's and
Zrubecz's reported systems, and also corrected VT-d info for Marek's
systems.

Others, please send in your systems descriptions!

Thanks,
joanna.

signature.asc

Zrubecz Laszlo

unread,
May 4, 2012, 10:24:28 AM5/4/12
to qubes...@googlegroups.com
On 4 May 2012 16:04, Joanna Rutkowska <joa...@invisiblethingslab.com> wrote:
> Ok, thanks, I just updated the HCL page to include also Danny's and
> Zrubecz's reported systems, and also corrected VT-d info for Marek's
> systems.

I just get VT-d working on the S751 (Core i5-2520M) with the latest
firmware (1.18) and after a BIOS settings reset...



--
Zrubi

Zrubecz Laszlo

unread,
May 4, 2012, 10:38:35 AM5/4/12
to qubes...@googlegroups.com
Anyway, how can we check that VT-d is really working on a system?


--
Zrubi

Radoslaw Szkodzinski

unread,
May 4, 2012, 3:35:51 PM5/4/12
to qubes...@googlegroups.com
Set iommu=pv,required on the Xen boot line and see if it boots - this
means you have secure Vt-d with interrupt remapping.
If you need workaround_bios_bug, interrupt remapping will not work and
you cannot use that with the required flag.

Of Vt-d features (also listed in xl dmesg). Interrupt Remapping is
definitely critical, lack of that feature will make you vulnerable to
e.g. Xen CVE-2011-1898 (MSI trap injection on PCI passthrough)
unless you disable Vt-d altogether, which instead leaves you open to
DMA-based attacks.
(CVE found ofo course by ITL = Qubes OS team.)

About Xeons E3, they don't support cache snoop control, shared EPT or
DMA bypass which are performance issues but not critical for security.
(DMA bypass will be emulated by Xen setting up 1:1 mappings as necessary.)
Source: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-1-datasheet.html

Xen wiki says you cannot use Vt-d to pass PCI/PCIe cards that don't
have FLR feature (Function Level Reset, defined in PCIe 1.1 as an
optional). That feature is pretty uncommon.
Look for FLReset+ in lspci -vv output, if that's present, then
passthrough will definitely work.
I'm pretty sure Xen still can't correctly reset devices via pure ASPM
power states. (full card reset) Perhaps it will be possible to setup
passthrough with devices w/o FLR using IOMMU, but not dynamically
alter configuration...

--
Radosław Szkodziński

Joanna Rutkowska

unread,
May 4, 2012, 4:49:51 PM5/4/12
to qubes...@googlegroups.com, Zrubecz Laszlo
xl info | grep ^virt_caps.*hvm_directio

(Don't worry it says "hvm" -- in Xen 4.x this works for both PV and HVM,
as the iommu=pv has been removed sometime ago:

http://xenbits.xen.org/hg/xen-4.1-testing.hg/rev/510c797ee115

I think we should add this check to qubes manager and display a warning
tray baloon, or something, upon each boot, if the system doesn't have
vt-d enabled. What do you think, Marek?

joanna.

signature.asc

Joanna Rutkowska

unread,
May 4, 2012, 4:55:32 PM5/4/12
to qubes...@googlegroups.com, Radoslaw Szkodzinski
On 05/04/12 21:35, Radoslaw Szkodzinski wrote:
> On Fri, May 4, 2012 at 4:38 PM, Zrubecz Laszlo <ma...@zrubi.hu> wrote:
>> On 4 May 2012 16:24, Zrubecz Laszlo <ma...@zrubi.hu> wrote:
>>> On 4 May 2012 16:04, Joanna Rutkowska <joa...@invisiblethingslab.com> wrote:
>>>> Ok, thanks, I just updated the HCL page to include also Danny's and
>>>> Zrubecz's reported systems, and also corrected VT-d info for Marek's
>>>> systems.
>>>
>>> I just get VT-d working on the S751 (Core i5-2520M) with the latest
>>> firmware (1.18) and after a BIOS settings reset...
>>
>> Anyway, how can we check that VT-d is really working on a system?
>
> Set iommu=pv,required on the Xen boot line and see if it boots - this
> means you have secure Vt-d with interrupt remapping.
> If you need workaround_bios_bug, interrupt remapping will not work and
> you cannot use that with the required flag.
>
iommu=pv option has been removed long time ago:

http://xenbits.xen.org/hg/xen-4.1-testing.hg/rev/510c797ee115

> Of Vt-d features (also listed in xl dmesg). Interrupt Remapping is
> definitely critical, lack of that feature will make you vulnerable to
> e.g. Xen CVE-2011-1898 (MSI trap injection on PCI passthrough)
> unless you disable Vt-d altogether, which instead leaves you open to
> DMA-based attacks.
> (CVE found ofo course by ITL = Qubes OS team.)
>
> About Xeons E3, they don't support cache snoop control, shared EPT or
> DMA bypass which are performance issues but not critical for security.
> (DMA bypass will be emulated by Xen setting up 1:1 mappings as necessary.)
> Source: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-1-datasheet.html
>
> Xen wiki says you cannot use Vt-d to pass PCI/PCIe cards that don't
> have FLR feature (Function Level Reset, defined in PCIe 1.1 as an
> optional). That feature is pretty uncommon.

Not really -- all (most?) integrated devices on most modern chipsets are
FLR capable. Some notable exceptions are, of course, some NVidia
discrete GPUs...

> Look for FLReset+ in lspci -vv output, if that's present, then
> passthrough will definitely work.
> I'm pretty sure Xen still can't correctly reset devices via pure ASPM
> power states. (full card reset) Perhaps it will be possible to setup
> passthrough with devices w/o FLR using IOMMU, but not dynamically
> alter configuration...
>
If a device doesn't support FLR, then Xen does full bus reset after the
domain (to which the device has been assigned) destroy/shutdown. I'm
pretty sure that, at least Xen 3.x, allowed to passthrough non-FLR
devices to domains (HVM at least).

joanna.

signature.asc

Marek Marczykowski

unread,
May 4, 2012, 5:08:27 PM5/4/12
to qubes...@googlegroups.com, Joanna Rutkowska, Zrubecz Laszlo
Notification on each boot will be at least annoying. This isn't something that
user can easily change, so there is no point in reminding once a time.
Perhaps some warning in installer/firstboot should be enough, maybe also some
info in qubes-manager (System->Security info?) as stated in ticket #6.
signature.asc

Joanna Rutkowska

unread,
May 4, 2012, 5:11:09 PM5/4/12
to Marek Marczykowski, qubes...@googlegroups.com, Zrubecz Laszlo
Ticket #6 is a bit more general, and that's why we postponed it until
2.0 (it requires TPM support actually, etc).

Anyway, how often do you reboot your system? I reboot mine only... when
I upgrade Xen or Dom0 kernel, which, even for me, this is not more often
than once in a few weeks. I think this is an acceptable level of
annoyance...

joanna.

signature.asc

Zrubecz Laszlo

unread,
May 4, 2012, 5:40:03 PM5/4/12
to qubes...@googlegroups.com, Joanna Rutkowska
On 4 May 2012 23:08, Marek Marczykowski <marm...@invisiblethingslab.com> wrote:
>> I think we should add this check to qubes manager and display a warning
>> tray baloon, or something, upon each boot, if the system doesn't have
>> vt-d enabled. What do you think, Marek?
>
> Notification on each boot will be at least annoying. This isn't something that
> user can easily change, so there is no point in reminding once a time.
> Perhaps some warning in installer/firstboot should be enough, maybe also some
> info in qubes-manager (System->Security info?) as stated in ticket #6.

from the perspective of a user:

* At least the installer shoud tell this issue.
(xenclient installet doing this)

* if the qubes manager are able to display it somehow that would be very useful.

warning at every boot not sounds practical...

--
Zrubi

Zrubecz Laszlo

unread,
May 4, 2012, 6:52:27 PM5/4/12
to qubes...@googlegroups.com
On 4 May 2012 22:49, Joanna Rutkowska <joa...@invisiblethingslab.com> wrote:
> On 05/04/12 16:38, Zrubecz Laszlo wrote:
>> Anyway, how can we check that VT-d is really working on a system?
>
> xl info | grep ^virt_caps.*hvm_directio

Thanks, it is looks like vt-d is really enabled then :)

--
Zrubi

Alex Dubois

unread,
May 5, 2012, 4:08:10 AM5/5/12
to qubes...@googlegroups.com, qubes...@googlegroups.com
Hi,

As user I would like a green amber red status in qubes manager. Clicking on it giving the security feature that could not be activated. I suspect that in 2 years time, if you buy a system, unless it is specifically designed for over clocking, all underlying hardware would be present to allow us all to be on a green or blue status

Alex

Radoslaw Szkodzinski

unread,
May 6, 2012, 3:18:37 AM5/6/12
to Joanna Rutkowska, qubes...@googlegroups.com
On Fri, May 4, 2012 at 10:55 PM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
>> Set iommu=pv,required on the Xen boot line and see if it boots - this
>> means you have secure Vt-d with interrupt remapping.
>> If you need workaround_bios_bug, interrupt remapping will not work and
>> you cannot use that with the required flag.
>>
> iommu=pv option has been removed long time ago:

Indeed it has been. So it should be iommu=required or iommu=force.

>> Xen wiki says you cannot use Vt-d to pass PCI/PCIe cards that don't
>> have FLR feature (Function Level Reset, defined in PCIe 1.1 as an
>> optional). That feature is pretty uncommon.
>
> Not really -- all (most?) integrated devices on most modern chipsets are
> FLR capable. Some notable exceptions are, of course, some NVidia
> discrete GPUs...

Nothing on this Asus P8B WS has FLReset+ with the exception of Intel HDA.
(also LSI MegaSAS 9260 RAID controller supports it)

However, some devices have FLR in the Advanced Features. Xen supports
that too since 4.1.
Look for AFCap: FLR+ there.
Here on Asus P8B WS, this includes iGPU, USB hosts and SATA controller.

There's also some quirk in Xen for a certain Intel 82599 10GbE network chipset.

> If a device doesn't support FLR, then Xen does full bus reset after the
> domain (to which the device has been assigned) destroy/shutdown. I'm
> pretty sure that, at least Xen 3.x, allowed to passthrough non-FLR
> devices to domains (HVM at least).

Indeed, it will fallback to a secondary bus reset. This means
NoSoftRst- is only required and that's pretty widespread.
So, unless the guest with the forwareded device has crashed or
something really bad has happened to the card, it should work.

However, certain cards will not erase volatile firmware and some other
state when a bus reset is issued, which might throw drivers for a
loop.
(One such instance I know of is Ralink 2860 WiFi. It's been worked
around in the driver later though.)

Linux dom0 will also get better support for xen pci reset in Linux 3.4 (rc2?):
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=d4c6fa73fe984e504d52f3d6bba291fd76fe49f7
This should make Xen PCI reset irrelevant.

--
Radosław Szkodziński

Joanna Rutkowska

unread,
May 6, 2012, 4:08:02 AM5/6/12
to Radoslaw Szkodzinski, qubes...@googlegroups.com
On 05/06/12 09:18, Radoslaw Szkodzinski wrote:
> On Fri, May 4, 2012 at 10:55 PM, Joanna Rutkowska
> <joa...@invisiblethingslab.com> wrote:
>>> Set iommu=pv,required on the Xen boot line and see if it boots - this
>>> means you have secure Vt-d with interrupt remapping.
>>> If you need workaround_bios_bug, interrupt remapping will not work and
>>> you cannot use that with the required flag.
>>>
>> iommu=pv option has been removed long time ago:
>
> Indeed it has been. So it should be iommu=required or iommu=force.
>
I think the 'required' option is only needed when one uses a TXT-based
boot (tboot, in fact). Otherwise, the fact that iommu=1 is set by
default should suffice (plus checking xl info output). This is because
if we don't use tboot, then we need to trust our boot sequence anyway,
and iommu=required will not help us if that is compromised...

>>> Xen wiki says you cannot use Vt-d to pass PCI/PCIe cards that don't
>>> have FLR feature (Function Level Reset, defined in PCIe 1.1 as an
>>> optional). That feature is pretty uncommon.
>>
>> Not really -- all (most?) integrated devices on most modern chipsets are
>> FLR capable. Some notable exceptions are, of course, some NVidia
>> discrete GPUs...
>
> Nothing on this Asus P8B WS has FLReset+ with the exception of Intel HDA.
> (also LSI MegaSAS 9260 RAID controller supports it)
>

What are the CPU/chipset on this laptop? BTW, did you submit it to our
HCL? ;)

> However, some devices have FLR in the Advanced Features. Xen supports
> that too since 4.1.
> Look for AFCap: FLR+ there.
> Here on Asus P8B WS, this includes iGPU, USB hosts and SATA controller.
>
> There's also some quirk in Xen for a certain Intel 82599 10GbE network chipset.
>
>> If a device doesn't support FLR, then Xen does full bus reset after the
>> domain (to which the device has been assigned) destroy/shutdown. I'm
>> pretty sure that, at least Xen 3.x, allowed to passthrough non-FLR
>> devices to domains (HVM at least).
>
> Indeed, it will fallback to a secondary bus reset. This means
> NoSoftRst- is only required and that's pretty widespread.
> So, unless the guest with the forwareded device has crashed or
> something really bad has happened to the card, it should work.
>

The important point, that we have thoroughly investigated (on Xen 3.x at
least) was that the reset will occurred even if the domain crashed in
some random way, without Xen's blessing. Otherwise it would be an attack
vector, of course.

> However, certain cards will not erase volatile firmware and some other
> state when a bus reset is issued, which might throw drivers for a
> loop.
> (One such instance I know of is Ralink 2860 WiFi. It's been worked
> around in the driver later though.)
>
If the card doesn't properly handle reset, then, generally, it's a
security threat to the system. It should actually be the device itself
that cares about it, since the driver code is running in untrusted VM...

Do you have more details about this card and this reset-non-complaining
behavior?

joanna.

signature.asc

Radoslaw Szkodzinski

unread,
May 6, 2012, 6:18:17 AM5/6/12
to Joanna Rutkowska, qubes...@googlegroups.com
On Sun, May 6, 2012 at 10:08 AM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> On 05/06/12 09:18, Radoslaw Szkodzinski wrote:
>> On Fri, May 4, 2012 at 10:55 PM, Joanna Rutkowska
>> <joa...@invisiblethingslab.com> wrote:
>>>> Set iommu=pv,required on the Xen boot line and see if it boots - this
>>>> means you have secure Vt-d with interrupt remapping.
>>>> If you need workaround_bios_bug, interrupt remapping will not work and
>>>> you cannot use that with the required flag.
>>>>
>>> iommu=pv option has been removed long time ago:
>>
>> Indeed it has been. So it should be iommu=required or iommu=force.
>>
> I think the 'required' option is only needed when one uses a TXT-based
> boot (tboot, in fact). Otherwise, the fact that iommu=1 is set by
> default should suffice (plus checking xl info output). This is because
> if we don't use tboot, then we need to trust our boot sequence anyway,
> and iommu=required will not help us if that is compromised...

One can have working tboot and broken IOMMU/Vt-d support. (e.g.
without interrupt remapping)
It is true though that this switch is mostly for diagnostic purposes.

>>>> Xen wiki says you cannot use Vt-d to pass PCI/PCIe cards that don't
>>>> have FLR feature (Function Level Reset, defined in PCIe 1.1 as an
>>>> optional). That feature is pretty uncommon.
>>>
>>> Not really -- all (most?) integrated devices on most modern chipsets are
>>> FLR capable. Some notable exceptions are, of course, some NVidia
>>> discrete GPUs...
>>
>> Nothing on this Asus P8B WS has FLReset+ with the exception of Intel HDA.
>> (also LSI MegaSAS 9260 RAID controller supports it)
>>
>
> What are the CPU/chipset on this laptop? BTW, did you submit it to our
> HCL? ;)

It's not a laptop, it's a mainboard in a workstation. :)
Xeon E3 1275, Intel C206.

tboot is in use with an Asus TPM-Infineon module. (supports full TPM
1.2, unlike some Atmel modules)

(We'd be lucky if laptops that good were available... Thinkpads W come
the closest.)

>> However, certain cards will not erase volatile firmware and some other
>> state when a bus reset is issued, which might throw drivers for a
>> loop.
>> (One such instance I know of is Ralink 2860 WiFi. It's been worked
>> around in the driver later though.)
>>
> If the card doesn't properly handle reset, then, generally, it's a
> security threat to the system. It should actually be the device itself
> that cares about it, since the driver code is running in untrusted VM...
>
> Do you have more details about this card and this reset-non-complaining
> behavior?

PCIe Specification v 1.1 only mandates that the registers and PCIe
state have to be reset. (see section 6.6)
This is identical to the requirements about RST# in PCI 2.3
specification, which says nothing about internal device state,
only about visible device state.

(page 23 of PCI-SIG Specification v2.3)
"RST# in
Reset is used to bring PCI-specific registers, sequencers, and
signals to a consistent state. What effect RST# has on a
device beyond the PCI sequencer is beyond the scope of this
specification, except for reset states of required PCI
configuration registers."

D3cold power state actually is mandated to remove Vcc and requires the
system to POST the device.
I suspect though that Linux will use D3hot whenever available.

The actually compliant behavior involves firmware staying loaded and
certain internal registers keeping their state.
Details can be seen in rt2800pci driver - the driver has to forcibly
reinitialize the card. Possibly other state can be retrieved.
(This has been hit a long time ago, the driver started after staging
driver rt2860sta has been loaded once and not due to broken firmware
upload, but due to registers having been correctly set already.)

Link:
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/net/wireless/rt2x00/rt2800pci.c;h=0397bbf0ce018d7d651fc0eb82283aeb4db9abe7;hb=HEAD#l461

--
Radosław Szkodziński

Joanna Rutkowska

unread,
May 6, 2012, 6:21:53 AM5/6/12
to Radoslaw Szkodzinski, qubes...@googlegroups.com
On 05/06/12 12:18, Radoslaw Szkodzinski wrote:
> On Sun, May 6, 2012 at 10:08 AM, Joanna Rutkowska
> <joa...@invisiblethingslab.com> wrote:
>> > On 05/06/12 09:18, Radoslaw Szkodzinski wrote:
>>> >> On Fri, May 4, 2012 at 10:55 PM, Joanna Rutkowska
>>> >> <joa...@invisiblethingslab.com> wrote:
>>>>> >>>> Set iommu=pv,required on the Xen boot line and see if it boots - this
>>>>> >>>> means you have secure Vt-d with interrupt remapping.
>>>>> >>>> If you need workaround_bios_bug, interrupt remapping will not work and
>>>>> >>>> you cannot use that with the required flag.
>>>>> >>>>
>>>> >>> iommu=pv option has been removed long time ago:
>>> >>
>>> >> Indeed it has been. So it should be iommu=required or iommu=force.
>>> >>
>> > I think the 'required' option is only needed when one uses a TXT-based
>> > boot (tboot, in fact). Otherwise, the fact that iommu=1 is set by
>> > default should suffice (plus checking xl info output). This is because
>> > if we don't use tboot, then we need to trust our boot sequence anyway,
>> > and iommu=required will not help us if that is compromised...
> One can have working tboot and broken IOMMU/Vt-d support. (e.g.
> without interrupt remapping)

That's why I said, above, that iommu=required is need (only) when we
have TXT-based boot, e.g. tboot.

> It is true though that this switch is mostly for diagnostic purposes.
>
No, it's not -- see above.

joanna.

signature.asc

Radoslaw Szkodzinski

unread,
May 6, 2012, 6:41:03 AM5/6/12
to Joanna Rutkowska, qubes...@googlegroups.com
On Sun, May 6, 2012 at 12:21 PM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> That's why I said, above, that iommu=required is need (only) when we
> have TXT-based boot, e.g. tboot.

If you have tboot and IOMMU enabled and (verified) working, the switch
is quite superfluous.
Unless perhaps someone compromises IOMMU without requiring TXT unseal
or TXT break altogether.

Via EFI settings? Some attack on DMAR? (e.g. setting x2APIC_OPT_OUT?)

I wouldn't trust TPM or firmware that allows this.

--
Radosław Szkodziński

Joanna Rutkowska

unread,
May 6, 2012, 6:55:54 AM5/6/12
to Radoslaw Szkodzinski, qubes...@googlegroups.com
See our "White Rabbit" paper for a discussion on this, and the followup
xen-devel discussions with Joe Cihula.

joanna.

signature.asc

Radoslaw Szkodzinski

unread,
May 6, 2012, 8:13:55 AM5/6/12
to Joanna Rutkowska, qubes...@googlegroups.com
On Sun, May 6, 2012 at 12:55 PM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> See our "White Rabbit" paper for a discussion on this, and the followup
> xen-devel discussions with Joe Cihula.

In other words, TPM should validate some MBR and Firmware checksum,
Firmware should validate the TPM chip and CPU ids.
Attack averted?

(It's not like anyone is changing the MBR every other day. Requiring
an unseal for that is reasonable.)

--
Radosław Szkodziński
Reply all
Reply to author
Forward
0 new messages