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]
Date:	Wed, 10 Sep 2014 08:56:20 +0200
From:	Jan Kiszka <jan.kiszka@...mens.com>
To:	Nathan Zimmer <nzimmer@....com>, jroedel@...e.de
CC:	iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Gary Kroening <gfk@....com>
Subject: Re: [RFC] iommu/vt-d: Use the SIRTP when enabling remapping

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.

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

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ