linux-kernel - Re: RFD: x32 ABI system call numbers

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 26 Aug 2011 17:36:35 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"H.J. Lu" <hjl.tools@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: RFD: x32 ABI system call numbers

On Fri, Aug 26, 2011 at 4:39 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 08/26/2011 04:13 PM, Linus Torvalds wrote:
>>
>>  - why do we need another system call model at all?
>
> We think we can get more performance for a process which doesn't need
> more than 4 GiB of virtual address space by allowing them to keep
> pointers 4 bytes long, while still giving them the advantage of 16
> 64-bit registers, PC-relative addressing, and so on.  Furthermore, there
> are users who seem more willing to port code known to not be 64-bit
> clean to x32 than to do a whole new port.

Let me repeat: what the f*&% does that have to do with a new system call model?

NOTHING.

At most, it means that we should add a PROT_4G to the mmap() system
call, so that user space can say "I want the result in the low 4G"
range. But even that wouldn't need a new system call.

> If the question is "why not just thunk this in userspace", the answer is
> that we'd like to take advantage of the compat layer already in the kernel.

And you *still* don't answer the question, you just make up new red
herring sentences.

Apart from mmap() (and to a lesser degree brk()), the kernel almost
never makes up user pointers. It's user space that points to them, and
gives them as arguments. There'sa few system calls that take pointers
to pointers: execve(), readv/writev, send/recvmsg, but then the actual
*example* you give isn't even one of those.

> If the question is "why not just use int $0x80" we actually did that in
> early prototyping, but SYSCALL64 is much faster.

No. The actual question is "why are you giving crazy examples, and
what the f*ck is going on"?

> sys_stat is unshared because it involves data structures in memory.  In
> x32, this invokes compat_sys_newstat just like you would from an i386
> process.

.. and this is exactly the kind of answer that makes me go NAK NAK NAK.

Christ no.

If you are doing a new native x32 model, then you DAMN WELL USE THE
EXISTING "stat()" system call.

There is *ZERO* reason to not use it. Use the standard 64-bit
structure layout. Why the hell would it be a new system call?

That's what I'm arguing against. This kind of crazy "let's make up YET
ANOTHER interface, even though the existing interface would work".
WHY?

If you want to be compatible with "int 0x80" and old libraries, then I
really don't see why you would introduce *anything* new.

And if it is truly a new ABI, then damn it, use the existing 64-bit
system calls as far as possible.

The "mix and match randomly and then introduce new system calls
because you made a bad design decision" sounds just crazy.

                              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/