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] [day] [month] [year] [list]

Date:   Thu, 5 Jan 2017 09:13:00 +0100
From:   Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:     Matthew Garrett <mjg59@...eos.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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>,
        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" <linux-pm@...r.kernel.org>,
        kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] Allow userspace control of runtime disabling/enabling of
 driver probing

On 4 January 2017 at 20:59, Matthew Garrett <mjg59@...eos.com> wrote:
> On Wed, Jan 4, 2017 at 1:46 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
>> On Wed, Jan 04, 2017 at 12:10:04PM -0600, Matthew Garrett wrote:
>>> On Wed, Jan 4, 2017 at 3:32 AM, Greg Kroah-Hartman
>>> <gregkh@...uxfoundation.org> wrote:
>>> > 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?
>>
>> How are you going to test this to ensure it continues to work properly?
>
> It's code that's already used over every suspend and resume. What kind
> of breakage are you expecting? How do we test any feature to ensure it
> continues to work properly?

In this specific case, we could use the Chamelium board to emulate USB
devices, automating the plugging of various USB device types at
different system states:

https://www.chromium.org/chromium-os/testing/chamelium

We are currently working on improving LAVA support for helper devices
such as the Chamelium, mainly for emulating displays in graphics
tests, but it can be useful for exercising other kernel ABIs such as
disable_device_probe. The goal is to have the result of these tests
reported to kernelci.org for spotting regressions early.

Regards,

Tomeu