From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E12B2C3DA45 for ; Wed, 10 Jul 2024 10:36:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E4C06B0096; Wed, 10 Jul 2024 06:36:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 595016B0098; Wed, 10 Jul 2024 06:36:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 40EBD6B0099; Wed, 10 Jul 2024 06:36:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 202A96B0096 for ; Wed, 10 Jul 2024 06:36:50 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9BB94C1C8F for ; Wed, 10 Jul 2024 10:36:49 +0000 (UTC) X-FDA: 82323489738.09.F228256 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf10.hostedemail.com (Postfix) with ESMTP id C87B2C0023 for ; Wed, 10 Jul 2024 10:36:47 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VVR1XST+; spf=pass (imf10.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720607783; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TbJg6z7j+ZQBtm21UhpDM4r/48rTnLX4yDmOeuhoEeA=; b=mk9g46GXE05LRJiRE6g3QavEhPf2/In6NGX6vRJJrUv3JbxPK3yBcYdRSkCfsWfPKcwDYX wxsLsTK6BbkDfzBf/QCs0aHI+/pNmUWClLwpXCmX61N57NQQNsA+WOIRNUok6T1zybCo5n yZMaYAfSrOp1LbQqP8trz1AwhdNR99I= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VVR1XST+; spf=pass (imf10.hostedemail.com: domain of fweimer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720607783; a=rsa-sha256; cv=none; b=AF8pDnB1Vy2SEJhSwxyo4GjXn+IIp5EJPP/kS0XIUbAzFwx3367fVZjIwaHD6u3Qz3fkss gvOC23/cjRdqKnDls4wOIUsnc/Xd2i0SqnC9aIlNlR9MHD7opsn8+mAtZHNznlErCYiDH8 eyiGpj/59fpl4+GTwpJChDWt8MKmrTI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1720607807; 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=TbJg6z7j+ZQBtm21UhpDM4r/48rTnLX4yDmOeuhoEeA=; b=VVR1XST+rdjw9tobwwJQ033cdufasHVPYa9Nu3xdB/PPx1ka85QNtdZQl9sWoeHGFWxPXI 8EG87AYQDM1j7SW7avkKG9Y+wIKOhs/kf+b8kvGep7nBnrCx+g0A/zHiiZhdVDhcOWTqHh k1hrKLBqt39GM6YIXjLnbvLuW+Z3kJ8= Received: from mx-prod-mc-01.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-186-a07wZjSjMfOCkc_bgrfTiQ-1; Wed, 10 Jul 2024 06:36:41 -0400 X-MC-Unique: a07wZjSjMfOCkc_bgrfTiQ-1 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 07722196CE01; Wed, 10 Jul 2024 10:36:36 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.45.224.154]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A378D19560AE; Wed, 10 Jul 2024 10:36:24 +0000 (UTC) From: Florian Weimer To: Mark Brown Cc: Catalin Marinas , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Brauner , Thiago Jung Bauermann , Ross Burton , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, "Schimpe, Christina" , "Pandey, Sunil K" Subject: Re: [PATCH v9 05/39] arm64/gcs: Document the ABI for Guarded Control Stacks In-Reply-To: <20240625-arm64-gcs-v9-5-0f634469b8f0@kernel.org> (Mark Brown's message of "Tue, 25 Jun 2024 15:57:33 +0100") References: <20240625-arm64-gcs-v9-0-0f634469b8f0@kernel.org> <20240625-arm64-gcs-v9-5-0f634469b8f0@kernel.org> Date: Wed, 10 Jul 2024 12:36:21 +0200 Message-ID: <87a5iph6u2.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Stat-Signature: d3f8z34fwh3ykzdo9gnjhcwnkpwo7xum X-Rspam-User: X-Rspamd-Queue-Id: C87B2C0023 X-Rspamd-Server: rspam02 X-HE-Tag: 1720607807-975190 X-HE-Meta: U2FsdGVkX1/iyA5l/pvnhB7L5N0fmWAeASaKWtMtY8CqCqSCxE4PtmYfH9GoAYBqACneM1IyBwHpoai3VZxTmHPXC2QM2VCt2Ps7TXAui6D7nOQFstfI6zsi80R9/fSwZ95ICTYmzKX5q9Ic5+4Uf93hr6Us6U7V+6x/QNn1qgWuB73GA07DbzgmtDwEkt602HUwNJTK8gcMFdNhvAsdKQBkzbVXOPoUMwYEvrRq8T7nepUrl2aM1C5TZoge9XHRUq5GhllTWqDC6Dy5gxUfMYnhlPfOdidZwDPbndCQCgfabNM3iLt5KrThv0WqjZfZE3Yp5ZxT/dbWHl90wJaPStxhL7QwSM3MDewjrsG4zH0f9qFVKYK5JO2lM9Wp7ny07peYZsViEMA//WWRSneFIMgiMuSfLTNaFZrUA1VdTdVyPBK64MHFtafJRxZLaQ/rB4yQiImNqomc/42fFhIkKc4SoU0kMpDuTdAuUszCj2J2skA/NvnO7xgNotaK8oZvyVllqiePFkrQsgU7YHbyUeJA+cYeKpOMWro0ZrXiOXWnajoEssThxeGPzXunWV/yV1bOsmZ2l1K17+uEieAnsECrBVMOeQXCUh4KaJV6DvAtt9P7vOjtq+1xUEgCQFf41k2Ppiu72lrYIJXadgAYZ/stWdnP6nEwDmpUU/wcUAaMoWaUT755NYHCI8E88MGO5azpKR/8ZuEVqkiTB6nD+g2nv0nP496VYbK8dOw5OUSyOWpCbTAGQXi79D+V24SwbO6bN7RnhSEQGGY3+TQpQXYMx745zfW/wuwEi2PN51fVwNk5Qf5MtIWLQtrdgw32QpsOYl7j5a14dpXOah31w462H9oajkBqSvv+ECMb7EkafRmBjqugCD26L9W3H3d5gKqZ3RCOkVqyClzYwB0JDSRo3Tof78xuq/pjptaW3SlJITyW65q1GOEeXPkpYdsii5SfH/hBR6KHl6ivt7d uvaB1COo shizVorSMSG82j4Q47IOFklDeEWzCPXfzso5sUck06IUFzgQCmo4/kvRwvBPO0mU330WNUMiFTMzup7heiq3dBWyY7GSCMzafR0pRDaxvbdr+gvoXOjE3TIt/XwwBbvm/zwZz32ehsAiBnfRLuSQgTJBmDJBd6IGTt7sAgxah5SJW/+dC6VxPVKVN0ltQn2QQ+6wfRdbhwNjV+2cyGZQzfPYANxWo92ALcQ2K+eyRz/XQXru4WLwOX5BBEPzXpmRZleV3c3VHF0haHjD/yOimvya0CA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: * Mark Brown: > +4. Signal handling > +-------------------- > + > +* A new signal frame record gcs_context encodes the current GCS mode and > + pointer for the interrupted context on signal delivery. This will always > + be present on systems that support GCS. > + > +* The record contains a flag field which reports the current GCS configuration > + for the interrupted context as PR_GET_SHADOW_STACK_STATUS would. > + > +* The signal handler is run with the same GCS configuration as the interrupted > + context. > + > +* When GCS is enabled for the interrupted thread a signal handling specific > + GCS cap token will be written to the GCS, this is an architectural GCS cap > + token with bit 63 set and the token type (bits 0..11) all clear. The > + GCSPR_EL0 reported in the signal frame will point to this cap token. How does this marker interfere with Top Byte Ignore (TBI; I hope I got the name right)? The specification currently does not say that only addresses pushed to the shadow stack with the top byte cleared, which potentially makes the markup ambiguous. On x86-64, the same issue may exist with LAM. I have not tested yet what happens there. On AArch64 and RISC-V, it may be more natural to use the LSB instead of the LSB for the mark bit because of its instruction alignment. We also have a gap on x86-64 for backtrace generation because the interrupted instruction address does not end up on the shadow stack. This address is potentially quite interesting for backtrace generation. I assume it's currently missing because the kernel does not resume execution using a regular return instruction. It would be really useful if it could be pushed to the shadow stack, or recoverable from the shadow stack in some other way (e.g., the address of the signal context could be pushed instead). That would need some form of marker as well. Thanks, Florian