From: Greg KH <gregkh@linuxfoundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>,
USB mailing list <linux-usb@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: USB Denial Of Service
Date: Wed, 12 Jun 2024 11:55:17 +0200 [thread overview]
Message-ID: <2024061236-diabolic-wisplike-d2b1@gregkh> (raw)
In-Reply-To: <40dfa45b-5f21-4eef-a8c1-51a2f320e267@rowland.harvard.edu>
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
prev parent reply other threads:[~2024-06-12 9:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-11 14:35 USB Denial Of Service Alan Stern
2024-06-11 19:09 ` Alan Stern
2024-06-12 7:43 ` Oliver Neukum
2024-06-12 9:55 ` Greg KH
2024-06-12 8:00 ` Oliver Neukum
2024-06-12 9:55 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2024061236-diabolic-wisplike-d2b1@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox