Hi Greg, On Tue, 2019-02-26 at 13:14 +0100, Greg KH wrote: > On Tue, Feb 26, 2019 at 01:09:30PM +0100, Nicolas Saenz Julienne wrote: > > Hi, > > as I'm sure most of you are aware of, every URB submission triggers a small > > memory allocation in the host controller. > > For every host controller driver? I thought we had some that did not do > that. That's probably true, I only looked into the more common ones. > > > On top of that it might be run in > > atomic context. This has always seemed to me as a possible source of very > > hard > > to reproduce and potentially nasty issues. For example I'm thinking of > > embedded > > systems driving some critical operation through USB. > > USB and "critical" should never be in the same sentance, without the > word "not" being in there as well. :) Fair enough. It might still annoy someone, which computers were never meant to. :) > > > I wonder if anyone has been able to log any failure on that area. I was > > unable > > to find anything on the relevant bugzillas, nor by talking with some > > knowledgeable people. Note that some drivers actively protect themselves > > from > > URB submission failures, taking care to resubmit them (see usbhid/hid- > > core.c). > > > > Making the allocation fail on some controlled test system seems feasible (it > > might not be that easy, it really depends on how realistic you want to be). > > But > > it might be pointless without a real life failure scenario. > > We have the memory allocation fault system, try using that to see how > well we recover (or not) from such failures. You can also inject memory allocation failures with BPF & BCC which is very fun and easy to use. I've managed to break some drivers as there is a recurring pattern where they don't try to resubmit a URB once it failed on a completion routine. That said I'm under the impression that there is a huge difference in relevance between forcing a kmalloc failure on a 512bytes buffer and managing for the allocator to fail in the wild. > Look at how syzbot tested the USB layer, I think they had some > scripts/programs that got kind of deep into the driver layers for this > type of testing. I'll look into it. Thanks, Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
