Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1458837ybt; Thu, 18 Jun 2020 09:08:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFQZHJp7OPBRz7BSreLI5dn461HegDZbcqXUYSTuJrlYLRgc9uv+5w6FZFSOE8w46sReho X-Received: by 2002:a50:cd56:: with SMTP id d22mr4640413edj.374.1592496491274; Thu, 18 Jun 2020 09:08:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592496491; cv=none; d=google.com; s=arc-20160816; b=gm3ommrV7agTPtYl2RTGf/6fPYvRvhmSbX//j8xut5sBZgj/z7S3RSsKhq3nO13uBU reW8pTvq8j5XaZOBhftv4KjDHPI87RF8tQcdE5AvsRpTUSwlHAmmPTO+rfpwLmHBE68J e8gxJOb96Qbk77i4GFUdcUxTTlwhfGeyoJIhIyXOCiSM0mBMukZjDDZCXm2yDHfY7kgq cayRQ8/gxCE/yWOgxvajMNh4bFLtqYHO+zOUWJuLa2mcPKQfKriML3rWLaC7EuIuo+Q6 t/NDJU9ZFQhTSv5qXzeFpPS6nlyASzbh1CjwWabiyqhMGgBEoAki93RqZjwIoIG96nkH SNtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=pkx7BWy//wewq1PhsJ5XtRKkf5nEWWLh9oQN5v1K95o=; b=ixHOGEnSQFbwCzRiFsp1VeoUFn4EXWIwP6MpKK4lijnjjaHAWERlnjM5gaKoasvolh 6pWc9BS7X1NZLMFsxy7PncjMQTj1hy3wcyiesOQ8gm9NlpoyNV27retRhqmMZqll54hk QMXUpf2uowvSBVLDii64m/3VyHHnkhkBECDwlmwgrKXTNr5evf8GZA2+ob1J006lpyY0 ONKQ+xHvTpOBUAPpnzmsjrBhHAtF3fNP8kIdSMcScZRaLi1cJqq8gsZb00E24SHhU5yt UhBtu/c/6KY6iLsV0Tmu3BGxGTf+oAy3p+SkDyZYeKR4WfBN7RLwaKO1mWgTXd+ZTiK4 FPSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UUazJfy9; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b8si2058899edr.398.2020.06.18.09.07.48; Thu, 18 Jun 2020 09:08:11 -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=@kernel.org header.s=default header.b=UUazJfy9; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731740AbgFRQCX (ORCPT + 99 others); Thu, 18 Jun 2020 12:02:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:32878 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728134AbgFRQCW (ORCPT ); Thu, 18 Jun 2020 12:02:22 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A19652075E; Thu, 18 Jun 2020 16:02:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592496140; bh=rqbQaxwYHVSog/6s0s06FTodGO8kQeNqtyZySUvpN6w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UUazJfy9+SSUKCLNfartxWy/emm+rlRyoRqcnyXex7QUgkrv8PbuxpR4XPTWliD9o JHrAaV6k7Rf0xEMIQqZ/A15hvXhqg5bAUs3F0/ERSZnyaZRws0u88T0CPjbT/qHzxL PJBFDWfUW4gUM4BGCg7YrDz1p0BYoXuWrU7avDc0= Date: Thu, 18 Jun 2020 18:02:12 +0200 From: Greg Kroah-Hartman To: Rajat Jain Cc: 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 , Raj Ashok , "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 Subject: Re: [PATCH 4/4] pci: export untrusted attribute in sysfs Message-ID: <20200618160212.GB3076467@kroah.com> References: <20200616011742.138975-1-rajatja@google.com> <20200616011742.138975-4-rajatja@google.com> <20200616073249.GB30385@infradead.org> <20200617073100.GA14424@infradead.org> <20200618083646.GA1066967@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. 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. Again, this is what USB does, but I'm getting really tired of saying this, so I'm going to stop now... greg k-h