linux-kernel - Re: [RFC] iommu/vt-d: Use the SIRTP when enabling remapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <541004B6.8070800@sgi.com>
Date:	Wed, 10 Sep 2014 02:58:46 -0500
From:	Gary Kroening <gfk@....com>
To:	Jan Kiszka <jan.kiszka@...mens.com>,
	Nathan Zimmer <nzimmer@....com>, jroedel@...e.de
Cc:	iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] iommu/vt-d: Use the SIRTP when enabling remapping

On 9/10/2014 1:56 AM, Jan Kiszka wrote:
> On 2014-09-09 23:11, Nathan Zimmer wrote:
>> The previous change (iommu/vt-d: Don't store SIRTP request) to this area
>> caused a crash in our simulator. In particular is seems that by the time a
>> UART interrupt is sent through the system, we don't see interrupt remapping
>> to be enabled.  So the interrupt does not get translated to a logical
>> interrupt and crashes.
>>
>> OR'ing the SIRTP request to make sure it is seen but hopefully not sticky.
>> This seems like a clean fix, at least on our simulator; if you don't agree,
>> our simulator guy will take a closer look at our iommu model.
>
> Check the VT-d spec (6.7, Set Interrupt Remapping Table Pointer
> Operation): "Software must always follow the interrupt-remapping table
> pointer set operation with a global invalidate of the IEC to ensure
> hardware references the new structures *before* enabling interrupt
> remapping." There is also (command register description): "If multiple
> control fields in this register need to be modified, software must
> serialize the modifications through multiple writes to this register."
> This, in combination with the command registers description of bits 24
> and 25 strongly suggests that your model is broken.

Thanks, Jan. I'll read up on it. Still working out some kinks with
the relatively new IOMMU/interrupt-remapping logic which we added over
the last 18 months or so. Sorry for any distraction, and thanks for the
help/info.
Gary

>
>>
>> Found testing on our simulator, not real hardware.
>
> Funnily, the original issue was found by the QEMU model of VT-d that
> used to take the last cited sentence very strictly (I asked to remove it
> due to the preexisting Linux versions).
>
> Jan
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/