lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Oct 2023 10:00:33 +0200
From: Stephen Röttger <>
To: Linus Torvalds <>
Cc: Theo de Raadt <>, Jeff Xu <>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall

> I do like us starting with just "mimmutable()", since it already
> exists. Particularly if chrome already knows how to use it.
> Maybe add a flag field (require it to be zero initially) just to allow
> any future expansion. Maybe the chrome team has *wanted* to have some
> finer granularity thing and currently doesn't use mimmutable() in some
> case?

Yes, we do have a use case in Chrome to split the sealing into unmap and
mprotect which will allow us to seal additional pages that we can't seal with
pure mimmutable().
For example, we have pkey-tagged RWX memory that we want to seal. Since
the memory is already RWX and the pkey controls write access, we don't care
about permission changes but sometimes we do need to mprotect data only
But the munmap sealing will provide protection against implicit changes of the
pkey in this case which would happen if a page gets unmapped and another
mapped in its place.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4005 bytes)

Powered by blists - more mailing lists