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;
Date:   Sat, 22 Jan 2022 15:46:05 +0100
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Bjorn Helgaas <helgaas@kernel.org>
Cc:     Rajat Jain <rajatja@google.com>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Len Brown <lenb@kernel.org>,
        Bjorn Helgaas <bhelgaas@google.com>,
        linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
        linux-kernel@vger.kernel.org, rajatxjain@gmail.com,
        dtor@google.com, jsbarnes@google.com,
        Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Pavel Machek <pavel@denx.de>,
        Oliver O'Halloran <oohall@gmail.com>,
        Joerg Roedel <joro@8bytes.org>
Subject: Re: [PATCH] PCI: ACPI: Allow internal devices to be marked as
 untrusted
Message-ID: <YewYrQeHsJWpNI5p@kroah.com>
References: <20220120000409.2706549-1-rajatja@google.com>
 <20220121214117.GA1154852@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220121214117.GA1154852@bhelgaas>
Precedence: bulk

On Fri, Jan 21, 2022 at 03:41:17PM -0600, Bjorn Helgaas wrote:
> [+cc Greg, Jean-Philippe, Mika, Pavel, Oliver, Joerg since they
> commented on previous "external-facing" discussion]
> 
> On Wed, Jan 19, 2022 at 04:04:09PM -0800, Rajat Jain wrote:
> > Today the pci_dev->untrusted is set for any devices sitting downstream
> > an external facing port (determined via "ExternalFacingPort" property).
> > This however, disallows any internal devices to be marked as untrusted.
> 
> This isn't stated quite accurately.  "dev->untrusted" is currently set
> only by set_pcie_untrusted(), when "dev" has an upstream bridge that
> is either external-facing or untrusted.
> 
> But that doesn't disallow or prevent internal devices from being
> marked as untrusted; it just doesn't implement that.
> 
> > 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).

Who is making this policy decision?

> > This patch introduces a new "UntrustedDevice" property that can be used
> > by the firmware to mark any device as untrusted.

Is this in the ACPI standard?  If so, where?

This notion of "trust" for PCI devices is crazy, as I have stated a
number of times before.  But at least you are not trying to say kernel
code is trusted or not.

thanks,

greg k-h