From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from port70.net (port70.net [81.7.13.123]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 58EEF29AB for ; Sat, 2 Mar 2024 15:03:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=81.7.13.123 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709391795; cv=none; b=AMYLg8N/4qrCqPw9ORGMPbZKu1LN5Sj6BdazhNyb8woUDMZAxjiSGspc+v8Ui5RMNu2eaLVacXZ2tLjjPjQqXlyMefomQ8Xw6+cuV1pk4Ut+2CirNqFKLMNypLKrk0898DM233sZizazGYmzwPN1393SOHfw9oXfc8Y9s3JemcU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709391795; c=relaxed/simple; bh=F+Ft9ySflUOsjYRoTJD/SuxsOSEZzbIMaYW9w/glpJY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a0bMNapnZQa0/quYl7TDYybdZwf7CKj/0H0By6h7DqP9XawkWoSR+aIAMtq+XjSHGR1rjjEv7UbIHlii3pDBhvTZ+9nv5StBR3EHYqegB8MTHSfmLOJ6yzI5bt7hKDvjcTu39UnB1emDFSOJCsxwqSL1njDZSzUwlJnIcGug/gA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=port70.net; spf=pass smtp.mailfrom=port70.net; arc=none smtp.client-ip=81.7.13.123 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=port70.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=port70.net Received: by port70.net (Postfix, from userid 1002) id 691CEABEC0C7; Sat, 2 Mar 2024 15:57:02 +0100 (CET) Date: Sat, 2 Mar 2024 15:57:02 +0100 From: Szabolcs Nagy To: Mark Brown Cc: "dalias@libc.org" , "Edgecombe, Rick P" , "linux-arch@vger.kernel.org" , "suzuki.poulose@arm.com" , "Szabolcs.Nagy@arm.com" , "musl@lists.openwall.com" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "kvmarm@lists.linux.dev" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "oliver.upton@linux.dev" , "palmer@dabbelt.com" , "debug@rivosinc.com" , "aou@eecs.berkeley.edu" , "shuah@kernel.org" , "arnd@arndb.de" , "maz@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "james.morse@arm.com" , "ebiederm@xmission.com" , "will@kernel.org" , "brauner@kernel.org" , "hjl.tools@gmail.com" , "linux-kselftest@vger.kernel.org" , "paul.walmsley@sifive.com" , "ardb@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , "thiago.bauermann@linaro.org" , "akpm@linux-foundation.org" , "sorear@fastmail.com" , "linux-doc@vger.kernel.org" Subject: Re: [musl] Re: [PATCH v8 00/38] arm64/gcs: Provide support for GCS in userspace Message-ID: <20240302145702.GD1884416@port70.net> Mail-Followup-To: Mark Brown , "dalias@libc.org" , "Edgecombe, Rick P" , "linux-arch@vger.kernel.org" , "suzuki.poulose@arm.com" , "Szabolcs.Nagy@arm.com" , "musl@lists.openwall.com" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "kvmarm@lists.linux.dev" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "oliver.upton@linux.dev" , "palmer@dabbelt.com" , "debug@rivosinc.com" , "aou@eecs.berkeley.edu" , "shuah@kernel.org" , "arnd@arndb.de" , "maz@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "james.morse@arm.com" , "ebiederm@xmission.com" , "will@kernel.org" , "brauner@kernel.org" , "hjl.tools@gmail.com" , "linux-kselftest@vger.kernel.org" , "paul.walmsley@sifive.com" , "ardb@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , "thiago.bauermann@linaro.org" , "akpm@linux-foundation.org" , "sorear@fastmail.com" , "linux-doc@vger.kernel.org" References: <22a53b78-10d7-4a5a-a01e-b2f3a8c22e94@app.fastmail.com> <4c7bdf8fde9cc45174f10b9221fa58ffb450b755.camel@intel.com> <20240220185714.GO4163@brightrain.aerifal.cx> <9fc9c45ff6e14df80ad023e66ff7a978bd4ec91c.camel@intel.com> <20240220235415.GP4163@brightrain.aerifal.cx> <20240221012736.GQ4163@brightrain.aerifal.cx> <20240221145800.GR4163@brightrain.aerifal.cx> <4a3809e8-61b2-4341-a868-292ba6e64e8a@sirena.org.uk> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a3809e8-61b2-4341-a868-292ba6e64e8a@sirena.org.uk> * Mark Brown [2024-02-21 17:36:12 +0000]: > On Wed, Feb 21, 2024 at 09:58:01AM -0500, dalias@libc.org wrote: > > On Wed, Feb 21, 2024 at 01:53:10PM +0000, Mark Brown wrote: > > > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dalias@libc.org wrote: > > > > On Wed, Feb 21, 2024 at 12:35:48AM +0000, Edgecombe, Rick P wrote: > > > > > > (INCSSP, RSTORSSP, etc). These are a collection of instructions that > > > > > allow limited control of the SSP. When shadow stack gets disabled, > > > > > these suddenly turn into #UD generating instructions. So any other > > > > > threads executing those instructions when shadow stack got disabled > > > > > would be in for a nasty surprise. > > > > > This is the kernel's problem if that's happening. It should be > > > > trapping these and returning immediately like a NOP if shadow stack > > > > has been disabled, not generating SIGILL. > > > > I'm not sure that's going to work out well, all it takes is some code > > > that's looking at the shadow stack and expecting something to happen as > > > a result of the instructions it's executing and we run into trouble. A > > > I said NOP but there's no reason it strictly needs to be a NOP. It > > could instead do something reasonable to convey the state of racing > > with shadow stack being disabled. > > This feels like it's getting complicated and I fear it may be an uphill > struggle to get such code merged, at least for arm64. My instinct is the aarch64 behaviour is already nop for gcs instructions when gcs is disabled. the isa was designed so async disable is possible. only x86 linux would have to emulate this. > that it's going to be much more robust and generally tractable to let > things run to some suitable synchronisation point and then disable > there, but if we're going to do that then userspace can hopefully > arrange to do the disabling itself through the standard disable > interface anyway. Presumably it'll want to notice things being disabled > at some point anyway? TBH that's been how all the prior proposals for > process wide disable I've seen were done. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A1311C5478C for ; Sat, 2 Mar 2024 15:03:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZsUMHh4D13hFdwu5tDewEWWQH4UmOyZFrARNSxK0j3Q=; b=obkFjjZcmk4N5f v0yH4XN6gdjpulq7afqPIs5Btlko7YuWk6JF2L25mmjSoJBBNaXTL5EFYZgUZRUPSy7C2sn/FPFfC Vyna+5jR6FYNYREWjoc3vOanzSEGyIMkUsWXx47YpynMP9E8ykZ+WEMzBVfAMK44J3Uz8kTp9kRsx qDcCTf1dtDnEHf+CY90ihTM8gSR8ZdxXQauzhi78PMLAgdqSCCfWzNf/T38Uv9TNLUOWVXtkuRE2B gJxUk12ypF8Nnl1xMpnH+N668vDSFceU1ntt5WlX3tr8IGmxs9wp/5ou9ah69pFxZGOdAY8d0cofQ eL/QjyY0Tb8Bv3emZkJw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rgQtY-00000003nM3-1QnO; Sat, 02 Mar 2024 15:03:24 +0000 Received: from port70.net ([81.7.13.123]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rgQtT-00000003nHr-2L2j; Sat, 02 Mar 2024 15:03:21 +0000 Received: by port70.net (Postfix, from userid 1002) id 691CEABEC0C7; Sat, 2 Mar 2024 15:57:02 +0100 (CET) Date: Sat, 2 Mar 2024 15:57:02 +0100 From: Szabolcs Nagy To: Mark Brown Cc: "dalias@libc.org" , "Edgecombe, Rick P" , "linux-arch@vger.kernel.org" , "suzuki.poulose@arm.com" , "Szabolcs.Nagy@arm.com" , "musl@lists.openwall.com" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "kvmarm@lists.linux.dev" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "oliver.upton@linux.dev" , "palmer@dabbelt.com" , "debug@rivosinc.com" , "aou@eecs.berkeley.edu" , "shuah@kernel.org" , "arnd@arndb.de" , "maz@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "james.morse@arm.com" , "ebiederm@xmission.com" , "will@kernel.org" , "brauner@kernel.org" , "hjl.tools@gmail.com" , "linux-kselftest@vger.kernel.org" , "paul.walmsley@sifive.com" , "ardb@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , "thiago.bauermann@linaro.org" , "akpm@linux-foundation.org" , "sorear@fastmail.com" , "linux-doc@vger.kernel.org" Subject: Re: [musl] Re: [PATCH v8 00/38] arm64/gcs: Provide support for GCS in userspace Message-ID: <20240302145702.GD1884416@port70.net> Mail-Followup-To: Mark Brown , "dalias@libc.org" , "Edgecombe, Rick P" , "linux-arch@vger.kernel.org" , "suzuki.poulose@arm.com" , "Szabolcs.Nagy@arm.com" , "musl@lists.openwall.com" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "kvmarm@lists.linux.dev" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "oliver.upton@linux.dev" , "palmer@dabbelt.com" , "debug@rivosinc.com" , "aou@eecs.berkeley.edu" , "shuah@kernel.org" , "arnd@arndb.de" , "maz@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "james.morse@arm.com" , "ebiederm@xmission.com" , "will@kernel.org" , "brauner@kernel.org" , "hjl.tools@gmail.com" , "linux-kselftest@vger.kernel.org" , "paul.walmsley@sifive.com" , "ardb@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , "thiago.bauermann@linaro.org" , "akpm@linux-foundation.org" , "sorear@fastmail.com" , "linux-doc@vger.kernel.org" References: <22a53b78-10d7-4a5a-a01e-b2f3a8c22e94@app.fastmail.com> <4c7bdf8fde9cc45174f10b9221fa58ffb450b755.camel@intel.com> <20240220185714.GO4163@brightrain.aerifal.cx> <9fc9c45ff6e14df80ad023e66ff7a978bd4ec91c.camel@intel.com> <20240220235415.GP4163@brightrain.aerifal.cx> <20240221012736.GQ4163@brightrain.aerifal.cx> <20240221145800.GR4163@brightrain.aerifal.cx> <4a3809e8-61b2-4341-a868-292ba6e64e8a@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4a3809e8-61b2-4341-a868-292ba6e64e8a@sirena.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240302_070319_783299_B2373C76 X-CRM114-Status: GOOD ( 26.16 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org * Mark Brown [2024-02-21 17:36:12 +0000]: > On Wed, Feb 21, 2024 at 09:58:01AM -0500, dalias@libc.org wrote: > > On Wed, Feb 21, 2024 at 01:53:10PM +0000, Mark Brown wrote: > > > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dalias@libc.org wrote: > > > > On Wed, Feb 21, 2024 at 12:35:48AM +0000, Edgecombe, Rick P wrote: > > > > > > (INCSSP, RSTORSSP, etc). These are a collection of instructions that > > > > > allow limited control of the SSP. When shadow stack gets disabled, > > > > > these suddenly turn into #UD generating instructions. So any other > > > > > threads executing those instructions when shadow stack got disabled > > > > > would be in for a nasty surprise. > > > > > This is the kernel's problem if that's happening. It should be > > > > trapping these and returning immediately like a NOP if shadow stack > > > > has been disabled, not generating SIGILL. > > > > I'm not sure that's going to work out well, all it takes is some code > > > that's looking at the shadow stack and expecting something to happen as > > > a result of the instructions it's executing and we run into trouble. A > > > I said NOP but there's no reason it strictly needs to be a NOP. It > > could instead do something reasonable to convey the state of racing > > with shadow stack being disabled. > > This feels like it's getting complicated and I fear it may be an uphill > struggle to get such code merged, at least for arm64. My instinct is the aarch64 behaviour is already nop for gcs instructions when gcs is disabled. the isa was designed so async disable is possible. only x86 linux would have to emulate this. > that it's going to be much more robust and generally tractable to let > things run to some suitable synchronisation point and then disable > there, but if we're going to do that then userspace can hopefully > arrange to do the disabling itself through the standard disable > interface anyway. Presumably it'll want to notice things being disabled > at some point anyway? TBH that's been how all the prior proposals for > process wide disable I've seen were done. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3C63AC54798 for ; Sat, 2 Mar 2024 15:03:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=G6xO9oIwzfM0RJITMXc636w1jfAwsyMHVt0M/qxAUIU=; b=S8gQh0+g7z4it5 3xHSnFJZ3nToRPLXsKmTsAWnkj4rJVllwWpz0J9VZe1p5cHUhMuwfIwT4z82gyxXkCZuVf19htHyE VOkrICnZ13ARoLsYJuXU65srJZTvaT+Nql84UgKgMjRqK9cd97XMeIdio/E0rFIt5B+DtWdxwy0jy BqtNuOcgF201HP9IstZVMYzn/RqqdzULK2qR6TaA2sFkJTzsNZajGbisgN3jBVC+ny7sM0Y/Q/dXB qo+vxBs6KooK7hTjvOybr0x1agRFs1sdN2PLWhxyt3Oz53iYWotiVd3w4h/7YQaP3Lauy0zX1MAi+ nNfHFGGJhjO8wFRayNvg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rgQtX-00000003nLO-1iFR; Sat, 02 Mar 2024 15:03:23 +0000 Received: from port70.net ([81.7.13.123]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rgQtT-00000003nHr-2L2j; Sat, 02 Mar 2024 15:03:21 +0000 Received: by port70.net (Postfix, from userid 1002) id 691CEABEC0C7; Sat, 2 Mar 2024 15:57:02 +0100 (CET) Date: Sat, 2 Mar 2024 15:57:02 +0100 From: Szabolcs Nagy To: Mark Brown Cc: "dalias@libc.org" , "Edgecombe, Rick P" , "linux-arch@vger.kernel.org" , "suzuki.poulose@arm.com" , "Szabolcs.Nagy@arm.com" , "musl@lists.openwall.com" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "kvmarm@lists.linux.dev" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "oliver.upton@linux.dev" , "palmer@dabbelt.com" , "debug@rivosinc.com" , "aou@eecs.berkeley.edu" , "shuah@kernel.org" , "arnd@arndb.de" , "maz@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "james.morse@arm.com" , "ebiederm@xmission.com" , "will@kernel.org" , "brauner@kernel.org" , "hjl.tools@gmail.com" , "linux-kselftest@vger.kernel.org" , "paul.walmsley@sifive.com" , "ardb@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , "thiago.bauermann@linaro.org" , "akpm@linux-foundation.org" , "sorear@fastmail.com" , "linux-doc@vger.kernel.org" Subject: Re: [musl] Re: [PATCH v8 00/38] arm64/gcs: Provide support for GCS in userspace Message-ID: <20240302145702.GD1884416@port70.net> Mail-Followup-To: Mark Brown , "dalias@libc.org" , "Edgecombe, Rick P" , "linux-arch@vger.kernel.org" , "suzuki.poulose@arm.com" , "Szabolcs.Nagy@arm.com" , "musl@lists.openwall.com" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "kvmarm@lists.linux.dev" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "oliver.upton@linux.dev" , "palmer@dabbelt.com" , "debug@rivosinc.com" , "aou@eecs.berkeley.edu" , "shuah@kernel.org" , "arnd@arndb.de" , "maz@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "james.morse@arm.com" , "ebiederm@xmission.com" , "will@kernel.org" , "brauner@kernel.org" , "hjl.tools@gmail.com" , "linux-kselftest@vger.kernel.org" , "paul.walmsley@sifive.com" , "ardb@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , "thiago.bauermann@linaro.org" , "akpm@linux-foundation.org" , "sorear@fastmail.com" , "linux-doc@vger.kernel.org" References: <22a53b78-10d7-4a5a-a01e-b2f3a8c22e94@app.fastmail.com> <4c7bdf8fde9cc45174f10b9221fa58ffb450b755.camel@intel.com> <20240220185714.GO4163@brightrain.aerifal.cx> <9fc9c45ff6e14df80ad023e66ff7a978bd4ec91c.camel@intel.com> <20240220235415.GP4163@brightrain.aerifal.cx> <20240221012736.GQ4163@brightrain.aerifal.cx> <20240221145800.GR4163@brightrain.aerifal.cx> <4a3809e8-61b2-4341-a868-292ba6e64e8a@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4a3809e8-61b2-4341-a868-292ba6e64e8a@sirena.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240302_070319_783299_B2373C76 X-CRM114-Status: GOOD ( 26.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org * Mark Brown [2024-02-21 17:36:12 +0000]: > On Wed, Feb 21, 2024 at 09:58:01AM -0500, dalias@libc.org wrote: > > On Wed, Feb 21, 2024 at 01:53:10PM +0000, Mark Brown wrote: > > > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dalias@libc.org wrote: > > > > On Wed, Feb 21, 2024 at 12:35:48AM +0000, Edgecombe, Rick P wrote: > > > > > > (INCSSP, RSTORSSP, etc). These are a collection of instructions that > > > > > allow limited control of the SSP. When shadow stack gets disabled, > > > > > these suddenly turn into #UD generating instructions. So any other > > > > > threads executing those instructions when shadow stack got disabled > > > > > would be in for a nasty surprise. > > > > > This is the kernel's problem if that's happening. It should be > > > > trapping these and returning immediately like a NOP if shadow stack > > > > has been disabled, not generating SIGILL. > > > > I'm not sure that's going to work out well, all it takes is some code > > > that's looking at the shadow stack and expecting something to happen as > > > a result of the instructions it's executing and we run into trouble. A > > > I said NOP but there's no reason it strictly needs to be a NOP. It > > could instead do something reasonable to convey the state of racing > > with shadow stack being disabled. > > This feels like it's getting complicated and I fear it may be an uphill > struggle to get such code merged, at least for arm64. My instinct is the aarch64 behaviour is already nop for gcs instructions when gcs is disabled. the isa was designed so async disable is possible. only x86 linux would have to emulate this. > that it's going to be much more robust and generally tractable to let > things run to some suitable synchronisation point and then disable > there, but if we're going to do that then userspace can hopefully > arrange to do the disabling itself through the standard disable > interface anyway. Presumably it'll want to notice things being disabled > at some point anyway? TBH that's been how all the prior proposals for > process wide disable I've seen were done. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel