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 9E0E2C001DB for ; Tue, 8 Aug 2023 13:39:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E47BF6B0071; Tue, 8 Aug 2023 09:39:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF6E36B0074; Tue, 8 Aug 2023 09:39:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBEFF8D0001; Tue, 8 Aug 2023 09:39:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BD8406B0071 for ; Tue, 8 Aug 2023 09:39:10 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 84BA81406B4 for ; Tue, 8 Aug 2023 13:39:10 +0000 (UTC) X-FDA: 81101043660.02.83AF516 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id 7250410000D for ; Tue, 8 Aug 2023 13:39:08 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dOsRv8DP; spf=pass (imf14.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691501948; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=f3bUliAT4xbwRl1NuDve7amWcJbHcaomGeN56KMUAag=; b=ZJkm2Kzy4pjFa61W0DPOk1CyKs63M5xG+kH+VeuGwrmw/oG20YomAq5SVlpZ/XxffGSnZm FY+BgopD8Oc5RJXpMhLYCO19luab4YJF9lz7rLfRb1vBY889Ope+ASazKPvKGOfLV8ooR4 lKOiaJEqhYUkLJW3Zbbliv5SQF5Dh/w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691501948; a=rsa-sha256; cv=none; b=ISO8gIDHdfBBwrLh/vzfeRpipGt6VjTSZ1Ruf7tMESf/H/cdum20YYySgg4n496tIDZiNy ZAloNrvkVBeMizqlkRWbGQE6vHeB8yfugoavHyFtYUnDo9yYqLMJdT0D38rOXiHlK8/xHE QewO6A6WJPMzBbtCPIUNi3qnw/EhwFE= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dOsRv8DP; spf=pass (imf14.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3C6C662231; Tue, 8 Aug 2023 13:39:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B716DC433C8; Tue, 8 Aug 2023 13:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691501946; bh=RnXjxseYsnFe6Wnck1M4XbqKJfcYUVsYZpbGiHCNKCw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dOsRv8DPnz3szlVVqAIekC0oAa1YWjq756EOBKQHNrWkdjOHTpZrdXFvoiy0dPstL zHVpr1V7MDywHBGGU4vstj24/ddQ2YUijhLOHhv21OptJRcyHiqH4PCaeITgRuOsQP xhcNw4WURUix63jdw9L0KUAaoaYuVRg6y2L3/+0DCRQV91VgQjhNmhSn7gmTUld4CN PukbIQT3kIDYfuJo8nq7Ezq5aseMpKv9N4/sMDanxbzcf38L9HyofcxB5+sD0FXxB4 LdhMsPJhZIcf39N6w/S5fgwPEA8bYg9AZCO455XBxu4iag2rRXSA1EHP7TfDTdQEgX lr0A4nNsxMLIQ== Date: Tue, 8 Aug 2023 14:38:58 +0100 From: Will Deacon To: Mark Brown Cc: Catalin Marinas , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Kees Cook , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v3 00/36] arm64/gcs: Provide support for GCS in userspace Message-ID: <20230808133857.GC2369@willie-the-truck> References: <20230731-arm64-gcs-v3-0-cddf9f980d98@kernel.org> <20230801141319.GC26253@willie-the-truck> <09b7a94d-cc88-4372-85de-52db26bc2daf@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09b7a94d-cc88-4372-85de-52db26bc2daf@sirena.org.uk> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 7250410000D X-Rspam-User: X-Stat-Signature: q9u3qj8mo7zog1bi14gi3pfp15c8yxke X-Rspamd-Server: rspam03 X-HE-Tag: 1691501948-798362 X-HE-Meta: U2FsdGVkX1/HEdWmJNofphn7Sb10gfQEcPFjjhezkO9gKqGJ9s+4LIVh1pPcnc+xO9DnVKePDBmvkTv5ZSoTmuq2ipwNlE0D85zRB906l2ukBbc1X/edcCD3OUZ05I6qAIaJnAbYxBuoA1lDuDhJLDWezQSokx5dm7I/N+QyFocfPwvVeCg0a79X5ANufBw3krOeROADBB4XwU7ggfjLjUinJCp72M2ncDE+3bVVgAOg4Nphb6NFdcf2CH9OdLb1zJKg8Mb5n5YoLo8UCee5a4QCQSF82Po6iO3WWCSUcKMLMK4hdYbSRsYq6qzDOFOXIfgQvCv7UIO6guN1+ikiFdrmxgOgz7Fnbf6LHLW0YlnAq/7itY+MzSMzOnonplSfB+S/atWDXJTDuUs5ZLERBv52vzVXnUOofTvStAP+8X5eO+O6QKTwxei0JDrpM55eIofnj9iMfdZUTlkxzcyzCYTkckyN+QkDvJGmjLKiqpCDGvTakV+Nlx3MSLh0OcdQfoL7nhKUaCfDtziiekadRVtZIA7I9IIJYn+w1I5tmWTKu081VnW8xS0/XVsRT1ey8Z8FhZKEyS3U8SUdN8HJUQ5ZEC8KJNBZzB3zh9aNFvuriT7PNUS6E7AOLnW7i+aTtbWBIl2qaKQ/STueJFTlmNPLJ9Gvo97tFKIDK3swQeAUBSigaMdhoQoidwxDvuEJIm8KoWnXjPaGfvCG9h9GpnXUDjg8+sOoPEqubwWzOWVgmvSoYmuWreWjmJ9spmqxcUGs6Fp/Ph0+VA+W3kylK1ARCQzLCBkr8Njno/Xfey+jddTGhL7c8HehC0599n4Ik7A/0a9I+8l25Dxf2KljDjxzj6MbibWLN2Jthy8Qj+zkcKsJsxvsw7DG7i2mLt0/pM0kzvGZZKhqrd8Jy+s5X+gEW0Cxjj7pTKpdib74HYBexpcNVc8V0B42lYg2ikSypebW6ZoUKV8FhE5a48T C24iEc9R T7qNNEV4DDWyHCmQg8ow6b58H9ySDm+CwXKNgV1TnQ087JEtC2WO5v7QfNV/8xdUVzktc6w4+h6u1m1VprS2okjWRAvHJRZn4jYgxiU8rWN+AF8kmH0ia/fQ+9xvFJ22KnGuthLhXA0JJtMGPxaytujocB+EaYUmk0yo/tFLChnjmrmIAyE0XTvglJ/6dcX8J/dl1pkaOr0gX9PI4XNW+qNQd8gTyOkPYd9ogeYaKM0WtfrRhyJiEoIDcgp2HLl9jM5SoYLhvD4rVZmRw5hGAbqnGju9cg54KGcNoSvuUl1VoSIUupa5peOcCFq5G7NLnztbngHJJ/MlBXNDSnXxxYM9qm63mtCsNB1h07tdYXxZwRT4= 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: On Tue, Aug 01, 2023 at 04:09:58PM +0100, Mark Brown wrote: > On Tue, Aug 01, 2023 at 03:13:20PM +0100, Will Deacon wrote: > > On Mon, Jul 31, 2023 at 02:43:09PM +0100, Mark Brown wrote: > > > > The arm64 Guarded Control Stack (GCS) feature provides support for > > > hardware protected stacks of return addresses, intended to provide > > > hardening against return oriented programming (ROP) attacks and to make > > > it easier to gather call stacks for applications such as profiling. > > > Why is this better than Clang's software shadow stack implementation? It > > would be nice to see some justification behind adding all this, rather > > than it being an architectural tick-box exercise. > > Mainly that it's hardware enforced (as the quoted paragraph says). This > makes it harder to attack, and hopefully it's also a bit faster (how > measurable that might be will be an open question, but even NOPs in > function entry/exit tend to get noticed). I dunno, "hardware enforced" can also mean worse security nowadays ;) But seriously, I think the question is more about what this brings us *on top of* SCS, since for the forseeable future folks that care about this stuff (like Android) will be using SCS. GCS on its own doesn't make sense to me, given the recompilation effort to remove SCS and the lack of hardware, so then you have to look at what it brings in addition to GCS and balance that against the performance cost. Given that, is anybody planning to ship a distribution with this enabled? If not, why are we bothering? If so, how much of that distribution has been brought up and how does the "dynamic linker or other startup code" decide what to do? After the mess we had with BTI and mprotect(), I'm hesitant to merge features like this without knowing that the ABI can stand real code. Will