linux-kernel - Re: [PATCHv3 0/4] sys

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]

Message-ID: <47426221.6020609@zytor.com>
Date:	Mon, 19 Nov 2007 20:27:13 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ulrich Drepper <drepper@...hat.com>
CC:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	mingo@...e.hu, tglx@...utronix.de, torvalds@...ux-foundation.org
Subject: Re: [PATCHv3 0/4] sys_indirect system call

Ulrich Drepper wrote:
> 
> But I still don't see that the magic encoding is a valid solution, it
> doesn't address the limited parameter number.  Plus, using sys_indirect
> could in future be used to transport entire parameters (like a sigset_t)
> along with other information, thereby saving individual copy operations.
> 

The limited number of parameters is a non-issue, we already have the 
convention for that: for more than 6 parameters, pass a parameter to 
arguments 6 and higher in the register normally used for parameter 6.

Now, for the specific case of x86-64 (as well as some of the RISC 
architectures), this meshes poorly with the C calling convention, which 
is that parameter 7+ are passed on the stack.  We would obtain a more 
efficient calling convention by allocating an additional register for 
such an indirect pointer and/or adopt the convention that the additional 
parameters are simply stored on the user stack starting at a specific 
offset, presumably +8.

I would really like to see a systematic calling convention that doesn't 
have limits that we have already broken several times.  In particular, I 
would like to see a convention that can be mapped 1:1 onto the platform 
C calling convention in a syscall-independent way.  We *almost* have 
this today, but sys_indirect would blow that out of the water in a 
particularly ugly way.(*)

> I think the sys_indirect approach is the way forward.  I'll submit a
> last version of the patch in a bit.

I think it is a horrible kluge.  It's yet another multiplexer, which we 
are trying desperately to avoid in the kernel.  Just to make things more 
painful, it is a multiplexer which creates yet another ad hoc calling 
convention, whereas we should strive to make the kernel calling 
convention as uniform as possible.

If is is NOT going to be used in the common case, then it really doesn't 
matter -- we can just use manually or automatically generated thunks. 
It's not like we have thousands of system calls, and it's not like "a 
system call" is a precious thing.

If it IS going to be used in the common case, then we should use 
something more streamlined.

	-hpa

-
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/