From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 CE76E1E7C02 for ; Wed, 15 Jan 2025 08:46:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736930775; cv=none; b=qV9wdOeV7Nf43S/H11Q24ydRX1Jc+UCpHcRZdWTQ5bQPREhK5DbeBIT+D98T9iAAySkT4YnPewsPjk38ZMF/ALBjRtq0bWkhs4LVYFPLGWgGf5piFKaps3ZYLMe6kc8J8nXT6O/MR+4UkwFwd6zr9Kb8XU53KEqKqNOP2WS9Mps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736930775; c=relaxed/simple; bh=Up7sdHdULndNV3wa1eoRT8YiiUCWqExy7Bh/qkpr2c8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=S7vJ3YvGeg5cHVhbdGsgEf7krFEj9y9Ya58CdiDqL1Bh3wEVkXk/VbaZ0mFjFyMgij2KTo3DqkHAoXM5EgIPi5tC9uMUPZq8upHz5TEkpQXQii4pgY2UxZh/ojhIJ7kCM2r5E0tIBBP5zNjzf/vXyA4lCO7H6i9B7mBBqvu8lRs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=bOHsbztT; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="bOHsbztT" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-38789e5b6a7so3458798f8f.1 for ; Wed, 15 Jan 2025 00:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1736930772; x=1737535572; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=vy1VNzBTuZPf0pEoPCF5h9VsVPv33S9oELOOuaVNs5A=; b=bOHsbztTXX3bOtoRsK65PoBtONwCWoCzv1qPDHiAsvNAiX1uWXWhf8Wl7mbKxpDBZ0 G/mKF7xdqox4aLdAQ+b09BprSyvVjTvJa1/3uHbfcvhArTXf0gmkGq3LKyHOcJ+qKqNU mTsSn2Admoanm7e+rR5F8YO4ZAD6gMY6SVN5J0WfymYbwA5EAWPqA/ktcHgDK94KThEO 7P9+moxm0fJUILYD98JmvLRlwQoaZCHtQbmkp9jbjEbXtU8pJuytNwYRUphjaYCv5gZv 8BN3/gSVmIgAOx8natmTKC0FiSQ0iMswJ5I2Gl+e01TALHORlR+GKv0OX0fFPjjV4334 PLiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736930772; x=1737535572; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vy1VNzBTuZPf0pEoPCF5h9VsVPv33S9oELOOuaVNs5A=; b=Pv2TQKG4A3NlhbGohu52bgCAW/e6NBZNxrsUAEksGHLOIGXCYVk9Z/xjcS//DvKREO UnSq3ottwbTId+yqS0s/ZUwvb99sIe5Tr4M3KoobJsPMGzoDq3T1ORJ68YQSnx0PSd/O QwwRdm4zWPD9+3iWgKu0/4n220RwoaFlnn6pLhQpzYe3UZNv2VGC2WwFiRr/41ctiNp1 Mm9wjYICsT6o5tR6BK77QDhJppVfrF796hKISVGcZh7SJEDPcwgoA49d0caOo22HC/Oi gIfdZEyzR5niZWN3p+QhXIR6V9Ir8C/0djx1MtxTVUcU+Mgc/HZJfIvfVpi8wQI9QNrg asaA== X-Forwarded-Encrypted: i=1; AJvYcCW5lV202W+li/SODt26GV+osEOGNpuLRftVdgxBBL/9d0sJTwCHgwmD+zeauCaCssbbbJX9HGfJdEqWF+c=@vger.kernel.org X-Gm-Message-State: AOJu0YwBnIKdVQf9RO24vOaz98w7M3n8hQqNp5GQpqZrpL4FhERQATNx p83PD5opbh6933/n3UQo7o2A5QZCcq9WPEECC7+KaAGsiyfhwaYnT2zf6ZrT9gI= X-Gm-Gg: ASbGncv8XATlOHinRLxCo3pZA5a7mK6+4OoSNkvukaXh3K3Gl5WF3fDnKLqiyOizlo3 Xn0rCfBrDP42GfXgApPrC3JxZxR2Giabuwa7ApYdUwLuwSB0v7ilA29LO8fue0hgfBe4Wb1A/y/ t0hhIaPgxjNxG/S3lb4skWhoQgKYiJv5h5fNtJMNhf65LRWU33VCqCJrN6MmFl8jbAjP5an/iBK 3lwJ5dLWm8+LokVXeTkfrOZmAWdPUtA2I4qiMaXADlubKov26R1hKv2ew== X-Google-Smtp-Source: AGHT+IFME8CbH/ZGTpWmcIC+L99hUYVgtrEwwgCc87ctbLiyealQR1Pe87aBz94hev6yzMucT7Nqsw== X-Received: by 2002:a05:6000:1566:b0:385:f1f2:13f1 with SMTP id ffacd0b85a97d-38a87303e63mr1936295f8f.22.1736930772109; Wed, 15 Jan 2025 00:46:12 -0800 (PST) Received: from pathway.suse.cz ([176.114.240.50]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a8e37d472sm16689950f8f.1.2025.01.15.00.46.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jan 2025 00:46:11 -0800 (PST) Date: Wed, 15 Jan 2025 09:46:10 +0100 From: Petr Mladek To: Andy Shevchenko Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Greg KH , Kees Cook , Steven Rostedt , Andrew Morton , "Gustavo A. R. Silva" , John Ogness , Rasmus Villemoes , Sebastian Andrzej Siewior , Sergey Senozhatsky , Thomas Gleixner , linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [DISCUSSION] vsprintf: the current state of restricted pointers (%pK) Message-ID: References: <20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue 2025-01-14 16:35:57, Andy Shevchenko wrote: > On Mon, Jan 13, 2025 at 05:46:44PM +0100, Thomas Weißschuh wrote: > > Hi everybody, > > > > as you know, leaking raw kernel pointers to the user is problematic as > > they can be used to break KASLR. > > Therefore back in 2011 the %pK format specifier was added [0], printing > > certain pointers zeroed out or raw depending on the usage context. > > Then in 2017 even the default %p format was changed to hash the pointers [1]. > > > > Both mechanisms are similar in their intention but have different, > > cross-interacting effects and configuration knobs. > > The end result is not always obvious. For example: > > * "no_hash_pointers" does not work for %pK if kernel.kptr_restrict>=1 > > * If kernel.kptr_restrict=1, "restricted" pointers are effectively > > less restricted than "normal" pointers. > > * For other values of kernel.kptr_restrict %p and %pK have the same > > security properties, but still different string representations. > > > > Additionally the current usage of %pK is incorrect in many cases. > > As %pK relies on the current task context for its permission check, it > > was only ever meant to be used from procfs/sysfs/debugfs handlers [2]. > > In reality many callers use it through printk(), leaking addresses > > into dmesg. While restricted_pointer() tries to detect some of such > > situations at runtime, this check is not and can not be always complete. > > > > File handlers which could use %pK correctly today, often use > > kallsyms_show_value() instead. This is similar, but checks explicitly > > against the credentials from an opened file instead of the implicit task > > credentials. This behavior was the goal for %pK all along [3]. > > > Is it time to inspect the users of %pK and migrate them to either > > %p/%px, kallsyms_show_value() or some similar new API? > > Then alias %pK to %p, maybe removing it at some point. > > To me this paragraph sounds like a good plan, which I agree on! +1 > > A different, but slightly related issue occurs with PREEMPT_RT. > > Calling printk("%pK") while holding a raw spinlock will trigger an > > invalid wait context and latency spikes if an LSM using sleeping > > spinlocks is enabled. > > As printk() should be callable from any context this is an issue. > > Removing the implicit group check would also avoid this. Good to know. Best Regards, Petr