From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 42D5616DEB0 for ; Wed, 26 Nov 2025 22:07:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764194832; cv=none; b=hJmD/7haFwpf+uaMns+F3UNuXLkGM0GQR2D+MZzL9Rx1IAtPV5DbStFIqyPpSekz3xqvtMojL8E4ZwLLHUSeFY5cPlKrBtDUxkpXeKFwezvGmhUa9kRBVefvT+ejbhZ0BWH2mER486to7lcDTBZNYTXhUjRcPf869tgt/A3oje8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764194832; c=relaxed/simple; bh=6Kuf8D/dPpy2hLtwPCfMRwmZXc2QTBKCra2dR+YmW8o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=SduT/5BURhhjcHI7tnKpmK22uijdJCGa2cQdnYVwIq+uB3jEjYsAK/8lG+sEg2gbcAqq6NasoqmSOvTnrEFycxsmvpXtlL7+aSgdqJKWM1g5tr+nB1+JscP8JcC7xmSL8WhIm7N5w5V+Y3Fb9rbbfS7mNdvA1FxtQeaFkacnoOA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=bWl+srgJ; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="bWl+srgJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1764194830; 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:references:references; bh=KHQhIXqTKHAfMVPiNgWTOnFa7PEs0nePHEYIRyuzrrs=; b=bWl+srgJPklr/Ovzyb/OYOc5hAg+eC11U6KkkXg3vTpKuLTTr7xhJGRLlVhnQAyhN+HpRM DV6nc17R2HeRxQpN3DboTcbq0Ldieg45r5yNWLIGViIP43u/Whl80FdwUwSegz28c3idvC UBxYlXhkFE7xy5oGRnqd8as3crXEO4s= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-678-lAB0YbrzMdWNI4sks5VnlA-1; Wed, 26 Nov 2025 17:07:04 -0500 X-MC-Unique: lAB0YbrzMdWNI4sks5VnlA-1 X-Mimecast-MFC-AGG-ID: lAB0YbrzMdWNI4sks5VnlA_1764194822 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 70ED51956048; Wed, 26 Nov 2025 22:07:01 +0000 (UTC) Received: from fweimer-oldenburg.csb.redhat.com (unknown [10.2.16.157]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DA0011800840; Wed, 26 Nov 2025 22:06:55 +0000 (UTC) From: Florian Weimer To: Thomas Gleixner 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: <873460h5yb.ffs@tglx> (Thomas Gleixner's message of "Wed, 26 Nov 2025 21:52:44 +0100") References: <138c29bd5f5a0a22270c9384ecc721c40b7d8fbd.1747817128.git.dvyukov@google.com> <8079f564-cec0-45e4-857b-74b2e630a9d5@arm.com> <87ikexhbah.ffs@tglx> <87a508he4h.ffs@tglx> <873460h5yb.ffs@tglx> Date: Wed, 26 Nov 2025 23:06:52 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 * Thomas Gleixner: >>> What do we have to take into account: >>> >>> 1) signals >>> >>> Broken as we know already. >>> >>> IMO, the proper solution is to provide a mechanism to register a >>> set of permissions which are used for signal delivery. The >>> resulting hardware value should expand the permission, but keep >>> the current active ones enabled. >>> >>> That can be kinda kept backwards compatible as the signal perms >>> would default to PKEY0. >> >> I had validated at one point that this works (although the patch that >> enables internal pkeys usage in glibc did not exist back then). >> >> pkeys: Support setting access rights for signal handlers >> > > That looks about right and what I had in mind. Seems I missed that back > in the days and that discussion unfortunately ran into a dead end :( There was a follow-up where I tried to incorporate the feedback (PKEY_ALLOC_SIGNALINHERIT), but based on more recent discussions (here and before that), the original approach referenced above seems preferable. >>> 2) rseq >>> >>> The option of having a separate key which needs to be always >>> enabled is definitely simple, but it wastes a key just for >>> that. There are only 16 of them :( >>> >>> If we solve the signal case with an explicit permission set, we >>> can just reuse those signal permissions. They are maybe wider than >>> what's required to access RSEQ, but the signal permissions have to >>> include the TLS/RSEQ area to actually work. >> >> Would it address the use case for single-colored memory access? Or >> would that still crash if the process gets descheduled while the access >> rights register is set to the restricted value? > > It would just work the same way as signals. Assume > > signal_perms = [PK0=RW, PK1=R, PK2=RW] > > set_pkey(PK0..6=NONE, PK7=R) > > access() <- can fault > <- or interrupt can happen > > set_pkey(normal) > > So when the fault or interrupt results in a signal and/or the return to > user space needs to access RSEQ we have in signal delivery: > > cur = pkey_extend(signal_perms); > > --> Perms are now [PK0=RW, PK1=R, PK2=RW, PK7=R] > > access_user_stack(); > .... > // Return with the extended permissions to deliver the signal > // Will be restored on sigreturn > > and in rseq: > > 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. There's an unmerged glibc patch that allocates a protection key for the dynamic linker, so we might end up with every process using rseq (without critical sections) and protection keys. Thanks, Florian