On Wed, Jul 15, 2015 at 12:37 AM, Michael Ellerman <m...@ellerman.id.au> wrote:
> The seccomp_bpf test uses BPF_LD|BPF_W|BPF_ABS to load 32-bit values
> from seccomp_data->args. On big endian machines this will load the high
> word of the argument, which is not what the test wants.
>
> Borrow a hack from samples/seccomp/bpf-helper.h which changes the offset
> on big endian to account for this.
>
> Signed-off-by: Michael Ellerman <m...@ellerman.id.au>
> ---
> tools/testing/selftests/seccomp/seccomp_bpf.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index b2374c131340..51adb9afb511 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -82,7 +82,13 @@ struct seccomp_data {
> };
> #endif
>
> +#if __BYTE_ORDER == __LITTLE_ENDIAN
> #define syscall_arg(_n) (offsetof(struct seccomp_data, args[_n]))
> +#elif __BYTE_ORDER == __BIG_ENDIAN
> +#define syscall_arg(_n) (offsetof(struct seccomp_data, args[_n]) +
> sizeof(__u32))
> +#else
> +#error "wut?"
> +#endif
Ah-ha! Yes, thanks. Could you change the #error to something that
describes the particular (impossible) failure condition? "wut? Unknown
__BYTE_ORDER?!". Not a huge deal, but I always like verbose errors. :)
Especially for "impossible" situations. :)
-Kees
>
> #define SIBLING_EXIT_UNKILLED 0xbadbeef
> #define SIBLING_EXIT_FAILURE 0xbadface
> --
> 2.1.0
>
--
Kees Cook
Chrome OS Security
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
