linux-kernel - Re: [PATCH] Allow userspace control of runtime disabling/enabling of driver probing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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?