Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp144148imm; Tue, 24 Jul 2018 15:47:57 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdygGXbAFy0EnEeABfkyxAbkCLqm4Z0zq+4F4cWZtTaUKSLTNn5UKxIqOt7gfAxpiqEi23c X-Received: by 2002:a17:902:b189:: with SMTP id s9-v6mr18467141plr.188.1532472477709; Tue, 24 Jul 2018 15:47:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532472477; cv=none; d=google.com; s=arc-20160816; b=RSc6fXs+sI1sr2ZY2AEDpaV5yeOJocY+GvW9cbGw6WVJkGxXjD++A17MoeJ06aT9bf lXvkDtOz7kTanXJihs6UZpUK1kxsshI/Qnjtc/lX7gsUJQRqJpeeAJCgcnuv9fqJGf2a KnDKSRpgkUl0McvncFqUYtz1UtomoEVKhtL3+7sIbsT82baRBx0FXklYNe4/xGtNdIe3 056IXjskmA0u/oiAw9e8CFDCDFqTrqkLF7xd+DBUQpOhrDgi+ebd+uD4tBPPBePHABFF 0IbeFo47XBxHXtScb2lXnNHz2B9HaDuk2ynmLk3H6hGcx+w47Kc4Ht1vLkOAq42kcO3g uBRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=BgMgFyczqYAkf0TrKRr6moBKVkmWr+i3Kv/B1cbSl6A=; b=YQRiFXb5OPajp3Gf2WcjT+8dlycx8bBLiyxd6My7Pb1QeGHxlDUmUu1adxLFw4gG+O Ch9CcMJhNvVEnqOLIZNNWGdkVqrP+0ZwEkgEw/99t0v/k2gYUEMtlLwlGKxhT6SngMN1 pN3YvLLCIg1HXHFfzEDkM3B2qoKP8VeNv0hKHOQImMWje40DFqH3Y88dPEPLK9jduvgq VPL1HNvOnDVC0/fivR6V0El9T+kxX5XFY4bIAZqdiTft+32hem2JVnNn+p1+tETU7KJa spPq9JMIQXx4LU8F4Z8zzCM11nCGY5OCqx0zjsidt3+LP6hVB0knL4nK0TRCKeSkwwwE frDA== 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 28-v6si12757438pgk.111.2018.07.24.15.47.41; Tue, 24 Jul 2018 15:47:57 -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 S2388879AbeGXXza (ORCPT + 99 others); Tue, 24 Jul 2018 19:55:30 -0400 Received: from foss.arm.com ([217.140.101.70]:58680 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388679AbeGXXz3 (ORCPT ); Tue, 24 Jul 2018 19:55:29 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C4CDC7A9; Tue, 24 Jul 2018 15:46:48 -0700 (PDT) Received: from [192.168.1.123] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A69C33F5B3; Tue, 24 Jul 2018 15:46:46 -0700 (PDT) Subject: Re: [PATCH v3 6/6] iommu/arm-smmu-v3: add bootup option "iommu_strict_mode" To: Zhen Lei , Jean-Philippe Brucker , Will Deacon , Joerg Roedel , linux-arm-kernel , iommu , linux-kernel References: <1531376312-2192-1-git-send-email-thunder.leizhen@huawei.com> <1531376312-2192-7-git-send-email-thunder.leizhen@huawei.com> From: Robin Murphy Message-ID: <33053c8f-3ac3-e1d6-e260-fd36c4af9312@arm.com> Date: Tue, 24 Jul 2018 23:46:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1531376312-2192-7-git-send-email-thunder.leizhen@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-07-12 7:18 AM, Zhen Lei wrote: > Because the non-strict mode introduces a vulnerability window, so add a > bootup option to make the manager can choose which mode to be used. The > default mode is IOMMU_STRICT. > > Signed-off-by: Zhen Lei > --- > Documentation/admin-guide/kernel-parameters.txt | 12 ++++++++++ > drivers/iommu/arm-smmu-v3.c | 32 ++++++++++++++++++++++--- > 2 files changed, 41 insertions(+), 3 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index efc7aa7..0cc80bc 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -1720,6 +1720,18 @@ > nobypass [PPC/POWERNV] > Disable IOMMU bypass, using IOMMU for PCI devices. > > + iommu_strict_mode= [arm-smmu-v3] If anything this should belong to iommu-dma, as that's where the actual decision of whether to use a flush queue or not happens. Also it would be nice to stick to the iommu.* option namespace in the hope of maintaining some consistency. > + 0 - strict mode > + Make sure all related TLBs to be invalidated before the > + memory released. > + 1 - non-strict mode > + Put off TLBs invalidation and release memory first. This mode > + introduces a vlunerability window, an untrusted device can > + access the reused memory because the TLBs may still valid. > + Please take full consideration before choosing this mode. > + Note that, VFIO is always use strict mode. > + others - strict mode > + > iommu.passthrough= > [ARM64] Configure DMA to bypass the IOMMU by default. > Format: { "0" | "1" } > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c > index 4a198a0..9b72fc4 100644 > --- a/drivers/iommu/arm-smmu-v3.c > +++ b/drivers/iommu/arm-smmu-v3.c > @@ -631,6 +631,24 @@ struct arm_smmu_option_prop { > { 0, NULL}, > }; > > +static u32 iommu_strict_mode __read_mostly = IOMMU_STRICT; > + > +static int __init setup_iommu_strict_mode(char *str) > +{ > + u32 strict_mode = IOMMU_STRICT; > + > + get_option(&str, &strict_mode); > + if (strict_mode == IOMMU_NON_STRICT) { > + iommu_strict_mode = strict_mode; > + pr_warn("WARNING: iommu non-strict mode is chose.\n" > + "It's good for scatter-gather performance but lacks full isolation\n"); > + add_taint(TAINT_WARN, LOCKDEP_STILL_OK); > + } > + > + return 0; > +} > +early_param("iommu_strict_mode", setup_iommu_strict_mode); > + > static inline void __iomem *arm_smmu_page1_fixup(unsigned long offset, > struct arm_smmu_device *smmu) > { > @@ -1441,7 +1459,7 @@ static bool arm_smmu_capable(enum iommu_cap cap) > case IOMMU_CAP_NOEXEC: > return true; > case IOMMU_CAP_NON_STRICT: > - return true; > + return (iommu_strict_mode == IOMMU_NON_STRICT) ? true : false; Ugh. The "completely redundant ternany" idiom hurts my soul :( Robin. > default: > return false; > } > @@ -1750,6 +1768,14 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > return ret; > } > > +static u32 arm_smmu_strict_mode(struct iommu_domain *domain) > +{ > + if (iommu_strict_mode == IOMMU_NON_STRICT) > + return IOMMU_DOMAIN_STRICT_MODE(domain); > + > + return IOMMU_STRICT; > +} > + > static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova, > phys_addr_t paddr, size_t size, int prot) > { > @@ -1769,7 +1795,7 @@ static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova, > if (!ops) > return 0; > > - return ops->unmap(ops, iova | IOMMU_DOMAIN_STRICT_MODE(domain), size); > + return ops->unmap(ops, iova | arm_smmu_strict_mode(domain), size); > } > > static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain) > @@ -1784,7 +1810,7 @@ static void arm_smmu_iotlb_sync(struct iommu_domain *domain) > { > struct arm_smmu_device *smmu = to_smmu_domain(domain)->smmu; > > - if (smmu && (IOMMU_DOMAIN_STRICT_MODE(domain) == IOMMU_STRICT)) > + if (smmu && (arm_smmu_strict_mode(domain) == IOMMU_STRICT)) > __arm_smmu_tlb_sync(smmu); > } > >