linux-hardening - Re: [PATCH v10 0/5] Introduce mseal

lists.openwall.net		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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wi04ZCm3vTtkcVnAUdiOpX3a0hBZ-aQWONwCubOJQEdXw@mail.gmail.com>
Date: Tue, 14 May 2024 18:20:23 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Theo de Raadt <deraadt@...nbsd.org>
Cc: Matthew Wilcox <willy@...radead.org>, Jonathan Corbet <corbet@....net>, 
	Andrew Morton <akpm@...ux-foundation.org>, jeffxu@...omium.org, keescook@...omium.org, 
	jannh@...gle.com, sroettger@...gle.com, gregkh@...uxfoundation.org, 
	usama.anjum@...labora.com, Liam.Howlett@...cle.com, surenb@...gle.com, 
	merimus@...gle.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 v10 0/5] Introduce mseal

On Tue, 14 May 2024 at 17:57, Theo de Raadt <deraadt@...nbsd.org> wrote:
>
> Let's wait and see.

You may not be aware, but the Open Group literally endorses the Linux model:

  "When mprotect() fails for reasons other than [EINVAL], the
protections on some of the pages in the range [addr,addr+len) may have
been changed"

at least according to this:

    https://pubs.opengroup.org/onlinepubs/9699919799/functions/mprotect.html

so I think your atomicity arguments have always been misleading. At
least for mprotect, POSIX is very explicit about this not being
atomic.

I find very similar wording in mmap:

  "If mmap() fails for reasons other than [EBADF], [EINVAL], or
[ENOTSUP], some of the mappings in the address range starting at addr
and continuing for len bytes may have been unmapped"

Maybe some atomicity rules have always been true for BSD, but they've
never been true for Linux, and while I don't know how authoritative
that opengroup thing is, it's what google found.

> (Linus, don't be a jerk)

I'm not the one who makes unsubstantiated statements and uses scare
tactics to try to make said arguments sound more valid than they are.

So keep your arguments real, please.

               Linus