From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Yonghong Song <yhs@meta.com>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
Lorenzo Bianconi <lorenzo@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf] bpf: Resolve fext program type when checking map compatibility
Date: Fri, 09 Dec 2022 13:17:09 +0100 [thread overview]
Message-ID: <87ilikkbzu.fsf@toke.dk> (raw)
In-Reply-To: <69cff1f4-b023-b064-bd47-f44e6c2b6d80@meta.com>
Yonghong Song <yhs@meta.com> writes:
> On 12/7/22 4:35 PM, Toke Høiland-Jørgensen wrote:
>> The bpf_prog_map_compatible() check makes sure that BPF program types are
>> not mixed inside BPF map types that can contain programs (tail call maps,
>> cpumaps and devmaps). It does this by setting the fields of the map->owner
>> struct to the values of the first program being checked against, and
>> rejecting any subsequent programs if the values don't match.
>>
>> One of the values being set in the map owner struct is the program type,
>> and since the code did not resolve the prog type for fext programs, the map
>> owner type would be set to PROG_TYPE_EXT and subsequent loading of programs
>> of the target type into the map would fail.
>>
>> This bug is seen in particular for XDP programs that are loaded as
>> PROG_TYPE_EXT using libxdp; these cannot insert programs into devmaps and
>> cpumaps because the check fails as described above.
>>
>> Fix the bug by resolving the fext program type to its target program type
>> as elsewhere in the verifier. This requires constifying the parameter of
>> resolve_prog_type() to avoid a compiler warning from the new call site.
>>
>> Fixes: f45d5b6ce2e8 ("bpf: generalise tail call map compatibility check")
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>
> Could you construct a test case for this problem?
Sure, will add a selftest and send a v2.
-Toke
prev parent reply other threads:[~2022-12-09 12:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 0:35 [PATCH bpf] bpf: Resolve fext program type when checking map compatibility Toke Høiland-Jørgensen
2022-12-09 4:05 ` Yonghong Song
2022-12-09 12:17 ` Toke Høiland-Jørgensen [this message]
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=87ilikkbzu.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=lorenzo@kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yhs@fb.com \
--cc=yhs@meta.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.