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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHmME9r7Vt1XFzceHhy7O67iVMhtpLJ-d0p8UGgV4Srd4Dt2Hg@mail.gmail.com>
Date:   Tue, 19 Apr 2022 18:42:09 +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

Hey Jann,

On Tue, Apr 19, 2022 at 6:38 PM Jann Horn <jannh@...gle.com> wrote:
> This is a bit of a weird API, because normally .poll is supposed to be
> level-triggered rather than edge-triggered... and AFAIK things like
> epoll also kinda assume that ->poll() doesn't modify state (but that
> only _really_ matters in weird cases). But at the same time, it looks
> like the existing proc_sys_poll() already goes against that? So I
> don't know what the right thing to do there is...

Doesn't the level vs edge distinction apply to POLLIN/POLLOUT events?
In this case, the event generated is actually POLLERR. On one hand,
this is sort of weird. On the other hand, it perhaps makes sense,
since nothing changes respect to its readability/writeability. And it
also happens to be how the sysctl poll() infrastructure was designed;
I didn't need to change anything for this behavior, and it comes as a
result of this rather trivial commit only. Looking at where else it's
used, it appears to be the intended use case for changes to
hostname/domainname. So while it's unusual, it also appears to be the
usual way that sysctl poll() works. So perhaps we're quite lucky here
in that sysctl poll() winds up being the correct interface for what we
want?

Jason