linux-kernel - Re: [PATCH 3/7] Add a UFFD_SECURE flag to the userfaultfd API.

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]

Date:   Wed, 23 Oct 2019 16:01:53 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Andrea Arcangeli <aarcange@...hat.com>
Cc:     Andy Lutomirski <luto@...nel.org>, Jann Horn <jannh@...gle.com>,
        Daniel Colascione <dancol@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Pavel Emelyanov <xemul@...tuozzo.com>,
        Lokesh Gidra <lokeshgidra@...gle.com>,
        Nick Kralevich <nnk@...gle.com>,
        Nosh Minwalla <nosh@...gle.com>,
        Tim Murray <timmurray@...gle.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Linux API <linux-api@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>
Subject: Re: [PATCH 3/7] Add a UFFD_SECURE flag to the userfaultfd API.



> On Oct 23, 2019, at 3:41 PM, Andrea Arcangeli <aarcange@...hat.com> wrote:
> 
> On Wed, Oct 23, 2019 at 02:25:35PM -0700, Andy Lutomirski wrote:
>> That doesn't solve the problem.  With your time machine, you should
> 
> Would you elaborate what problem remains if execve closes all uffd
> so that read() cannot run post execve?
> 

fcntl() can clear the CLOEXEC flag. And CLOEXEC has no effect on SCM_RIGHTS.

>> instead use ioctl() or recvmsg().
> 
> The event delivery is modeled after eventfd.c per userfaultfd.c header
> file, so would then eventfd also need to be converted to ioctl or
> recvmsg to deliver its event any better? Initially I evaluated to use
> eventfd for it in fact, but it wasn't possible. I didn't look like it
> could get any better than eventfd in terms of event delivery.
> 
> Or do you refer to single out only the delivery of the UFFD_EVENT_FORK
> event not through read()?

Delivering events through read() is just fine. The problem is when delivering an event does more than just returning bytes. As far as I’ve noticed, uffd’s read() just returns bytes as long as FORK is disabled.