Hi Theo On Fri, Oct 4, 2024 at 12:11 PM Theo de Raadt <deraadt@xxxxxxxxxxx> wrote: > > Jeff Xu <jeffxu@xxxxxxxxxxxx> wrote: > > > > > + replacement with a new mapping with new set of attributes, or can > > > > + overwrite the existing mapping with another mapping. > > > > + > > > > + mprotect and pkey_mprotect are blocked because they changes the > > > > + protection bits (RWX) of the mapping. > > > > + > > > > + Some destructive madvise behaviors (MADV_DONTNEED, MADV_FREE,> + MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, MADV_WIPEONFORK) > > > > + for anonymous memory, when users don't have write permission to the > > > > + memory. Those behaviors can alter region contents by discarding pages, > > > > > > above is not a sentence but I don't know how to fix it. > > > > > Would below work ? > > > > Certain destructive madvise behaviors, specifically MADV_DONTNEED, > > MADV_FREE, MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, > > MADV_WIPEONFORK, can pose risks when applied to anonymous memory by > > threads without write permissions. These behaviors have the potential > > to modify region contents by discarding pages, effectively performing > > a memset(0) operation on the anonymous memory. > > > In OpenBSD, mimmutable blocks all those madvise() operations. > > > I don't understand the sentence supplied above. Is it saying that > mseal() solves that problem, or that mseal() does not solve that > problem. > Yes. The mseal solved the problem, I will modify the sentence to clarify that. thanks > I would hope it solves that problem. But the sentence explains the > problem without taking a position on what to do. >