From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id B5BAE25869 for ; Sat, 2 Mar 2024 16:06:39 +0100 (CET) Received: (qmail 32396 invoked by uid 550); 2 Mar 2024 15:02:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32373 invoked from network); 2 Mar 2024 15:02:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709391986; x=1709996786; darn=lists.openwall.com; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qrSAlaPh6y0XeZbwLQygm09FiBVmDsRwj6kIPbpO+ac=; b=DQDdzkIWVWXvtU0DJHGZ3Xb8AeIK+Saz5DVnSOaoCL7FXxHj3AiTFL3TDCCRSGRTVT hgtU3qgXrdCxzW7DnaxjvVzOl5lBgAvMeBrJ/aKDym9Py5NNSiU09hHOSEYseqqRAxaA mEFtppLd1rp60jMJ+E8mBapbiao3k9ltwgIHFbA3c5vXKaZ0tMw6eKRYaoWX5MHLSLZh XF0wbdqY7DEW+E4Ac0j2NPkS9aKQDteQTrL3EduIjwEbNzAGRvVIyLHbsihdo92bhouc 6Pv+I7nebw0R4mq0nDkYQRg4lqfWVVns5wRg4WXxIGTrhNLqe0JIVwv6uVdw8u6oarVw Pwvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709391986; x=1709996786; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qrSAlaPh6y0XeZbwLQygm09FiBVmDsRwj6kIPbpO+ac=; b=KdAwhSp9+Lt6wC7as66bMrk/pgTsK+JOalDcHcrAwbrUgZr4107xGq6MfCmcB5Dz9Y PPHpTs5yvPUec2SUrA+vXQsJPpDpoYtjjpw+gBFsx+HakLii5Jm8v/6uuhgQu3j/Gyyd 6HVjGZJyPbZY/aPihIH7nrLD5BvbArPbhpZrLG71WpusbV2sBfxlvqOaDFYjEL3zjS1b lWNLlyGD2NGrUVMCRS2mSN0dLuxKVuUvRD/AFxHjlN60zBzffrzXuQJUTHmA5aN+uH+J fsPI8PS9DwM4uBUzmCYP/J+u6rbEgz+n+LkIoRXCBvicbfGm8tL91vlAGFa9vAHg6Kdv qmkQ== X-Forwarded-Encrypted: i=1; AJvYcCVu7Xdook0ENvOQGLvXUacu4z2cBGCp1k3LKRqUzOzlrjN1t7rc4TIXaRmUjThsHTHowhhkRlt3swv3KFBhWKRRs/9rxRl7Nw== X-Gm-Message-State: AOJu0YyQUPidJ/hk127G+KN8BA4pRxh1GCliJbpkMeD6blIakkTWyafo nIsjpD5r8xOAUa3NEhGBvzZKr7oucMMPNuEmhPf4qr2/Ptcn3vujqxOK8yQHhF7HVOgj24VOzHQ UXv0NxsMVbHosPvib9hwgapyNydE= X-Google-Smtp-Source: AGHT+IEaoJ0EIEJMr1Auv9LAe6hd3ruRGKQaWswy7UXoWRUhb+BsZa3cljQHfsjmVp7ROvTWXxlriSX3h2quvblOfsc= X-Received: by 2002:a81:6f03:0:b0:608:7a9c:9a82 with SMTP id k3-20020a816f03000000b006087a9c9a82mr4546852ywc.47.1709391985893; Sat, 02 Mar 2024 07:06:25 -0800 (PST) MIME-Version: 1.0 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> <20240302145702.GD1884416@port70.net> In-Reply-To: <20240302145702.GD1884416@port70.net> From: "H.J. Lu" Date: Sat, 2 Mar 2024 07:05:49 -0800 Message-ID: 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" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Re: [PATCH v8 00/38] arm64/gcs: Provide support for GCS in userspace On Sat, Mar 2, 2024 at 6:57=E2=80=AFAM Szabolcs Nagy wrote= : > > * 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 disabl= ed, > > > > > > these suddenly turn into #UD generating instructions. So any ot= her > > > > > > threads executing those instructions when shadow stack got disa= bled > > > > > > 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 sta= ck > > > > > has been disabled, not generating SIGILL. > > > > > > I'm not sure that's going to work out well, all it takes is some co= de > > > > that's looking at the shadow stack and expecting something to happe= n 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. On Linux/x86, normal instructions are used to update SSP after checking SHSTK is enabled. If SHSTK is disabled in between, program behavior may be undefined. --=20 H.J.