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: <20160902061040.GB13294@kroah.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ