Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1724843ybg; Sat, 19 Oct 2019 01:08:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqx19u+Xec7/nB2bjm28yY3luvkIRyCvfQtxp2L10oytte02L6lfT/+XaWSC72pJVN10zU18 X-Received: by 2002:a05:6402:1255:: with SMTP id l21mr767019edw.41.1571472504193; Sat, 19 Oct 2019 01:08:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571472504; cv=none; d=google.com; s=arc-20160816; b=fCbS/8iOahNbahzxC+1GFewDK+3Tvfbn1QFicWgt8oF6REjxiy6aGvD9YKTMu5t9kP 9Rr4+d5VUO6EbmcaqT2M9rKXJSYSgS8QSss9lsDTgLAGPj/jpt3K0M1PfENyG27Vz6+2 hCfiwbbTrSBwy2+4y9lDeZaAz36UwyFX5RO3lm7wOfCIHogJoc4xLuP2/BKfKunLPI/F JApmGujAcELodHRSHoJ5ojPmXFY8GimxBe2rO7RVmpPW/khFdZCNaPkl0BZTQ3Zoi0hs MVClc8sg5TY/ggK4aX7U87VxsqSHoSu6FjbOdGvpx8ClxbFHdDlny7six/Poumltm4ai XJmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=/QC2nnMNmQZ7AIk2ETZnAUBho6yZfHlovy15BO9E6Vk=; b=IvfpYj3Cs+810BLpFmDx1FvQnDtUD5aIXUlAh9VsrYf67NIyGjoC/IAHidjPvoML1x 0uwmuVtsADYGGqOiK0A0tHyMuvLn42b5rllW8PZvM6ZMr+k8I2D90FFOBY2/tj6LtBdj okkSW6Ur99dhs7sd+mhalyXVwz/lOCzjecTH8NnTzfod8sb3w8ea27W1/6416rA5x9a9 n5/AixCWSpkeCVRmkuwHfImwy4WhMfZ9S2O8KthWaT0UFpaBAlP8UBdusSQPLkdfQqFY 1dfqD1tP1xGIQdKFk/EOyymq8JHO2qn2lBEDydUTZZmQ/oh3TxyfJ/wLiAdr4xsFdhmT Hbwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x9si4656999eju.147.2019.10.19.01.08.01; Sat, 19 Oct 2019 01:08:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404530AbfJRJig (ORCPT + 99 others); Fri, 18 Oct 2019 05:38:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:51944 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727917AbfJRJig (ORCPT ); Fri, 18 Oct 2019 05:38:36 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 693F2B1D5; Fri, 18 Oct 2019 09:38:34 +0000 (UTC) Date: Fri, 18 Oct 2019 11:38:30 +0200 From: Joerg Roedel To: Qian Cai Cc: Jerry Snitselaar , don.brace@microsemi.com, martin.petersen@oracle.com, linux-scsi@vger.kernel.org, jejb@linux.ibm.com, esc.storagedev@microsemi.com, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org Subject: [PATCH] iommu/amd: Check PM_LEVEL_SIZE() condition in locked section Message-ID: <20191018093830.GA26328@suse.de> References: <20191016225859.j3jq6pt73mn56chn@cantor> <577A2A6B-3012-4CDE-BE57-3E0D628572CB@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577A2A6B-3012-4CDE-BE57-3E0D628572CB@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 17, 2019 at 07:36:51AM -0400, Qian Cai wrote: > > > > On Oct 16, 2019, at 6:59 PM, Jerry Snitselaar wrote: > > > > I guess the mode level 6 check is really for other potential callers > > increase_address_space, none exist at the moment, and the condition > > of the while loop in alloc_pte should fail if the mode level is 6. > > Because there is no locking around iommu_map_page(), if there are > several concurrent callers of it for the same domain, could it be that > it silently corrupt data due to invalid access? No, that can't happen because increase_address_space locks the domain before actually doing anything. So the address space can't grow above domain->mode == 6. But what can happen is that the WARN_ON_ONCE triggers in there and that the address space is increased multiple times when only one increase would be sufficient. To fix this we just need to check the PM_LEVEL_SIZE() condition again when we hold the lock: From e930e792a998e89dfd4feef15fbbf289c45124dc Mon Sep 17 00:00:00 2001 From: Joerg Roedel Date: Fri, 18 Oct 2019 11:34:22 +0200 Subject: [PATCH] iommu/amd: Check PM_LEVEL_SIZE() condition in locked section The increase_address_space() function has to check the PM_LEVEL_SIZE() condition again under the domain->lock to avoid a false trigger of the WARN_ON_ONCE() and to avoid that the address space is increase more often than necessary. Reported-by: Qian Cai Fixes: 754265bcab78 ("iommu/amd: Fix race in increase_address_space()") Signed-off-by: Joerg Roedel --- drivers/iommu/amd_iommu.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 2369b8af81f3..a0639e511ffe 100644 --- a/drivers/iommu/amd_iommu.c +++ b/drivers/iommu/amd_iommu.c @@ -1463,6 +1463,7 @@ static void free_pagetable(struct protection_domain *domain) * to 64 bits. */ static bool increase_address_space(struct protection_domain *domain, + unsigned long address, gfp_t gfp) { unsigned long flags; @@ -1471,8 +1472,8 @@ static bool increase_address_space(struct protection_domain *domain, spin_lock_irqsave(&domain->lock, flags); - if (WARN_ON_ONCE(domain->mode == PAGE_MODE_6_LEVEL)) - /* address space already 64 bit large */ + if (address <= PM_LEVEL_SIZE(domain->mode) || + WARN_ON_ONCE(domain->mode == PAGE_MODE_6_LEVEL)) goto out; pte = (void *)get_zeroed_page(gfp); @@ -1505,7 +1506,7 @@ static u64 *alloc_pte(struct protection_domain *domain, BUG_ON(!is_power_of_2(page_size)); while (address > PM_LEVEL_SIZE(domain->mode)) - *updated = increase_address_space(domain, gfp) || *updated; + *updated = increase_address_space(domain, address, gfp) || *updated; level = domain->mode - 1; pte = &domain->pt_root[PM_LEVEL_INDEX(level, address)]; -- 2.16.4