Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1495453rwe; Thu, 1 Sep 2022 21:10:45 -0700 (PDT) X-Google-Smtp-Source: AA6agR5kqhka/ZCPZaHwag+tetZdL7uEbzDMixZ4SmOoWNtgPPRRzarPa0fMlrKDPUOinE1LRfM8 X-Received: by 2002:a17:902:ce81:b0:172:9ac1:6ee with SMTP id f1-20020a170902ce8100b001729ac106eemr33013742plg.93.1662091845388; Thu, 01 Sep 2022 21:10:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662091845; cv=none; d=google.com; s=arc-20160816; b=kH2kLrlcc+V8DS73o+Lt4K9QaJmEGJ/mmwgYAvksZfkhKD0vSKfiq3PC/OCFtjDpmL J8FZUhk5/8k+i4qWCU0IwimnT+3XuzbGDhCufdvxHol1V7YBgYyk7uZKPa5ZozmcroPV 3eMZbZrrCP2KBsXNdSE4F0eW96BWx/rs4LHMlhZ7WGHbJzvU63OwwQjZgkldhoApexTJ /uGoABfAgVQKTRIv7sLT2qznY9SNCfbp2P/2wqLQZj0Om1pU//KrMUUUGKiJ8FK9nV9j +bc4WrWrmkGLhbSBuCtUHtKA9AWUf86DI0xTAns+MDN+LMCLW6V4hxFHZiHMFt8qVuAb Pecg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=E+LJ1geH9sHZ7zNZY9aNOFdRivMlaRJnVrHaJZ75NKo=; b=RHQoumQjHpOWNovF7UtjQEvIX1N13FlsYJafORStwbmGXYzEYHKv6o5xpHwBcWFJaN N7rAzZ2dKntxtZxA2fhYOiGizp1iCsT8PpXO8UJAJwqIvXiGqiUyrcasm1vWeODojNYn 6fG/ooQkfh0nRRjXdGUFmAJh0Y1pafqQdyxve4Kw87+eolkP3Li2X/lIPBX3W+/kdkLt whNpCEjwcXeCoH7LkMYKrwyikdnu+tbfVNFG+3+245arJYJgwSg6MNWSv7te38bqa5w1 gqZdHr7XdElJJ1cs63+1BAIRXwOGJvUalcV5HkGYlPnQHtZkcdJ2ALkdO42VK+3IgWxs KOxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=nRy9G0eh; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f12-20020a056a001acc00b0052e677b7056si1023971pfv.279.2022.09.01.21.10.34; Thu, 01 Sep 2022 21:10:45 -0700 (PDT) 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=@gmail.com header.s=20210112 header.b=nRy9G0eh; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235426AbiIBDv0 (ORCPT + 99 others); Thu, 1 Sep 2022 23:51:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235422AbiIBDvL (ORCPT ); Thu, 1 Sep 2022 23:51:11 -0400 Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F17953037; Thu, 1 Sep 2022 20:50:55 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id n202so701813iod.6; Thu, 01 Sep 2022 20:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=E+LJ1geH9sHZ7zNZY9aNOFdRivMlaRJnVrHaJZ75NKo=; b=nRy9G0eht6ytO52NCU/doiQCtMeaRAV6V7krSlmSA9qcUj7j3ecvqgG1ge+ubUm4hy 5zTEUU2+pN2G9UjF/E1TmIyiq2Gtmx0YhQVHIuwxsTaygjYaZSspj1di9q324yvyHLOs onkk7PntBDcPqCBMReGZ5Kx+7NwYsGoO6vm00HM1pp3JzxLVuDF5vGFxvOLmqc1dnknH vdmXethcA7SAPx10M2RQkjSXVHxCcjMzI/ZvksBqpGZsPJvqn0pJGHV0vOSCiSGioJS/ UbfCnamfaV1Into6YeCLtbsjys6xcHUKFr2MT9AU/SAm9XZXLaA3eLvR/YlyAKFCnfHy Fgpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=E+LJ1geH9sHZ7zNZY9aNOFdRivMlaRJnVrHaJZ75NKo=; b=AgEYTiyfAdDw0NWjJPXEVo7Tj2KSOOPbBouarQIE8qToZJe3D+wri0Eudj9KY5xwN3 352IgrPwPnyY5RuoRM5O/IlkOlv4tUJENMaX1sKyTTf2H+gJ947XHZUcsrAIXlf3urhF TADQYSBamnrlGT0n7OPzT1jcFRQXrw4sVBBpVUJeqJXtHxg5B2Dph0b/rMrfxEGqZn0P gbv6EizHn7/EfBRL33dnK5YDa6UzPWvemF9bUvarXinCenDGRD/SvfZzFQKeV0tRzHB3 OG8qbcpX1gD9LoQF3EytG+xmYXaDaBDW2G+DOi0NASgJgnPsRn/OnCsyZ4mUfIU+okMw iI+A== X-Gm-Message-State: ACgBeo0jX18X2szq0twvLakogsDczJSfB+fszslNj+eS1zLIdRxaWTt0 J4R0xLfZkhc2BhecvTH2bRwXl0pBQAqda1qliRg= X-Received: by 2002:a6b:2ac4:0:b0:688:3a14:2002 with SMTP id q187-20020a6b2ac4000000b006883a142002mr15979839ioq.62.1662090654002; Thu, 01 Sep 2022 20:50:54 -0700 (PDT) MIME-Version: 1.0 References: <20220824134055.1328882-1-benjamin.tissoires@redhat.com> <20220824134055.1328882-2-benjamin.tissoires@redhat.com> In-Reply-To: From: Kumar Kartikeya Dwivedi Date: Fri, 2 Sep 2022 05:50:18 +0200 Message-ID: Subject: Re: [PATCH bpf-next v9 01/23] bpf/verifier: allow all functions to read user provided context To: Benjamin Tissoires Cc: Alexei Starovoitov , Greg KH , Jiri Kosina , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Shuah Khan , Dave Marchevsky , Joe Stringer , Jonathan Corbet , Tero Kristo , LKML , "open list:HID CORE LAYER" , Network Development , bpf , "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 Thu, 1 Sept 2022 at 18:48, Benjamin Tissoires wrote: > > [...] > If the above is correct, then yes, it would make sense to me to have 2 > distinct functions: one to check for the args types only (does the > function definition in the problem matches BTF), and one to check for > its use. > Behind the scenes, btf_check_subprog_arg_match() calls > btf_check_func_arg_match() which is the one function with entangled > arguments type checking and actually assessing that the values > provided are correct. > > I can try to split that btf_check_func_arg_match() into 2 distinct > functions, though I am not sure I'll get it right. FYI, I've already split them into separate functions in my tree because it had become super ugly at this point with all the new support and I refactored it to add the linked list helpers support using kfuncs (which requires some special handling for the args), so I think you can just leave it with a "processing_call" check in for your series for now. > Maybe the hack about having "processing_call" for > btf_check_func_arg_match() only will be good enough as a first step > towards a better solution? > > > And may cleanup the rest of that function ? > > Like all of if (is_kfunc) applies only to 'calling' case. > > Other ideas? > > > > I was trying to understand the problem most of today, and the only > other thing I could think of was "why is the assumption that > PTR_TO_CTX is not NULL actually required?". But again, this question > is "valid" in the function declaration part, but not in the caller > insn part. So I think splitting btf_check_subprog_arg_match() in 2 is > probably the best. > > Cheers, > Benjamin >