[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 01 Feb 2024 17:26:25 -0700
From: "Theo de Raadt" <deraadt@...nbsd.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Jeff Xu <jeffxu@...omium.org>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Jonathan Corbet <corbet@....net>, akpm@...ux-foundation.org,
keescook@...omium.org, jannh@...gle.com, sroettger@...gle.com,
willy@...radead.org, gregkh@...uxfoundation.org,
usama.anjum@...labora.com, rdunlap@...radead.org, jeffxu@...gle.com,
jorgelo@...omium.org, groeck@...omium.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-mm@...ck.org, pedro.falcato@...il.com, dave.hansen@...el.com,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH v8 0/4] Introduce mseal
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> and using PROT_SEAL at mmap() time is similarly the same obvious
> notion of "map this, and then seal that mapping".
The usual way is:
ptr = mmap(NULL, len PROT_READ|PROT_WRITE, ...)
initialize region between ptr, ptr+len
mprotect(ptr, len, PROT_READ)
mseal(ptr, len, 0);
Our source tree contains one place where a locking happens very close
to a mmap().
It is the shared-library-linker 'hints file', this is a file that gets
mapped PROT_READ and then we lock it.
It feels like that could be one operation? It can't be.
addr = (void *)mmap(0, hsize, PROT_READ, MAP_PRIVATE, hfd, 0);
if (_dl_mmap_error(addr))
goto bad_hints;
hheader = (struct hints_header *)addr;
if (HH_BADMAG(*hheader) || hheader->hh_ehints > hsize)
goto bad_hints;
/* couple more error checks */
mimmutable(addr, hsize);
close(hfd);
return (0);
bad_hints:
munmap(addr, hsize);
...
See the problem? It unmaps it if the contents are broken. So even that
case cannot use something like "PROT_SEAL".
These are not hypotheticals. I'm grepping an entire Unix kernel and
userland source tree, and I know what 100,000+ applications do. I found
piece of code that could almost use it, but upon inspection it can't,
and it is obvious why: it is best idiom to allow a programmer to insert
an inspection operation between two disctinct operations, and especially
critical if the 2nd operation cannot be reversed.
Noone needs PROT_SEAL as a shortcut operation in mmap() or mprotect().
Throwing around ideas without proving their use in practice is very
unscientific.
Powered by blists - more mailing lists