linux-kernel - Re: [git pull] vfs.git: poll annotations

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: <CA+55aFz8UL883+rj0nYsU_gtX6jLhriPGncDb1XDteEu817HRQ@mail.gmail.com>
Date:   Tue, 30 Jan 2018 18:21:37 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [git pull] vfs.git: poll annotations

On Tue, Jan 30, 2018 at 10:39 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>         Introduces a __bitwise type for POLL... bitmap, propagates
> the annotations through the tree.

Ok, I'm not entirely happy with this.

I don't think the mangle/demangle_poll() stuff should be in the uapi
headers, and it really worries me that we use the same names - with
different values - for the kernel and user versions of the POLLxyz
macros.

So honestly, like the structure translations we do (ie termios <->
ktermios, stat <-> kstat), I really think we'd be better off having
explicit naming when some kernel data is different from user data.

That could make the mangling be automated too, ie assuming gcc gets it
right, maybe done with

   #define pollmask_to_kernel(uval, UMASK, KMASK) \
        ((force __poll_t)(((uval)&UMASK)/UMASK*KMASK))

   static inline __poll_t unmangle_poll(unsigned int uval)
   {
        return pollmask_to_kernel(uval, POLLIN, KPOLLIN) |
             pollmask_to_kernel(uval, POLLOUT, KPOLLOUT) |
             pollmask_to_kernel(uval, POLLERR, KPOLLERR) |
             ...

or similar. With no arch-specific hardcoded bit knowledge except for
the actual values of POLLIN/etc.

I dunno. Maybe it ends up being too painful.

So I've pulled this, but I just wanted to state that I'm not entirely
happy about it all.

                Linus