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: <473FED5F.2010303@zytor.com>
Date:	Sat, 17 Nov 2007 23:44:31 -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:
> wing patches provide an alternative implementation of the
> sys_indirect system call which has been discussed a few times.
> This no system call allows us to extend existing system call
> interfaces with adding more system calls.
> 
> Davide's previous implementation is IMO far more complex than
> warranted.  This code here is trivial, as you can see.  I've
> discussed this approach with Linus last week and for a brief moment
> we actually agreed on something.
> 
> We pass an additional block of data to the kernel, it is copied into
> the task_struct, and then it is up to the function implementing the system
> call to interpret the data.  Each system call, which is meant to be
> extended this way, has to be white-listed in sys_indirect.  The
> alternative is to filter out those system calls which absolutely cannot
> be handled using sys_indirect (like clone, execve) since they require
> the stack layout of an ordinary system call.  This is more dangerous
> since it is too easy to miss a call.
> 

I stared at this a bit, and it took me some time to try to grok what it 
is trying to do.  Eventually I figured it out, and I wonder if there 
isn't an easier -- or at least more efficient -- way to accomplish this 
goal.

It seems to me that we could accomplish the same thing by passing the 
number of parameters in the upper bits of the system call number 
register (%eax in the case of x86.)  If set to zero, we'd fill in the 
legacy number of registers (for backwards compatibility.)  Unspecified 
arguments are then forced to zero before invoking the target function; 
we could also make a register count available if need be.

Alternatively, the same thing can be done with a dense system call 
number space by adding a number of parameters field to the system call 
table, however, that is more invasive in that one has to poke something 
into each architecture (unfortunately -- it would be so much nicer if 
there was a central metafile which one could process into the various 
architecture system call tables.)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ