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:	Sun, 10 Jul 2016 19:40:53 +0800
From:	Wan Zongshun <vw@...mu.org>
To:	Joerg Roedel <joro@...tes.org>, iommu@...ts.linux-foundation.org
Cc:	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 2016年07月07日 00:00, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@...e.de>
>
> There is a race condition in the AMD IOMMU init code that
> causes requested unity mappings to be blocked by the IOMMU
> for a short period of time. This results on boot failures
> and IO_PAGE_FAULTs on some machines.
>
> Fix this by making sure the unity mappings are installed
> before all other DMA is blocked.
>
> Fixes: aafd8ba0ca74 ('iommu/amd: Implement add_device and remove_device')
> Cc: stable@...r.kernel.org # v4.2+
> Signed-off-by: Joerg Roedel <jroedel@...e.de>
> ---
>   drivers/iommu/amd_iommu_init.c | 14 ++++++++++++--
>   1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index d091def..59741ea 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -1568,13 +1568,23 @@ static int __init amd_iommu_init_pci(void)
>   			break;
>   	}
>
> +	/*
> +	 * Order is important here to make sure any unity map requirements are
> +	 * fulfilled. The unity mappings are created and written to the device
> +	 * table during the amd_iommu_init_api() call.
> +	 *
> +	 * After that we call init_device_table_dma() to make sure any
> +	 * uninitialized DTE will block DMA, and in the end we flush the caches
> +	 * of all IOMMUs to make sure the changes to the device table are
> +	 * active.
> +	 */

Joerg,

Do you mean we need enable the V and TV bits to DTE entry after all DTEs 
tables were initialized completely?

I checked this function 'init_device_table_dma', and find it just set
V and TV bit, to set translation info valid and DTE bits127:1 valid.

So I just think all things it should to do are to allow DMA access,
GPA-to-SPA translation should be active, why you add function comments 
below is to not allow DMA access and suppress all page faults?

/*
  * Init the device table to not allow DMA access for devices and
  * suppress all page faults
  */
static void init_device_table_dma(void)

> +	ret = amd_iommu_init_api();
> +
>   	init_device_table_dma();
>
>   	for_each_iommu(iommu)
>   		iommu_flush_all_caches(iommu);
>
> -	ret = amd_iommu_init_api();
> -
>   	if (!ret)
>   		print_iommu_info();
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ