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=-3.1 required=5.0 tests=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 4E6DE25670 for ; Thu, 15 Feb 2024 15:06:36 +0100 (CET) Received: (qmail 24432 invoked by uid 550); 15 Feb 2024 14:03:30 -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 24388 invoked from network); 15 Feb 2024 14:03:29 -0000 Date: Thu, 15 Feb 2024 09:06:40 -0500 From: Rich Felker To: Stefan O'Rear Cc: musl@lists.openwall.com, Markus Wichmann , enh Message-ID: <20240215140639.GF4163@brightrain.aerifal.cx> References: <20240212184236.GZ4163@brightrain.aerifal.cx> <20240212224657.GA4163@brightrain.aerifal.cx> <20240213020834.GB4163@brightrain.aerifal.cx> <20240214021925.GC4163@brightrain.aerifal.cx> <82c59be8-6a6e-467e-9383-476660821ca5@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82c59be8-6a6e-467e-9383-476660821ca5@app.fastmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] PAC/BTI Support on aarch64 On Thu, Feb 15, 2024 at 08:29:15AM -0500, Stefan O'Rear wrote: > On Tue, Feb 13, 2024, at 9:19 PM, Rich Felker wrote: > > What is the situation on x86? Does it use the same kind of per-page > > enforcement mode, or is it only global, requiring disabling it if any > > DSO lacks support? Is the endbr64 opcode a guaranteed-safe nop on > > older ISA levels, or does it need to be conditional? > > The situation for hardware control flow hardening on risc-v is two > in-development extensions: > > Zicfilp (landing pads) provides a 4-byte instruction which marks valid > targets for indirect jumps and calls, written `lpad LABEL`. This is > an *architectural NOP at all ISA levels*. Enforcement is > process-global, not per-page. > > Indirect jumps can be exempted from landing pad depending on which > register is used for the address; this is expected to be used if the > address is obtained from read-only memory or an auipc instruction, so > jump tables do not use landing pads, nor are landing pads needed after > direct calls regardless of length. A function which is not a visible > symbol and does not have its address taken does not need a landing pad. > > The ABI function return is a member of the set of indirect jumps > which bypass landing pad checks, so no landing pads are needed at the > return sites of ABI function calls. Zicfilp intentionally does not > provide any protection against ROP, a different extension must be used > to protect return addresses. This all sounds very good and reasonable to support. > Landing pads have a 20-bit label which is expected to be used for a > function type signature, catching function type confusion events. > The hashing scheme used to generate the label from the call signature > has not yet been decided. The call signature must be placed in the > x7/t2 register prior to an indirect jump. The immediate layout is > such that indirect jump sites can use a single lui instruction with > a matching 20-bit immediate. Landing pads do not check x7/t2 if > reached by a direct jump, so there is no need to initialize it prior > to a direct jump. A `lpad 0` matches any incoming type signature. This is very interesting. I wonder if it will break code with UB like: https://github.com/systemd/systemd/blob/d0aef638ac43ad64df920d8b3f6c2d835db7643c/src/basic/sort-util.h It's my belief that it *should* break such code, and that breaking it would be a feature. But I could see folks making the choice to hash just the "mechanical" types rather than actual types, and there may be practical reasons this is what needs to be done. Note that this also has implications for musl and whether we would ever be able to redefine some opaque types. In fact, we already have some types, like pthread_t, which are defined differently in __cplusplus mode to match a name mangling ABI; these would be badly broken. I'm not sure what the right fix for that would be. (Doing that to begin with was almost surely a big mistake.) > Zicfiss (shadow stacks) provides a new shadow stack pointer register > and shadow stack memory which cannot be modified using ordinary stores. > Unlike GCS and SHSTK, the shadow stack is never accessed automatically, > "sspush ra" and "sspopchk ra" instructions must be added to the prologue > and epilogue of functions which spill their return address to the stack. > These instructions are NOPs if the shadow stack is disabled at runtime, > but are *not architectural NOPs* and will trap if executed on current > hardware. > > Also unlike GCS and SHSTK, the Zicfiss `ssp` register can be read and > written from user mode using dedicated instructions, so no special > mechanism is used for shadow stack switching. > > To my knowledge, nothing analogous to PAC is under development. This is unfortunate, since PAC seems a lot less invasive and actually-doable. However, protection equivalent to PAC also seems possible in software, in an entirely arch-agnostic way, with overhead only slightly higher than standard SSP... so I'm not sure why we aren't just pursuing getting compilers to do that rather than chasing arch-specific anti-ROP hacks vendors are trying to use to differentiate themselves and remain relevant in the age of open ISAs... > Both shadow stacks and landing pads are enabled by bits in the senvcfg > register, and are exposed via a prctl. The shadow stack prctl is being > developed as an architecture-independent API, which provides some form > of automatic allocation and deallocation of shadow stacks for threads. > I believe the current strategy for marking CFI support in binaries is > an ELF note similar to the x86 approach, but have not checked this part > in detail. I know this should be written up in more detail, but based on request on IRC, I think it would be good to go ahead and mention "in public" on the list: *** Any API for shadow stacks that involved automatic allocation and deallocation which can fail "behind the application's back" at runtime is a very poor candidate for support by musl. *** To be supported, shadow stacks would probably need to use contiguous memory (with special protections applied to it for the duration of its usage as call stack, with automatic end to that status if it's subsequently accessed with normal loads/stores) with the normal application-provided stack, so as not to break sigaltstack, pthread_setstack, makecontext, etc. and not to introduce memory leaks or conditions under which a behind-the-scenes allocation failure makes hard program termination the only possible result. AFAICT the current shadow stack stuff in the kernel (and maybe the underlying hardware mechanisms) is not usable. Rich