linux-kernel - Re: Suppress pte soft-dirty bit with 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] [day] [month] [year] [list]

Message-ID: <CAJHvVcjLecujsDCQ2AK89C5HJ7LLYc8ez1VEpG5m9yP8eJtnHg@mail.gmail.com>
Date: Fri, 23 May 2025 13:32:11 -0700
From: Axel Rasmussen <axelrasmussen@...gle.com>
To: Peter Xu <peterx@...hat.com>
Cc: Kyle Huey <me@...ehuey.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	open list <linux-kernel@...r.kernel.org>, linux-mm@...ck.org, criu@...ts.linux.dev, 
	"Robert O'Callahan" <robert@...llahan.org>, Mike Rapoport <rppt@...nel.org>, 
	Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: Suppress pte soft-dirty bit with UFFDIO_COPY?

On Tue, May 13, 2025 at 6:25 AM Peter Xu <peterx@...hat.com> wrote:
>
> On Mon, May 12, 2025 at 10:16:12AM -0700, Kyle Huey wrote:
> > Personally I don't think it's a real issue to have to create a
> > sacrificial fd once at process initialization to see what features are
> > available. I wouldn't have even said anything if the man page hadn't
> > explicitly told me there was another way.
>
> Yes, that's indeed the part that could be confusing and needs fixing.  Just
> to keep a record (I have you copied), I sent the man-pages changes here:
>
> https://lore.kernel.org/r/20250512171922.356408-1-peterx@redhat.com

Agreed, at a high level I think this is the right fix. I believe I
just forgot the probing required a separate FD when I wrote that
version of the man page. :)

>
> We can stick with the sacrificial fd until there's a solid clue showing
> that we should introduce a new way to probe.

For what it's worth, I'm still convinced the whole handshake / probing
thing is overcomplicated, and it would be simpler to just do:

1. Userspace asks for the features it wants (UFFDIO_API)
2. Kernel responds (fills in the struct) with the (possibly subset) of
features it supports
3. Userspace can react as it sees fit if it gets a subset (fail with
error, gracefully degrade, ...)

But, based on previous discussion of that I believe I'm in the minority. :)

If we are sticking with the handshake approach, I agree needing a
second uffd is no big deal. We could add an ioctl to just probe
without configuring, but that would purely be for convenience, and I
don't think it saves many lines of code in userspace. So, on balance /
considering the small benefit I would probably prefer keeping the
kernel simpler.

>
> Thanks,
>
> --
> Peter Xu
>

On Tue, May 13, 2025 at 6:25 AM Peter Xu <peterx@...hat.com> wrote:
>
> On Mon, May 12, 2025 at 10:16:12AM -0700, Kyle Huey wrote:
> > Personally I don't think it's a real issue to have to create a
> > sacrificial fd once at process initialization to see what features are
> > available. I wouldn't have even said anything if the man page hadn't
> > explicitly told me there was another way.
>
> Yes, that's indeed the part that could be confusing and needs fixing.  Just
> to keep a record (I have you copied), I sent the man-pages changes here:
>
> https://lore.kernel.org/r/20250512171922.356408-1-peterx@redhat.com
>
> We can stick with the sacrificial fd until there's a solid clue showing
> that we should introduce a new way to probe.
>
> Thanks,
>
> --
> Peter Xu
>