linux-kernel - Re: [PATCHv2 3/4] staging: android: ion: Add an ioctl for ABI checking

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: <b88faa4e-4ec3-61df-d90b-e17ec6238726@redhat.com>
Date:   Fri, 2 Sep 2016 13:26:31 -0700
From:   Laura Abbott <labbott@...hat.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Sumit Semwal <sumit.semwal@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        Arve Hjønnevåg <arve@...roid.com>,
        Riley Andrews <riandrews@...roid.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        linaro-mm-sig@...ts.linaro.org, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org,
        Eun Taik Lee <eun.taik.lee@...sung.com>,
        Liviu Dudau <Liviu.Dudau@....com>,
        Jon Medhurst <tixy@...aro.org>,
        Mitchel Humpherys <mitchelh@...eaurora.org>,
        Jeremy Gebben <jgebben@...eaurora.org>,
        Bryan Huntsman <bryanh@...eaurora.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        Chen Feng <puck.chen@...ilicon.com>,
        Brian Starkey <brian.starkey@....com>
Subject: Re: [PATCHv2 3/4] staging: android: ion: Add an ioctl for ABI
 checking

On 09/01/2016 11:10 PM, Greg Kroah-Hartman wrote:
> On Thu, Sep 01, 2016 at 03:40:43PM -0700, Laura Abbott wrote:
>>
>> The current Ion ioctls lack a good way to tell what ioctls are
>> available. Introduce an ioctl to give an ABI version. This way when the
>> ABI inevitably gets screwed up userspace will have a way to tell what
>> version of the screw up is available.
>
> This worries me.  Why do we need this?  Shouldn't any "new" abi changes
> just add on, and not change existing ioctl structure calls?  Or worst
> case, you remove an ioctl and then userspace "knows" that when the call
> fails.

This may be more of an "I wish we had this when some poor decisions were
made in the past". There were a couple of instances when the Ion ABI
was broken (adding new fields, new ioctl numbers) that were a nightmare
to deal with and a similar ioctl would have helped a lot. The
botching-ioctls document also made reference to something simliar.

>
> And who is the major userspace user of this interface?  Who controls it?
> How are we keeping things in sync here?
>

I would expect this to not actually be used until we have breakage. The
broken ioctl would then be checked as needed.

Reading all this and thinking some, it sounds like this shouldn't actually
be needed so long as we continue to not break the ioctls. I had a thought
of this possibly making life easier for out of tree users to eventually
convert over but I haven't heard much from actual out of tree users.

I'd like to keep it just to hedge my bets but I also haven't had as much
experience maintaining stable ioctls for the long term. If, from others
experience, this type of ioctl is actually just more prone to breakage
and doesn't help then I don't want to push something that will eventually
break.

> thanks,
>
> greg k-h
>

Thanks,
Laura