linux-kernel - Re: [PATCH v2 01/17] compat_ioctl: add generic_compat_ioctl

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: <CAK8P3a2PTaanqmJycLCJ5QgNFXONb7nVye1=TJST639wDBNpAQ@mail.gmail.com>
Date:   Thu, 13 Sep 2018 12:29:02 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 01/17] compat_ioctl: add generic_compat_ioctl_ptrarg()

On Thu, Sep 13, 2018 at 4:07 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Wed, Sep 12, 2018 at 05:01:02PM +0200, Arnd Bergmann wrote:
> > Many drivers have ioctl() handlers that are completely compatible
> > between 32-bit and 64-bit architectures, except for the argument
> > that is passed down from user space and may have to be passed
> > through compat_ptr() in order to become a valid 64-bit pointer.
> >
> > Using ".compat_ptr=generic_compat_ioctl_ptrarg" in file operations
> > should let us simplify a lot of those drivers to avoid #ifdef
> > checks, and convert additional drivers that don't have proper
> > compat handling yet.
>
> Just keep in mind that this should *only* be used when all
> ioctls implemented in a given instance do take pointers.
> Because otherwise you are asking for trouble - e.g. if one of
> them takes an u32 used as a bitmap, this will run into trouble
> as soon as somebody uses bit 31.  With no visible warnings.
>
> IOW, it shouldn't be used blindly and it should come with big
> fat warning.

I was hoping that the _ptrarg suffix gives enough warning here,
but maybe not. I was careful to only use it in cases that I
checked are safe, either using only pointer arguments, or
no arguments.

What we might do for further clarification (besides adding a
comment next to the declaration), would be to add a
complementary generic_compat_ioctl_intarg() that skips
the compat_ptr(). There are only a handful of drivers that
would use this though.

       Arnd