Dan Williams
2021-Oct-01 18:09 UTC
[PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest
On Fri, Oct 1, 2021 at 9:47 AM Alan Stern <stern at rowland.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?
Alan Stern
2021-Oct-01 19:00 UTC
[PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest
On Fri, Oct 01, 2021 at 11:09:52AM -0700, Dan Williams wrote:> On Fri, Oct 1, 2021 at 9:47 AM Alan Stern <stern at rowland.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?Yes, I think so. But I haven't tried making this change to test and see what really happens. Alan Stern