[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPeXnHudW-YDmoK8NrFzQgAq4WuRDgFNC5-0GaG0+jVkq+3meQ@mail.gmail.com>
Date: Wed, 4 Jan 2017 12:10:04 -0600
From: Matthew Garrett <mjg59@...eos.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Kees Cook <keescook@...omium.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>, Ulf Hansson <ulf.hansson@...aro.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Tomeu Vizoso <tomeu.vizoso@...labora.com>,
Lukas Wunner <lukas@...ner.de>, Madalin Bucur <madalin.bucur@....com>,
Sudip Mukherjee <sudipm.mukherjee@...il.com>, Rasmus Villemoes <linux@...musvillemoes.dk>,
Arnd Bergmann <arnd@...db.de>, Andrew Morton <akpm@...ux-foundation.org>,
Russell King <rmk+kernel@....linux.org.uk>, Petr Tesarik <ptesarik@...e.com>,
linux-pm@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] Allow userspace control of runtime disabling/enabling of
driver probing
On Wed, Jan 4, 2017 at 3:32 AM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> Ick, hiding this in the power management code? That's messy, and
> complex, as Rafael pointed out.
It's in code that's used in the power management layer, not in power
management code. This is all in the driver core.
> Turning on and off at random times "new devices can not be bound, wait,
> now they can!" is ripe for loads of issues and is going to be a pain to
> properly maintain over time.
What kind of issues?
> What's wrong with the facility that the USB layer provides today to
> allow only "authenticated" devices to be enabled? That has been used
> for a few years now to prevent these "don't allow random devices that
> are plugged into the computer to be enabled" type attacks. Doing much
> the same thing, in a different manner, is ripe for problems (how do the
> two interact now?)
The USB authentication feature was intended for handling wireless USB
devices - it can be reused for this, but the code isn't generic enough
to apply to other bus types. The two interact in exactly the way you'd
expect, ie they don't. If you use both, then you need to handle both.
> If you are worried about PCI devices, why not just implement what USB
> did for PCI? Or better yet, move the USB functionality into the driver
> core, adding that type of authentication ability to any bus that wishes
> to have it (and not break existing working systems that are using the
> USB solution today.)
The USB approach requires userspace to keep track of which devices
were added while the session was locked, whereas the kernel already
has the logic to do all of this. All the complexity already exists and
is used every time anybody suspends and resumes, so why add additional
complexity?
I'm not clear on how this patch breaks anybody using the existing USB solution?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
