Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp417910pxb; Tue, 1 Feb 2022 02:50:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJwzUl6DvfZMg2DoERPTZM519vV/AYSwwFNsb8v/L4Wmue2uOpeNTsYG2Av3uohI7E2AyIPi X-Received: by 2002:a17:907:1302:: with SMTP id vj2mr20212130ejb.429.1643712620213; Tue, 01 Feb 2022 02:50:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643712620; cv=none; d=google.com; s=arc-20160816; b=i9WeMs1RQSEWNCJaxZvQjhUwBLKHypH50TBlkItp0MyIw5Rj3ILRM7fyIDHiX8V9tc f6bzye8cFyw75xfrmpxycLwxR19diU4VL8Kh1Z0cOLuNzwF7xa1qy6oxXhMJih5GGg9H bBisftf+i443mJaA1hQifYIES1wIzFLw0JoR9yb1I2TsTJEcXR7XLmqpRCQWTSS7GQUJ 4qHjgA/MVcUDWSoab4k2xzzT6iaLrvjvL2DRwEgTzbemcLz3nwBscGXZGjmYYdP4L5/X 2YHHB+d6ZBRqEuCcHWVQluPt5QOedjs3RrYcAdHo19mw+nVbaWRBw0Gtf2sQwDyWyLuw YuEA== 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=RaxK62DF2brZUuoILwZG6Sy3u6nklK5nRZA4Svlzegg=; b=NLDrcfzzn3f6xhA/AcVan8MLk36aGlB/jt+l1HUM9aysc6mTJvy6vz/JOBV6dCjy0O Qdflre83zGccdEsToHA1PBYcvFZyP0ojgIlyuNw3uJfqrA5mVOgzHBtT863U61wtqkbw rP3Ns5DpuVQe7gcrPyIb6r+vvJwnEjQucFeM1A9BAo5yvaEY4yHG/8Y5bpj4vBhq+big q1XZang3hixc4DaXJiDIj0P2W+P1tHfKFKuqdlL94Z+XyugDaf8dEbu0h6FrgWZgJnkt 6d90lbg/5rIUZW0SMci2zb6ztS3jc7iCpugCDncDJKrZvxwDxfaZJ8C9po4b+4Y7lH77 iBHw== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f25si8604851edv.450.2022.02.01.02.49.55; Tue, 01 Feb 2022 02:50:20 -0800 (PST) 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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354998AbiA3Oaz (ORCPT + 99 others); Sun, 30 Jan 2022 09:30:55 -0500 Received: from mail-yb1-f180.google.com ([209.85.219.180]:41507 "EHLO mail-yb1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354993AbiA3Oaw (ORCPT ); Sun, 30 Jan 2022 09:30:52 -0500 Received: by mail-yb1-f180.google.com with SMTP id g14so32773239ybs.8; Sun, 30 Jan 2022 06:30:51 -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=RaxK62DF2brZUuoILwZG6Sy3u6nklK5nRZA4Svlzegg=; b=G+6it9Z1wVGKPNcPzKLlYRCvuJ10vYgb+Qyv+JWPNvGi7LV47dNmnjQ+aFwoZmETnF wKqchiSaZqsakBdZuUVpEVGXrrtYgmLJe0nT9++DXV48NTJI1A2SEldhy3XuLSxLm4Zp NrkslOw3GiEz0riZ2u97PVpO6Un6cKRjJ3GaNeJjudBgD4S+LczaR9H88Kx9v9nkiV64 ZChTsBPTKOSWFFvu4erCynTP0ePY9ZnC9M1MwynFXJRUvSBrD+WbLSU2jFfetQJ0DtvM ZlRbS+gelIsdVhGshpLV3nvrUU10NzKgaEalGZI1ZoZ4Cg49VnKsZODaXdnMNFhvpAr0 X0AQ== X-Gm-Message-State: AOAM532PIfeXIwcMbz7m7qBuarV8ardfXhp2eBPCzndozzrG2BLmvXLH +ttSBUhS25dNEsuwFGkWhhML7eeegi95TB6DSvU= X-Received: by 2002:a25:34c4:: with SMTP id b187mr24736922yba.78.1643553050777; Sun, 30 Jan 2022 06:30:50 -0800 (PST) MIME-Version: 1.0 References: <20220120000409.2706549-1-rajatja@google.com> <20220121214117.GA1154852@bhelgaas> In-Reply-To: From: "Rafael J. Wysocki" Date: Sun, 30 Jan 2022 15:30:39 +0100 Message-ID: Subject: Re: [PATCH] PCI: ACPI: Allow internal devices to be marked as untrusted To: Rajat Jain Cc: Mika Westerberg , "Rafael J. Wysocki" , Greg Kroah-Hartman , Bjorn Helgaas , Len Brown , Bjorn Helgaas , ACPI Devel Maling List , Linux PCI , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 28, 2022 at 10:34 PM Rajat Jain wrote: > > Hi Mika, All, > > On Thu, Jan 27, 2022 at 11:49 PM Mika Westerberg > wrote: > > > > Hi, > > > > On Thu, Jan 27, 2022 at 02:26:07PM -0800, Rajat Jain wrote: > > > Hello Rafael, Bjorn, Mika, Dmitry, Greg, > > > > > > Thanks a lot for your comments. > > > > > > On Tue, Jan 25, 2022 at 6:45 AM Rafael J. Wysocki wrote: > > > > > > > > On Tue, Jan 25, 2022 at 1:55 PM Mika Westerberg > > > > wrote: > > > > > > > > > > On Tue, Jan 25, 2022 at 12:15:02PM +0100, Greg Kroah-Hartman wrote: > > > > > > On Tue, Jan 25, 2022 at 12:58:52PM +0200, Mika Westerberg wrote: > > > > > > > On Mon, Jan 24, 2022 at 08:27:17AM +0200, Mika Westerberg wrote: > > > > > > > > > > This patch introduces a new "UntrustedDevice" property that can be used > > > > > > > > > > by the firmware to mark any device as untrusted. > > > > > > > > > > > > > > > > I think this new property should be documented somewhere too (also > > > > > > > > explain when to use it instead of ExternalFacingPort). If not in the > > > > > > > > next ACPI spec or some supplemental doc then perhaps in the DT bindings > > > > > > > > under Documentation/devicetree/bindings. > > > > > > > > > > > > > > Actually Microsoft has similar already: > > > > > > > > > > > > > > https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-internal-pcie-ports-accessible-to-users-and-requiring-dma-protection > > > > > > > > > > > > > > I think we should use that too here. > > > > > > But because this property also applies to a root port (only), it only > > > helps if the device is downstream a PCIe root port. In our case, we > > > have an internal (wifi) device 00:14.3 (sits on the internal PCI bus > > > 0), so cannot use this. > > > > Right. I wonder if we can expand it to cover all internal devices, not > > just PCIe root ports? We anyways need to support that property so does > > not make much sense to me to invent yet another that does pretty much > > the same thing. > > I'm open to doing so if the others also feel the same way. IMHO > though, the semantics of ACPI "DmaProperty" differ from the semantics > of the property I'm proposing here. > > The current (documented) semantics (of "DmaProperty"): *This device > (root port) is trusted*, but any devices downstream are not to be > trusted. > > What I need and am proposing (new "UntrustedDevice"): *This device as > well as any downstream devices* are untrusted. > > Note that there may be firmware implementing "DmaProperty" already out > there (for windows), and if we decide to use it for my purposes, then > there shall be a discrepancy in how Linux uses that property vs > Windows. Is that acceptable? It may be confusing, so I'd rather not do that. The platform firmware will use it with the Windows use case in mind and if it has side effects in Linux, problems are likely to appear in the field. So the question is rather not about it being acceptable, but about whether or not this is generally going to work.