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 409D1C52D6F for ; Fri, 2 Aug 2024 16:04:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7FF16B0095; Fri, 2 Aug 2024 12:03:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2F946B0096; Fri, 2 Aug 2024 12:03:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF7156B0098; Fri, 2 Aug 2024 12:03:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 917476B0095 for ; Fri, 2 Aug 2024 12:03:59 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9954081240 for ; Fri, 2 Aug 2024 16:03:58 +0000 (UTC) X-FDA: 82407776556.20.D7ABDBE Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf16.hostedemail.com (Postfix) with ESMTP id 9532B18002C for ; Fri, 2 Aug 2024 16:03:56 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=u0Azdmi6; spf=pass (imf16.hostedemail.com: domain of anders.roxell@linaro.org designates 209.85.167.47 as permitted sender) smtp.mailfrom=anders.roxell@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722614607; a=rsa-sha256; cv=none; b=zuYcGqWKlwnu8PAiL52o9toeGHeLmS4wWF0ZCCTWIK/XrlYHoV0iKjBzICsACmcjXQ9xKA h3VYKwQ7eZqodQfcrKFWfXCDl8pUvuYQI55Vvf7POj9Qqz2yYNdLcxkGRLAtqw/4wpA/DM 0e4Idmn4c3l+bib2JdnmHjRejwMBqnk= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=u0Azdmi6; spf=pass (imf16.hostedemail.com: domain of anders.roxell@linaro.org designates 209.85.167.47 as permitted sender) smtp.mailfrom=anders.roxell@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722614607; 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=jaYp+4ySrYqox0C2LwNhC4Vws80twAVdjJbOgnZz/S0=; b=n2tRYRTcoyiILnzyFoHi2YBNvH8ZKilXs8Pc8Bm6CyLX7GMcSChKO0vrWZWw7C+BXCA72A CStly4YH4GIHD+Lfwv4k96z5I2+aFy2S0d2cAqPVADX+WgASF/bJ7qnHyVzl4BdVUOitfb yt8GHbf1Y/S22xBnfjhJ5xhDqFwFkuc= Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-52efd8807aaso12304098e87.3 for ; Fri, 02 Aug 2024 09:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1722614635; x=1723219435; darn=kvack.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=jaYp+4ySrYqox0C2LwNhC4Vws80twAVdjJbOgnZz/S0=; b=u0Azdmi6Z7nCzpZS+BKHFR6f/98GJBrJaFdIFbW15aTo2IO/gYEDepatQSoi7lGi60 x2arBpggpAtmMUvKWL9oDVPIl4ZoFL7hsRpfJmQzCjnXPPrffCDp9l8a/+mIl1sSf3xN FDKEWuVFKmTU8GxmVI67KLiQD6OtZBIhnWU9Sdf7d5qQNmZ2tc0A33/aH5WPXPDUVV8N /dcQ+Gu8HRCnNDnIivyH7c5cbzfyQTZ5TEW+bh3BwOAhlCnQWQMqEzTwnp/S6XH5NOcZ jZUnqBqwtizXHaIhy8pMVQWunqW3LzWVUpQ7ivwNFjvikNsnh+9++9AO817MABBAbRH9 ngFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722614635; x=1723219435; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jaYp+4ySrYqox0C2LwNhC4Vws80twAVdjJbOgnZz/S0=; b=mLVaE012U1X2VH6e6IhIbxgrbVIyqePfZozKjNP/+ETUUDQDJtw3LAStWC/+CzkMgz 9a8y4z68J/p7n30ig6UYbx5Du8vNQZrnShAibViXQd/3BQtAvawG3HO0mUXpkuWmnu60 05c4cR4SBg7Y8qbI8dOeT57oFKQ/HBmyxQArvmRVk1TiYCa/W54qSJ0ASWPFPSP4a3qM CQGUL/KXXwx8HXJVI3pUu3+GLjciXrRH+LAveIqFlFjoJoRluSUt6E3LYeY5duMpcWDE myh3HoyYrjmhajqVQzyiFMzERpTLN/DxY6RAozHCRfqKZaBJ3/t9y9nBhtuW71Ll/Dq3 0vWA== X-Forwarded-Encrypted: i=1; AJvYcCXujwEkt5CNl8XEkK6vyob9qzqMHwXUAaEkL1UCCcTDUNlqkrccuh5y003CvUJjbZG3+LIfEDX29TgYa6StMAnEHo8= X-Gm-Message-State: AOJu0YwW/EB6Ucumd9lS0rVQREDPG87wM6UxCPglm/u08ZcffODguBUW h0kEc5Y6l4rPc4rK45cC4t/Waq4XKztmPJ0k5TVYg2D9jeyaUxIpX8hQ/Czmzjs= X-Google-Smtp-Source: AGHT+IHar+PPGcrxDNcjSr1um3g+3xRCfTrmLOXPeIhwAHJBP67s3XLeWwHx6hWOKLC6el1844qAfg== X-Received: by 2002:a05:6512:3ba0:b0:52f:c14e:2533 with SMTP id 2adb3069b0e04-530bb3c79e9mr2525031e87.48.1722614633808; Fri, 02 Aug 2024 09:03:53 -0700 (PDT) Received: from mutt (c-9b0ee555.07-21-73746f28.bbcust.telenor.se. [85.229.14.155]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-530bba07dc7sm266293e87.16.2024.08.02.09.03.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Aug 2024 09:03:44 -0700 (PDT) Date: Fri, 2 Aug 2024 18:03:27 +0200 From: Anders Roxell To: Mark Brown Cc: Catalin Marinas , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , Ross Burton , 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 v10 00/40] arm64/gcs: Provide support for GCS in userspace Message-ID: <20240802160326.GA36502@mutt> References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Stat-Signature: uto1ftyg5ju13jw8119chouoqh6qpbab X-Rspamd-Queue-Id: 9532B18002C X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1722614636-530351 X-HE-Meta: U2FsdGVkX19TFOyflI2RVDWV/3zlpcgx0gWZxqmxgUmAXDql5IJPxOMuwA6/B5fYy9tBgHQC2RTOhYaUWGB7hX7wU7yLk85h/DliT/EmVmt4Mj7bcBRecb5Ox/Uu0o05+qeokys1fnpb7UfwcVbsl7PQ4l1Txp1443NYLwodnJ7MlDWJKD9Hn4GXBEQxTpp7HpwYSyVuBekD2Ykn/6bT5uhznd+xBE9V0qbsmGL786CC6zV80rIGpkTDO1duTA6gNvjbrOa+QFPE6LQElpMqoD5PchcdPxCDbnjANEam3ILuBkQhYYHAwk9ly8uLgkzzd0ktVoZv1PA8woNp9Lv3Lo7ocKNfLHvtFZ1tuMeImx9uQCaY5sMxsAjD+HAjdEjDkcv1XsndSJ6u3pC5FrtaAzK03z06lxoXuYgl/8w6bmUe0CwWPDrVJL/IuLBI29mdKqi6hsclJ/7lV2XWXbySHTYwnCHEQ/dSe9+rXqzqRlWuz30mtVWjfuQBUZQT+J7TqFZgQVZ8UxjzQYXRhbgBCUFrdMB8Fx3wBs6I+AeycYIkXDfxF1Z6l4EtehR/XKs/CkOaVfVkqTLF05ScL1VmKLUSmbjD+Ad1ReBIYSqau1mQXP2jWQOBCMVY2ry7b3lxqpBPDN43+UQYkB7BnimbaP4BTaxUZ5AZBoRG0wYg13zjIt6ZqwLJUqGpBpDOtJup7z4s/K0Z8RIE4XIwBvNSRBKEvBgUKBtuOMg2jw4FaMKQLsa7OIGnLBoD4bDGKSXk3aWrf6KaFW4/C44iFUG5Miy//iubDjYlfIisKhL4mOcEjPhZXOVLdy9/svjpioXpgc0mkJFc45UxzRznEOBgdrxSh/i4vu5wy+8Jy9MyoB7wrRW3gltw04Gn0nchoi3nNxRc8HIX8LIaQRa1Jk4XiiU5MTPucDCf5hqZiuOAYgkfa8tuzDLTJHxhrInZJyGZn8icSWLkVBWOHj2fv5V FikQzK4a m/PFuArqC0YfopTr7+zaedH3mhD7EhuAj+S2o3jezP5cDaGrsiYWRUAXsQp8nUNyE6sRMvuQL0n3N9TkMRs2nmLZPel5gOiv5DnRnHbxTMo0iWf+n/42VtBfo7Uz5fgVsdQKWcjVu7YGhy6dmxwLV1tsM5PMhot8bPlRU3lWubFK/5zW9vuxo2EWpekeI7AKcIXbSfyeyhrAHGtwkebfhqdQnn63Ajfr9mF3EGNqaReMYCg6dri67CI8uVqH4Xn8nNXkmiOeRnMckDBlN9BYLUuNYtyxFW3rFZAHhTn2cTZpL5yS6CnJ3FXyonPUWREC/H2VFwlyitmC1rBIKZdCGN1G5redXmxlAsqA4HRtaCtQpjV36Xl7rASm3Xrgn1U628RMwNRyCYPhjhXk0I59irBi1yPu3e5bOOkBuonaCXS1sheGzr5tlGkbj5JFTYBXuMhV5 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 2024-08-01 13:06, 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. > > When GCS is active a secondary stack called the Guarded Control Stack is > maintained, protected with a memory attribute which means that it can > only be written with specific GCS operations. The current GCS pointer > can not be directly written to by userspace. When a BL is executed the > value stored in LR is also pushed onto the GCS, and when a RET is > executed the top of the GCS is popped and compared to LR with a fault > being raised if the values do not match. GCS operations may only be > performed on GCS pages, a data abort is generated if they are not. > > The combination of hardware enforcement and lack of extra instructions > in the function entry and exit paths should result in something which > has less overhead and is more difficult to attack than a purely software > implementation like clang's shadow stacks. > > This series implements support for use of GCS by userspace, along with > support for use of GCS within KVM guests. It does not enable use of GCS > by either EL1 or EL2, this will be implemented separately. Executables > are started without GCS and must use a prctl() to enable it, it is > expected that this will be done very early in application execution by > the dynamic linker or other startup code. For dynamic linking this will > be done by checking that everything in the executable is marked as GCS > compatible. > > x86 has an equivalent feature called shadow stacks, this series depends > on the x86 patches for generic memory management support for the new > guarded/shadow stack page type and shares APIs as much as possible. As > there has been extensive discussion with the wider community around the > ABI for shadow stacks I have as far as practical kept implementation > decisions close to those for x86, anticipating that review would lead to > similar conclusions in the absence of strong reasoning for divergence. > > The main divergence I am concious of is that x86 allows shadow stack to > be enabled and disabled repeatedly, freeing the shadow stack for the > thread whenever disabled, while this implementation keeps the GCS > allocated after disable but refuses to reenable it. This is to avoid > races with things actively walking the GCS during a disable, we do > anticipate that some systems will wish to disable GCS at runtime but are > not aware of any demand for subsequently reenabling it. > > x86 uses an arch_prctl() to manage enable and disable, since only x86 > and S/390 use arch_prctl() a generic prctl() was proposed[1] as part of a > patch set for the equivalent RISC-V Zicfiss feature which I initially > adopted fairly directly but following review feedback has been revised > quite a bit. > > We currently maintain the x86 pattern of implicitly allocating a shadow > stack for threads started with shadow stack enabled, there has been some > discussion of removing this support and requiring the use of clone3() > with explicit allocation of shadow stacks instead. I have no strong > feelings either way, implicit allocation is not really consistent with > anything else we do and creates the potential for errors around thread > exit but on the other hand it is existing ABI on x86 and minimises the > changes needed in userspace code. > > glibc and bionic changes using this ABI have been implemented and > tested. Headless Android systems have been validated and Ross Burton > has used this code has been used to bring up a Yocto system with GCS > enabed as standard, a test implementation of V8 support has also been > done. > > There is an open issue with support for CRIU, on x86 this required the > ability to set the GCS mode via ptrace. This series supports > configuring mode bits other than enable/disable via ptrace but it needs > to be confirmed if this is sufficient. > > The series depends on support for shadow stacks in clone3(), that series > includes the addition of ARCH_HAS_USER_SHADOW_STACK. > > https://lore.kernel.org/r/20240731-clone3-shadow-stack-v7-0-a9532eebfb1d@kernel.org > Verified this patchset on a FVP. Tested-by: Linux Kernel Functional Testing Cheers, Anders