Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4219840pxj; Mon, 21 Jun 2021 16:54:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIBxvVnj5kRWIvsPnYRBhzLzBtyPLeM7e7AW/oxLACE9AyWzZws/9lmfX88pPX3zxqKOAb X-Received: by 2002:a02:b19b:: with SMTP id t27mr951443jah.29.1624319671717; Mon, 21 Jun 2021 16:54:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624319671; cv=none; d=google.com; s=arc-20160816; b=c6M0K9+HGHf+O/C8CIjh8TIRA6DoDFNkKLO1rb6C9GIvVV4u7bOU/4417w9qg2smpI Y+AtspE0MsXpqWXQrZWnkdEAUlOHj1ifn28/bPZvQLooA0J9UoXGPX+SKC5blfUeW2m4 PE5Opq2FpmsUwHx8AMp4ipaCqraCwm8dPwTuLDqROOtRCo0l2njPGtFsP7it0omzhLX4 VfEYFZxQt1zs9Yb2nZ9LjgM5NuhBkXWUSJuDkwXKOLY7Y7zN0OgF6MvSpEqpm0wFgRMC naM34A7bHACPArfnYSskKx2JwGART45VIvrIiVC5ploxbXXLleFfvZuKXw9B1c3/SWnj zCDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=KLTgOAPTL/hdLPXehUk7jin9tlU4DA3I5amBsr+XFlI=; b=eb6j4E2Q3k0EXhKfdbPW4TWpW+dMPtAh1UhE5XPVa5OD6ssnj8oadPnR693Zxu05vq 3VykdrCXGszc6W22UZMYlXHC+1SRgJnrEHm0m9YS4CENOdD4l6IhfsbS0ueLVVmq7zGw pbVv5W3swahtL0Tk8DNEgLp+7/+imRq2C1wHyYLsBgPQ1s+TEFWqBiwXKeUgUI2Lib6T a0lbRU/TcDvAB80pO2lqLs4sVPMNgMo8R8rQW8nztlIpIoSH2XEiNubylK7gV2EmmxAU K9rh6/aN+8dnQ7p2EMP4AHGjHmwYxZAiVeqCQQnR4yp80pA+X8Vciqb4EztKqkdftj5L UxSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=IakNO8AV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i26si19971279iol.73.2021.06.21.16.54.19; Mon, 21 Jun 2021 16:54:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=IakNO8AV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232355AbhFUXze (ORCPT + 99 others); Mon, 21 Jun 2021 19:55:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232290AbhFUXz3 (ORCPT ); Mon, 21 Jun 2021 19:55:29 -0400 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFBF7C0617AF for ; Mon, 21 Jun 2021 16:53:13 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id f10so7314468plg.0 for ; Mon, 21 Jun 2021 16:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KLTgOAPTL/hdLPXehUk7jin9tlU4DA3I5amBsr+XFlI=; b=IakNO8AV5d2AjRngN+nO9dr4scVOZ/i0GXGfPwpIa86ahW3Gx5lGZr/Qvp7nX9QLEF ah2PHyMzxecYm5jvWAhtwLlNrNpFAqJF7xOfwTdlDZQDqN2rtdNZFIoQTtMU1ur4ZApC 7UbMpvJg4P3n/t96Z0aCStxGsE3he4J8bRing= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=KLTgOAPTL/hdLPXehUk7jin9tlU4DA3I5amBsr+XFlI=; b=OEFGSTI/Hgh9R7E3NXiYXAwXZ6j8z1BxY/FSIY8rZnFGt+U91Z3ziXMFdvwKRHgHnK xco/sw6hc7165gIYO807gu1kyZzf9sPnJzvZivZJluOkEfjFv2RuPI0HHXf7hganVkZN Re9Lfj6fB6o2awH/UIDIpKmiNiF4YX5Kr/tTd1ksrHJ43J9HTQCs8uJi2ks39UnPMxwz iqgZ1VcmmBpk/flLMHEbljuyw0V/tQJw3pT5GcpjHWEkbOVQ2p3Ama/uvXfDvKchwYUu nOEQRx6OFz/D+gfxqcOvdqFoqcWxFbavTvPk/xg2uG2FcKfsFM+Nte9OMkSxNxnfkUWq IzwQ== X-Gm-Message-State: AOAM53358lZV0N4vkPUoCfxfagmRn1ajNW4CLdfEX/5ZH1mGqbDuWncC j2MfHcUZAz5xLAi31XKS5Ef/8Q== X-Received: by 2002:a17:90a:be03:: with SMTP id a3mr611377pjs.43.1624319593246; Mon, 21 Jun 2021 16:53:13 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:bdc1:a4b1:b06e:91d1]) by smtp.gmail.com with ESMTPSA id s27sm4339663pfg.169.2021.06.21.16.53.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Jun 2021 16:53:12 -0700 (PDT) From: Douglas Anderson To: gregkh@linuxfoundation.org, rafael@kernel.org, rafael.j.wysocki@intel.com, will@kernel.org, robin.murphy@arm.com, joro@8bytes.org, bjorn.andersson@linaro.org, ulf.hansson@linaro.org, adrian.hunter@intel.com, bhelgaas@google.com Cc: robdclark@chromium.org, linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org, quic_c_gdjako@quicinc.com, iommu@lists.linux-foundation.org, sonnyrao@chromium.org, saiprakash.ranjan@codeaurora.org, linux-mmc@vger.kernel.org, vbadigan@codeaurora.org, rajatja@google.com, saravanak@google.com, joel@joelfernandes.org, Douglas Anderson , Bartosz Golaszewski , Dan Williams , Heikki Krogerus , Randy Dunlap , linux-kernel@vger.kernel.org Subject: [PATCH 2/6] drivers: base: Add bits to struct device to control iommu strictness Date: Mon, 21 Jun 2021 16:52:44 -0700 Message-Id: <20210621165230.2.Icfe7cbb2cc86a38dde0ee5ba240e0580a0ec9596@changeid> X-Mailer: git-send-email 2.32.0.288.g62a8d224e6-goog In-Reply-To: <20210621235248.2521620-1-dianders@chromium.org> References: <20210621235248.2521620-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org How to control the "strictness" of an IOMMU is a bit of a mess right now. As far as I can tell, right now: * You can set the default to "non-strict" and some devices (right now, only PCI devices) can request to run in "strict" mode. * You can set the default to "strict" and no devices in the system are allowed to run as "non-strict". I believe this needs to be improved a bit. Specifically: * We should be able to default to "strict" mode but let devices that claim to be fairly low risk request that they be run in "non-strict" mode. * We should allow devices outside of PCIe to request "strict" mode if the system default is "non-strict". I believe the correct way to do this is two bits in "struct device". One allows a device to force things to "strict" mode and the other allows a device to _request_ "non-strict" mode. The asymmetry here is on purpose. Generally if anything in the system makes a request for strictness of something then we want it strict. Thus drivers can only request (but not force) non-strictness. It's expected that the strictness fields can be filled in by the bus code like in the patch ("PCI: Indicate that we want to force strict DMA for untrusted devices") or by using the new pre_probe concept introduced in the patch ("drivers: base: Add the concept of "pre_probe" to drivers"). Signed-off-by: Douglas Anderson --- include/linux/device.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/include/linux/device.h b/include/linux/device.h index f1a00040fa53..c1b985e10c47 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -449,6 +449,15 @@ struct dev_links_info { * and optionall (if the coherent mask is large enough) also * for dma allocations. This flag is managed by the dma ops * instance from ->dma_supported. + * @force_strict_iommu: If set to %true then we should force this device to + * iommu.strict regardless of the other defaults in the + * system. Only has an effect if an IOMMU is in place. + * @request_non_strict_iommu: If set to %true and there are no other known + * reasons to make the iommu.strict for this device, + * then default to non-strict mode. This implies + * some belief that the DMA master for this device + * won't abuse the DMA path to compromise the kernel. + * Only has an effect if an IOMMU is in place. * * At the lowest level, every device in a Linux system is represented by an * instance of struct device. The device structure contains the information @@ -557,6 +566,8 @@ struct device { #ifdef CONFIG_DMA_OPS_BYPASS bool dma_ops_bypass : 1; #endif + bool force_strict_iommu:1; + bool request_non_strict_iommu:1; }; /** -- 2.32.0.288.g62a8d224e6-goog