[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4i__reKFRP1KjWUov_W5jBQN9_vbUbKRL_V7KMM3oPuuQ@mail.gmail.com>
Date: Fri, 1 Oct 2021 11:09:52 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Borislav Petkov <bp@...en8.de>, X86 ML <x86@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Andreas Noever <andreas.noever@...il.com>,
Michael Jamet <michael.jamet@...el.com>,
Yehezkel Bernat <YehezkelShB@...il.com>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Jonathan Corbet <corbet@....net>,
Jason Wang <jasowang@...hat.com>,
Andi Kleen <ak@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux PCI <linux-pci@...r.kernel.org>,
USB list <linux-usb@...r.kernel.org>,
virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for
confidential guest
On Fri, Oct 1, 2021 at 9:47 AM Alan Stern <stern@...land.harvard.edu> wrote:
>
> On Fri, Oct 01, 2021 at 09:13:54AM -0700, Dan Williams wrote:
> > Bear with me, and perhaps it's a lack of imagination on my part, but I
> > don't see how to get to a globally generic "authorized" sysfs ABI
> > given that USB and Thunderbolt want to do bus specific actions on
> > authorization toggle events. Certainly a default generic authorized
> > attribute can be defined for all the other buses that don't have
> > legacy here, but Thunderbolt will still require support for '2' as an
> > authorized value, and USB will still want to base probe decisions on
> > the authorization state of both the usb_device and the usb_interface.
>
> The USB part isn't really accurate (I can't speak for Thunderbolt).
> When a usb_device is deauthorized, the device will be unconfigured,
> deleting all its interfaces and removing the need for any probe
> decisions about them. In other words, the probe decision for a
> usb_device or usb_interface depends only on the device's/interface's
> own authorization state.
>
> True, the interface binding code does contain a test of the device's
> authorization setting. That test is redundant and can be removed.
>
> The actions that USB wants to take on authorization toggle events for
> usb_devices are: for authorize, select and install a configuration;
> for deauthorize, unconfigure the device. Each of these could be
> handled simply enough just by binding/unbinding the device. (There
> is some special code for handling wireless USB devices, but wireless
> USB is now defunct.)
Ah, so are you saying that it would be sufficient for USB if the
generic authorized implementation did something like:
dev->authorized = 1;
device_attach(dev);
...for the authorize case, and:
dev->authorize = 0;
device_release_driver(dev);
...for the deauthorize case?
Powered by blists - more mailing lists