Re: [PATCH v7 2/4] mseal: add mseal syscall

[Theo de Raadt]

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.