Re: [PATCH v3 2/5] mm/mseal: update madvise() logic

[David Hildenbrand]

On 25.07.25 00:29, Kees Cook wrote:
> On Thu, Jul 24, 2025 at 11:41:04PM +0200, David Hildenbrand wrote:
> > On 24.07.25 23:32, David Hildenbrand wrote:
> > > > As an aside, why should discard work in this case even without step 4?
> > > > Wouldn't setting "read-only" imply you don't want the memory to change
> > > > out from under you? I guess I'm not clear on the semantics: how do memory
> > > > protection bits map to madvise actions like this?
> > >
> > > They generally don't affect MADV_DONTNEED behavior. The only documented
> > > (man page) reason for EPERM in the man page is related to MADV_HWPOISON.
> >
> > (Exception: MADV_POPULATE_READ/MADV_POPULATE_WRITE requires corresponding
> > permissions)
>
> Shouldn't an MADV action that changes memory contents require the W bit
> though?

In a MAP_RPIVATE file mapping, to know whether you are actually 
modifying memory ("discarding pages" ...) would require checking the 
actually mapped pages (mixture of anon and !anon folios). Only zapping 
anon folios is the problematic bit, really.

It could be implemented (e.g., fail halfway through while actually 
walking the page tables and zap).

But, yeah ...

> I mean, I assume the ship may have sailed on this, but it feels
> mismatched to me.

... I think that is that case, unfortunately.

I remember that userfaultfd can do some really nasty stuff with 
UFFDIO_COPY and MADV_DONTNEED on memory areas that don't have write 
permissions ... or even read permissions. Not sure if CRIU or other use 
cases depend on that in some weird way.

--
Cheers,

David / dhildenb