From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 C53D33DD51B for ; Wed, 18 Mar 2026 14:57:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773845843; cv=none; b=AFQ0F6IGnnCxPYhARscXTsPYBcGtMTvsOZmNktuWmpm7Fv5QMhGvXn585UWQ9b3j7R1mWQBt84E8uN1QzlQuTyN7Bseky04jG4XCqstxGUB6to+lKAIsq8ND2uDPI+ni0t1nkOyd4pFY4qJqOlQie5vTmUy/Dec6OMqLo3Srs6o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773845843; c=relaxed/simple; bh=aj3XovDsq3mXAa+v/D/rA450i2mcgDJfzoSPyA5fpkU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LZ746c7ahg0yFBcInTFl4KNuoc7RmMriRpKh2R+zFkEom1d9EFarD+9WlSQM7m84Iu12BhY8+zUHezP/26W1BhcFfkuCMxwtBz9BpFNLLywYaNI+4HEa7oXxjt2wQeZF2hVfRcBfw8lpY7AQPDw5OTXpP1Vj16uRPsS4oy9liUs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=g4ysoOnl; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=16oGbuVf; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="g4ysoOnl"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="16oGbuVf" Date: Wed, 18 Mar 2026 15:57:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1773845840; h=from:from: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; bh=UvNDMzlyqptvnmTdr7WqEv7zV4spn/QABh6QwoFc8/s=; b=g4ysoOnl+5B0YnjcJuZdridRRiYt213vKUQvK0l04SN0MpN4mBtK9SmGT8Et7kFezlafjD duXR1vhEZ7GtluvRNyX3nNB3f+wwLh49l9x1HHq4fvtHUOoOAJS40qESpeFhRjYn5llG43 YezJJwsDR/wRmvGehan8C29fxJchjX9hqrPA+zb6gm+5ae5xn7tPC1mC36unHhWcnVSDc8 qQtWTvst+9U5CwxFsaUoGffn92oGO82oqZaRjHuMlx7Ok0XNjwjE3rhQqp5FCPM4+ayoXN Uh0ADR/5z+6vG/ORgwj5KmBRxhQWMAec0kDzCNlmvQcqKTzPl491g7+00H21Og== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1773845840; h=from:from: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; bh=UvNDMzlyqptvnmTdr7WqEv7zV4spn/QABh6QwoFc8/s=; b=16oGbuVflVeSnh8nsHlegHqFDOeH+0pW0DdMEaLwb8wuj1hrUYgqdwQOx4UUZCMHpJhttd xn0pIsoz1w+CVaCQ== From: Sebastian Andrzej Siewior To: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= Cc: Petr Mladek , Kees Cook , Andrew Morton , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Sergey Senozhatsky , linux-kernel@vger.kernel.org, John Ogness Subject: Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting Message-ID: <20260318145718.vlw3iaYL@linutronix.de> References: <20260317-restricted-pointers-final-v1-1-b4dca0ed6483@linutronix.de> <20260318094555-37b1a6ce-4977-4e54-95f2-2a30bec904e1@linutronix.de> <20260318135936.mGaAlujF@linutronix.de> <20260318151711-95ae5393-908c-40f0-b5fd-e4ddd9de8801@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20260318151711-95ae5393-908c-40f0-b5fd-e4ddd9de8801@linutronix.de> On 2026-03-18 15:45:06 [+0100], Thomas Wei=C3=9Fschuh wrote: > > might_sleep() seems reasonable if any usage under spinlock_t can be > > excluded. >=20 > Unfortunately it can't be excluded. See net/unix/af_unix.c, which uses > unix_state_lock(), a spinlock, around printk(%pK). So if the security code can't use a mutex_t internally as locking then we can't do might_sleep() then. > > If the usage is intended to happen only from task context then > > in_task() would make sense. This would already ban any softirq context > > and everything else I know we had in the past. >=20 > %pK only makes sense from task context. There should also be an assertion > if this is violated independently of the value of kptr_restrict. >=20 > Also in_task() looks like the better replacement for this check in > restricted_pointer(): >=20 > if (in_hardirq() || in_serving_softirq() || in_nmi()) exactly. > > The fake spinlock_t could be achieved by just something like > > might_lock() which would avoid any overhead of real locking. >=20 > might_lock() simulates and acquisition and immediate release of the lock. > With an alternative solution which holds the fake lock for the whole > execution of restricted_pointer() we could make sure that lockdep > can detect any incompatible locks being taken in the callees, even if > the actual caller of restrict_pointer() is not currently holding any > spinlocks which would trigger such a warning. > I'm happy about opinions whether this is useful. might_lock() just grabs and releases it. You could acquire it at the top and drop it at the end. In order to simulate a lock+unlock behaviour without an actual lock. > > But do we still need %pK? There are far more %p users in seq_printf() > > context as per > > git grep -E 'seq_printf.*%p\>' >=20 > That would probably be a question for the networking folks who are using = it. > Getting rid of it would certainly make various things easier. Lets see what Kees says, then maybe poke the netdev unless Kees explains why this need to remain. > > than %pK. According to commit 312b4e226951f ("vsprintf: check real > > user/group id for %pK") it is temporary as of 2013. There should be a > > check at open time instead. >=20 > Doing the check at open time requires some place to store the result > of it. The users of %pK I looked at all reused their core datastructures > as state in seq_file, so finding space for the result from open time > would require some non-trivial changes to them. You could go for the easy solution and return early with -EACCES or so. That was the intention according to my understanding. > > > > > switch (kptr_restrict) { > > > > > case 0: > > > > > /* Handle as %p, hash and do _not_ leak addresses. */ >=20 >=20 > Thomas Sebastian