Re: + mseal-update-msealrst.patch added to mm-hotfixes-unstable branch

[Theo de Raadt <deraadt@cvs.openbsd.org>]

>-Additional notes:
>-=================
> As Jann Horn pointed out in [3], there are still a few ways to write
>-to RO memory, which is, in a way, by design. Those cases are not covered
>-by mseal(). If applications want to block such cases, sandbox tools (such as
>-seccomp, LSM, etc) might be considered.
>+to RO memory, which is, in a way, by design. And those could be blocked
>+by different security measures.
> 
> Those cases are:
> 
>-- Write to read-only memory through /proc/self/mem interface.
>-- Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
>-- userfaultfd.
>+   - Write to read-only memory through /proc/self/mem interface (FOLL_FORCE).
>+   - Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
>+   - userfaultfd.

This block of notes keeps bothering me, because I've encountered a bunch
of people who walk away with "oh but what's the purpose of this thing then
it is useless".

mimmutable and mseal are about restricting playing with the permission of
the *MAPPING* of memory, not about restricting the memory itself.

If it is going to remain, should it also say?

   - Write to a non-readonly mapping of the same memory object shared
     by a a different process, or shared to a different address in the
     same process, which is not read-only  (and this is a thing many
     older JIT do)

To wit, this is not because of mseal.  It is not because of the mapping
of the memory.  It is not because of the mapping of the memory.  It is
because a different interface to reach the same memory can always act.
It is because the permissions on one mapping obviously do not apply to
another mapping or access method.  Permissions apply to mappings, not to
memory.

A note: many decades ago, the Sun / CSRG named these calls mmap, munmap,
and mprotect.  The word "map" in mmap suggests the leading "m" is "memory".
With mprotect this gets confusing, because with shared mappings on the
same memory, it does not protect the memory, only the access via the
mapping region. "mseal" and "mimmutable" fall into the same catagory
where "m" refers to "mapping", not to "memory"; memory is actual bits
and bytes which may be mapped twice or more in circumstances.