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-=wgDv5vPx2xoxNQh+kbvLsskWubGGGK69cqF_i4FkM-GCw@mail.gmail.com>
Date: Thu, 19 Oct 2023 16:06:14 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Pedro Falcato <pedro.falcato@...il.com>
Cc: Jeff Xu <jeffxu@...gle.com>, Matthew Wilcox <willy@...radead.org>, jeffxu@...omium.org, 
	akpm@...ux-foundation.org, keescook@...omium.org, sroettger@...gle.com, 
	jorgelo@...omium.org, groeck@...omium.org, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, linux-mm@...ck.org, jannh@...gle.com, 
	surenb@...gle.com, alex.sierra@....com, apopple@...dia.com, 
	aneesh.kumar@...ux.ibm.com, axelrasmussen@...gle.com, ben@...adent.org.uk, 
	catalin.marinas@....com, david@...hat.com, dwmw@...zon.co.uk, 
	ying.huang@...el.com, hughd@...gle.com, joey.gouly@....com, corbet@....net, 
	wangkefeng.wang@...wei.com, Liam.Howlett@...cle.com, lstoakes@...il.com, 
	mawupeng1@...wei.com, linmiaohe@...wei.com, namit@...are.com, 
	peterx@...hat.com, peterz@...radead.org, ryan.roberts@....com, 
	shr@...kernel.io, vbabka@...e.cz, xiujianfeng@...wei.com, yu.ma@...el.com, 
	zhangpeng362@...wei.com, dave.hansen@...el.com, luto@...nel.org, 
	linux-hardening@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall

On Thu, 19 Oct 2023 at 15:47, Pedro Falcato <pedro.falcato@...il.com> wrote:
> >
> > For mprotect()/mmap(), is Linux implementation limited by POSIX ?
>
> No. POSIX works merely as a baseline that UNIX systems aim towards.
> You can (and very frequently do) extend POSIX interfaces (in fact,
> it's how most of POSIX was written, through sheer
> "design-by-committee" on a bunch of UNIX systems' extensions).

We can in extreme circumstances actually go further than that, and not
only extend on POSIX requirements, but actively even violate them.

It does need a very good reason, though, but it has happened when
POSIX requirements were simply actively wrong.

For example, at one point POSIX required

     int accept(int s, struct sockaddr *addr, size_t *addrlen);

which was simply completely wrong. It's utter shite, and didn't
actually match any reality.

The 'addrlen' parameter is 'int *', and POSIX suddenly trying to make
it "size_t" was completely unacceptable.

So we ignored it, told POSIX people that they were full of sh*t, and
they eventually fixed it in the next version (by introducing a
"socklen_t" that had better be the same as "int").

So POSIX can simply be wrong.

Also, if it turns out that we had some ABI that wasn't
POSIX-compatible, the whole "don't break user space" will take
precedence over any POSIX concerns, and we will not "fix" our system
call if people already use our old semantics.

So in that case, we generally end up with a new system call (or new
flags) instead.

Or sometimes it just is such a small detail that nobody cares - POSIX
also has a notion of documenting areas of non-conformance, and people
who really care end up having notions like "conformance vs _strict_
conformance".

                 Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ