From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH arm64-next v4] net: bpf: arm64: address randomize and write protect JIT code
Date: Tue, 16 Sep 2014 17:25:31 +0100 [thread overview]
Message-ID: <20140916162531.GC32073@arm.com> (raw)
In-Reply-To: <1410853730-16470-1-git-send-email-dborkman@redhat.com>
On Tue, Sep 16, 2014 at 08:48:50AM +0100, Daniel Borkmann wrote:
> This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf
> jit against spraying attacks").
>
> Thanks to commit 11d91a770f1f ("arm64: Add CONFIG_DEBUG_SET_MODULE_RONX
> support") which added necessary infrastructure, we can now implement
> RO marking of eBPF generated JIT image pages and randomize start offset
> for the JIT code, so that it does not reside directly on a page boundary
> anymore. Likewise, the holes are filled with illegal instructions: here
> we use BRK #0x100 (opcode 0xd4202000) to trigger a fault in the kernel
> (unallocated BRKs would trigger a fault through do_debug_exception). This
> seems more reliable as we don't have a guaranteed undefined instruction
> space on ARM64.
>
> This is basically the ARM64 variant of what we already have in ARM via
> commit 55309dd3d4cd ("net: bpf: arm: address randomize and write protect
> JIT code"). Moreover, this commit also presents a merge resolution due to
> conflicts with commit 60a3b2253c41 ("net: bpf: make eBPF interpreter images
> read-only") as we don't use kfree() in bpf_jit_free() anymore to release
> the locked bpf_prog structure, but instead bpf_prog_unlock_free() through
> a different allocator.
>
> JIT tested on aarch64 with BPF test suite.
>
> Reference: http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Zi Shen Lim <zlim.lnx@gmail.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Alexei Starovoitov <ast@plumgrid.com>
> ---
> v3->v4:
> - Inclusion into debug-monitors.h as suggested by Will
> v2->v3:
> - Use cpu_to_le32() as suggested by Zi/Will
> v1->v2:
> - Use brk insn as suggested by Catalin
> Note:
> - This patch depends on net-next being merged to mainline due
> to the mentioned merge conflict.
>
> arch/arm64/include/asm/debug-monitors.h | 8 +++++++
> arch/arm64/net/bpf_jit_comp.c | 39 +++++++++++++++++++++++++--------
> 2 files changed, 38 insertions(+), 9 deletions(-)
Thanks, Daniel, this looks great:
Acked-by: Will Deacon <will.deacon@arm.com>
We can merge this at -rc1.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Daniel Borkmann <dborkman@redhat.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Zi Shen Lim <zlim.lnx@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Alexei Starovoitov <ast@plumgrid.com>
Subject: Re: [PATCH arm64-next v4] net: bpf: arm64: address randomize and write protect JIT code
Date: Tue, 16 Sep 2014 17:25:31 +0100 [thread overview]
Message-ID: <20140916162531.GC32073@arm.com> (raw)
In-Reply-To: <1410853730-16470-1-git-send-email-dborkman@redhat.com>
On Tue, Sep 16, 2014 at 08:48:50AM +0100, Daniel Borkmann wrote:
> This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf
> jit against spraying attacks").
>
> Thanks to commit 11d91a770f1f ("arm64: Add CONFIG_DEBUG_SET_MODULE_RONX
> support") which added necessary infrastructure, we can now implement
> RO marking of eBPF generated JIT image pages and randomize start offset
> for the JIT code, so that it does not reside directly on a page boundary
> anymore. Likewise, the holes are filled with illegal instructions: here
> we use BRK #0x100 (opcode 0xd4202000) to trigger a fault in the kernel
> (unallocated BRKs would trigger a fault through do_debug_exception). This
> seems more reliable as we don't have a guaranteed undefined instruction
> space on ARM64.
>
> This is basically the ARM64 variant of what we already have in ARM via
> commit 55309dd3d4cd ("net: bpf: arm: address randomize and write protect
> JIT code"). Moreover, this commit also presents a merge resolution due to
> conflicts with commit 60a3b2253c41 ("net: bpf: make eBPF interpreter images
> read-only") as we don't use kfree() in bpf_jit_free() anymore to release
> the locked bpf_prog structure, but instead bpf_prog_unlock_free() through
> a different allocator.
>
> JIT tested on aarch64 with BPF test suite.
>
> Reference: http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Zi Shen Lim <zlim.lnx@gmail.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Alexei Starovoitov <ast@plumgrid.com>
> ---
> v3->v4:
> - Inclusion into debug-monitors.h as suggested by Will
> v2->v3:
> - Use cpu_to_le32() as suggested by Zi/Will
> v1->v2:
> - Use brk insn as suggested by Catalin
> Note:
> - This patch depends on net-next being merged to mainline due
> to the mentioned merge conflict.
>
> arch/arm64/include/asm/debug-monitors.h | 8 +++++++
> arch/arm64/net/bpf_jit_comp.c | 39 +++++++++++++++++++++++++--------
> 2 files changed, 38 insertions(+), 9 deletions(-)
Thanks, Daniel, this looks great:
Acked-by: Will Deacon <will.deacon@arm.com>
We can merge this at -rc1.
Will
next prev parent reply other threads:[~2014-09-16 16:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-16 7:48 [PATCH arm64-next v4] net: bpf: arm64: address randomize and write protect JIT code Daniel Borkmann
2014-09-16 7:48 ` Daniel Borkmann
2014-09-16 16:25 ` Will Deacon [this message]
2014-09-16 16:25 ` Will Deacon
2014-09-16 16:29 ` Z Lim
2014-09-16 16:29 ` Z Lim
2014-09-16 16:34 ` Z Lim
2014-09-16 16:34 ` Z Lim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140916162531.GC32073@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.