[PATCH v8 1/8] linux: Add mseal syscall support

[Florian Weimer]

* Adhemerval Zanella:

> +A successful call to the @code {mseal} function seals the memory range of
> +@var{length} bytes, starting at @var{address}.  The sealed memory is
> +protection against further modifictions such as:

This is quite misleading.  Sealing prevents metadata changes, it does
not prevent changes to the data itself (even if the mapping is not
writeable at sealing).  Could you rephrase it?

> +@item
> +Moving or expanding a different VMA into the current location, via
> +@code{mremap}.

> +@item
> +Expanding the size with @code{mremap}.

Duplicate?

> +@item
> +Change the protection flags with @code{mprotect} or @code{pkey_mprotect}.

This doesn't mention the protection key for pkey_mprotect.  What is the
expected impact 

> +
> +@item
> +Destructive behaviors on anonymous memory, such as @code{madvice} with
> +@code{MADV_DONTNEED}.
> +@end itemize
> +
> +The @var{address} must be an allocated virtual memory done by @code{mmap}
> +or @code{mremap}, and it must be page aligned.  The end address (@var{address}
> +plus @var{length}) must be within an allocated virtual memory range.  There
> +should be no unallocated memory between the start and end of address range.
> +
> +The @var{flags} is currently ununsed.
> +
> +The @code{mseal} function returns @math{0} on sucess and @math{-1} on
> +failure.
> +
> +The following @code{errno} error conditions are defined for this
> +function:
> +
> +@table @code
> +@item EPERM
> +The system blocked the operation, and the given address is unmodified

the given address [range] is unmidifed?

> +without partion update.  This error is also returned when @code{mseal}

without [a] parti[al] update?

> +is issued on a 32 bit CPUs (the sealing is currently supported only on
> +64-bit CPUs, although 32 bit binaries running on 64 bit kernel is
> +supported).
> +
> +@item ENOMEM
> +Either the @var{address} is not allocated, or the end address is not
> +allocation, or there is an unallocated memory between start and end address.

the end address is not [within the] allocation?

> +@item ENOSYS
> +The kernel does not support the @code{mseal} syscall.
> +
> +@strong{NB:} The memory sealing changes the lifetime of a mapping, where the
> +sealing memory could not be unmapped until the process terminates or starts
> +another one through @code{execve} function.

terminates or [replaces the process image] through @code{execve}?


Are seals inherited via fork?

Thanks,
Florian