[OE-core] pseudo: host user contamination

Andre McCurdy armccurdy at gmail.com
Sat Mar 24 01:43:12 UTC 2018


On Fri, Mar 23, 2018 at 6:17 PM, Seebs <seebs at seebs.net> wrote:
> On Fri, 23 Mar 2018 18:10:21 -0700
> Andre McCurdy <armccurdy at gmail.com> wrote:
>
>> The syscall wrapper in musl handles 6 additional arguments -
>> unconditionally. Based on that you might not need to interpret
>> anything - just extract 6 arguments and pass them on?
>>
>> long syscall(long n, ...)
>> {
>>     va_list ap;
>>     syscall_arg_t a,b,c,d,e,f;
>>     va_start(ap, n);
>>     a=va_arg(ap, syscall_arg_t);
>>     b=va_arg(ap, syscall_arg_t);
>>     c=va_arg(ap, syscall_arg_t);
>>     d=va_arg(ap, syscall_arg_t);
>>     e=va_arg(ap, syscall_arg_t);
>>     f=va_arg(ap, syscall_arg_t);
>>     va_end(ap);
>>     return __syscall_ret(__syscall(n,a,b,c,d,e,f));
>> }
>
> That is the sort of thing which *might* work, but which is potentially
> subject to arch-specific calling conventions or strangeness.
>
> It's worth a try, I guess? But I also think it may be worth just having
> all the people maintaining stuff that expects this go yell at coreutils
> about bad implementation choices, like "bypass libc to make raw
> syscalls when you are not, in fact, implementing libc".

Since glibc doesn't provide a wrapper for renameat2, making the
syscall via the libc syscall() API is exactly what coreutils (actually
gnulib) should be doing. There would certainly be grounds to complain
if user space code were making a syscall directly, but that's not
what's happening here - the syscall is still being made from within
libc.

Some more background here:

  https://lwn.net/Articles/655028/



More information about the Openembedded-core mailing list