Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1517809ybt; Thu, 18 Jun 2020 10:29:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyNaiDUHBQybF5QH34lQITUw3zrmNWNoPaDpwnouJ4aHsy0K2JFfWbgUiI+FQMbqc2C8sAl X-Received: by 2002:a17:906:470b:: with SMTP id y11mr5084689ejq.182.1592501361993; Thu, 18 Jun 2020 10:29:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592501361; cv=none; d=google.com; s=arc-20160816; b=deyeVAV4qHEVXZP5CHnASkC8MObVT83quk9u5FuUyHk6KMZn//pwF5pIDR+JShBUZV bQbWDcOcc6jcLX40XIm39cK+YkntGznerWkQX5v67T1pSVp1f2qGv/hGMsBx0HUMtSQ+ IQ19oVhlnYobvk1K20lezAFQVxu/5nmXCQxp3SawD2Tt7vcJCF8M7rmlW1ZG9VrYbOpn +FvQ6LX5vkxw13sL89vWNc8XM306XhadEQIAJaQ1uyds5ZBjixlXUGl6SMwgfQgnMrWi cibckj+goCYqqrks58FH9wCh32E9Bash4uWfpjbjR/8U1pSgO6dhJnVcVNep8XgjJ6vz DqAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=IYlmzlXm+VrJo7JYODsM8cd9UWnB3bZArKAUI6t3sVA=; b=WETzqXknN81+9y3ikjJnpHpJ+GMUyhwjhlN8+1vDuQXytCNcPNvtj68gztGCSqrbws Xh2JTP7Zt758x1Drfm8qIomrhKpt+4TqqBwA9r3ZT3g9602Pr1qeJSMC1JHJwiQF1mfo DwcihAx82WX09JHcWabLmaEVmgXGP5peS0zF6NED3EGAUHfKeWO/fhYkXqaRmdJwX5Yp 1PoKjV2/pwNkVqlSoyESIRgZQFPzsph/SqFY2ae/i8AFUc/TZbZoT8PVaCEOkJVRVFZ+ sX79rla7uPVmYdIgL43DhfXRRcpoRFGUPe1DMcGseVgzIbWwgjpIcMl0+anY5wwtCYU1 bAAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VwqXe+SC; 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 w26si2242413edq.285.2020.06.18.10.28.59; Thu, 18 Jun 2020 10:29:21 -0700 (PDT) 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=20161025 header.b=VwqXe+SC; 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 S1732128AbgFRRYU (ORCPT + 99 others); Thu, 18 Jun 2020 13:24:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732098AbgFRRYT (ORCPT ); Thu, 18 Jun 2020 13:24:19 -0400 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0885C0613ED for ; Thu, 18 Jun 2020 10:24:19 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id s1so8269563ljo.0 for ; Thu, 18 Jun 2020 10:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IYlmzlXm+VrJo7JYODsM8cd9UWnB3bZArKAUI6t3sVA=; b=VwqXe+SC9JBUUohRt1aVE6bPQXlMwSRhAaTu+S1Nde6pinRGw/JacoeMqkVAyD0Tm9 TVYeNmo71/8OpIBMvakVOTRQ4qdt7N2gWHl0KoBND9b2yGBmLhGD9FHUXmMmGj7k6Chk EFs44/ZeAbBAcrTdN3aT8D2KnyrTPPfhfClu/0sofjIVcmRQS81JNj13Xca9teYGGKKi YkjuuIbBrIBIAhlln8dD6OXGjyPAs6J8c5Ghh9XfRl6Q19hGHUNKRtIjJ84FHV4kXucZ IIob5LqKzd2fyEMF5BjzUJjc3R+oQE1aN9N3sqafgghbekZ01vHrvykL8xbIXG1NPZQs Q8Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IYlmzlXm+VrJo7JYODsM8cd9UWnB3bZArKAUI6t3sVA=; b=ltW4gSJEHkv1FW86BH5jENhML1YPI1T2rxNB5CaCRDsdzBm1zNnuZehPf2ZyMVdg7k cA/855IlkhlrfUTPW9ZwoWmrM262HMJRQLLxisFzYMARpue53m4vNTM+G7kvhoK8V0fG PswJlRqgESDm4meUVimzTh69TFMcpXPqKt4SIyRi2EVujkVOlz0c1Jh+jFx1q5w4JUkK ET9xjdBTfDpcKTs3IEqx0uPQI82IVBaIyH0mGec67TCDbdenItXnSnUn4fY8PvIMNShH mRQEGaVsYV1zcTngLe8TEPPf36MwMH4k8NPtmbezLIm+itzPrpYjhl/WO7VW4aPUvrIh MDtg== X-Gm-Message-State: AOAM531tZpJXu3qm5EIym3fZrc9n4pPOtfYx//sHEn8be0GiXHrPqb6l vPrYIEZnWzzhhe8r8exV0PFmuedJ+GaIcIohgU03FQ== X-Received: by 2002:a2e:8e8d:: with SMTP id z13mr2640858ljk.461.1592501057300; Thu, 18 Jun 2020 10:24:17 -0700 (PDT) MIME-Version: 1.0 References: <20200616011742.138975-4-rajatja@google.com> <20200616073249.GB30385@infradead.org> <20200617073100.GA14424@infradead.org> <20200618083646.GA1066967@kroah.com> <20200618160212.GB3076467@kroah.com> <20200618162322.GI34820@otc-nc-03> In-Reply-To: <20200618162322.GI34820@otc-nc-03> From: Rajat Jain Date: Thu, 18 Jun 2020 10:23:38 -0700 Message-ID: Subject: Re: [PATCH 4/4] pci: export untrusted attribute in sysfs To: "Raj, Ashok" Cc: Greg Kroah-Hartman , Andy Shevchenko , Christoph Hellwig , David Woodhouse , Lu Baolu , Joerg Roedel , Bjorn Helgaas , "Rafael J. Wysocki" , Len Brown , iommu@lists.linux-foundation.org, Linux Kernel Mailing List , linux-pci , ACPI Devel Maling List , "Krishnakumar, Lalithambika" , Mika Westerberg , Jean-Philippe Brucker , Prashant Malani , Benson Leung , Todd Broch , Alex Levin , Mattias Nissler , Rajat Jain , Bernie Keany , Aaron Durbin , Diego Rivas , Duncan Laurie , Furquan Shaikh , Jesse Barnes , Christian Kellner , Alex Williamson , "Oliver O'Halloran" , Jean-Philippe Brucker Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks Greg and Andy for your continued inputs, and thanks Ashok for chiming in. On Thu, Jun 18, 2020 at 9:23 AM Raj, Ashok wrote: > > Hi Greg, > > > On Thu, Jun 18, 2020 at 06:02:12PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Jain wrote: > > > Hello, > > > > > > On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko > > > wrote: > > > > > > > > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman > > > > wrote: > > > > > > > > > > On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote: > > > > > > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote: > > > > > > > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig wrote: > > > > > > > > > > > > ... > > > > > > > > > > > > > (and likely call it "external" instead of "untrusted". > > > > > > > > > > > > Which is not okay. 'External' to what? 'untrusted' has been carefully > > > > > > chosen by the meaning of it. > > > > > > What external does mean for M.2. WWAN card in my laptop? It's in ACPI > > > > > > tables, but I can replace it. > > > > > > > > > > Then your ACPI tables should show this, there is an attribute for it, > > > > > right? > > > > > > > > There is a _PLD() method, but it's for the USB devices (or optional > > > > for others, I don't remember by heart). So, most of the ACPI tables, > > > > alas, don't show this. > > > > > > > > > > This is only one example. Or if firmware of some device is altered, > > > > > > and it's internal (whatever it means) is it trusted or not? > > > > > > > > > > That is what people are using policy for today, if you object to this, > > > > > please bring it up to those developers :) > > > > > > > > > > So, please leave it as is (I mean name). > > > > > > > > > > firmware today exports this attribute, why do you not want userspace to > > > > > also know it? > > > > > > To clarify, the attribute exposed by the firmware today is > > > "ExternalFacingPort" and "external-facing" respectively: > > > > > > 617654aae50e ("PCI / ACPI: Identify untrusted PCI devices") > > > 9cb30a71ac45d("PCI: OF: Support "external-facing" property") > > > > > > The kernel flag was named "untrusted" though, hence the assumption > > > that "external=untrusted" is currently baked into the kernel today. > > > IMHO, using "external" would fix that (The assumption can thus be > > > contained in the IOMMU drivers) and at the same time allow more use of > > > this attribute. > > > > > > > > > > > > > Trust is different, yes, don't get the two mixed up please. That should > > > > > be a different sysfs attribute for obvious reasons. > > > > > > > > Yes, as a bottom line that's what I meant as well. > > > > > > So what is the consensus here? I don't have a strong opinion - but it > > > seemed to me Greg is saying "external" and Andy is saying "untrusted"? > > > > Those two things are totally separate things when it comes to a device. > > Agree that these are two separate attributes, and better not mixed. +1. > > > > > One (external) describes the location of the device in the system. > > > > The other (untrusted) describes what you want the kernel to do with this > > device (trust or not trust it). > > > > One you can change (from trust to untrusted or back), the other you can > > not, it is a fixed read-only property that describes the hardware device > > as defined by the firmware. Correct. I believe what is being described by the firmware is a fixed read-only property describing the location of the device ("external") - not what to do with it ("untrusted"). > > The genesis is due to lack of a mechanism to establish if the device > is trusted or not was the due lack of some specs and implementation around > Component Measurement And Authentication (CMA). Treating external as > untrusted was the best first effort. i.e trust internal > devices and don't trust external devices for enabling ATS. > > But that said external is just describing topology, and if Linux wants to > use that in the policy that's different. Some day external device may also > use CMA to estabilish trust. FWIW even internal devices aren't trust > worthy, except maybe RCIEP's. Correct. Since the firmware is actually describing the unchangeable topology (and not the policy), the takeaway I am taking from this discussion is that the flag should be called "external". Like I said, I don't have any hard opinions on this. So if you feel that my conclusion is wrong and consensus was the other way around ("untrusted"), let me know and I'll be happy to change this. Thanks, Rajat > > > > > Depending on the policy you wish to define, you can use the location of > > the device to determine if you want to trust the device or not. > > > > Cheers, > Ashok