netdev - 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]

Date:	Fri, 17 Feb 2012 04:27:45 +0100
From:	"Indan Zupancic" <indan@....nu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Andrew Lutomirski" <luto@....edu>,
	"Will Drewry" <wad@...omium.org>, 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,
	eparis@...hat.com, serge.hallyn@...onical.com, djm@...drot.org,
	scarybeasts@...il.com, 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 Fri, February 17, 2012 03:22, H. Peter Anvin wrote:
> On 02/16/2012 06:16 PM, Andrew Lutomirski wrote:
>>
>> Is there really no syscall that cares about endianness?

Perhaps when 64-bit syscall args are passed via two 32-bit registers.
But that is no argument to make all argument accesses endianness aware.

>> 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...)
>>
>
> Not to mention that the reshuffling code will add totally unnecessary
> cost to the normal operation.

There is no such extra cost.

> Either way, Indan has it backwards ... it
> *is* one field, the fact that two operations is needed to access it is a
> function of the underlying byte code, and even if the byte code can't
> support it, a JIT could merge adjacent operations if 64-bit operations
> are possible -- or we could (and arguably should) add 64-bit opcodes in
> the future for efficiency.

It is a virtual data structure with as sole purpose to provide syscall
info to the byte code. The actual data structure as such never exists
in memory. So giving something that is hard to digest is silly.

A JIT won't be able to merge accesses because it also has to merge other
instructions and recognize when 64-bit operations are done with 32-bit
instructions. I think that will be too hard for a JIT.

The only good reason to use 64 bit fields is if 64-bit support will be
added to BPF in the future. If not, then it's just unnecessary pain for
no good reason.

An alternative to struct seccomp_data would be to add special instructions
that load the desired info to 'A'. E.g. BPF_S_ANC_SYSCALL_ARG with 'k'
selecting which arg. But that's probably harder to fit into the current
filter code.

Greetings,

Indan

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html