Date:	Sun, 20 Jan 2013 20:09:14 -0500
From:	Mike Frysinger <vapier@...too.org>
To:	libc-alpha@...rceware.org
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Carlos O'Donell" <carlos@...temhalted.org>,
	Eric Paris <eparis@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>,
	Casey Schaufler <casey@...aufler-ca.com>,
	linux-kernel@...r.kernel.org, dwalsh@...hat.com,
	dmalcolm@...hat.com, sds@...ho.nsa.gov, segoon@...nwall.com,
	linux-security-module@...r.kernel.org
Subject: Re: Friendlier EPERM - Request for input

On Sunday 20 January 2013 19:00:46 Eric W. Biederman wrote:
> Carlos O'Donell writes:
> > On 01/09/2013 04:09 PM, Eric Paris wrote:
> >> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
> >>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> >>>> I'm suggesting that the string returned by get_extended_error_info()
> >>>> ought to be the audit record the system call would generate,
> >>>> regardless of whether the audit system would emit it or not.
> >>> 
> >>> What system call would that info be for and would it be reset on next
> >>> syscall that succeeded, or also failed?
> >>> 
> >>> The thing is, various functions e.g. perform some syscall, save errno,
> >>> do some other syscall, and if they decide that the first syscall
> >>> should be what determines the whole function's errno, just restore
> >>> errno from the saved value and return.  Similarly, various functions
> >>> just set errno upon detecting some error condition in userspace.
> >>> There is no 1:1 mapping between many libc library calls and syscalls.
> >>> So, when would it be safe to call this new get_extended_error_info
> >>> function and how to determine to which syscall it was relevant?
> > 
> > I asked the same questions as Jakub asked but in a slightly different
> > formulation (http://cygwin.com/ml/libc-alpha/2013-01/msg00267.html).
> > 
> >> I was thinking of it to be the last kernel error.  So if the first and
> >> that second operation caused the kernel to want to make available
> >> extended errno information you would end up with the second.  I see this
> >> is an informative piece of information, not normative.  Not a
> >> replacement for errno.  I'm hoping for a best effort way to provide
> >> extended errno information.
> > 
> > IMO Casey's answer is the right solution i.e. whatever the errno
> > behaviour was.
> 
> Let me propose a different mechanism for getting this to user space
> that gives you a save/restore ability.
> 
> When a system call returns with an error we return the error code
> in one register and leave the rest of the registers that calling
> conventions allow us to stomp unchanged.

the syscall ABI is not the same as the calling convention.  pretty much all C 
libraries use inline asm to do syscalls.  a few applications do too, but for 
the most part those have converted to the syscall() library function nowadays 
since the kernel stopped exporting _syscall[1-6]() macros for apps to use 
directly.

basically, that means you can't change the syscall ABI w/out breaking 
userspace especially on i386 as it is the most constrained architecture.  you 
might get away with it with others which have a lot of spare regs that pretty 
much no one uses, but that can be dicey too since you're relying on how code 
just happens to be generated by gcc.

the inline asm declares the syscall args only as inputs.  the only output is 
the return register, and memory/cc are the only clobbers.

you could do this in a backwards compatible way by setting a bit in the 
syscall NR to indicate that userland knows it will get back two values.  the 
kernel will check & clear that bit first before looking up the syscall table.  
somewhat like how the x32 ABI is handled.

not saying i like that idea at all, just providing an alternative that would 
work w/out breaking userspace.
-mike

Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists