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