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;
MIME-Version: 1.0
References: <20220121214117.GA1154852@bhelgaas> <Ye5GvQbFKo+CFtRb@lahna>
 <Ye/X7E2dKb+zem34@lahna> <Ye/btvA1rLB2rp02@kroah.com> <Ye/zTHR5aCG58z87@lahna>
 <CAJZ5v0gitdeEAxcgSoB1=VHA9FnRdCtmUqA_cN_f1a2yFRDghQ@mail.gmail.com>
 <CACK8Z6H2DLTJgxgS3pcvfOh=5S8cxEMKvwEPfB9zoVf1g2H_UQ@mail.gmail.com>
 <YfOf2X7Snm7cvDRV@lahna> <CACK8Z6FMgc5UQY-ZGB9sKYR5Wt6L6huTnEKZaFyVRAmDmQt9XQ@mail.gmail.com>
 <CAJZ5v0iuM_qjhPxvhzgvtKM-4pBB2skf9G=R=Qo6NzKnZ2LN=w@mail.gmail.com> <YfeEoF35RPDVMdzD@lahna>
In-Reply-To: <YfeEoF35RPDVMdzD@lahna>
From:   Rajat Jain <rajatja@google.com>
Date:   Mon, 31 Jan 2022 11:57:00 -0800
Message-ID: <CACK8Z6EBbdPHhMtD+vMWs54GRw-ChCeNNfeKM4Hk5JcAqex6hg@mail.gmail.com>
Subject: Re: [PATCH] PCI: ACPI: Allow internal devices to be marked as untrusted
To:     Mika Westerberg <mika.westerberg@linux.intel.com>
Cc:     "Rafael J. Wysocki" <rafael@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Bjorn Helgaas <helgaas@kernel.org>,
        Len Brown <lenb@kernel.org>,
        Bjorn Helgaas <bhelgaas@google.com>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Linux PCI <linux-pci@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Rajat Jain <rajatxjain@gmail.com>,
        Dmitry Torokhov <dtor@google.com>,
        Jesse Barnes <jsbarnes@google.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Pavel Machek <pavel@denx.de>,
        "Oliver O'Halloran" <oohall@gmail.com>,
        Joerg Roedel <joro@8bytes.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hello Mika, Rafael,

On Sun, Jan 30, 2022 at 10:42 PM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> Hi,
>
> On Sun, Jan 30, 2022 at 03:30:39PM +0100, Rafael J. Wysocki wrote:
> > > 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.
>
> I was kind of implying that we could perhaps contact Microsoft and ask
> them if the wording could be changed to cover all the devices, not just
> PCIe root ports. I think this is something they will also need for
> things like internal WI-FI controllers.

We (Chromeos) do not have a contact at Microsoft, not sure if Intel
does. If someone can point me to a contact I will be happy to initiate
a conversation. However, given that they have already published it,
and changing the semantics might mean they will also have to change
windows implementation. Not sure if we have enough leverage with
Microsoft here, so I wouldn't have any high hopes though. Like Rafael
said, we're on the receiving end here.

Rafael, one last question: is "untrusted-device" an acceptable ACPI
property name, or does it have to be Camel case?

Thanks & Best Regards,

Rajat

>
> If that's not possible then no objections adding "UntrustedDevice". We
> just need to deal with the "DmaProperty" anyway and both end up setting
> pdev->untrusted in the similar manner.