Hi Theo On Fri, Oct 4, 2024 at 6:04 PM Theo de Raadt <deraadt@xxxxxxxxxxx> wrote: > > Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > > > On 10/4/24 9:52 AM, Jeff Xu wrote: > > >> 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. > > > > Yes, that works. > > Or at least it explains the problem, like Theo said. > > In OpenBSD, mimmutable() solves this problem (in later code iterations). > > In Linux, does mseal() solve the problem or not? The statement doesn't > answer this question. It only explains the problem. > > If it doesn't solve the problem, that's pretty surprising (weaker than > mimmutable). > > During development I wrote a fake little program which placed an 'int = > 1' resided into a zone of readonly memory (.data), and then imagined "an > attacker gets enough control to perform an madvise(), but only had > enough control, and has to return to normal control flow immediately". > The madvise() operations was able to trash the int, altering the > program's later behaviour. So I researched the matter more, and adapted > mimmutable() to block ALL system-call variations similar to 'write to a > not-permitted region'. > > So the question remains: Does mseal() block such a (rare) pattern or not. Apology for delay. Yes, mseal does block such patterns. Thanks -Jeff > The sentence doesn't indicate that mseal() has a response to the stated > problem. >
