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 80947C48BC3 for ; Tue, 20 Feb 2024 20:32:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DCAF56B007B; Tue, 20 Feb 2024 15:32:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D7B136B007E; Tue, 20 Feb 2024 15:32:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1C0D6B0080; Tue, 20 Feb 2024 15:32:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id AF83C6B007B for ; Tue, 20 Feb 2024 15:32:53 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4C3D7A087C for ; Tue, 20 Feb 2024 20:32:53 +0000 (UTC) X-FDA: 81813331026.18.8848B1B Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [104.156.224.86]) by imf08.hostedemail.com (Postfix) with ESMTP id 74C37160011 for ; Tue, 20 Feb 2024 20:32:51 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of dalias@libc.org designates 104.156.224.86 as permitted sender) smtp.mailfrom=dalias@libc.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708461171; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6mM33Jkn1BipsBWTmgMAWz6Dc1aKF1QRK2SYMEn5EW0=; b=iW2aqY92p/Vi4pi3YzSobB/y1abmdSHe1wUzR3wi7K9aDzw5AJWgYh5qRx9EirYLexuLgB D9Y8LKU30EndJX8kGjPY6JLEdyVhvbPkAgU7PaFMhYlavhj9jU0Tgh7BEz03I54vrlR86Y Lha1Nx+cq5YAi4adtCbBFUzz6UkgvJ0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708461171; a=rsa-sha256; cv=none; b=D7QOjzQ0NXJrqmvRj7ZzlCLaMIP1tbnCLuTtumbVu+jJj/wRAQwxpK0HBzDyUHnv7qrCGy S+ldi8TZiR0/fAKW7H72tm6YwdicrwgKJAjTmuZ8rLrgxoSgbKR1C8YmtC8t+JKZ4Su/6U ITcD6k7HACZ7/Acg4jKKQrB1Mr45ZQI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of dalias@libc.org designates 104.156.224.86 as permitted sender) smtp.mailfrom=dalias@libc.org; dmarc=none Date: Tue, 20 Feb 2024 13:57:15 -0500 From: Rich Felker To: "Edgecombe, Rick P" Cc: "corbet@lwn.net" , "ardb@kernel.org" , "maz@kernel.org" , "shuah@kernel.org" , "Szabolcs.Nagy@arm.com" , "keescook@chromium.org" , "james.morse@arm.com" , "debug@rivosinc.com" , "akpm@linux-foundation.org" , "catalin.marinas@arm.com" , "oleg@redhat.com" , "arnd@arndb.de" , "ebiederm@xmission.com" , "will@kernel.org" , "suzuki.poulose@arm.com" , "sorear@fastmail.com" , "oliver.upton@linux.dev" , "broonie@kernel.org" , "brauner@kernel.org" , "fweimer@redhat.com" , "aou@eecs.berkeley.edu" , "linux-kernel@vger.kernel.org" , "paul.walmsley@sifive.com" , "hjl.tools@gmail.com" , "linux-mm@kvack.org" , "palmer@dabbelt.com" , "kvmarm@lists.linux.dev" , "linux-arch@vger.kernel.org" , "thiago.bauermann@linaro.org" , "linux-doc@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kselftest@vger.kernel.org" , "musl@lists.openwall.com" , "linux-riscv@lists.infradead.org" Subject: Re: [musl] Re: [PATCH v8 00/38] arm64/gcs: Provide support for GCS in userspace Message-ID: <20240220185714.GO4163@brightrain.aerifal.cx> References: <20240203-arm64-gcs-v8-0-c9fec77673ef@kernel.org> <22a53b78-10d7-4a5a-a01e-b2f3a8c22e94@app.fastmail.com> <4c7bdf8fde9cc45174f10b9221fa58ffb450b755.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4c7bdf8fde9cc45174f10b9221fa58ffb450b755.camel@intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Stat-Signature: bfzacistutoekm5zy9hystef7j3p9kro X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 74C37160011 X-Rspam-User: X-HE-Tag: 1708461171-432771 X-HE-Meta: U2FsdGVkX18Is/V5jqdwGZ/do9YFXKqDDHh5cYcykh8dx7HHjqIBAKkagZsp+CqSXzXsE6epYISfXjjFcleBAtljxU+Y6086NAG+goGVGdMIQmdT+LmeXZ4DVnhU/Agov+i1IOjysWncNeCRqNDNIMB90N0BbFVw6aGpqEZaS/n365LKmP+jgiu2hFEP4UDRhsRPhX4Wya5BhixKpbiSdUTsUcQ1GWsODFyn2mz8Bc/+e8B2WLqBr2YcWWpb3y7R4smKZgKFnvaVXPLP0hAdI5y3OAfgmMQOaIOn+5n42LFRRcM+ZLQDArMkhEfSX1d21rVXqnlAD44szJS3S+uzAptdjEBv/r6/gsYR3uH4D8YqN8dGtazJ665IK7jKePkSaTZUwMP9trWiyYevSPIObBQ+YezIMV/4kb4pFeMcS/Us9viBzPhhUBsNCCB/rGVK0nHqrfCc0hHkqrZbiiV4zAJE8plbzUKrOosZvLlDAx++kmplyrv7vzSz7PrVYjW8WVr2QqR5raG6oeRPwKAvREBgOChpOWU/kr6v21M/mzyx2AZiml+I+Jd1DD86dmyNwpklcigk9DcaIis0/VnXpFT+cY0UHZJXPF8CaAbFBhQaC8OkXXP7cxRBvy6gUGmnDgZxatPjzHnSbt6ctg4ohF36rRWm7rDsa97fBZ09F3Kaibwuh25PNPPfIeBxdtbwAt4DZCf2pjym8bh6BJl61IzCBnhgE7MpZUqgNiIdgqYXtP+Q0PE1/VxP2pBk71iQk7U/LYprPuxTAZ1dt9UOvwaE4K6zC5R+oSs0Dz/cIGWGfxS7uIuH3o4oYH+RS47YSUFRSZ02woMvlzEUj5ePWhdU96vRhhQni5xfCd6EdFvVlouuF86CG7VkLTDedIMHvx26PkvyQhba5QU0i1JhCacKr2GzbHbNAzOo0B61uLseP5JREzcO9AmF3ikpCIJHYCSdLn2ny6RgsDy5D+Z Dc78Ku75 T987dZ/C3CnZQM8a91RJNBr4fk9MXNtvgDSIB 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: On Tue, Feb 20, 2024 at 06:41:05PM +0000, Edgecombe, Rick P wrote: > Hi, > > I worked on the x86 kernel shadow stack support. I think it is an > interesting suggestion. Some questions below, and I will think more on > it. > > On Tue, 2024-02-20 at 11:36 -0500, Stefan O'Rear wrote: > > While discussing the ABI implications of shadow stacks in the context > > of > > Zicfiss and musl a few days ago, I had the following idea for how to > > solve > > the source compatibility problems with shadow stacks in POSIX.1-2004 > > and > > POSIX.1-2017: > > > > 1. Introduce a "flexible shadow stack handling" option.  For what > > follows, > >    it doesn't matter if this is system-wide, per-mm, or per-vma. > > > > 2. Shadow stack faults on non-shadow stack pages, if flexible shadow > > stack > >    handling is in effect, cause the affected page to become a shadow > > stack > >    page.  When this happens, the page filled with invalid address > > tokens. > > Hmm, could the shadow stack underflow onto the real stack then? Not > sure how bad that is. INCSSP (incrementing the SSP register on x86) > loops are not rare so it seems like something that could happen. Shadow stack underflow should fault on attempt to access non-shadow-stack memory as shadow-stack, no? > >    Faults from non-shadow-stack accesses to a shadow-stack page which > > was > >    created by the previous paragraph will cause the page to revert to > >    non-shadow-stack usage, with or without clearing. > > Won't this prevent catching stack overflows when they happen? An > overflow will just turn the shadow stack into normal stack and only get > detected when the shadow stack unwinds? I don't think that's as big a problem as it sounds like. It might make pinpointing the spot at which things went wrong take a little bit more work, but it should not admit any wrong-execution. > A related question would be how to handle the expanding nature of the > initial stack. I guess the initial stack could be special and have a > separate shadow stack. That seems fine. > >    Important: a shadow stack operation can only load a valid address > > from > >    a page if that page has been in continuous shadow stack use since > > the > >    address was written by another shadow stack operation; the > > flexibility > >    delays error reporting in cases of stray writes but it never > > allows for > >    corruption of shadow stack operation. > > Shadow stacks currently have automatic guard gaps to try to prevent one > thread from overflowing onto another thread's shadow stack. This would > somewhat opens that up, as the stack guard gaps are usually maintained > by userspace for new threads. It would have to be thought through if > these could still be enforced with checking at additional spots. I would think the existing guard pages would already do that if a thread's shadow stack is contiguous with its own data stack. > > 3. Standards-defined operations which use a user-provided stack > >    (makecontext, sigaltstack, pthread_attr_setstack) use a subrange > > of the > >    provided stack for shadow stack storage.  I propose to use a > > shadow > >    stack size of 1/32 of the provided stack size, rounded up to a > > positive > >    integer number of pages, and place the shadow stack allocation at > > the > >    lowest page-aligned address inside the provided stack region. > > > >    Since page usage is flexible, no change in page permissions is > >    immediately needed; this merely sets the initial shadow stack > > pointer for > >    the new context. > > > >    If the shadow stack grew in the opposite direction to the > > architectural > >    stack, it would not be necessary to pick a fixed direction. > > > > 4. SIGSTKSZ and MINSIGSTKSZ are increased by 2 pages to provide > > sufficient > >    space for a minimum-sized shadow stack region and worst case > > alignment. > > Do all makecontext() callers ensure the size is greater than this? > > I guess glibc's makecontext() could do this scheme to prevent leaking > without any changes to the kernel. Basically steal a little of the > stack address range and overwrite it with a shadow stack mapping. But > only if the apps leave enough room. If they need to be updated, then > they could be updated to manage their own shadow stacks too I think. >From the musl side, I have always looked at the entirely of shadow stack stuff with very heavy skepticism, and anything that breaks existing interface contracts, introduced places where apps can get auto-killed because a late resource allocation fails, or requires applications to code around the existence of something that should be an implementation detail, is a non-starter. To even consider shadow stack support, it must truely be fully non-breaking. > > _Without_ doing this, sigaltstack cannot be used to recover from > > stack > > overflows if the shadow stack limit is reached first, and makecontext > > cannot be supported without memory leaks and unreportable error > > conditions. > > FWIW, I think the makecontext() shadow stack leaking is a bad idea. I > would prefer the existing makecontext() interface just didn't support > shadow stack, rather than the leaking solution glibc does today. AIUI the proposal by Stefan makes it non-leaking because it's just using normal memory that reverts to normal usage on any non-shadow-stack access. Rich