From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
John Fastabend <john.fastabend@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Ovidiu Panait <ovidiu.panait@windriver.com>
Subject: [PATCH 5.4 21/23] bpf: Test_verifier, add alu32 bounds tracking tests
Date: Fri, 6 Aug 2021 10:16:53 +0200 [thread overview]
Message-ID: <20210806081112.866840862@linuxfoundation.org> (raw)
In-Reply-To: <20210806081112.104686873@linuxfoundation.org>
From: John Fastabend <john.fastabend@gmail.com>
commit 41f70fe0649dddf02046315dc566e06da5a2dc91 upstream
Its possible to have divergent ALU32 and ALU64 bounds when using JMP32
instructins and ALU64 arithmatic operations. Sometimes the clang will
even generate this code. Because the case is a bit tricky lets add
a specific test for it.
Here is pseudocode asm version to illustrate the idea,
1 r0 = 0xffffffff00000001;
2 if w0 > 1 goto %l[fail];
3 r0 += 1
5 if w0 > 2 goto %l[fail]
6 exit
The intent here is the verifier will fail the load if the 32bit bounds
are not tracked correctly through ALU64 op. Similarly we can check the
64bit bounds are correctly zero extended after ALU32 ops.
1 r0 = 0xffffffff00000001;
2 w0 += 1
2 if r0 > 3 goto %l[fail];
6 exit
The above will fail if we do not correctly zero extend 64bit bounds
after 32bit op.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/158560430155.10843.514209255758200922.stgit@john-Precision-5820-Tower
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/testing/selftests/bpf/verifier/bounds.c | 39 ++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
--- a/tools/testing/selftests/bpf/verifier/bounds.c
+++ b/tools/testing/selftests/bpf/verifier/bounds.c
@@ -506,3 +506,42 @@
.errstr = "map_value pointer and 1000000000000",
.result = REJECT
},
+{
+ "bounds check mixed 32bit and 64bit arithmatic. test1",
+ .insns = {
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_MOV64_IMM(BPF_REG_1, -1),
+ BPF_ALU64_IMM(BPF_LSH, BPF_REG_1, 32),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 1),
+ /* r1 = 0xffffFFFF00000001 */
+ BPF_JMP32_IMM(BPF_JGT, BPF_REG_1, 1, 3),
+ /* check ALU64 op keeps 32bit bounds */
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 1),
+ BPF_JMP32_IMM(BPF_JGT, BPF_REG_1, 2, 1),
+ BPF_JMP_A(1),
+ /* invalid ldx if bounds are lost above */
+ BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_0, -1),
+ BPF_EXIT_INSN(),
+ },
+ .result = ACCEPT
+},
+{
+ "bounds check mixed 32bit and 64bit arithmatic. test2",
+ .insns = {
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_MOV64_IMM(BPF_REG_1, -1),
+ BPF_ALU64_IMM(BPF_LSH, BPF_REG_1, 32),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 1),
+ /* r1 = 0xffffFFFF00000001 */
+ BPF_MOV64_IMM(BPF_REG_2, 3),
+ /* r1 = 0x2 */
+ BPF_ALU32_IMM(BPF_ADD, BPF_REG_1, 1),
+ /* check ALU32 op zero extends 64bit bounds */
+ BPF_JMP_REG(BPF_JGT, BPF_REG_1, BPF_REG_2, 1),
+ BPF_JMP_A(1),
+ /* invalid ldx if bounds are lost above */
+ BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_0, -1),
+ BPF_EXIT_INSN(),
+ },
+ .result = ACCEPT
+},
next prev parent reply other threads:[~2021-08-06 8:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-06 8:16 [PATCH 5.4 00/23] 5.4.139-rc1 review Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 01/23] btrfs: delete duplicated words + other fixes in comments Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 02/23] btrfs: do not commit logs and transactions during link and rename operations Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 03/23] btrfs: fix race causing unnecessary inode logging during link and rename Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 04/23] btrfs: fix lost inode on log replay after mix of fsync, rename and inode eviction Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 05/23] regulator: rt5033: Fix n_voltages settings for BUCK and LDO Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 06/23] spi: stm32h7: fix full duplex irq handler handling Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 07/23] ASoC: tlv320aic31xx: fix reversed bclk/wclk master bits Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 08/23] r8152: Fix potential PM refcount imbalance Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 09/23] qed: fix possible unpaired spin_{un}lock_bh in _qed_mcp_cmd_and_union() Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 10/23] net: Fix zero-copy head len calculation Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 11/23] nvme: fix nvme_setup_command metadata trace event Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 12/23] ACPI: fix NULL pointer dereference Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 13/23] Revert "spi: mediatek: fix fifo rx mode" Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 14/23] Revert "Bluetooth: Shutdown controller after workqueues are flushed or cancelled" Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 15/23] firmware: arm_scmi: Ensure drivers provide a probe function Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 16/23] firmware: arm_scmi: Add delayed response status check Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 17/23] Revert "watchdog: iTCO_wdt: Account for rebooting on second timeout" Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 18/23] bpf: Inherit expanded/patched seen count from old aux data Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 19/23] bpf: Do not mark insn as seen under speculative path verification Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 20/23] bpf: Fix leakage under speculation on mispredicted branches Greg Kroah-Hartman
2021-08-06 8:16 ` Greg Kroah-Hartman [this message]
2021-08-06 8:16 ` [PATCH 5.4 22/23] bpf, selftests: Add a verifier test for assigning 32bit reg states to 64bit ones Greg Kroah-Hartman
2021-08-06 8:16 ` [PATCH 5.4 23/23] bpf, selftests: Adjust few selftest outcomes wrt unreachable code Greg Kroah-Hartman
2021-08-06 14:33 ` [PATCH 5.4 00/23] 5.4.139-rc1 review Jon Hunter
2021-08-06 18:58 ` Guenter Roeck
2021-08-07 10:41 ` Sudip Mukherjee
2021-08-07 18:40 ` Naresh Kamboju
2021-08-08 3:27 ` Aakash Hemadri
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=20210806081112.866840862@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=ast@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ovidiu.panait@windriver.com \
--cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox