On Tue, Jun 11, 2024 at 10:35:12AM -0400, Alan Stern wrote: > Greg, Oliver, or anyone else: > > Questions: > > If a broken or malicious device causes a USB class driver to add a > thousand (or more) error messages per second to the kernel log, > indefinitely, would that be considered a form of DOS? > > Should the driver be fixed? Good question. Right now, by default, we "trust" usb devices to an extent. We have been "pushing back" that boundry over time, such that now we will validate USB descriptors to verify that they actually are sane before allowing a driver to bind to them, and if there's any bugs with that, we will fix them. But we totally trust the data stream from devices, and trust that once an urb is submitted, they work properly. If we wish to change that threat model, great, but that will require those that wish to change that model to DO THE ACTUAL WORK! I don't want to see fuzzers start to fuzz the data streams of USB drivers and expect us to fix the bugs. That's flat out not ok, as this is something that right now, we do not care about. If companies do care about this, they need to do the work as that is NOT how Linux is currently designed and implemented. Same goes for other device types. I get this conversation all the time (had it last week at a very very very large Linux company.) It usually goes something like: Them: We want to claim that we can trust drivers to work properly for malicious devices Me: Wonderful, send the patches to do so, fixing up all subsystems that rely on them! Them: No, that's something that Linux should already support. Me: Why do you care about this? Them: Because we want to host systems in untrusted situations. Me: So you want to save money by not using a single physical host. Them: Yes. Me: Then spend some of that money to do the work to make this happen, do not force the community to do it for you. Them: ... > What is an acceptable rate for an unending stream of error messages? > Once a second? Once a minute? The *_ratelimited() functions should handle this if you want to use them. > At what point should the driver give up and stop trying to communicate > with the device? That's tricky, we don't have good answers for that as everyone has a different idea of how long "flaky" devices should be able to flake out before coming back. > (These are not moot questions. There are indeed drivers, and probably > not just in the USB subsystem, subject to this sort of behavior.) Totally agreed. But again, the design of Linux right now is that we implicitly trust the hardware we are running on. If that design decision wants to be changed, some people need to do a ton of work to change it. Thanks, greg k-h
