From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C818EC4829A for ; Wed, 14 Feb 2024 00:27:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C8B66B0096; Tue, 13 Feb 2024 19:27:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 351566B0098; Tue, 13 Feb 2024 19:27:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CB156B009B; Tue, 13 Feb 2024 19:27:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 06F826B0096 for ; Tue, 13 Feb 2024 19:27:10 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 982BD1A0245 for ; Wed, 14 Feb 2024 00:27:09 +0000 (UTC) X-FDA: 81788519778.28.3FB9197 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by imf10.hostedemail.com (Postfix) with ESMTP id DB89BC0019 for ; Wed, 14 Feb 2024 00:27:07 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ws1X9Tu6; spf=pass (imf10.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707870428; a=rsa-sha256; cv=none; b=iu1nf3eUM8y6J6ZMOceyk7CPIBEOfu0h1PaOoXesPjCPWGsy7Nst6yNMRo4lyPg6vWyd5f 4L8HLAURqFMJloAW55BpQALTsXxkKkmIbONq2pjFpnRcpPlKqLUZTTRAmPKGHKtWcGz8NZ tP8Nkj6DTPo4L85A4vz5wVuGldssZVk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ws1X9Tu6; spf=pass (imf10.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707870428; h=from:from:sender: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:dkim-signature; bh=mVrq6nMRBsw/SGkOy5fHBOuY1ivCN4ZLbbWxk/mKrsY=; b=hIPhgKVY0B7k8oJdkK0k3sBgKcMqbGrhcenfmdvZkBRTP4tejWECVgaKwlD81WptUVr4ih kBH0vLxPNy687gNx5ahuBAOHaOPYM9CsBUA2XDfbQkxnpDDPQDc6VbBHkd5dnJZ4GD5Vju ivgVBB2wUSs11GAHS2HUPfrQwgc/Nbo= Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-33b86bc4bbaso1245186f8f.0 for ; Tue, 13 Feb 2024 16:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707870426; x=1708475226; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mVrq6nMRBsw/SGkOy5fHBOuY1ivCN4ZLbbWxk/mKrsY=; b=Ws1X9Tu6OkoS9SeEuVMEwUeLqmj5n0/CtPMJbm4lEyLytRqVaKtYZt8JTpxWsRc8nB fm/1JMyro1AzartE7tP6RiYChd8j1/y412QhScPBIHXpqaSBSnGsPWee6yF0cDoUvs/A CcjS5ZhMsaPgD04pDlN/BJ4xdxfOEvK9xLmW18HrMsqbH82w4OZSYRfd5niBpqLJ1WIQ XUphwAD++998AP8PHU6M4Lb6Yw+0mqSltTBqqbJDu7vTZcBxNWbjJNmMN4LFgDmTmdkM 0n2U6ntK/GwEzxZLrwgzQXEDTXB/ke6GVsLflgYA8PzBzGrnEiPUH/ufq2rAublI/Sz2 99mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707870426; x=1708475226; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mVrq6nMRBsw/SGkOy5fHBOuY1ivCN4ZLbbWxk/mKrsY=; b=FBfezDWfh3HctEiwW0VUwVlnBHli8VwtyMoKw9iane4sXO/6kfkSm847A0IMxPZL3P 6phzXYlft6Zmlc0uZH0d3DN1MP71urg6qHNHHl8Iu84cwgwelqcLOgGns2OWSZ/sc55r 0nddlk7K19Tg5cWIeZpU25ffzYWwJaa8+BCI19ZV6T+joko3nZB9P4aQvt9Zaeyi3scC UR9ea91I/SduyD3b5UqFGAcMJkzE3Js14nWYlcvR6sZeMQOwQAZAs1P6CPQooOjBenO7 vuH6Xcly7NJ+fPNid1ex1FawCwIEItCh6zE4ij60mrsJrk0chIXJ5DunuI/Jr6ZPQ65f ITpw== X-Forwarded-Encrypted: i=1; AJvYcCUEQmrkuhwtboFx/arnlc1BlgKt8ZgNl5VB4jXILTKYtfuteZkPkdru3/Fyfn/6dd6/AkcLZRMKc4EMneMUNQTnUhc= X-Gm-Message-State: AOJu0YzkpAZOqNJsOXf5ah94wAAbhIfh9QKmB4iUFrgmAO8tvHKIVpN3 xXC/5Sp6Vb48kd5LcBKO60mgrtsTYWZdFqpitqs9LBRPE+d62+3Qcjm9+QPKCpwe1bFjmZTK3lg uLsM+PMSPIHxP8zjkEbYBuFQ+asA= X-Google-Smtp-Source: AGHT+IFtyZUy3+7EA2UHfKG8+DSkPiPYZ9UHx9q8LeHkfS6JPgv+2WDYOOe2UVDXEqU0hmxu7JtEk6wVk/v3n61Lojo= X-Received: by 2002:a5d:6ac5:0:b0:33c:e32f:fb7e with SMTP id u5-20020a5d6ac5000000b0033ce32ffb7emr471037wrw.2.1707870426098; Tue, 13 Feb 2024 16:27:06 -0800 (PST) MIME-Version: 1.0 References: <20240209040608.98927-1-alexei.starovoitov@gmail.com> <20240209040608.98927-11-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Tue, 13 Feb 2024 16:26:54 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 10/20] bpf: Recognize btf_decl_tag("arg:arena") as PTR_TO_ARENA. To: Andrii Nakryiko Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Eddy Z , Tejun Heo , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DB89BC0019 X-Stat-Signature: w3sxmeheixtkor3w43cwukcdfzfrx1s1 X-Rspam-User: X-HE-Tag: 1707870427-318688 X-HE-Meta: U2FsdGVkX1/sV+AsDyXNS+sdkgUjAnNzM9ao6WSOPX3XEzYBO+GJaq91fnqM2fcrXHxG8ivFoPoTX1Vz21j2DUlGWe1IN2VEP7AZxZRByIZMOdwja178FUYXPpg2jKTcvWms6EiN65IF6fxAO9su42Z9Z6yrl+PwaYtUy2Czia1wpnJ1rU/gh3ISH7eit6v9KJpvlTTNnuCv6sc5391DAbqPAQDDQl7KS34nfjFTfp48BgH06qXIjj+9fLRQlC+ep66IIqaAmc7WrmxjDYSdutz7bqw4uC5qrfNR6qnFMnm78grDtKseQc3mNh7PAS6wkgWAj/6yy9JiQm0S8LQ2EY6v4DluySV9NkjtXdoVp3I4jYhFsHG/4W9mfyqv/pkcJLWJbxJB2VRLq/emToWaF/DVzsQuarlhs4ysK39XS44IA8SsOs63m6TNjB5hJ3tuInnEFYhKPAevUyxBIi4mtVZMxI+RB7NbYBa3/6syeZUwzdX1z2IFW1sPN6qWSo1LN08No90sLDPIg7KLrGluwRCKDDgArYfjl0q6CrSGHO66RFohm2jEfAchQF78KSK3OgTIBLHtkGpO6S1rFam0MNagEphOgqgisBROjWkCxU+t0Fi+6EOIOheJvblO4PfdPwgWDGhq9eqQD3GW4SkRlwNqOeonAHJC8O25K6O3EZg6zWQHuc566b9ghErjq5nKG66nLrG1g2TFGNeUQWgQQ1lclLktNFQ33gZbXJuLlo3cGfI7hUantNJNgb1/rat0GFOvn+w1EKUyK7dRnPketnun8E+yq5yo1I3tsIOonc51tDeYi5HHS+3+n+ERYi56ZhHKdLHeMFoQgZERsgckmWFE6fHnw54ATK6lazjmi9Qbj3yPKSQV+eOFAMSU+xy+eLBhcrC7PzEb8wM6BWyvxWT9dZ+NJyid1kOWCQf4zA8gB1NY9AsNKFl/5Ub2vE+LjgmrkeyCMJZj7iOT3lO SoSpklmr fNxWDP0YjEn67hYBB3SqOTkysFnlRj7sP+d2eMGyHxet4ufigU7TbLh0gC+cgfIyI8wjR0JHB9chw6GLH4swy1P8JziRwkfYfkH1XjKTvW2K2WBSwFXIOQNDE7+jAfKHzujSRtZ8fguSi1bljM+adN2Eynkxs4ZAaldWiIbtXJYOKxCrcjGz40yPs+A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Feb 13, 2024 at 3:15=E2=80=AFPM Andrii Nakryiko wrote: > > On Thu, Feb 8, 2024 at 8:06=E2=80=AFPM Alexei Starovoitov > wrote: > > > > From: Alexei Starovoitov > > > > In global bpf functions recognize btf_decl_tag("arg:arena") as PTR_TO_A= RENA. > > > > Note, when the verifier sees: > > > > __weak void foo(struct bar *p) > > > > it recognizes 'p' as PTR_TO_MEM and 'struct bar' has to be a struct wit= h scalars. > > Hence the only way to use arena pointers in global functions is to tag = them with "arg:arena". > > > > Signed-off-by: Alexei Starovoitov > > --- > > include/linux/bpf.h | 1 + > > kernel/bpf/btf.c | 19 +++++++++++++++---- > > kernel/bpf/verifier.c | 15 +++++++++++++++ > > 3 files changed, 31 insertions(+), 4 deletions(-) > > > > [...] > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > index 5eeb9bf7e324..fa49602194d5 100644 > > --- a/kernel/bpf/verifier.c > > +++ b/kernel/bpf/verifier.c > > @@ -9348,6 +9348,18 @@ static int btf_check_func_arg_match(struct bpf_v= erifier_env *env, int subprog, > > bpf_log(log, "arg#%d is expected to be = non-NULL\n", i); > > return -EINVAL; > > } > > + } else if (base_type(arg->arg_type) =3D=3D ARG_PTR_TO_A= RENA) { > > + /* > > + * Can pass any value and the kernel won't cras= h, but > > + * only PTR_TO_ARENA or SCALAR make sense. Ever= ything > > + * else is a bug in the bpf program. Point it o= ut to > > + * the user at the verification time instead of > > + * run-time debug nightmare. > > + */ > > + if (reg->type !=3D PTR_TO_ARENA && reg->type != =3D SCALAR_VALUE) { > > the comment above doesn't explain why it's ok to pass SCALAR_VALUE. Is > it because PTR_TO_ARENA will become SCALAR_VALUE after some arithmetic > operations and we don't want to regress user experience? If that's the > case, what's the way for user to convert SCALAR_VALUE back to > PTR_TO_ARENA without going through global subprog? bpf_cast_xxx > instruction through assembly? bpf_cast_xx inline asm should never be used. It's for selftests only until llvm 19 is released and in distros. The scalar_value can come in lots of cases. Any pointer dereference returns scalar. Most of the time all arena math is on scalars. Scalars are passed into global and static funcs and become ptr_to_arena right before LDX/STX through that pointer. Sometime llvm still does a bit of math after scalar became ptr_to_arena, hence needs_zext flag to downgrade alu64 to alu32. In these selftests that produce non trivial bpf progs there are 4 such insns that needs_zext in arena_htab.bpf.o. Also 23 cast_kern, zero cast_user, and 57 ldx/stx from arena. > > > + bpf_log(log, "R%d is not a pointer to a= rena or scalar.\n", regno); > > + return -EINVAL; > > + } > > } else if (arg->arg_type =3D=3D (ARG_PTR_TO_DYNPTR | ME= M_RDONLY)) { > > ret =3D process_dynptr_func(env, regno, -1, arg= ->arg_type, 0); > > if (ret) > > @@ -20329,6 +20341,9 @@ static int do_check_common(struct bpf_verifier_= env *env, int subprog) > > reg->btf =3D bpf_get_btf_vmlinux(); /* = can't fail at this point */ > > reg->btf_id =3D arg->btf_id; > > reg->id =3D ++env->id_gen; > > + } else if (base_type(arg->arg_type) =3D=3D ARG_= PTR_TO_ARENA) { > > + /* caller can pass either PTR_TO_ARENA = or SCALAR */ > > + mark_reg_unknown(env, regs, i); > > shouldn't we set the register type to PTR_TO_ARENA here? No. It has to be scalar. It's not ok to deref it with kern_vm_base yet. It's a full 64-bit value here and upper 32-bit are likely correct user_vm_s= tart. Hence my struggle with this __arg_arena feature, since it's really for the verifier not to complain at the call site only.