Received: by 2002:a05:6358:f14:b0:e5:3b68:ec04 with SMTP id b20csp6340396rwj; Wed, 21 Dec 2022 14:15:14 -0800 (PST) X-Google-Smtp-Source: AMrXdXtF3qhssnHT7uvBYRen8oQOINBk46RMSACmonxEXMXUoIBvHxoc5j6BeqV1sy2nBb3k2Yyp X-Received: by 2002:a17:902:7fca:b0:189:c99d:6af4 with SMTP id t10-20020a1709027fca00b00189c99d6af4mr3347166plb.8.1671660914493; Wed, 21 Dec 2022 14:15:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671660914; cv=none; d=google.com; s=arc-20160816; b=zNIHXf7U9AODpMEOcAwLVwjzs+nVFlqNaRfRotxCKUykWXuYwSzz18NeDECnWYiqCY EdSXuIghBBQn+L+9lYuXZGXKGYyfawCFzGx5yYSA1wikZ7iLFJtsomt2s87GUvegSPzL hatm2XeIMjQrujXcsA4OVH3pMhKP1KtHU757nohg+ewFV/jJ/LjHrlvJFanSO7nlBr3f o1LjCEeOZoZgpkr4Q0binYvG1S+rCJmCi3KXvIBgCzWqA3eonVtmNmNQU+4b1jxlX32T jcZy9dTeKUde1Z6QbD1t2mpRIOrbHnqny+VTQjWok3IJZPJsGGNq+wQFO4eEjoAJ7MpM rHpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:mime-version:date :dkim-signature:message-id; bh=0ZUs0Oi+KQ6ND7Xr4JK7sAaYTromssvZdryVCNE4E8E=; b=s7bTW5TYZGVsfXfWpReu8ZBGba9Vz/ZNP1vgN+1rLi1OPyNgoVsoBc3EsMcUjwEEY4 obcaH5FFs2HRSGGCXzXgGBDWYa6E314BbU1edhrw32kdn9m482pDfh7svKF8gh2dcEy1 1tG1eIo9KZrOJHUw4o9Dg7466SlDpADuDvv5RhePA8FvOEJCCK7moT1CNFzt2AV046wT vWvgeNJbkFpRHz933/WgO8Q8L033KcIGUhNwBYUlY7GmXZFf1hpc8BaifM8yGQ/0fG0B eD+XMxJ7ld7tdc9TW0X8D9EqEIrqFOBh5gakoeLDJbvCuov4pww36cqIF3W6NwvUTuzC 0hvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b="kUsg/pqN"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id iw9-20020a170903044900b00186ed93fc75si16472126plb.204.2022.12.21.14.15.04; Wed, 21 Dec 2022 14:15:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b="kUsg/pqN"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234875AbiLUVVf (ORCPT + 68 others); Wed, 21 Dec 2022 16:21:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230395AbiLUVVc (ORCPT ); Wed, 21 Dec 2022 16:21:32 -0500 Received: from out2.migadu.com (out2.migadu.com [IPv6:2001:41d0:2:aacc::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5168322B35; Wed, 21 Dec 2022 13:21:31 -0800 (PST) Message-ID: <18e1219a-d2b2-0373-1f30-fcf83acd328f@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1671657689; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0ZUs0Oi+KQ6ND7Xr4JK7sAaYTromssvZdryVCNE4E8E=; b=kUsg/pqNcucRnMDDXoSqn/4qnyug7Z9+bB4VEfwvYpk5pgRkOQyOFhaikO0PD5jeCaTf89 YRVKicwgMLH+BdcT4eoKA7c8RiVyockir7mDP3EIHJckUUJ8UnjlWbejxyw/OkPxIbCY0e uPfaQlLu7qOWPbeVPlCb3Ab1OlwSY0E= Date: Wed, 21 Dec 2022 13:21:25 -0800 MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v2 2/2] selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID Content-Language: en-US To: Hao Sun Cc: Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , David Miller , Linux Kernel Mailing List , bpf References: <20221213030436.17907-1-sunhao.th@gmail.com> <20221213030436.17907-2-sunhao.th@gmail.com> <7cfaaafa-0eda-a314-5b22-7e22c029f4ad@linux.dev> <7EAED688-C971-410E-BA56-9629CF9B3C91@gmail.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Martin KaFai Lau In-Reply-To: <7EAED688-C971-410E-BA56-9629CF9B3C91@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/21/22 5:46 AM, Hao Sun wrote: > Hi, > > I’ve tried something like the bellow, but soon realized that this > won’t work because once compiler figures out `inner_map` equals > to `val`, it can choose either reg to write into in the following > path, meaning that this program can be rejected due to writing > into read-only PTR_TO_BTF_ID reg, and this makes the test useless. hmm... I read the above a few times but I still don't quite get it. In particular, '...can be rejected due to writing into read-only PTR_TO_BTF_ID reg...'. Where is it writing into a read-only PTR_TO_BTF_ID reg in the following bpf prog? Did I overlook something? > > Essentially, we want two regs, one points to PTR_TO_BTD_ID, one > points to MAP_VALUR_OR_NULL, then compare them and deref map val. If I read this request correctly, I guess the compiler has changed 'ret = *val' to 'ret = *inner_map'? Thus, the verifier did not reject because it deref a PTR_TO_BTF_ID? > It’s hard to implement this in C level because compilers decide > which reg to use but not us, maybe we can just drop this test. Have you tried inline assembly. Something like this (untested): asm volatile ( "r8 = %[val];\n" "r9 = %[inner_map];\n" "if r8 != r9 goto +1;\n" "%[ret] = *(u64 *)(r8 +0);\n" :[ret] "+r"(ret) : [inner_map] "r"(inner_map), [val] "r"(val) :"r8", "r9"); Please attach the verifier output in the future. It will be easier to understand. > > thoughts? > > +struct { > + __uint(type, BPF_MAP_TYPE_HASH); > + __uint(max_entries, 1); > + __type(key, u64); > + __type(value, u64); > +} m_hash SEC(".maps"); > + > +SEC("?raw_tp") > +__failure __msg("invalid mem access 'map_value_or_null") > +int jeq_infer_not_null_ptr_to_btfid(void *ctx) > +{ > + struct bpf_map *map = (struct bpf_map *)&m_hash; > + struct bpf_map *inner_map = map->inner_map_meta; > + u64 key = 0, ret = 0, *val; > + > + val = bpf_map_lookup_elem(map, &key); > + /* Do not mark ptr as non-null if one of them is > + * PTR_TO_BTF_ID, reject because of invalid access > + * to map value. > + */ > + if (val == inner_map) > + ret = *val; > + > + return ret; > +}