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: Mon, 23 Oct 2023 10:44:16 -0700
From: Jeff Xu <>
To: Linus Torvalds <>
Cc: Pedro Falcato <>, Jeff Xu <>, 
	Matthew Wilcox <>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall

On Thu, Oct 19, 2023 at 4:06 PM Linus Torvalds
<> wrote:
> On Thu, 19 Oct 2023 at 15:47, Pedro Falcato <> 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

Thanks Linus for clarifying the guidelines on POSIX in Linux.


Powered by blists - more mailing lists