[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACkBjsZFmYK-j=JDbCLhNEzYELQits5NB79uNa4p3iHmoKwh5w@mail.gmail.com>
Date: Wed, 17 Jan 2024 10:42:51 +0100
From: Hao Sun <sunhao.th@...il.com>
To: bpf@...r.kernel.org
Cc: ast@...nel.org, andrii@...nel.org, daniel@...earbox.net, eddyz87@...il.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly
On Wed, Jan 17, 2024 at 10:40 AM Hao Sun <sunhao.th@...il.com> wrote:
>
> Current checking rules are structured to disallow alu on particular ptr
> types explicitly, so default cases are allowed implicitly. This may lead
> to newly added ptr types being allowed unexpectedly. So restruture it to
> allow alu explicitly. The tradeoff is mainly a bit more cases added in
> the switch. The following table from Eduard summarizes the rules:
>
> | Pointer type | Arithmetics allowed |
> |---------------------+---------------------|
> | PTR_TO_CTX | yes |
> | CONST_PTR_TO_MAP | conditionally |
> | PTR_TO_MAP_VALUE | yes |
> | PTR_TO_MAP_KEY | yes |
> | PTR_TO_STACK | yes |
> | PTR_TO_PACKET_META | yes |
> | PTR_TO_PACKET | yes |
> | PTR_TO_PACKET_END | no |
> | PTR_TO_FLOW_KEYS | conditionally |
> | PTR_TO_SOCKET | no |
> | PTR_TO_SOCK_COMMON | no |
> | PTR_TO_TCP_SOCK | no |
> | PTR_TO_TP_BUFFER | yes |
> | PTR_TO_XDP_SOCK | no |
> | PTR_TO_BTF_ID | yes |
> | PTR_TO_MEM | yes |
> | PTR_TO_BUF | yes |
> | PTR_TO_FUNC | yes |
> | CONST_PTR_TO_DYNPTR | yes |
>
> The refactored rules are equivalent to the original one. Note that
> PTR_TO_FUNC and CONST_PTR_TO_DYNPTR are not reject here because: (1)
> check_mem_access() rejects load/store on those ptrs, and those ptrs
> with offset passing to calls are rejected check_func_arg_reg_off();
> (2) someone may rely on the verifier not rejecting programs earily.
>
> Signed-off-by: Hao Sun <sunhao.th@...il.com>
> ---
Not specifying bpf-next as the target repo as my previous patch is not
in it yet.
Powered by blists - more mailing lists