Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp149551imm; Thu, 26 Jul 2018 00:42:30 -0700 (PDT) X-Google-Smtp-Source: AAOMgpczg4qwHHhI8cmHGfN7aPYYwjh7QOtXXrP3w7qSLYlXRt5bUxIAzo4Ca2n+6omM9g2DXo8w X-Received: by 2002:a62:3b89:: with SMTP id w9-v6mr1013841pfj.80.1532590950590; Thu, 26 Jul 2018 00:42:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532590950; cv=none; d=google.com; s=arc-20160816; b=J/SXX+OqRMC39Ym8oDACnz0X4QELYwNWeU9MBTwSR7baOu88Ng4vu2fu1+UsNXUulZ QHqrWJMFGOSegQF7nFY14GXNfEuTN31LZAtI6GiC19xnug5V2EsHpTRCeZOyTS/riXNv dvJsfYbcNEFov/b/jtGC9bNHO164VKhvpwtCpf3c48Kgf1gvTFzVxoXSgE44b0Bg8zNz 2jWgSqbxC0krSMv8QdzcRAXVxA/SQZsZL9Njf9BWER9tfkOzsB3jnUtMacDNZSpOiyqZ BN8AC702WkqvX9EzKh/xJW5u5dze/KS00IjIaYqD3AvBk1WbI/v1Qe1GQt2g6xDzG09u /fYw== 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:in-reply-to :mime-version:user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=Tb3TE6gNbYdxUwt9eeSzMl2GYbxXvLpZE4tIdSjlltk=; b=yu95F9VJGizGFZnamU2HFb5tyHlQh0OtoEzWuE/fugLPdDKG8wnJyiGh5cWpAUGJWl GAF66MdCxUMnVn0QwVcYPdNbRoHAPw5UOq2IYS7n5me+Ljx29th70fGXn28Am8DVCPzb qWZnhAROquOwMnSUGMl0wjnMtJ5US6xbJPb2+RcXvQureoVpfuSmkbMkVOjskIktW9Yd X4f4j9+x4eLN4u4eW3qTMZBp73CliuVHeI1Sk6k9qyxMbAvk0mpVZuhHPqJWwmLbZw9o FRl9jCt8gH2eOGBuE4CvvDXnMPvTUVIFcVlkZhh6xTXZ1oGMezR5kaKoDiI5kNNPjyvf Zozg== 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 n8-v6si663842plk.255.2018.07.26.00.42.15; Thu, 26 Jul 2018 00:42:30 -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 S1729002AbeGZI4y (ORCPT + 99 others); Thu, 26 Jul 2018 04:56:54 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:49866 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726734AbeGZI4x (ORCPT ); Thu, 26 Jul 2018 04:56:53 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id E8D009C218EAD; Thu, 26 Jul 2018 15:41:15 +0800 (CST) Received: from [127.0.0.1] (10.177.23.164) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.382.0; Thu, 26 Jul 2018 15:41:08 +0800 Subject: Re: [PATCH v3 6/6] iommu/arm-smmu-v3: add bootup option "iommu_strict_mode" To: Robin Murphy , Jean-Philippe Brucker , Will Deacon , "Joerg Roedel" , linux-arm-kernel , iommu , linux-kernel , LinuxArm References: <1531376312-2192-1-git-send-email-thunder.leizhen@huawei.com> <1531376312-2192-7-git-send-email-thunder.leizhen@huawei.com> <33053c8f-3ac3-e1d6-e260-fd36c4af9312@arm.com> From: "Leizhen (ThunderTown)" Message-ID: <5B597B12.9020600@huawei.com> Date: Thu, 26 Jul 2018 15:41:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <33053c8f-3ac3-e1d6-e260-fd36c4af9312@arm.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/7/25 6:46, Robin Murphy wrote: > 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. How about arm_iommu? like "s390_iommu" and "intel_iommu". After all it only affect smmu now. > >> + 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 :( OK, I will modify it. > > 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); >> } >> > > . > -- Thanks! BestRegards