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_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 D3785238AD for ; Thu, 15 Feb 2024 14:30:26 +0100 (CET) Received: (qmail 5532 invoked by uid 550); 15 Feb 2024 13:27:19 -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 5488 invoked from network); 15 Feb 2024 13:27:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1708003812; x=1708090212; bh=PIqhWv+qHn DsrpNtI3ZyjC3uVl07oKjzVb3fDUz0l20=; b=dQwAS55hqh85iwjuJP99ZBE2+k 7hk7PgrlCV0dfrNzV/yg3Cgrn3vVQuyihaASOkxXama4vIaJgoyaLQTNbb3wSSWH 1ireJUtb/crEFdxRp0HCMTKI4hUlWTYkafHNtziTywHbqJko3PV2WU2tcNZPYssg cvcewVvND626rEEK+yEdPX2Ce4ASZfNvfIWaCVuhU/l/yi3GW90QU6fDPmwiMH1l Nf44eGNYMzAIH5CzYiacHWCM7sRyvnPPEd42Mw2XWP9XCLM8iLaBZ98cxrza7fuf 2WmHYtnBs6zO1HlhzConXRw3DEizxq8Po576qR5DTOitgnsQnn5IJ7oAeEpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1708003812; x=1708090212; bh=PIqhWv+qHnDsrpNtI3ZyjC3uVl07 oKjzVb3fDUz0l20=; b=blNeYcnZ2vkA7fesVVuHw+AbDjOR3YtsXzCPBp4pZXrR KesjL9Faj3+Yyd0g1O1OCmDeRakDfwekUi5kXE3DM5Ai0rayR/NGFMLVTQIk/lbM qVVJdAXpvuG8X1PGSJKHkhGPZ7r3yWpqhILj4erYvKEmx8Eu9Km8QQK+X4gGLu2D fnR4G6NUgjMtjPZsS1cXR0YBL4S7DiTE1ExCZ0HFfWhysjOmh6gPGIll7vz0VApo SCsWWBu+IfZrPjHW7CvBcXgXezCFu6HfkDZo4EP7x3JtknMEqStS+VtqpHdyxFBs lfB1uCIoCS/dKKqUR2eA40WQnaPyFWeVLCloFLzesw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvddtgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvfevufgtsehttd ertderredtnecuhfhrohhmpedfufhtvghfrghnucfqkdftvggrrhdfuceoshhorhgvrghr sehfrghsthhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepfedujedvjeduvdejje dukefgieekveevveeliedtvdetudejgeejjefguefgiedunecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhorhgvrghrsehfrghsthhmrghilh drtghomh X-ME-Proxy: Feedback-ID: i84414492:Fastmail X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 MIME-Version: 1.0 Message-Id: <82c59be8-6a6e-467e-9383-476660821ca5@app.fastmail.com> In-Reply-To: <20240214021925.GC4163@brightrain.aerifal.cx> References: <20240212184236.GZ4163@brightrain.aerifal.cx> <20240212224657.GA4163@brightrain.aerifal.cx> <20240213020834.GB4163@brightrain.aerifal.cx> <20240214021925.GC4163@brightrain.aerifal.cx> Date: Thu, 15 Feb 2024 08:29:15 -0500 From: "Stefan O'Rear" To: "Rich Felker" , musl@lists.openwall.com, "Markus Wichmann" Cc: enh Content-Type: text/plain Subject: Re: [musl] PAC/BTI Support on aarch64 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. 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. 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. 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. -s