From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D93EA3081BE for ; Thu, 25 Jun 2026 18:32:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782412365; cv=none; b=aNG6mwdEb73wP5/GPI3NLuyZpM23Cl3u1PmOg/kMc0pQEtApzg9P5u7EyprhmIt6pZUyBbc8Ket8ZpPHi1k/4HHltG4tOFd/Z9or3/p+kLzfGB7gQhHs+Cn2+h8tIVSgv71A5ZthciurtJCpeXV6qk6PT7aBNLVGXWHdDEE1Uto= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782412365; c=relaxed/simple; bh=GSBvzHimrtPTHyFZYnFlxss5tjoakS2FIABKN+BFO4U=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=NlSuq6ob0WpvcVU79IDzHLqdsjRvCbGmY5JaEZARl+D/8nkOzIRyCTwR/62UrPfWiKM+stJt558+tMHzHPtBaN1rd12fhYxmv5KocnUcxmmhFadhhxkcPsat2023lfB0KdrzBnYOUNsMp/FrLbA2jmlmmqcMdZX6QWhAo2wuZR0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=KdnxM3IT; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KdnxM3IT" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2c80810247dso2501005ad.1 for ; Thu, 25 Jun 2026 11:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782412363; x=1783017163; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=lByFWkdr8AqsD6eHmvZL45Q1tDRFoc5Hf59UJo9Xm3k=; b=KdnxM3ITK8b1OwcVHF2CrNUDLpPeQy0KnFyhnWejpkobOvD2+vng2VyLc0vTIw1MsC xz5C4UY9AS7x1huLHAUeOG3bIFQGDx5Iaj+IKmVb4bD0+uJOD2nxMuTVuzCabxF7b2ww TpYnHcqa2Q7BjXMzCA/SGI7L3M0d3TwAMt9d44GqyphqCbPRED8SaBdg+d69UBWUCBY/ s6LxP/0GsouUoL3qZPmWTSTVIxJNOMwotTyUr9NUCYoUn6EYCOhEDtfmafmZal93yI5i pFpfDNUta+CsLW/KfNBB54NZnlePHIB+F6YinN1Mmoab2Z8+xXyOIiO3lGxWYwcxGX4P 5nUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782412363; x=1783017163; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lByFWkdr8AqsD6eHmvZL45Q1tDRFoc5Hf59UJo9Xm3k=; b=R8EYTEZ6SMlvaBQOJkFprpCL9fZ7sfthKscE+A+MftDcMDFkEv6eYYAoz8OLUaDfZh a896NqM4xFQloTrn6FBILWpQBafkPgF+A6pHouHaall9B8oDAs3npeTpF8BpI4/9dDOD BoUOAMiXQD9K6NNw/qJt7uNuz6fIQvdFXisLIUMrpNKlawbKuZ702oBS7MeOAn+nPK/T JZ5sfJwU3QSBa0IvCL04oFSVt1wMqH0jFFFoQ6zPxCHOByZieuFSRkBIjBVrmj/ahvFI pSfvFPtIuXVQVIseSrtws86MnB9iAbft1ZmtDdaUyNadoooS3Nd/uZfNblAHdW1jjund mnTA== X-Forwarded-Encrypted: i=1; AHgh+Rp4FiVQ1c2203PF3C6hHRDF/Q/lJnwXMsf/APoZrgxEMD3kALJSv0qt+DDJwZ8OVNT9mAuEmh/f+TRsOaU=@vger.kernel.org X-Gm-Message-State: AOJu0YxfrxmwYADfKA4rscVnBcmnp45lw9zJHE9WNGH02pDG0AzH+tHd jsE+AUIKPy+ORt3uewoJG4ah0QTvHFJd8JyuZ4BhAQDO/Qxw+lFyN6+hXvFArkbkS1M= X-Gm-Gg: AfdE7cn0UmAPyW+KsRrNVdk1DhichXcIljxDRkEE7wySr2/ZcBLj2W4VMQIq2FkvFsX KHilDWIzL98c2PoVx9JBFOeMtf6mLhRyI9dA7pSZVz7BxCMceXKC4Bc20+cLDOtvDyc45DI7A9S 2BeQ8n0YCSRl9le3lYwM7wl4/nVgESinHKOkLF23JvlgxdZIX2et56qzWkn3twFoWxeOEHAebVr krpM6Fg5Mr+FtzUq5R9mG23aiHDeKt1IqCStHh2zv1iz6JJcsKnYRY92NIJn5T67owLHW7EdH/B Y0ecFMyd7lK/uaMQwl7F2whMFtaxTwTkVmM9CFNu6N9IVB53rCvv/eztGI2XhVI9UuZZFNKtDJu z9zjeU6FK5jUrJA5/6Y6irQG86xEQfh6lCXAsHW43uqh+P98aPoQ9kYJZX30hsAyBLzZ9JvOPK6 19Hd/rYU5+5vKxqkrRv6TeoCNjMo5rWZtpJhTH4om/+A== X-Received: by 2002:a17:902:f690:b0:2bf:128d:f7ff with SMTP id d9443c01a7336-2c7fc6ad9bcmr39674465ad.16.1782412363176; Thu, 25 Jun 2026 11:32:43 -0700 (PDT) Received: from [192.168.0.226] ([38.34.87.7]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c7f63b2e18sm25757935ad.41.2026.06.25.11.32.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2026 11:32:42 -0700 (PDT) Message-ID: <860e915356c571791712be02c636405aadfc6467.camel@gmail.com> Subject: Re: [PATCH bpf 1/2] bpf: Keep fastcall spills for helper stack reads From: Eduard Zingerman To: Nuoqi Gui , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi Cc: John Fastabend , Martin KaFai Lau , Shuah Khan , bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 25 Jun 2026 11:32:32 -0700 In-Reply-To: <20260624-f01-12-fastcall-helper-stack-read-v1-1-e0a86085ef77@mails.tsinghua.edu.cn> References: <20260624-f01-12-fastcall-helper-stack-read-v1-0-e0a86085ef77@mails.tsinghua.edu.cn> <20260624-f01-12-fastcall-helper-stack-read-v1-1-e0a86085ef77@mails.tsinghua.edu.cn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (3.60.1-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-06-24 at 16:39 +0800, Nuoqi Gui wrote: > The fastcall spill/fill rewrite is only sound while the stack slots used = by > the pattern are not accessed outside the pattern. Direct stack loads and > stores already call check_fastcall_stack_contract() to enforce this. >=20 > Helper and kfunc memory-argument checks can validate PTR_TO_STACK reads > through check_stack_range_initialized() without applying the same contrac= t. > When such a read overlaps a fastcall spill slot, > bpf_remove_fastcall_spills_fills() can still remove the spill/fill pair. > It can then shrink the subprogram stack depth even though a helper or kfu= nc > reads that stack address. >=20 > Apply check_fastcall_stack_contract() from check_stack_range_initialized(= ) > after the concrete stack range is known. Zero-sized accesses do not read = or > write memory, so leave the fastcall optimization unchanged for those. >=20 > Fixes: 5b5f51bff1b66 ("bpf: no_caller_saved_registers attribute for helpe= r calls") > Signed-off-by: Nuoqi Gui > --- > kernel/bpf/verifier.c | 4 ++++ > 1 file changed, 4 insertions(+) >=20 > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index ff9b1f68ceca4..d77332eeab359 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -6873,6 +6873,10 @@ static int check_stack_range_initialized( > max_off =3D reg->smax_value + off; > } > =20 > + if (access_size) > + check_fastcall_stack_contract(env, state, env->insn_idx, > + min_off); > + Thank you for finding this bug. I think that placing the check_fastcall_stack_contract() call here makes the same call unnecessary in the check_stack_read_var_off(), as it calls to check_stack_range_initialized() with zero_size_allowed=3D=3D= false. > if (meta && meta->raw_mode) { > /* Ensure we won't be overwriting dynptrs when simulating byte > * by byte access in check_helper_call using meta.access_size.