Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2289359pxb; Wed, 9 Feb 2022 15:16:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJwiiDpnwmKfdFibXJE1xxsRwC6xLvpIJyIvK/UYiXi9YUXOoR+eZmr5J9SdM2dFdTGNPCE8 X-Received: by 2002:a17:90a:b795:: with SMTP id m21mr5264987pjr.57.1644448586675; Wed, 09 Feb 2022 15:16:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644448586; cv=none; d=google.com; s=arc-20160816; b=c4VvPpXFIipz67XmjvMRT1OC4hDvLFaGu79SCLAsOAbknFJ82T6TiLF0DYXHl/i4UV EabZk+W74eQKz4ptsMjpNvn+wwqWBfWfhVCQmbi7yo7/GWkJ4ER5omyUp0CqGM2h6JBH MuSao3093gLwbpCKed5sJPzfsmanW5PNfKZ1Vc1FVKZ336hogaFKCDuOEZOio8ESH1RL A1Mv6mxM91x3Q1/IJ3pjANg7sFOztNkl0JIeAk9W0FaFB8e1uwLoFkjje1R6FVJTXpPE Uc3xEsAF5dU5PISHQ9A71PRnC4fhrsscv7cVwpW4FAqJiwCTGU8f6A5Lrml+Enyygtz0 t1Zg== 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:dkim-signature; bh=xNzkFtkEdwS4V5xuimABsw6tYvmcHWMu0L6uE58HPK4=; b=l15fZpFjVxpb6Oz5dFMPmFDKTye4OFMXQHovl3Oag4+z9XO+olj6HO4A9sbM0CZt1r LaUxO0OkmA5RMjpfpXZDZvdvl1hjivzliKgEenwU44munivFaakw3Nmj4fATbhQGNzof Pp/lTAVUM5XlRHVZRCx29/9y/UwYksjnY7pIptKZ5+zM4rCPCo2LIsjktHtZMxduJEME VLxSjcU1yDm5uB6PX1Sl/72MCOyP5OeODl/de04HXZDns4vJO1k1/vtqPsxBVraqzBS3 FrgiHLbsRUAeLSFfKi4chEm8r0NpHe/7N0sjPsAJCzfyHxLwDTw1LC5+tluCsebwNy6X hR2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="kyxSH/1s"; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q15si355770plx.29.2022.02.09.15.16.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 15:16:26 -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; dkim=pass header.i=@google.com header.s=20210112 header.b="kyxSH/1s"; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B707AE053F8C; Wed, 9 Feb 2022 15:15:09 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234914AbiBIWEQ (ORCPT + 99 others); Wed, 9 Feb 2022 17:04:16 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:51340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234966AbiBIWEM (ORCPT ); Wed, 9 Feb 2022 17:04:12 -0500 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD80BE010DBE for ; Wed, 9 Feb 2022 14:04:10 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id t14-20020a17090a3e4e00b001b8f6032d96so3669488pjm.2 for ; Wed, 09 Feb 2022 14:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xNzkFtkEdwS4V5xuimABsw6tYvmcHWMu0L6uE58HPK4=; b=kyxSH/1s4tYkpnIvrk1pCVVHvuka0Iv2uFFyhp9uZb0aans0RzfOy3BkDicIzvpIK2 JZ+AInXaf/dEUAOlK2atr40Ts389WYvQGH1Iw96AZ1SFqT1j4ADLygKvmII//Yw6WSq0 1ZztH/K36DxhmzhYbKgN7gkepOJvdyMan3uZz8JP3RBDwsE3mZ3ABC+VnPzYAI08zOkn JX6p7qgUTG4FbF0Q/KazCCYn0vfox4zeNuxNgGWuoQJp0sXTZmeP6Wj4GZXH8yRWt5bP 7j8sps3kN/wCna3m6wFG2i5r2m9G2x5j8DF1WZrhxmKarKilBeUF8EVrQGaqOa90iawA HXCA== 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=xNzkFtkEdwS4V5xuimABsw6tYvmcHWMu0L6uE58HPK4=; b=DqclZDT9MxmcgItKQJFbd4ovMX+lfQaMFhT+YhuAivTKN8k2xnKEZLwY6bY2TucK6L sOLiOhI66DTq4WC2ieAFzm+PR7ue8eXnKJ96pe22jjMNKGRGRwbgH1b685oGBD1yAMdU 9AFjgloFt6f3Ocs8RMopmdGu4O2IPG7rJyBxsdLYrsUNos8Vh0Ezd3hyH4/FN+uiZPE4 hH0HlTxAdV4K605DwH/yLkSz4Ir/pr0nZnDp2PXE3PKXW6UvWPyOvA7x0PsKIV+XVbsV mSrJAtsECrn9bUxg7VSpooZFVTb612uY18MW+FPa6s+0QXwA2JEKYTsImUAFeJwpuWfR o6tg== X-Gm-Message-State: AOAM533ZYwJv5/abP3AEkui6fA/sl2KagrfIxGSHDp3J7nMXINe2oZVI Nhd+ayZIVDHeoHN5zgtO9VjIawkA8oFg3pc4kOgqXA== X-Received: by 2002:a17:90a:5303:: with SMTP id x3mr5254322pjh.64.1644444249918; Wed, 09 Feb 2022 14:04:09 -0800 (PST) MIME-Version: 1.0 References: <20220202020103.2149130-1-rajatja@google.com> In-Reply-To: From: Rajat Jain Date: Wed, 9 Feb 2022 14:03:34 -0800 Message-ID: Subject: Re: [PATCH v2 1/2] PCI: Allow internal devices to be marked as untrusted To: "Rafael J. Wysocki" Cc: Rob Herring , 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=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL 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 Hello, On Wed, Feb 9, 2022 at 11:11 AM Rafael J. Wysocki wrote: > > 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? I'm following the other similar properties that Bjorn mentioned. The pdev->untrusted is already initialized to 0 so it wouldn't matter. > > 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. I hope my other response addressed this one. Thanks & Best Regards, Rajat > > > +} > > 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 > >