Randy Dunlap rdunlap@infradead.org 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. The sentence doesn't indicate that mseal() has a response to the stated problem.