lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 18 Jun 2020 08:03:49 -0700
From:   Rajat Jain <rajatja@...gle.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>, iommu@...ts.linux-foundation.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Raj Ashok <ashok.raj@...el.com>,
        "Krishnakumar, Lalithambika" <lalithambika.krishnakumar@...el.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Prashant Malani <pmalani@...gle.com>,
        Benson Leung <bleung@...gle.com>,
        Todd Broch <tbroch@...gle.com>,
        Alex Levin <levinale@...gle.com>,
        Mattias Nissler <mnissler@...gle.com>,
        Rajat Jain <rajatxjain@...il.com>,
        Bernie Keany <bernie.keany@...el.com>,
        Aaron Durbin <adurbin@...gle.com>,
        Diego Rivas <diegorivas@...gle.com>,
        Duncan Laurie <dlaurie@...gle.com>,
        Furquan Shaikh <furquan@...gle.com>,
        Jesse Barnes <jsbarnes@...gle.com>,
        Christian Kellner <christian@...lner.me>,
        Alex Williamson <alex.williamson@...hat.com>,
        "Oliver O'Halloran" <oohall@...il.com>
Subject: Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

Hello,

On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
>
> On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> 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 <rajatja@...gle.com> wrote:
> > > > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig <hch@...radead.org> 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"?

Thanks,
Rajat

>
> --
> With Best Regards,
> Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ