Received: by 2002:a05:6a10:8a4f:0:0:0:0 with SMTP id dn15csp2600610pxb; Mon, 31 Jan 2022 03:40:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJxoyh7pLggh+8a7GfnvWbgk37N+l6ozsp0m+cW4uSWna6nD21fNdyNIQj1gWuCE79lLbPkE X-Received: by 2002:a17:90b:3ec8:: with SMTP id rm8mr31607944pjb.47.1643629239281; Mon, 31 Jan 2022 03:40:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643629239; cv=none; d=google.com; s=arc-20160816; b=ywEU4EBr4QAMLaGY3p0k3h7H7vC+MsOxmZTPBXoswM+H/GuR6ITSH6TghRDI0VNz7F Qen9Wz5Ue7zs4/oW7gae+XDt9J0Sz+h8AZxaZXx2JOIB/xwis5aD6ldJS76Hsk6pn3MB gwvBT9Z1uv03CIhKzzaHWAoZ6Ki560WucE3jUqq8F2wKJeKYYcgQcqBCe8v1sIneCr+r m1uARPKDY1xs3IE9oX7PgucAH5yFYdYxBItPlNBwE5NlzU5KHply7Gz4GRqLStmuF3pF 735nqrd/OibjeiFzTQ2HRERCKU5woWA8WIQ8MEFxqfSzMGjDv451UMGeXUYYShX/s7OQ TTqQ== 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=Sy/Y8yEWHigDuQdOlOLkaoU18i+f7DaCjn+DCmpwyFI=; b=W9xnlgS3no8/cCStnlo1PCfiGs1owogz2FxKBRUlBovk0ZKc6kC3YxxB6RXivcovax cNYvYfKZQB2YRL552DmgZPhFzd0R20QRIgW4nEkDnT5Z/TDSNapo+5TGZXuHRyOIPUBs FfXlY/pVRC0KgoE5nqaXgUDD/t3/JFbtYTytzS45MzBiLUHPVNzZDq3bDFvMIRKm+1i6 MvOq3DdumQmUqLcm9DwFJPRGVztWQOZVtToJ0ekJrnyXsUah/AKujD0Ww/WQMVzxHTRq bkdR10p1tWh/io3v39fYIqjt8XjQmeu+Q7CG2Rpcmng8a84IEPXmNHfXTQ6j2lh+9Khp tCFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=hHmYyqdR; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l17si13460309pls.155.2022.01.31.03.40.28; Mon, 31 Jan 2022 03:40:39 -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; dkim=pass header.i=@google.com header.s=20210112 header.b=hHmYyqdR; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245464AbiA1Vez (ORCPT + 99 others); Fri, 28 Jan 2022 16:34:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236367AbiA1Vex (ORCPT ); Fri, 28 Jan 2022 16:34:53 -0500 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45C76C061747 for ; Fri, 28 Jan 2022 13:34:53 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id z5so7329781plg.8 for ; Fri, 28 Jan 2022 13:34:53 -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=Sy/Y8yEWHigDuQdOlOLkaoU18i+f7DaCjn+DCmpwyFI=; b=hHmYyqdR9Q2JZUHGSGzbIgw7t9UNRsSBkuwDJ7oJU1ZVMuuh9q4jSdXlYRSA94DjTr V7R7MKNh/igjsct2gL3Zz4mzs1JXx2SE1S34DTakruz/UO9vRM/Mq2zEY3oQOUAOs2e9 bRTNzUmQfMlcWPrDx+wmUaQdVwdzHb8AKtf3Na5NqORiHpssCKgffjD7uMWNsDC88jxj zvYRWSooCK5VAGDOcoIwq4kDvd7skeQK9isV7CULeYCsenIm8ouoCSNj0lrxzJIIDcf4 XazTpdNAFlZ3tnnGjqh2ztDvByAn0dGNYTyHAaLt1VLG4+3BPhC0W2pGxqKHMEbx/SRD WZqw== 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=Sy/Y8yEWHigDuQdOlOLkaoU18i+f7DaCjn+DCmpwyFI=; b=RBc4wOS5lAGErU7voSjO8mxFthpCK0C6nvTzNIlm43hrbGIWHTmOu6bIEw9qDiP+rl ZimtBJaOFFJVuBblNoG6ZXN09F2M5eVYXahcqLIDpN64+RcoDy1LcrTjYcEkQSQqKs4w wnL9fEH8w+AjkJc3/OyU2cvz1k9/QfdTq/Ep5gPomMP6226p/adk4GpOdbok2au0gCTj 7I4nmaEup0WI8P7bh5N79fg2WRHJmQrWILv/uRUtSOTzuOvh7yJfS8ZyN8VMCMk0L/Bx /qgK0kPMyVgI1kNNtAtimD87gn61gCGRYNG7adSCv5iDrNIlv40iQwfJAaoiDQHpc+4+ ra+g== X-Gm-Message-State: AOAM533ZiGULSeqjcWB1XY2nlnRaZFsa/OR4QWdnk6sce0Qa9/oO7QJx FL6cpRr5ZHOLhKCe+Q24CpabHstrH9QyiqW0iQSWuQ== X-Received: by 2002:a17:90a:f485:: with SMTP id bx5mr21803979pjb.46.1643405692450; Fri, 28 Jan 2022 13:34:52 -0800 (PST) MIME-Version: 1.0 References: <20220120000409.2706549-1-rajatja@google.com> <20220121214117.GA1154852@bhelgaas> In-Reply-To: From: Rajat Jain Date: Fri, 28 Jan 2022 13:34:16 -0800 Message-ID: Subject: Re: [PATCH] PCI: ACPI: Allow internal devices to be marked as untrusted To: Mika Westerberg Cc: "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 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? Thanks & Best Regards, Rajat