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: <Z0SwOILi4R4g9JBa@x1n>
Date: Mon, 25 Nov 2024 12:13:28 -0500
From: Peter Xu <peterx@...hat.com>
To: stsp <stsp2@...dex.ru>
Cc: Linux kernel <linux-kernel@...r.kernel.org>,
	Muhammad Usama Anjum <usama.anjum@...labora.com>,
	Axel Rasmussen <axelrasmussen@...gle.com>,
	Mike Rapoport <rppt@...nel.org>
Subject: Re: userfaultfd: two-step UFFDIO_API always gives -EINVAL

On Mon, Nov 25, 2024 at 08:07:34PM +0300, stsp wrote:
> 25.11.2024 19:58, Peter Xu пишет:
> > On Mon, Nov 25, 2024 at 07:15:10PM +0300, stsp wrote:
> > > Man page clearly talks about
> > > "the userfaultfd object" (one object)
> > > when mandating the "two-step handshake".
> > > I spent hours of head-scratching
> > > before went looking into the sources,
> > > and even then I was confident the man
> > > page is right: people should always assume
> > > documentation is correct, code is buggy.
> > Hmm yes.  I didn't pay much attention initially, but then after I read the
> > latest man-pages/, especially "UFFDIO_API(2const)" I found it looks indeed
> > wrong in the doc.
> > 
> > In this case we can't change the code because we need to keep it working
> > like before to not break ABI.  We may still update the doc.
> I wonder if some non-ABI-breaker
> is possible, like eg keep the current
> behavior of "features=0", but allow
> to (optionally) override that by a
> non-0 request? Yes, I've seen kselftests
> are trying to double-register after 0,
> but IIRC they tried to register wrong
> options, which would fail anyway.

Old kernels will fail with -EINVAL, new will succeed.  It's already an ABI
violation, IMHO.

Not to mention I'm not sure what could happen if uffd feature flags can
change on the fly.  Your proposal means it can happen when anon missing
trap is enabled at least.  That's probably unwanted, and unnecessary
complexity to maintain to the kernel.

Thanks,

-- 
Peter Xu