Re: pseudo: host user contamination

[Andre McCurdy <armccurdy@gmail.com>]

On Tue, Mar 27, 2018 at 12:22 PM, Seebs <seebs@seebs.net> wrote:
>
> I was wondering about 64-bit EABI. The man page didn't say "32-bit
> EABI", it said "EABI".

EABI is just a name (Embedded ABI) which on ARM is used to distinguish
between the original ABI (now referred to as OABI, or Old ABI) and the
current one.

As far as I know, only one ABI exists for 64bit ARM and it's just
called the AArch64 ABI, not 64bit EABI etc.

Where the manpage says "EABI" it means ARM 32bit EABI, nothing else.

> The information that you don't need to do that
> on at least some ARM EABI arguably makes this *worse*, rather than
> *better*, from the standpoint of "how do I write correct code for
> this". So this appears to be at least partially a documentation error,
> although it's quite possible that the text predates the question having
> come up.
>
> But it does also mean that it should be harmless to us in this case.

You've lost me here...

> My basic concern is that I don't think I have enough information to
> produce a Provably Correct handling for syscall arguments in the
> presence of at least one architecture where argument order can change
> for at least one syscall.

Not sure what you mean by "handling of syscall arguments".

If you mean forwarding arguments through a wrapper without
interpreting them then I don't know what your concern is. Forwarding
arguments can be handled completely generically - for any architecture
and any syscall. See the musl implementation.

If you mean interpreting the arguments of a particular syscall then
yes - for each particular syscall, the C code calling libc syscall()
(and any code within libc syscall() which needs to interpret the
arguments) must be aware of the argument order for that particular
syscall as defined by the kernel for each architecture/ABI.

However the good news is that code in a syscall() wrapper doesn't need
to be any *more* aware of argument ordering than the C code calling
syscall(). In this particular case, if the code in gnulib calling
syscall(SYS_renameat2, ...) doesn't do anything architecture specific
then either it's not needed (and therefore also not needed in a
syscall() wrapper which wants interpret renameat2 syscalls) or there's
a portability bug in gnulib. ie there is no case where architecture
specific awareness is required in a syscall() wrapper but not in the
original C code which calls syscall().