On 08/18/2016 03:18 PM, Felipe Balbi wrote: > Hi, > > Binyamin Sharet <bsharet@xxxxxxxxx> writes: > > [...] > >>>>>> Many USB host implementations, including at least older versions of Linux, >>>>>> have bugs in the enumeration phase. While I cannot pinpoint a ToC/ToU >>>>>> vulnerability in the configuration descriptor at the moment, I found more than >>>>>> a couple of issues with configuration descriptor parsing. I will post them here >>>>>> soon, hopefully today. >>>>>> >>>>>> However, just over the last year multiple USB related CVEs in the Linux kernel >>>>>> were published (not by me). >>>>>> >>>>>> Also, while there might not be a specific ToC/ToU bug in configuration >>>>>> descriptor >>>>>> parsing in Linux at the moment, there might still be in the future, or >>>>>> in a different >>>>>> operating system, or in a user application that queries those descriptor. >>>>>> My goal is to test all those cases, not just the current Linux kernel. >>>>> Fair enough, let's just wrap this "forward everything to userspace" with >>>>> a Kconfig choice depending on EXPERT so that it doesn't leak to >>>>> production kernel builds. >>>>> >>>>> Thanks >>>>> >>>> I think this will cause existing implementation over gadgetfs to fail >>>> with this >>>> special kernel (as now it will delegate everything all of the time). How >>>> about >>>> using a ioctl to configure it, but wrapping this ioctl with Kconfig? >>>> This way >>>> gadgetfs will operate as always unless a user activates "delegate all" >>>> in runtime. >>>> >>>> Sounds reasonable? >>> You mean a ep0 ioctl? Makes sense to me. Then we can add more features >>> later. Perhaps just add a "Get supported features" IOCTL which returns >>> a struct with 256 bits (4x uint64_t). I doubt we will ever need that >>> many bits, but better safe than sorry, I guess. >>> >> Don't we need some "set feature" IOCTL as well? > Why? Features are enabled at kernel compile time. Userspace issues ioctl > to ask the kernel "which features do you have enabled for > GadgetFS?". Note that we have a backwards compatibility problem here. If > "which features do you have enabled for GadgetFS" ioctl fails, we will > assume that kernel is older than the first kernel where this ioctl was > added. > > To help userland a little more, we can make sure that, from now on, the > ioctl itself is always enabled and bit0 out of the 256 bits we have MUST > always be set. This means that "Forward all requests to userspace" > feature has to be, at least, bit1. > > This mimics what USB descriptors where bit7 of config descriptor's > bmAttributes must always be set. We're just using bit0 instead. > What I mean is - when the gadgetfs compiled with "Forward all requests to userspace" feature, it should behave as before until an ep0 ioctl is issued to actually enable this feature (e.g. forward the messages) otherwise, this version of gadgetfs will break any current userspace application that uses it. Am I missing something? -- Binyamin Sharet, Cisco, STARE-C -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
