linux-kernel - Re: [PATCH] iommu/amd: Fix unity mapping initialization race

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 11 Jul 2016 11:39:07 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	Wan Zongshun <vw@...mu.org>
Cc:	iommu@...ts.linux-foundation.org, Joerg Roedel <jroedel@...e.de>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] iommu/amd: Fix unity mapping initialization race

On Mon, Jul 11, 2016 at 05:25:29PM +0800, Wan Zongshun wrote:
> Okay, this patch should also better to general case not only unity-mapping.
> 
> How about the interrupt remap function? Do we need same considering
> for IV bit enable for interrupt remap?

No, there are no unity mappings for irqs, so we are not running into the
same race here.

> Sorry, why you still say this 'init_device_table_dma' can block DMA?
> I just think this function will enable DMA transfer, since  we set
> the V and TV bits, right? or I misunderstand what "block DMA" mean?

When the V and TV bits are not set, it means that all DMA from that
device-id is forwared untranslated by the IOMMU. But if we set V and TV
it means that there is translation information, and the IOMMU translates
the requests using the rest of the DTE information. As all other bits
are 0, this means that page-table-level is 0 (== no page-table) and that
the global IW and IR bits are 0 too (== no read and write permissions).
So all requests are blocked.

	Joerg