linux-kernel - Re: userfaultfd: two-step UFFDIO

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: <3d4c1c59-4b01-4fa3-af84-e2d84f4ebf44@yandex.ru>
Date: Tue, 26 Nov 2024 19:16:19 +0300
From: stsp <stsp2@...dex.ru>
To: Peter Xu <peterx@...hat.com>
Cc: Muhammad Usama Anjum <Usama.Anjum@...labora.com>,
 Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: userfaultfd: two-step UFFDIO_API always gives -EINVAL

26.11.2024 18:56, Peter Xu пишет:
> This doesn't sound like the right thing to do.. as the fd (returned from
> syscall(userfaultfd)) should be linked to a specific mm.  If the parent
> invoked that syscall, it's linked to the parent address space, not child.
> You may want to do syscall(userfalut) in child process, then pass it over
> with scm rights.  Otherwise IIUC the trap will be armed on parent virtual
> address space.
Ok, thanks for info.
man page doesn't seem to describe
the multi-process case, so both fork()
and SCM_RIGHTS were just a guesses
on my side, one of which worked.
Probably something to add to the doc.

The last problem I had (last one, I promise! :)
is that if I remove O_NONBLOCK, then
the entire app hangs. It turns out, w/o
O_NONBLOCK, userfaultfd's fd awakes
the select() call with the ready-to-read
descriptor at the very beginning, long
before any fault is detected. Then it
goes to read() and blocks forever. My
code is not prepared for read() blocking
after select().
I then checked and double-checked
and re-checked that with O_NONBLOCK
nothing like that happens at all: select()
is not awaken until the faults are coming.
It could be that select awakes anyway
but read() doesn block, but no, its not
the case. In nonblock mode select()
awakes only when it should. And in
blocking mode - it awakes immediately,
leading to a hang.
Is this a bug?