From: Hao Sun <sunhao.th@gmail.com>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com,
andrii@kernel.org, martin.lau@linux.dev, song@kernel.org,
yhs@fb.com, kpsingh@kernel.org, sdf@google.com,
haoluo@google.com, jolsa@kernel.org, davem@davemloft.net,
linux-kernel@vger.kernel.org, Hao Sun <sunhao.th@gmail.com>
Subject: [PATCH bpf-next 0/3] bpf: Add LDX/STX/ST sanitize in jited BPF progs
Date: Wed, 23 Nov 2022 22:15:43 +0800 [thread overview]
Message-ID: <20221123141546.238297-1-sunhao.th@gmail.com> (raw)
The verifier sometimes makes mistakes[1][2] that may be exploited to
achieve arbitrary read/write. Currently, syzbot is continuously testing
bpf, and can find memory issues in bpf syscalls, but it can hardly find
mischecking/bugs in the verifier. We need runtime checks like KASAN in
BPF programs for this. This patch series implements address sanitize
in jited BPF progs for testing purpose, so that tools like syzbot can
find interesting bugs in the verifier automatically by, if possible,
generating and executing BPF programs that bypass the verifier but have
memory issues, then triggering this sanitizing.
The idea is to dispatch read/write addr of a BPF program to the kernel
functions that are instrumented by KASAN, to achieve indirect checking.
Indirect checking is adopted because this is much simple, instrument
direct checking like compilers makes the jit much more complex. The
main step is: back up R0&R1 and store addr in R1, and then insert the
checking function before load/store insns, during bpf_misc_fixup(), and
finally in the jit stage, backup R1~R5 to make sure the checking funcs
won't corrupt regs states. An extra Kconfig option is used to enable
this, so normal use case won't be impacted at all.
Also, not all ldx/stx/st are instrumented. Insns rewrote by other fixup
or conversion passes that use BPF_REG_AX are skipped, because that
conflicts with us; insns whose access addr is specified by R10 are also
skipped because they are trivial to verify.
Patch1 sanitizes st/stx insns, and Patch2 sanitizes ldx insns, Patch3 adds
selftests for instrumentation in each possible case, and all new/existing
selftests for the verifier can pass. Also, a BPF prog that also exploits
CVE-2022-23222 to achieve OOB read is provided[3], this can be perfertly
captured with this patch series.
I haven't found a better way to back up the regs before executing the
checking functions, and have to store them on the stack. Comments and
advice are surely welcome.
[1] http://bit.do/CVE-2021-3490
[2] http://bit.do/CVE-2022-23222
[3] OOB-read: https://pastebin.com/raw/Ee1Cw492
Hao Sun (3):
bpf: Sanitize STX/ST in jited BPF progs with KASAN
bpf: Sanitize LDX in jited BPF progs with KASAN
selftests/bpf: Add tests for LDX/STX/ST sanitize
arch/x86/net/bpf_jit_comp.c | 34 ++
include/linux/bpf.h | 14 +
kernel/bpf/Kconfig | 14 +
kernel/bpf/verifier.c | 190 +++++++++++
.../selftests/bpf/verifier/sanitize_st_ldx.c | 323 ++++++++++++++++++
5 files changed, 575 insertions(+)
create mode 100644 tools/testing/selftests/bpf/verifier/sanitize_st_ldx.c
base-commit: 8a2162a9227dda936a21fe72014a9931a3853a7b
--
2.38.1
next reply other threads:[~2022-11-23 14:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 14:15 Hao Sun [this message]
2022-11-23 14:15 ` [PATCH bpf-next 1/3] bpf: Sanitize STX/ST in jited BPF progs with KASAN Hao Sun
2022-11-23 14:15 ` [PATCH bpf-next 2/3] bpf: Sanitize LDX " Hao Sun
2022-11-23 14:15 ` [PATCH bpf-next 3/3] selftests/bpf: Add tests for LDX/STX/ST sanitize Hao Sun
2022-11-23 23:41 ` [PATCH bpf-next 0/3] bpf: Add LDX/STX/ST sanitize in jited BPF progs Daniel Borkmann
2022-11-24 3:05 ` Hao Sun
2022-11-25 5:26 ` Hao Sun
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=20221123141546.238297-1-sunhao.th@gmail.com \
--to=sunhao.th@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yhs@fb.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox