All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: "Eduard Zingerman" <eddyz87@gmail.com>, <bpf@vger.kernel.org>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Emil Tsalapatis" <emil@etsalapatis.com>,
	"Nicholas Carlini" <npc@anthropic.com>, <kkd@meta.com>,
	<kernel-team@meta.com>
Subject: Re: [PATCH bpf v4 05/11] selftests/bpf: Test early in-kernel CO-RE relocation
Date: Wed, 16 Sep 2026 20:26:09 +0200	[thread overview]
Message-ID: <DLGYAEPM4TBY.332NDL5NSA5C8@gmail.com> (raw)
In-Reply-To: <91d077abd444c0941bc93260c7bc75b09fce7263.camel@gmail.com>

On Wed Sep 16, 2026 at 8:23 PM CEST, Eduard Zingerman wrote:
> On Tue, 2026-09-15 at 00:25 +0200, Kumar Kartikeya Dwivedi wrote:
>> Add a raw program load with CO-RE relocation metadata but no func_info or
>> line_info. Place the relocation in dead code and require the poisoning log,
>> proving that the kernel processes standalone CO-RE metadata instead of
>> silently skipping it.
>>
>> Also poison a subprogram's terminal exit and require check_subprogs() to
>> reject the resulting fall-through. This confirms that in-kernel CO-RE runs
>> before the verifier validates the subprogram layout and before later CFG
>> consumers rely on it.
>>
>> Load both instruction streams without relocation metadata first to ensure
>> that CO-RE processing causes the rejection and diagnostic.
>>
>> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>> ---
>
> Acked-by: Eduard Zingerman <eddyz87@gmail.com>
>
>> +static void test_early_core_relo(void)
>> +{
>> +	struct bpf_insn core_only[] = {
>> +		BPF_MOV64_IMM(BPF_REG_0, 0),
>> +		BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1),
>> +		BPF_MOV64_IMM(BPF_REG_0, 0),
>> +		BPF_EXIT_INSN(),
>> +	};
>> +	struct bpf_insn subprog[] = {
>> +		BPF_CALL_REL(2),
>> +		BPF_MOV64_IMM(BPF_REG_0, 0),
>> +		BPF_EXIT_INSN(),
>> +		BPF_MOV64_IMM(BPF_REG_0, 0),
>> +		BPF_EXIT_INSN(),
>> +	};
>> +	struct bpf_func_info funcs[2];
>> +	const void *raw_btf;
>> +	struct btf *btf;
>> +	__u32 raw_btf_size;
>> +	int access_str_off, btf_fd = -1, enum_id;
>> +	int int_id, main_id, prog_fd = -1, proto_id, sub_id;
>> +
>> +	btf = btf__new_empty();
>> +	if (!ASSERT_OK_PTR(btf, "btf_new_empty"))
>> +		return;
>> +	int_id = btf__add_int(btf, "int", 4, BTF_INT_SIGNED);
>> +	if (!ASSERT_GT(int_id, 0, "add_int"))
>> +		goto cleanup;
>> +	proto_id = btf__add_func_proto(btf, int_id);
>> +	if (!ASSERT_GT(proto_id, 0, "add_func_proto"))
>> +		goto cleanup;
>> +	main_id = btf__add_func(btf, "main_fn", BTF_FUNC_STATIC, proto_id);
>> +	if (!ASSERT_GT(main_id, 0, "add_main_func"))
>> +		goto cleanup;
>> +	sub_id = btf__add_func(btf, "sub_fn", BTF_FUNC_STATIC, proto_id);
>> +	if (!ASSERT_GT(sub_id, 0, "add_sub_func"))
>> +		goto cleanup;
>> +	enum_id = btf__add_enum(btf, "core_relo_poison_missing", 4);
>> +	if (!ASSERT_GT(enum_id, 0, "add_enum") ||
>> +	    !ASSERT_OK(btf__add_enum_value(btf, "value", 0), "add_enum_value"))
>> +		goto cleanup;
>> +	access_str_off = btf__add_str(btf, "0");
>> +	if (!ASSERT_GT(access_str_off, 0, "add_access_str"))
>> +		goto cleanup;
>
> I asked to update this to use utility macro, but if there are no other
> nits let's land as-is.
>
> ...

I have a local follow up, will send once this lands.
Thanks

  reply	other threads:[~2026-09-16 18:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14 22:24 [PATCH bpf v4 00/11] Misc bug fixes - part 5 Kumar Kartikeya Dwivedi
2026-09-14 22:24 ` [PATCH bpf v4 01/11] bpf: Make post-verification instruction rewrites killable Kumar Kartikeya Dwivedi
2026-09-14 22:24 ` [PATCH bpf v4 02/11] bpf: Preserve packet pointer class displacement in regsafe() Kumar Kartikeya Dwivedi
2026-09-14 22:25 ` [PATCH bpf v4 03/11] selftests/bpf: Test packet pointer class displacement pruning Kumar Kartikeya Dwivedi
2026-09-14 22:25 ` [PATCH bpf v4 04/11] bpf: Apply CO-RE relocations before subprogram validation Kumar Kartikeya Dwivedi
2026-09-14 23:15   ` bot+bpf-ci
2026-09-16 18:22   ` Eduard Zingerman
2026-09-14 22:25 ` [PATCH bpf v4 05/11] selftests/bpf: Test early in-kernel CO-RE relocation Kumar Kartikeya Dwivedi
2026-09-14 23:28   ` bot+bpf-ci
2026-09-16 18:23   ` Eduard Zingerman
2026-09-16 18:26     ` Kumar Kartikeya Dwivedi [this message]
2026-09-14 22:25 ` [PATCH bpf v4 06/11] bpf: Restrict CO-RE poisoning to relocatable instructions Kumar Kartikeya Dwivedi
2026-09-14 23:28   ` bot+bpf-ci
2026-09-14 22:25 ` [PATCH bpf v4 07/11] selftests/bpf: Test CO-RE instruction poisoning restrictions Kumar Kartikeya Dwivedi
2026-09-16 18:27   ` Eduard Zingerman
2026-09-14 22:25 ` [PATCH bpf v4 08/11] bpf: Assign lock identity to callback map values Kumar Kartikeya Dwivedi
2026-09-14 22:25 ` [PATCH bpf v4 09/11] selftests/bpf: Check callback map value lock identity Kumar Kartikeya Dwivedi
2026-09-16 19:04   ` Eduard Zingerman
2026-09-14 22:25 ` [PATCH bpf v4 10/11] libbpf: Reject truncated ldimm64 CO-RE relocations Kumar Kartikeya Dwivedi
2026-09-16 18:37   ` Eduard Zingerman
2026-09-14 22:25 ` [PATCH bpf v4 11/11] selftests/bpf: Add truncated CO-RE ldimm64 test Kumar Kartikeya Dwivedi
2026-09-14 23:15   ` bot+bpf-ci
2026-09-16 18:43   ` Eduard Zingerman
2026-09-16 19:02     ` Kumar Kartikeya Dwivedi

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=DLGYAEPM4TBY.332NDL5NSA5C8@gmail.com \
    --to=memxor@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=kernel-team@meta.com \
    --cc=kkd@meta.com \
    --cc=npc@anthropic.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 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.