This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support six-argument syscalls from C for 32-bit x86, use generic lowlevellock-futex.h (bug 18138)
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Richard Henderson <rth at twiddle dot net>
- Cc: libc-alpha at sourceware dot org, roland at hack dot frob dot com, triegel at redhat dot com, carlos at redhat dot com
- Date: Tue, 24 Mar 2015 04:15:31 +0100
- Subject: Re: Support six-argument syscalls from C for 32-bit x86, use generic lowlevellock-futex.h (bug 18138)
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1503210026500 dot 5144 at digraph dot polyomino dot org dot uk> <55104F40 dot 302 at twiddle dot net> <alpine dot DEB dot 2 dot 10 dot 1503232146050 dot 18218 at digraph dot polyomino dot org dot uk>
On 03/23/2015 10:47 PM, Joseph Myers wrote:
> On Mon, 23 Mar 2015, Richard Henderson wrote:
>
>> On 03/20/2015 05:28 PM, Joseph Myers wrote:
>>> +#define INTERNAL_SYSCALL_MAIN_6(name, err, arg1, arg2, arg3, \
>>> + arg4, arg5, arg6) \
>>> + struct libc_do_syscall_args _xv = \
>>> + { \
>>> + (int) (arg1), \
>>> + (int) (arg5), \
>>> + (int) (arg6) \
>>> + }; \
>>> + asm volatile ( \
>>> + "movl %1, %%eax\n\t" \
>>> + "call __libc_do_syscall" \
>>> + : "=a" (resultvar) \
>>> + : "i" (__NR_##name), "c" (arg2), "d" (arg3), "S" (arg4), "D" (&_xv) \
>>> + : "memory", "cc")
>>
>> Is this really so much better than
>>
>> extern int __attribute__((regcall(3))) attribute_hidden
>> __libc_do_syscall(int nr_eax, int arg3_edx, int arg2_ecx, int arg1_ebx,
>> int arg4_esi, int arg5_edi, int arg6_ebp);
>>
>> and performing the call itself in C? It's only one more register you need to
>> read from the stack in the function, but it avoids the compiler seeing a leaked
>> pointer to the caller's stack frame. The later could well influence
>> optimization negatively.
>
> I don't see the leaked pointer as relevant to optimization. GCC knows
> that a pointer to one stack object can't be a basis for a pointer to
> another stack object, and that the variable's lifetime ends at end of
> scope.
Your code causes instrumentation with -fstack-protector-strong (because
there is an addressable local variable), and the plain function call
wouldn't.
--
Florian Weimer / Red Hat Product Security