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]

Message-ID: <caee30e2-ddc4-0076-907e-558dbcfe7c52@kernel.org>
Date:   Mon, 25 Mar 2019 09:51:21 -0600
From:   shuah <shuah@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     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>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sasha Levin <alexander.levin@...rosoft.com>,
        shuah <shuah@...nel.org>
Subject: Re: [PATCH] tools: usb: usbip: adding support for older kernel
 versions

On 3/18/19 12:23 PM, Brian Norris wrote:
> On Sat, Mar 16, 2019 at 4:40 PM shuah <shuah@...nel.org> wrote:
>> usbip tool is tied to the kernel version. This is reason why it is
>> co-located with the usbip driver in the kernel sources. This is not
>> a typical tool scenario to be able to use new tool on old kernels.
>>
>> I would like to understand the reasons for wanting to run new tool on
>> old kernels.
> 
> On Chromium OS, we ship more or less the same user space for a variety
> of systems, but not all of those run the same kernel. That's not
> exactly a novel concept -- many good tools are written such that they
> degrade gracefully when running with reduced feature sets (e.g., older
> kernels). While we are working on reducing the divergence and number
> of kernels we ship, it's currently a fact of life that we have to
> support multiple target kernel versions.

Thanks for the context for this change.

> 
> Is there a fundamental problem with VHCI such that it doesn't have a
> stable ABI that tools can be written against?
> 

In general the ABI is stable.

+#define V3_18_STATUS_HEADER "prt sta spd bus dev socket 
local_busid"

What's your 3.18 kernel version? I think you are missing security
fixes that prevent socket address leak in the status file.

+#define V4_4_STATUS_HEADER "prt sta spd dev      sockfd local_busid"
+#define V4_14_STATUS_HEADER "hub port sta spd dev      sockfd local_busid"

The difference here is the high speed support. Let's find a better
way to fix this than hard-coding kernel revisions in the tool.

> If stability is possible but you just don't care, then I guess we can
> fork our own version...
> 
> Or even worse, we could build N copies of usbip for N kernels. But we
> don't do that for any other user space component.
> 

It might be easier to build N versions than maintaining the fork :)

In any case, let's find ways to fix the problem with a constructive
approach.

thanks,
-- Shuah