Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > Adding mseal() into picture, however, the heap is then sealed > > partially, user can still free it, but the memory remains to be RO, > > and the result of brk-shrink is nondeterministic, depending on if > > munmap() will try to free the sealed memory.(brk uses munmap to shrink > > the heap). "You are holding it wrong". > > [...]. We could document above mentioned limitations so devs are > > more careful at the time to choose what memory to seal. You mean like they need to be careful what memory they map, careful what memory they unmap, careful what they do with mprotect, careful about not writing or reading out of bounds, etc. They need to be careful about everything. Programmers have complete control over the address space in a program. This is Linux we are talking about, it still doesn't have strict policy on W | X memory, but misuse of mseal is suddenly a developer crisis? Why is this memory attribute different, and how does it actually help? When they use mseal on objects with unproven future, the program will crash later, beautifully demonstrating that they held it wrong. Then they can fix their abusive incorrect code. This discussion about the malloc heap is ridiculous. Obviously it is programmer error to lock the permissions on memory you will free for reuse. But you can't fix this problem with malloc(), without breaking other extremely common circumstances where the allocation of memory and PERMANENT-USE-WITHOUT-RELEASE of such memory are seperated over a memory boundary, unless you start telling all open source library authors to always use MAP_SEALABLE in their mmap() calls.
