linux-kernel - Re: [PATCH v8 3/8] seccomp: add system call filtering using BPF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F3D7250.6040504@zytor.com>
Date:	Thu, 16 Feb 2012 13:17:04 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Will Drewry <wad@...omium.org>
CC:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-doc@...r.kernel.org, kernel-hardening@...ts.openwall.com,
	netdev@...r.kernel.org, x86@...nel.org, arnd@...db.de,
	davem@...emloft.net, mingo@...hat.com, oleg@...hat.com,
	peterz@...radead.org, rdunlap@...otime.net, mcgrathr@...omium.org,
	tglx@...utronix.de, luto@....edu, eparis@...hat.com,
	serge.hallyn@...onical.com, djm@...drot.org, scarybeasts@...il.com,
	indan@....nu, pmoore@...hat.com, akpm@...ux-foundation.org,
	corbet@....net, eric.dumazet@...il.com, markus@...omium.org,
	keescook@...omium.org
Subject: Re: [PATCH v8 3/8] seccomp: add system call filtering using BPF

On 02/16/2012 12:25 PM, Will Drewry wrote:
>
> I agree :)  BPF being a 32-bit creature introduced some edge cases.  I
> has started with a
>      union { u32 args32[6]; u64 args64[6]; }
>
> This was somewhat derailed by CONFIG_COMPAT behavior where
> syscall_get_arguments always writes to argument of register width --
> not bad, just irritating (since a copy isn't strictly necessary nor
> actually done in the patch).  Also, Indan pointed out that while BPF
> programs expect constants in the machine-local endian layout, any
> consumers would need to change how they accessed the arguments across
> big/little endian machines since a load of the low-order bits would
> vary.
>
> In a second pass, I attempted to resolve this like aio_abi.h:
>     union {
>       struct {
>          u32 ENDIAN_SWAP(lo32, hi32);
>        };
>        u64 arg64;
>      } args[6];
> It wasn't clear that this actually made matters better (though it did
> mean syscall_get_arguments() could write directly to arg64).  Usings
> offsetof() in the user program would be fine, but any offsets set
> another way would be invalid.  At that point, I moved to Indan's
> proposal to stabilize low order and high order offsets -- what is in
> the patch series.  Now a BPF program can reliably index into the low
> bits of an argument and into the high bits without endianness changing
> the filter program structure.
>
> I don't feel strongly about any given data layout, and this one seems
> to balance the 32-bit-ness of BPF and the impact that has on
> endianness.  I'm happy to hear alternatives that might be more
> aesthetically pleasing :)
>

I would have to say I think native endian is probably the sane thing 
still, out of several bad alternatives.  Certainly splitting the high 
and low halves of arguments is insane.

The other thing that you really need in addition to system call number 
is ABI identifier, since a syscall number may mean different things for 
different entry points.  For example, on x86-64 system call number 4 is 
write() if called via int $0x80 but stat() if called via syscall64. 
This is a local property of the system call, not a global per process.

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/