From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 371803A5E71 for ; Thu, 4 Jun 2026 12:08:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780574937; cv=none; b=UutScNWkCZIkXsPkQufRGSsSdSAkgmAGpQ87XXYKsilQndPjFIAdHf9HxOVKGjp5fSII0j3hyFxYWvKaTDwFua/42EXCo6VMo54NJcvenKu27F9rkpGwTB5VWdkCkMt1+b8MCxJc4tjcHGvfu75iwTE751N/qC3Nn3hgFMi/z/0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780574937; c=relaxed/simple; bh=jY3Pzqq530Cn72frYkgbtdMUeZZjNDuhAa03g5Uw7yo=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:From:To: References:In-Reply-To; b=CXCUhpOT2ngFdrn7k2PK/u3A7OdkfdPiQrtoWY3t1aWOnKeDjsiOHDIsnw9hq1oJYh/teP40gxxkAfWQ7S8u8eNOg0VZzfAL4qkXWU0enOK9erXLVZscNjyKwBhXbXhGv268AR86fXBLaVuMo69IpmFoZ0FQtmaKWPLBKZhjzFs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=L4cfS0Ud; arc=none smtp.client-ip=185.171.202.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="L4cfS0Ud" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 507C3C63452 for ; Thu, 4 Jun 2026 12:08:51 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id F0F955FEF7; Thu, 4 Jun 2026 12:08:51 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 2B0C5106A035A; Thu, 4 Jun 2026 14:08:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1780574931; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=8JExlbsCTH+ccnzG/dkGRTjdMWB4w6e4ceeXGKPD6vk=; b=L4cfS0UdZ7ltln4Odkyg5QmKC/Sn73ZeQQGf3R8wB4dJI3rxo9YrpH7W26r7wdG0RqUPiv u1YW7A7ZUSIQuzL5kJdPWZJM4QzOoAUhePMVJSyZ7lubCql0Be8QQf08Fv4WKkuOHhQ8eQ WSGSVp5D7l4c5bW71S9GGNXFo4bNwCdYJ/4cuGR33NE6OGvVdCKWUlpT3EJ8ocm96DJSlx f92DAyTs4NYMk7CJuJJ1De1vTsYCahvzb4N07H2IJD/CfROaJFqnNCD/FXRMBqGDawl0CG ZI7gRTfB9aXIeXcIZOxfmtphYhpQYli00+JTG7aHkKXoqyCITXaWp5MLos4ffQ== Precedence: bulk X-Mailing-List: sashiko@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 04 Jun 2026 14:08:48 +0200 Message-Id: Subject: Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack Cc: From: =?utf-8?q?Alexis_Lothor=C3=A9?= To: , =?utf-8?b?QWxleGlzIExvdGhvcsOpIChlQlBGIEZvdW5kYXRpb24p?= X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260413-kasan-v1-2-1a5831230821@bootlin.com> <20260425050557.827F3C2BCB2@smtp.kernel.org> In-Reply-To: <20260425050557.827F3C2BCB2@smtp.kernel.org> X-Last-TLS-Session-Version: TLSv1.3 On Sat Apr 25, 2026 at 7:05 AM CEST, sashiko-bot wrote: [...] >> #define LR_FRAMENO_BITS 3 >> #define LR_SPI_BITS 6 > [ ... ] >> @@ -6493,6 +6498,8 @@ static int check_mem_access(struct bpf_verifier_en= v *env, int insn_idx, u32 regn >> else >> err =3D check_stack_write(env, regno, off, size, >> value_regno, insn_idx); >> + >> + mark_insn_accesses_stack(env, insn_idx); > > Global subprograms are verified independently of their call sites, and po= inter > arguments are tracked as PTR_TO_MEM rather than PTR_TO_STACK. Inside the > subprogram, check_mem_access() evaluates loads and stores under the > PTR_TO_MEM branch, which does not invoke mark_insn_accesses_stack(). > > If a BPF caller dynamically passes a pointer to its stack as an argument = to > the global subprogram, will the JIT-compiled global subprogram execute wi= th > KASAN checks enabled for those accesses?=20 > > Does this erroneously monitor the BPF stack, bypassing the intended > suppression mechanism? After having thought about this one for quite some time, I see no simple way to correctly distinguish stack accesses hidden behing a PTR_TO_MEM passed to a global subprog, as those are verified separately. I can either: 1. skip PTR_TO_MEM memory instrumentation when we are in global subprograms, at the risk of missing instrumentation on passed memory accesses that _need_ to be instrumented 2. systematically instrument passed PTR_TO_MEM memory accesses in global subprog, at the risk of inserting unneeded instrumentation when the passed memory comes in fact from caller memory. I then propose to be conservative and apply 2: the only downside I can think of is that a few alwasy-passing kasan checks will be inserted, but we are at least sure not to miss any instrumentation. --=20 Alexis Lothor=C3=A9, Bootlin Embedded Linux and Kernel engineering https://bootlin.com