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 14FEDCA4E for ; Wed, 26 Nov 2025 09:32:43 +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=1764149565; cv=none; b=Ai8kPC2rIuWgZ8wyOe62iNojnmOZfJxQFHFFiYnpauaP/bAgwSPTnIV21dhuyv6YSv9fyYgV4wd886VovDdtS/VwC6mmehvCbewSdn0S+J4aiVsKQkUOmgSZCz4ynNZEvvIUjbSoqJoKxqO7xOGWHruDDzb2lIGt72SoBLAZ+18= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764149565; c=relaxed/simple; bh=c5CBMkDv3NUD12DSetwuE7FLoCbiOIl2ARJULgurRRU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=aDcWt0XOjgc/nkjTBEO3Jt6ik5WhH2IutNuOmd+1VUqeyyfcLixFdL1HEXWaFbdc4UuFmhLFXjJWMDv+YHRiqGQJC4la0gEqBVOnln2odZ5HjfzsBLt5xfsxJZp8K+c53XnTsc5WUscBPQo9tyMR6aULqO0DA0my7jJzXKsLWqM= 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=ZA3lbsI4; 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="ZA3lbsI4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1764149563; 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=7ICvH5jHLOnhW9z56ebHOvvtCUHuhKD4jRzInP0nQgE=; b=ZA3lbsI4KzkHxy+McYu0aTPqbVBgLJmqgWCwwFsV9auKpICuJWOXh2LnSn1u3AF7CHH5LM gMe4WDY3ki7u2AkpMJHpWWD/huixE8OWSaOu8yyf3+miFn/QW5+ILBvenJ7Ib3ZGy0H75E CldibQ6kcb8wN0XVFihoOurew0m3JY8= 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-172-Vf_9sS0sM3im2-lVty5HRQ-1; Wed, 26 Nov 2025 04:32:38 -0500 X-MC-Unique: Vf_9sS0sM3im2-lVty5HRQ-1 X-Mimecast-MFC-AGG-ID: Vf_9sS0sM3im2-lVty5HRQ_1764149556 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 79D251956053; Wed, 26 Nov 2025 09:32:35 +0000 (UTC) Received: from fweimer-oldenburg.csb.redhat.com (unknown [10.44.32.146]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0B85618004A3; Wed, 26 Nov 2025 09:32:29 +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 Subject: Re: [PATCH v7 3/4] rseq: Make rseq work with protection keys In-Reply-To: <87ikexhbah.ffs@tglx> (Thomas Gleixner's message of "Wed, 26 Nov 2025 01:45:10 +0100") References: <138c29bd5f5a0a22270c9384ecc721c40b7d8fbd.1747817128.git.dvyukov@google.com> <8079f564-cec0-45e4-857b-74b2e630a9d5@arm.com> <87ikexhbah.ffs@tglx> Date: Wed, 26 Nov 2025 10:32:27 +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.93 * Thomas Gleixner: > That's all broken. Assume: > > 1) process starts with pkey 0 (default) > 2) glibc creates TLS (protected by pkey 0) > 3) main() switches to protection pkey 1 > > If the switch to pkey 1 does not ensure that TLS (where RSEQ sits) is > accessible by pkey 1, then how is userspace able to survive? > > You then do not even need the help of the kernel to die. If the process > accesses TLS it dies on it's own. Signals have the same problem. With the x86 approach to disable all access, protection keys are not really usable without tight control over all code in the process. This behavior breaks encapsulation. I'm less concerned about the impact on restart of restartable sequences because by design, it's a non-modular feature: syscalls and function calls are already banned. If the code wants to restart, it has to make sure that the access rights at the restart point are correct. But that's like any other register contents, I think. In the other direction, code that sets a restrictive access mask is already not allowed to call into arbitrary code. For example, we could use protection keys internally within glibc in the dynamic linker and require that a key that we allocated retains read access. Unfortunately, there's a use case for singleton access rights that does not include key 0: validate that a pointer points to memory colored in a specific way (e.g, for vtables, or for bytecode). If the kernel/scheduler cannot bypass restrictions on access key 0, then supporting this kind of memory color check is rather difficult because userspace would always have to put key 0 into the accessible set. Would it help to allocate a dedicated key for rseq and specify that userspace must always include this access in the accessible set? In glibc, we cannot easily set a different key for the TLS area today because it's not necessarily on an isolated page on which we could call pkey_mprotect. We plan to fix this next year, but it's not a trivial change. On the other hand, I get the idea that protection keys are pretty dead. So far, I couldn't get the x86 signal issue fixed in the kernel, so we can't use them for glibc hardening. AArch64 duplicated the x86 behavior, too. And POWER removed protection key support with the switch to the radix MMU. Thanks, Florian