Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp25664imn; Thu, 28 Jul 2022 20:52:36 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tF+hFCl3Gk0Na2fBoluL3DcfXKtUxEmVY20jnvZJwTbXZNhNQQxmOuaJSkvMq1cdfmmhKe X-Received: by 2002:a63:4047:0:b0:419:7599:9a9c with SMTP id n68-20020a634047000000b0041975999a9cmr1427846pga.23.1659066756445; Thu, 28 Jul 2022 20:52:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659066756; cv=none; d=google.com; s=arc-20160816; b=IbXkDcntmz4MBD7kiKEJdf+yqs1xlXC/TDUeQaOQDtTjUxdbavt9ZGvma/Pm5J9tZK 8KHSbtFaN7Bxwkc0smiFLTsHnBjYmx3RCY/LlQu+on9asxdZVeP0YZqT46rY05Rn4T+I ncpCBXPfnkY4mJ9r/qogcWl3c9+UckRsTM53/jIwDLpKTJ8JIzAd2lRTYeDldsJItIFH 1XWFHkn0ZtcvDWF/ivWS+JM2Si+vAnEAJ+so1A1SXAMjqB6GULj4fjGyQ4r2Le1Zmlrc XZDPwSQ6hCBNftr/8qpr1I2JADzTx9tWpjFYDzQlQVxYBi/3cQ2P8Ckq+EaYVQrLMrV9 7Uzw== 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=VVLENy3LPh95mhi2xJgnxH73SWwfWDHHc6Zw1S4ewWk=; b=GHeRvLsG1hI91dHaM20I9UzssAPg7iNx2sbOBSJyyArCpgYTY7wSqcabWxIcowZZ+R QYbbyS3S1YINz8vJjjR6CkVWQhzTrAsk3HOu8Ub646YlN+DETxRhQB/EBXsjtT2bh0Nt Ajx6Bm8UGLAlupWkcvCSgaAsSatfQp/LvGgqyCxEoZ1hiP9ej4vfS2j6ZL5b19ycCTyG TMjyGphNSooxwzdLCFcAdXOVhEjuHu7SjT6yzjUR6HZTQ99XJWC4NTSl+9B5+dDJzuqN kMKiIYo3rYjuRvd6yxJrjNK+o2TYw2zKhTWhpelPQqVlapMowIhA3xJWVepXVcEw6ig4 4Eng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=F7bVwxDS; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h191-20020a6383c8000000b00419c136055fsi2932535pge.671.2022.07.28.20.52.21; Thu, 28 Jul 2022 20:52:36 -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=@google.com header.s=20210112 header.b=F7bVwxDS; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234177AbiG2Dvo (ORCPT + 99 others); Thu, 28 Jul 2022 23:51:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230483AbiG2Dvk (ORCPT ); Thu, 28 Jul 2022 23:51:40 -0400 Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88B775A175 for ; Thu, 28 Jul 2022 20:51:39 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id b21so2538468qte.12 for ; Thu, 28 Jul 2022 20:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VVLENy3LPh95mhi2xJgnxH73SWwfWDHHc6Zw1S4ewWk=; b=F7bVwxDS/4ZPprmVkY+83whgQIzky9i9rpHH2Fi6UWwicsVJeUJHzAEpCMTkObQOQO I9NbyePISPve9zoHOGKUCklWyFSlPlDNbiiSki7jK+UdCJnmS4d540SvWxp8DTSMe/Yj 81Q4UV9XTArpjEswH+iVJEKrhc6IGnoI6C0SiefLECVrX8XGwHz2sCTfenjrHOcioxj2 qTzMrVHdsbXN49m3HCO/NcSYHUIWuy4txYJLrWTas38jnEZDVBfXBpzD+Scjuw5ifVTi 2XqqLav+8ekiN07l7AsAjqjgpSI57GZnNr8iSnUaobaVVh8dPSMDOf5O0/t4T8WCrpHS Y47Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VVLENy3LPh95mhi2xJgnxH73SWwfWDHHc6Zw1S4ewWk=; b=3NGZJiow+114VKWqN/HiUGSvtFcMK/t1Ne+isAkyny1hWPPva1LuQyWKlEMPk+rI89 xYaTuB/98k++d7a/fsUfr6P0MXV4l5XY1wXTbOLKxWIOwCUa7JHYAdcs6NEIbgNq1XdB Ss/TjqqVRl4m6DTSUtDV075aOrVllDjOmVTQ9y78iDybo1av0zn+H/uAkE+7UW65+hLg MrOZuhdJpEoWTWT6mipnEcZiXHQOwG8sxuejwaYdohI5Gep7j5nNW6oav4o1Vs0GSjli jlj2x0RyE0XnyIrBloeUcG3iyRYbNGIPWD2IvcZcuPQz256Ey+yCAfLGVq4g8UfYCWjc Xzlw== X-Gm-Message-State: AJIora92JMAvNBy69Cb9tG2aDkAisUxtpe9ui8ir/MLJ9GfkpFgeXHTt F5Vh/1zV+804RIn8L24sxrE/tVE0gxpbVyCzX7YmZQ== X-Received: by 2002:ac8:5793:0:b0:31f:4aa:81dd with SMTP id v19-20020ac85793000000b0031f04aa81ddmr1808965qta.299.1659066698566; Thu, 28 Jul 2022 20:51:38 -0700 (PDT) MIME-Version: 1.0 References: <20220729033033.3022-1-liulin063@gmail.com> In-Reply-To: <20220729033033.3022-1-liulin063@gmail.com> From: Hao Luo Date: Thu, 28 Jul 2022 20:51:27 -0700 Message-ID: Subject: Re: [PATCH bpf] bpf: Do more tight ALU bounds tracking To: Kuee K1r0a Cc: ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, kpsingh@kernel.org, sdf@google.com, jolsa@kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable 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 Hi, On Thu, Jul 28, 2022 at 8:31 PM Kuee K1r0a wrote: > > 32bit bounds and 64bit bounds are updated separately in > adjust_scalar_min_max_vals() currently, let them learn from each other to > get more tight bounds tracking. Similar operation can be found in > reg_set_min_max(). > > Before: > > func#0 @0 > 0: R1=ctx(off=0,imm=0) R10=fp0 > 0: (b7) r0 = 0 ; R0_w=0 > 1: (b7) r1 = 0 ; R1_w=0 > 2: (87) r1 = -r1 ; R1_w=scalar() > 3: (87) r1 = -r1 ; R1_w=scalar() > 4: (c7) r1 s>>= 63 ; R1_w=scalar(smin=-1,smax=0) > 5: (07) r1 += 2 ; R1_w=scalar(umin=1,umax=2,var_off=(0x0; 0xffffffff)) <--- [*] > 6: (95) exit > > It can be seen that even if the 64bit bounds is clear here, the 32bit > bounds is still in the state of 'UNKNOWN'. > > After: > > func#0 @0 > 0: R1=ctx(off=0,imm=0) R10=fp0 > 0: (b7) r0 = 0 ; R0_w=0 > 1: (b7) r1 = 0 ; R1_w=0 > 2: (87) r1 = -r1 ; R1_w=scalar() > 3: (87) r1 = -r1 ; R1_w=scalar() > 4: (c7) r1 s>>= 63 ; R1_w=scalar(smin=-1,smax=0) > 5: (07) r1 += 2 ; R1_w=scalar(umin=1,umax=2,var_off=(0x0; 0x3)) <--- [*] > 6: (95) exit > > Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") > Signed-off-by: Kuee K1r0a Please sign with your real name. Thanks. > --- > kernel/bpf/verifier.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 0efbac0fd126..888aa50fbdc0 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -8934,10 +8934,13 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env, > break; > } > > - /* ALU32 ops are zero extended into 64bit register */ > - if (alu32) > + if (alu32) { > + /* ALU32 ops are zero extended into 64bit register */ > zext_32_to_64(dst_reg); > - reg_bounds_sync(dst_reg); > + __reg_combine_32_into_64(dst_reg); > + } else { > + __reg_combine_64_into_32(dst_reg); > + } > return 0; > } > > -- > 2.25.1 >