Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2294532pxb; Wed, 9 Feb 2022 15:24:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJywgVx8AxGzeBXzW/e80jstwgRyk+1GxrasX9gkhvBTb1rv5mid/iD5EPOF1x00em2d/Pxj X-Received: by 2002:a17:90a:eb17:: with SMTP id j23mr6200530pjz.76.1644449087399; Wed, 09 Feb 2022 15:24:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644449087; cv=none; d=google.com; s=arc-20160816; b=nzf/+Q4qBDPZSU3Fc2SUnT7Bp5dSBpOY8tJoOJkkj5q7IyadYB/RFrUKOtRbGutzHS RjK/sep8HYvHJceGfY8adRyYbFy8JdcYBaeljARckYZoXWQH4J9vaYrsJPZe8JreRcXX xU0l2myYEqZ2Xl+1MD0ChjTcfzUqKDYhiHA84QuM7HjkfuU0n3nuWgwa6shuphzXQM13 1/XDFnqe9GNGJY4CRnCJ6wz1+MXau+77mOLyQRRxY7s5ae/TwS45StnqiJQITUARcGX5 fp2tvZGrjJoyozdO5QtzKIeX9e3FTbPLafCu/L3nFR3R9cWjsiATDqEVkaDiWyXnhgGA EZWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=2Hqo9jmascljYsohX3+dNe11LfZ+a8ceLYfy+hC5e8w=; b=HXlVSJ1hllXo+HsBDZuE61pGH+6HPI/pTXaq9mSxZZ6EUYPXl8Pxjt8rvndAFWB1Oq 3EW1PN9EHM3Jx2Zk2Iophz0Ux5r0bFt8HoQdyt0VWHyYHI1p7Xdm2Ow+aDHZvgUeeCVI /bviIlqASVipWYA0k3aFwrEmGkqJ8eD2HwGQYA+GUjRUa8GUman8FlSnQVagghdTfz+6 4XuPEBnrDe8DgTRHWAPspcXEHDIeZnpRSu96fsi2hh9/wgAkdXANfhuDdYb08EfKua7T DV7jYHoJnQRYLSGx25YsnCGSNnLIrpM/jOoJ1Mej/nYvK1vj00TUDtjqzeA17q34jjCw ttbg== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id m7si18132247pgn.860.2022.02.09.15.24.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 15:24:47 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AB03CE05380E; Wed, 9 Feb 2022 15:19:33 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232478AbiBITNA (ORCPT + 99 others); Wed, 9 Feb 2022 14:13:00 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:59938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231808AbiBITMr (ORCPT ); Wed, 9 Feb 2022 14:12:47 -0500 Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A320C008645; Wed, 9 Feb 2022 11:12:40 -0800 (PST) Received: by mail-yb1-f172.google.com with SMTP id y6so8882929ybc.5; Wed, 09 Feb 2022 11:12:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2Hqo9jmascljYsohX3+dNe11LfZ+a8ceLYfy+hC5e8w=; b=qF/OxivWqyhjJvOgW19M5yH2R7A4WVih7QOwv19ibSsFFKP1NFgx9rRxtsKyIpTl3a Nu+lO7vv64ssFVrRtVsk0z2MwofZ9U5JX5JI/XWOSbSzD8EXSHx0FlScIm8Wld63qrg3 85B6gbXoES7bxGs3YIV3ZvssYc8jzzyT9AaG7c3RN9lyGlKrSWPQvxGWfds/jEiDQw0N wt6tMOD6VUt3D0Qshq2ZSLuUnWP7dQXeuluk/3DP9oc1+f+do2GaLXrROQYIEio6YDih 82ddT8GL8mlW9RrGHALdsg2LUiOHqiDjdjaZyNdj5+nb5yZNUiiNdUZdHQkRUfIA1rAO oHqA== X-Gm-Message-State: AOAM530yePtzicNW12BM91S4q6JsL7PMORRz8JkjmO2REAlgM/0NHqoW W/1A8PVddacYV9QFlWJu5NnVVCIsbwTJkhNK9pE= X-Received: by 2002:a25:3410:: with SMTP id b16mr3539165yba.78.1644433875451; Wed, 09 Feb 2022 11:11:15 -0800 (PST) MIME-Version: 1.0 References: <20220202020103.2149130-1-rajatja@google.com> In-Reply-To: <20220202020103.2149130-1-rajatja@google.com> From: "Rafael J. Wysocki" Date: Wed, 9 Feb 2022 20:11:04 +0100 Message-ID: Subject: Re: [PATCH v2 1/2] PCI: Allow internal devices to be marked as untrusted To: Rajat Jain Cc: Rob Herring , "Rafael J. Wysocki" , Len Brown , Linux PCI , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Mika Westerberg , Greg Kroah-Hartman , Bjorn Helgaas , Bjorn Helgaas , ACPI Devel Maling List , Linux Kernel Mailing List , Rajat Jain , Dmitry Torokhov , Jesse Barnes , Jean-Philippe Brucker , Pavel Machek , "Oliver O'Halloran" , Joerg Roedel Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 2, 2022 at 3:01 AM Rajat Jain wrote: > > Today the pci_dev->untrusted is set for any devices sitting downstream > an external facing port (determined via "ExternalFacingPort" or the > "external-facing" properties). > > However, currently there is no way for internal devices to be marked as > untrusted. > > There are use-cases though, where a platform would like to treat an > internal device as untrusted (perhaps because it runs untrusted firmware > or offers an attack surface by handling untrusted network data etc). > > Introduce a new "UntrustedDevice" property that can be used by the > firmware to mark any device as untrusted. > > Signed-off-by: Rajat Jain > --- > v2: * Also use the same property for device tree based systems. > * Add documentation (next patch) > > drivers/pci/of.c | 2 ++ > drivers/pci/pci-acpi.c | 1 + > drivers/pci/pci.c | 9 +++++++++ > drivers/pci/pci.h | 2 ++ > 4 files changed, 14 insertions(+) > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c > index cb2e8351c2cc..e8b804664b69 100644 > --- a/drivers/pci/of.c > +++ b/drivers/pci/of.c > @@ -24,6 +24,8 @@ void pci_set_of_node(struct pci_dev *dev) > dev->devfn); > if (dev->dev.of_node) > dev->dev.fwnode = &dev->dev.of_node->fwnode; > + > + pci_set_untrusted(dev); > } > > void pci_release_of_node(struct pci_dev *dev) > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c > index a42dbf448860..2bffbd5c6114 100644 > --- a/drivers/pci/pci-acpi.c > +++ b/drivers/pci/pci-acpi.c > @@ -1356,6 +1356,7 @@ void pci_acpi_setup(struct device *dev, struct acpi_device *adev) > > pci_acpi_optimize_delay(pci_dev, adev->handle); > pci_acpi_set_external_facing(pci_dev); > + pci_set_untrusted(pci_dev); > pci_acpi_add_edr_notifier(pci_dev); > > pci_acpi_add_pm_notifier(adev, pci_dev); > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 9ecce435fb3f..41e887c27004 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -6869,3 +6869,12 @@ static int __init pci_realloc_setup_params(void) > return 0; > } > pure_initcall(pci_realloc_setup_params); > + > +void pci_set_untrusted(struct pci_dev *pdev) > +{ > + u8 val; > + > + if (!device_property_read_u8(&pdev->dev, "UntrustedDevice", &val) > + && val) > + pdev->untrusted = 1; I'm not sure why you ignore val = 0. Is it not a valid value? The property is not particularly well defined here. It is not clear from its name that it only applies to PCI devices and how. AFAICS, the "untrusted" bit affected by it is only used by the ATS code and in one PCH ACS quirk, but I'm not sure if this is all you have in mind. > +} > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h > index 3d60cabde1a1..6c273ce5e0ba 100644 > --- a/drivers/pci/pci.h > +++ b/drivers/pci/pci.h > @@ -761,4 +761,6 @@ static inline pci_power_t mid_pci_get_power_state(struct pci_dev *pdev) > } > #endif > > +void pci_set_untrusted(struct pci_dev *pdev); > + > #endif /* DRIVERS_PCI_H */ > -- > 2.35.0.rc2.247.g8bbb082509-goog >