On Wed, Jan 17, 2024 at 10:40 AM Hao Sun <sunhao.th@xxxxxxxxx> 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@xxxxxxxxx> > --- Not specifying bpf-next as the target repo as my previous patch is not in it yet.
