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.9 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, 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 266C02C6F0 for ; Wed, 21 Feb 2024 21:19:27 +0100 (CET) Received: (qmail 23623 invoked by uid 550); 21 Feb 2024 20:16:04 -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 23565 invoked from network); 21 Feb 2024 20:16:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708546753; x=1709151553; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dC0/jGGGg/HFaRyL81RjL7rrIVZv2xHBQs/cZSwhbtU=; b=FxM+7Pk/2oast/IJrSw/jrCpg20nKTluIsUHjhQBX875a3hjCczX6DD1HoXzjja9IZ Vzsep0FNdNZNQUxbdYAVO59x4qJqnOxx3AlBUgakZoptGKdk4fnNHodVgoenBMcGUrr6 9fn6OAGYbwugyJq4KWJiAB/A82zRFilJpXh9tYk+45S1pGNmQ7kXrRc8M/AS3vGL6dWw vW2aapAMjoGk/ovQYaDo8k1zO2cFoOEfPCLxDYCGiXk5ekq0eb+E138Z89JyBOFOoe9H M+1mDskSracdXMBuoKRzFvHwAZLEdS7vGpkXRH0aGFIwlsS6GCBhtRE5CKztO1tBgBam 7Flg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708546753; x=1709151553; h=content-transfer-encoding:cc: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=dC0/jGGGg/HFaRyL81RjL7rrIVZv2xHBQs/cZSwhbtU=; b=Irr9R0EUjuZZCtWMzYkgZM9/UsrhpQsUgUFiSAFo9yg3klLMjztkeHI+h+hwt5DCqq +m201WfIJ4DrBjIFa2/11j7SlRoId2ioQZtg6HbQa5ulEiddCI6Zgq+S4isIxm9hHZUc sTHpxB+tE0Y+MlseIUjmGxoQ6xHrxMlZzHneaSeoGRz8YtpBZUvOuoa+C7f0Uzjdnp3Q yCXGdNIG5PtboUvOYEHJGSwUhJnOSNpFjYcnhX7/Y9eq3rtCQbjsjs4559RFEtyWnnq6 C2A1UhHjC33EOTaJzcnPx3ddyYWwD0A0RzPLgd0MrnL5P3ISFfrU02KP6MspbsRzzobo kjdQ== X-Forwarded-Encrypted: i=1; AJvYcCX67oc/JfFB/TfN0QEAe/k3wE8vMnApCpKNghh0cjwPT73FoqS5qiKquzdrm8DbC0801G4/o5ODSoKdgTNtdARsrtcASHg1jQ== X-Gm-Message-State: AOJu0Yx0IE8xMBYdbr9l5VLe4XFXW1PUbFbiJAkEGddRlSccBvwr3FOA nUfFuNRN1Nyq63uDgSVg74eYa1xuLd36NZq4jAn/Y+CfZCE/DbGdZDOh2DhrzL2XWVdZL6GYGDr q0mEBg4TkLptR87sm/iyZ3jvWM3s= X-Google-Smtp-Source: AGHT+IH3LQerluMYb9fAN1mFFrYm7uBDz1sUFvXpU3AHFaytahksdyc6iEy7q2HkrUujPZEoOh6XClpzAjLcebGmCEk= X-Received: by 2002:a25:a543:0:b0:dc7:497e:cddf with SMTP id h61-20020a25a543000000b00dc7497ecddfmr380363ybi.33.1708546753425; Wed, 21 Feb 2024 12:19:13 -0800 (PST) MIME-Version: 1.0 References: <20240220235415.GP4163@brightrain.aerifal.cx> <20240221012736.GQ4163@brightrain.aerifal.cx> <20240221145800.GR4163@brightrain.aerifal.cx> <4a3809e8-61b2-4341-a868-292ba6e64e8a@sirena.org.uk> <20240221175717.GS4163@brightrain.aerifal.cx> <20240221183055.GT4163@brightrain.aerifal.cx> <20240221190639.GU4163@brightrain.aerifal.cx> In-Reply-To: From: "H.J. Lu" Date: Wed, 21 Feb 2024 12:18:37 -0800 Message-ID: To: "Edgecombe, Rick P" Cc: "dalias@libc.org" , "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" , "broonie@kernel.org" , "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" , "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 Wed, Feb 21, 2024 at 11:22=E2=80=AFAM Edgecombe, Rick P wrote: > > On Wed, 2024-02-21 at 14:06 -0500, dalias@libc.org wrote: > > Due to arbitrarily nestable signal frames, no, this does not suffice. > > An interrupted operation using the lock could be arbitrarily delayed, > > even never execute again, making any call to dlopen deadlock. > > Doh! Yep, it is not robust to this. The only thing that could be done > would be a timeout in dlopen(). Which would make the whole thing just > better than nothing. > > > > > > > > > > It's fine to turn RDSSP into an actual emulated read of the SSP, or > > at > > least an emulated load of zero so that uninitialized data is not left > > in the target register. > > We can't intercept RDSSP, but it becomes a NOP by default. (disclaimer > x86-only knowledge). > > > If doing the latter, code working with the > > shadow stack just needs to be prepared for the possibility that it > > could be async-disabled, and check the return value. > > > > I have not looked at all the instructions that become #UD but I > > suspect they all have reasonable trivial ways to implement a > > "disabled" version of them that userspace can act upon reasonably. > > This would have to be thought through functionally and performance > wise. I'm not opposed if can come up with a fully fleshed out plan. How > serious are you in pursuing musl support, if we had something like > this? > > HJ, any thoughts on whether glibc would use this as well? Assuming that we are talking about permissive mode, if kernel can suppress UD, we don't need to disable SHSTK. Glibc can enable ARCH_SHSTK_SUPPRESS_UD instead. > It is probably worth mentioning that from the security side (as Mark > mentioned there is always tension in the tradeoffs on these features), > permissive mode is seen by some as something that weakens security too > much. Apps could call dlopen() on a known unsupported DSO before doing > ROP. I don't know if you have any musl users with specific shadow stack > use cases to ask about this. --=20 H.J.