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]

Date:   Fri, 2 Sep 2016 08:10:40 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Laura Abbott <labbott@...hat.com>
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 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.

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

thanks,

greg k-h