linux-kernel - Re: [PATCH net-next v2] net: bpf: make eBPF interpreter images read-only

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20140905.120309.442605076285121829.davem@davemloft.net>
Date:	Fri, 05 Sep 2014 12:03:09 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	hannes@...essinduktion.org
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	spender@...ecurity.net, dborkman@...hat.com, ast@...mgrid.com,
	keescook@...omium.org
Subject: Re: [PATCH net-next v2] net: bpf: make eBPF interpreter images
 read-only

From: Hannes Frederic Sowa <hannes@...essinduktion.org>
Date: Tue,  2 Sep 2014 22:53:44 +0200

> From: Daniel Borkmann <dborkman@...hat.com>
> 
> With eBPF getting more extended and exposure to user space is on it's way,
> hardening the memory range the interpreter uses to steer its command flow
> seems appropriate.  This patch moves the to be interpreted bytecode to
> read-only pages.
> 
> In case we execute a corrupted BPF interpreter image for some reason e.g.
> caused by an attacker which got past a verifier stage, it would not only
> provide arbitrary read/write memory access but arbitrary function calls
> as well. After setting up the BPF interpreter image, its contents do not
> change until destruction time, thus we can setup the image on immutable
> made pages in order to mitigate modifications to that code. The idea
> is derived from commit 314beb9bcabf ("x86: bpf_jit_comp: secure bpf jit
> against spraying attacks").
> 
> This is possible because bpf_prog is not part of sk_filter anymore.
> After setup bpf_prog cannot be altered during its life-time. This prevents
> any modifications to the entire bpf_prog structure (incl. function/JIT
> image pointer).
> 
> Every eBPF program (including classic BPF that are migrated) have to call
> bpf_prog_select_runtime() to select either interpreter or a JIT image
> as a last setup step, and they all are being freed via bpf_prog_free(),
> including non-JIT. Therefore, we can easily integrate this into the
> eBPF life-time, plus since we directly allocate a bpf_prog, we have no
> performance penalty.
> 
> Tested with seccomp and test_bpf testsuite in JIT/non-JIT mode and manual
> inspection of kernel_page_tables.  Brad Spengler proposed the same idea
> via Twitter during development of this patch.
> 
> Joint work with Hannes Frederic Sowa.
> 
> Suggested-by: Brad Spengler <spender@...ecurity.net>
> Signed-off-by: Daniel Borkmann <dborkman@...hat.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@...essinduktion.org>

Applied, thanks.
--
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/