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 66C3D32E74A for ; Thu, 27 Nov 2025 14:38:42 +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=1764254324; cv=none; b=j4Ot1ut+5wq3+lD/12jmAf/Vrpx3aoOITrmRHmfI00lXCEF+4Cv3ZsLlUiSQAknQqWCZZ4IsFOn8O3CFNC+n5m+8yhfPFUtfaqWXz7PJZdn15RGBidNQFY6G+rB+a2MwtlhQTMuV80wFB6bma2kDPWK7FGbCopnlwcZcaDxma34= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764254324; c=relaxed/simple; bh=kVESzGS9UmwMHHyxK7/iAqMaND3/+J+EAflBiVnulcQ=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:MIME-Version: Content-Type; b=rTd6qtEG4VqGDa9++A/DcMv/3AHeRiMKGbO1F4a6Yv+ydIBaCnaUG4hlY/edsAoBUOKpuPXe2qhDD3aADT83YJcMdr/2RbomNvu5EJKwmUJ6gYx/iizBj83IkPofvcUw/c66gp51d0l/LrsIwvEnIM4jF4AD2wEIerSUwh9S0go= 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=xvAhbLix; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=bW5BhdJg; 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="xvAhbLix"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="bW5BhdJg" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1764254320; 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: in-reply-to:in-reply-to; bh=nSdcdYXIM1EBlEBA7J6ilA0NI6d0H0X99xUx/Qzxex8=; b=xvAhbLix48GcDkN19F7LIwrDc8ChYBqYdyRtVW+FdORb59M+dek9rwfCJJxMDGIgawn7iR ZdXuJYjXpx8ZR8j59KSZa6fIXN8zq8UupjgMn9Vd+6Hxmoo2OCSGpy1cDmcBsiPuqjHmq+ gfkYeMGdJH7jjZgEmkQjyCpD34kiaUOoJyP6Kr4349CywZYyEEk4NJZ2RCik95B/t3y0Et iw+ycy4BWYamL1wZ0PuPdibJVtPo3IcxX3e2gXYK0khbYGyHMBFlVaaKkgczirIA/idHWG r3Z/JRY9b3c1rypSb2IOW5ItPdj4R2mbX346izyU9Fn2xaFyUhMIdy3d/IkClA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1764254320; 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: in-reply-to:in-reply-to; bh=nSdcdYXIM1EBlEBA7J6ilA0NI6d0H0X99xUx/Qzxex8=; b=bW5BhdJgz3YwA5I6mLbzjHDL2jYOENC0nNvhAr8SCOh88ZT7ZbGMcxdInGFS+DIf/wTivT IPf9K/88OmBRyTDQ== To: Florian Weimer Cc: Kevin Brodsky , Dmitry Vyukov , mathieu.desnoyers@efficios.com, peterz@infradead.org, boqun.feng@gmail.com, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, aruna.ramakrishna@oracle.com, elver@google.com, "Paul E. McKenney" , x86@kernel.org, linux-kernel@vger.kernel.org, Jens Axboe Subject: Re: [PATCH v7 3/4] rseq: Make rseq work with protection keys In-Reply-To: Date: Thu, 27 Nov 2025 15:38:39 +0100 Message-ID: <87y0nrfsls.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Wed, Nov 26 2025 at 23:06, Florian Weimer wrote: > * Thomas Gleixner: >> cur = pkey_extend(signal_perms); >> >> --> Perms are now [PK0=RW, PK1=R, PK2=RW, PK7=R] >> >> access_user_rseq(); >> pkey_set(cur); >> >> If the RSEQ access is nested in the signal delivery return then nothing >> happens as the permissions are not changing because they are already >> extended: A | A = A :). > > Agreed. And the pkey_extend/pkey_set don't have a prohibitive cost, I > assume. I got the impression you were trying to avoid that sequence, > but I think it's more about defining the way pkey_extend works. Correct. I was trying to avoid doing it on the exit to user path, but after thinking more about it, I'm not so worried about it anymore. With the recent rewrite of the RSEQ handling in the exit code path that should more or less vanish in the noise. I'll hack something up and evaluate the impact. The real question is the semantics of this mechanism. In your proposed patch you define it as (if I read it correctly): 1) The default signal protection is the same as the default for fork, which is PKEY0 unless user space changes it. 2) pkey_alloc() with PKEY_ALLOC_SETSIGNAL set propagates the protection to the signal mask/permission set 3) The permissions on signal delivery are: (default & signal_mask) | signal_perms I'm not entirely sure whether #3 is the right thing to do. My initial thought was to keep the current permission set at the point where the task got interrupted and expand it with the signal permissions, i.e: (current & signal_mask) | signal_perms Both variants can be argued for, but we have to agree on one them :) Thanks, tglx