linux-kernel - Re: [PATCH] random: add fork_event sysctl for polling VM forks

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHmME9q+mDw6n3FNJLvoZoD3UsX-G5PvTwb5L7h_M9RFKNemSw@mail.gmail.com>
Date:   Wed, 20 Apr 2022 02:15:45 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Jann Horn <jannh@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Alexander Graf <graf@...zon.com>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Theodore Ts'o" <tytso@....edu>,
        Colm MacCarthaigh <colmmacc@...zon.com>
Subject: Re: [PATCH] random: add fork_event sysctl for polling VM forks

Hi Jann,

On Tue, Apr 19, 2022 at 9:45 PM Jann Horn <jannh@...gle.com> wrote:
> AFAIK this also means that if you make an epoll watch for
> /proc/sys/kernel/random/fork_event, and then call poll() *on the epoll
> fd* for some reason, that will probably already consume the event; and
> if you then try to actually receive the epoll event via epoll_wait(),
> it'll already be gone (because epoll tries to re-poll the "ready"
> files to figure out what state those files are at now). Similarly if
> you try to create an epoll watch for an FD that already has an event
> pending: Installing the watch will call the ->poll handler once,
> resetting the file's state, and the following epoll_wait() will call
> ->poll again and think the event is already gone. See the call paths
> to vfs_poll() in fs/eventpoll.c.
>
> Maybe we don't care about such exotic usage, and are willing to accept
> the UAPI inconsistency and slight epoll breakage of plumbing
> edge-triggered polling through APIs designed for level-triggered
> polling. IDK.

Hmm, I see. The thing is, this is _already_ what's done for
domainname/hostname. It's how the sysctl poll handler was "designed".
So our options here are:

a) Remove this quirky behavior from domainname/hostname and start
over. This would potentially break userspace, but maybe nobody uses
this? No idea, but sounds risky.

b) Apply this commit as-is, because it's using the API as the API was
designed, and call it a day.

c) Apply this commit as-is, because it's using the API as the API was
designed, and then later try to fix up the epoll behavior on this.

Of these, (a) seems like a non-starter. (c) is most appealing, but it
sounds like it might not actually be possible?

Jason