On Thu, Feb 16, 2012 at 6:00 PM, Indan Zupancic [off-list ref] wrote:

On Fri, February 17, 2012 02:33, H. Peter Anvin wrote:

quoted

On 02/16/2012 04:48 PM, Indan Zupancic wrote:

quoted

On Thu, February 16, 2012 22:17, H. Peter Anvin wrote:

I would go for something like:

struct seccomp_data {
     int nr;
     __u32 arg_low[6];
     __u32 arg_high[6];
     __u32 instruction_pointer_low;
     __u32 instruction_pointer_high;
     __u32 __reserved[3];
};

Uh, that is the absolutely WORST way to do it - not only are you
creating two fields, they're not even adjacent.

You want:

struct seccomp_data {
       int nr;
       __u32 __reserved[3];
       __u64 arg[6];
       __u64 instruction_pointer;
};

And I agree it looks a lot nicer.

You can pretend a 64-bit arg will be one field, but it won't be. It will
be always two fields no matter what. Making them adjacent is only good
because seccomp_data won't have to change if 64-bit support is ever added
to BPF.

It looks nicer, but it only makes it harder to know the right offset for
the fields for the 32-bit only BPF programs. You can try to hide reality,
but that won't change it.

quoted

quoted

(Not sure what use the IP is because that doesn't tell anything about how
the system call instruction was reached.)

The only way to avoid splitting args is to add 64-bit support to BPF.
That is probably the best way forwards, but would require breaking the
BPF ABI by either adding a 64-bit version directly or adding extra
instructions.

Or the compiler or whatever generates the BPF code just is going to have
to generate two instructions -- just like we always have to handle
[u]int64_t on 32-bit platforms.  There is no difference here.

Except that if you don't hide the platform differences your compiler
or whatever needs to generate different instructions depending on the
endianess, while it could always generate the same instructions instead.

My impression is that you want to push all extra complexity into the
compiler or whatever instead of making the ABI cross-platform, because
it looks nicer. I don't care that much, but I think you're just pushing
the ugliness around instead of getting rid of it.

Is there really no syscall that cares about endianness?

Even if it ends up working, forcing syscall arguments to have a
particular endianness seems like a bad decision, especially if anyone
ever wants to make a 64-bit BPF implementation.  (Or if any
architecture adds 128-bit syscall arguments to a future syscall
namespace or whatever it's called.  x86-64 has 128-bit xmm
registers...)

--Andy