linux-kernel - Re: [PATCH] tools: usb: usbip: adding support for older kernel versions

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]

Date:   Mon, 25 Mar 2019 17:49:07 -0700
From:   Brian Norris <briannorris@...omium.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     shuah <shuah@...nel.org>, David Valleau <valleau@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux USB Mailing List <linux-usb@...r.kernel.org>,
        Michael Grzeschik <m.grzeschik@...gutronix.de>,
        Valentina Manea <valentina.manea.m@...il.com>,
        Sasha Levin <alexander.levin@...rosoft.com>
Subject: Re: [PATCH] tools: usb: usbip: adding support for older kernel versions

Hi Greg,

On Mon, Mar 25, 2019 at 5:35 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> 3.18 was released at the end of 2014, and as the tool that came with
> that kernel still works just fine, you are just pushing the boundry here
> really hard :)

For some reason, we're focusing on 3.18, when the last breakage we're
currently aware of was as recent as 4.13. So we (Chrom{ium,e} OS) also
dealing with 4.4, which is still getting active LTS releases (thanks!)
and is in heavy use.

> Why do you want to update your userspace tool and not update your
> kernel?  What is forcing your userspace tool to be updated?

I tried to downplay that part: we're primarily interested in finding
some way to utilize the *same* tool on all kernels in question. It
doesn't have to be the latest. But it's currently impossible, mostly
due to commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed
support").

We also certainly have flexibility to hack things on our own and don't
need upstream to care about everything we care about (e.g.,
sufficiently old kernels), but I did want to have this conversation at
least, so that people are aware of the breakages they are making, and
so we can understand what to expect.

> Not to say that this shouldn't be fixed if at all possible, but realize
> that this is not the "normal" case of "we do not break userspace" here,
> given the tool involved, and the apis being used.

I think I sort of understand what you're going for here, but can you
elaborate so I don't have to assume?

Thanks,
Brian