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 B6326E81DF9 for ; Fri, 6 Oct 2023 13:23:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D14EE8E0020; Fri, 6 Oct 2023 09:23:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9E398E000B; Fri, 6 Oct 2023 09:23:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B17638E0020; Fri, 6 Oct 2023 09:23:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9F2448E000B for ; Fri, 6 Oct 2023 09:23:35 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 57B991407F6 for ; Fri, 6 Oct 2023 13:23:35 +0000 (UTC) X-FDA: 81315103590.09.B124907 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf19.hostedemail.com (Postfix) with ESMTP id E1B601A002A for ; Fri, 6 Oct 2023 13:23:32 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r7kN1bhY; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696598613; 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=cjyyJuiBEmN/zEDBVr9JAjFL+r95tcpVq5ej/W0iL/Y=; b=0LvnO5ICpv9Ogp9odQVRB+La+LrZInOkq22GuqXtxkFYLSlxUxjocEjYatU1PcXWSYMzA5 2U6mwoIllNDka+bQY/WSCX5VGR+y7ENMpLMnQNbbTlCDqDsw6gsrh1Ovg4TNW7A2Lt4sK0 Xu6omyzyICOTzL/wrPisqwXEuIzy86c= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r7kN1bhY; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696598613; a=rsa-sha256; cv=none; b=We6E0016NJ5guRHljcQQFRz/q0TZHkLVWLnZH2A9VzFTN7QygImc3Z8ZSkFPnBCRj1QgaX T/rszXOCKnxHY/IJVF/pkButGOoSek4e8yMvwDj30wMfEd80TnB822ivznTWzoORJODSI/ klzKZB7DBid8iRhsYdpTO8nAXNzhK3Q= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id AF9FACE2603; Fri, 6 Oct 2023 13:23:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B6A1C433C8; Fri, 6 Oct 2023 13:23:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696598608; bh=EaTnbJI4I15tCsE5PAEOFEMV2gEpZ5O8xv29SdDb+qM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=r7kN1bhYCxtxsrayiH2/Qvakhgo3xCg+wGyDWqoba/ZC5pHVgpQDCCyLUBMq5h54g ECPy9lW5VnfDNKExrrh7fEdQi/U/bsZ892xqQHM3S72mb56W82U4MfmqpjVIrrIJyB qr4LzQDOov95/YlKhpIXNX+7KimqRGoyORxBH1I2m/XYsnYxcLtqw4e1YjQNFIDBA5 tnW4b6DBxOSfdtiaDHBr9QAGaSCEQWZ729s1flrAd+bmsOCjhqUZ+msIzUEQjcpObI fcYAdK0dvdOg+7/O/AD46RjkpZyTdrX3BsQGRWK8UKSyIfp93PxVJs9Zo8bm/vRFfv hsYBCwh6ppprg== Date: Fri, 6 Oct 2023 14:23:18 +0100 From: Mark Brown To: "Eric W. Biederman" Cc: Catalin Marinas , Szabolcs Nagy , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Kees Cook , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , "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, Florian Weimer , Christian Brauner Subject: Re: [PATCH v4 03/36] arm64/gcs: Document the ABI for Guarded Control Stacks Message-ID: References: <43ec219d-bf20-47b8-a5f8-32bc3b64d487@sirena.org.uk> <38edb5c3-367e-4ab7-8cb7-aa1a5c0e330c@sirena.org.uk> <638a7be5-6662-471d-a3ce-0de0ac768e99@sirena.org.uk> <87y1ggylvq.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ji8GpeD8VVTZwCCT" Content-Disposition: inline In-Reply-To: <87y1ggylvq.fsf@email.froward.int.ebiederm.org> X-Cookie: Rome wasn't burnt in a day. X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E1B601A002A X-Stat-Signature: cpezp8xqm7rjw8yoqg9miyqfr8cfpp7x X-Rspam-User: X-HE-Tag: 1696598612-857025 X-HE-Meta: U2FsdGVkX1/NAJmW84YI9CaT8VRJ69OED4OYc3RdcB+h1KL+tGEf+u+ykVHg5DTWcqUFr9kXjIdwd5HjnCCArImJcCZua38dFCKj/qOT3pWLtNKVAUUpw592+yYjfqPBKKj7hTSfzfYIk2crGfQUdxtIDZ1Mf1MScqy7M1f3yHpwJosjEmtE3Ea3F62mtvUH1O5wXyaHZYomB8o4VV+Njy/IjOE/Dr3klyV1Wl+9T1TBsZqDukLx0ooQHaTZQ6CJnm/wAArwKYDC3fivPXpSOnYAwRzjfbSMJLGktxAkjZXTYAZFGJX+cP4D7enmwwH33V0jriHsIAE4hYAdupOmHUdMZXejUfcFXv6CBnoxPvHLQ9pM5BzXnuTWYPfkkDtXkWDG6IvVHmMkG2mlzsBdnKYkrLcpbdmR3Y0odZcJ24KrXpVXI8QljvWoX8GfRAmv2XoM2sPpNV45Gj0C+aSJlgCZPhoTAtk8UaAtlMo0PKh+ZA25g5BX+fVccC9CI3vjfHXvaVD8IcCTukL+mGQg+YOOfhSXv6xYvz6+YBIWRjqNQNhuLhyMfwgg9vd2goj1Zudy+z+kqbhwmw9bMGwj6+FrXoL0x0zmu4cvXnUY7yWzpFgH8t/h85tvssaBvYARBkyF5WiO6Vh40Nh/MKkeQ5ss6njKgxFCYEUA7/7hP1MSBDalNEZoVE0c8tz1+323qNuAotY1Y2FRfkWr4w7QsFOPrQQG/0nKL4Q7AFCY8Ykw/Cmp6t5SAX7NF/W5cYLkS18HD88Jdb5pF6aTn+5xout3w1LJn/oGnMn/cHaDLNLmzQiH5giDiiBOCRMVdvcUaGtErNpqpJD53SlwNbFZ9PVEsY7hB76PsuVdNlJpzQ2rObTALImXpS9BXyBVDI0a3uQ2Q+SCNUbmFLKrn/8WTf65VQJ9pSbkl80AHi2kud6h48lurslV3zyqkCLgdnHaYYL0vvg25IqpU/4L0/m GjIwMAAq sHuSq1AIf0ttGfAsDSbRG14pDaYZ6dAjSIsMzgXTA9IeJGTvgJWrzkHGNJTZoI2p+7B+8MmIvKmctoufkm6X5Eza1jx7ZDoOyio5gS0WfIZjpJHoxgaeR5q1dFTsWHNktfmmMaHX3CqguPExqwJKkE9Qpl2l2Kx/GXzsk6iwrR+MBCyLXYJ9nOl8LUXU7KxjpGiZ/nx/uUvpMvyj75FkO/mnVBbQ2MBSMoSGuHFMZu5wQZjtpuYAv+JBAtliMsf7AK66c2i2ODGZLKfYnERQU4IGFAcdXfXIybjWZ4+8oVoZbTNvtFzHON7G3nsWR+VeY4fZsrJtkkUnglAX1dLWtWf/luNBpRWBIS4I3Fcv0AXQ4A/CmjTeiWhyNCAGGedIjmHR2GXKbhkmOzO0= 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: --Ji8GpeD8VVTZwCCT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 06, 2023 at 07:29:45AM -0500, Eric W. Biederman wrote: > Mark Brown writes: > >> It's not just the default size that I dislike (I think the x86 > >> RLIMIT_STACK or clone3() stack_size is probably good enough) but the > >> kernel allocating the shadow stack and inserting it into the user > >> address space. The actual thread stack is managed by the user but the > >> shadow stack is not (and we don't do this very often). Anyway, I don't > >> have a better solution for direct uses of clone() or clone3(), other > >> than running those threads with the shadow stack disabled. Not sure > >> that's desirable. > > Running threads with the shadow stack disabled if they don't explicitly > > request it feels like it's asking for trouble - as well as the escape > > route from the protection it'd provide I'd expect there to be trouble > > for things that do stack pivots, potentially random issues if there's a > > mix of ways threads are started. It's going to be a tradeoff whatever > > we do. > Something I haven't seen in the discussion is that one of the ways I > have seen a non-libc clone used is to implement a fork with flags. > That is a new mm is created, and effectively a new process. Which > makes the characterization different. > In general creating a thread with clone and bypassing libc is > incompatible with pthreads, and the caller gets to keep both pieces. > As long as there is enough information code can detect that > shadow stacks are in use, and the code is able to create their own > I don't see why it shouldn't be the callers responsibility. > On the other hand I don't see the maintainer of clone Christian Brauner > or the libc folks especially Florian cc'd on this thread. So I really > don't think you have the right folks in on this conversation. Well, copying them in now. The discussion here is about allocation of shadow stacks for the arm64 implementation of the feature (the arm64 feature is called Guarded Control Stack in the architecture). These maintain a second copy of the stack with only the return targets in memory allocated with special protections so userspace can't write to it directly and use this when doing returns to ensure that the returns haven't been redirected. These shadow stacks can be allocated directly by userspace using a new system call map_shadow_stack(), doing this via mmap() was extensively discussed but it was concluded that this was very likely to lead to security problems so we've got this new syscall that ensures that shadow stack memory is never accessible to userspace via other means. The x86 implementation that has already been merged into mainline will allocate a new shadow stack for newly created threads when the creating thread has one. There was a suggestion to have arm64 diverge and require that threads be created with clone3() and manualy provide a shadow stack but then concerns were raised that as well as the issues with divergence this would be too disruptive for adoption due to non-libc thread creation. It's not controversial that it'd be good to have clone3() by able to explicitly specify a shadow stack, just if it should be required. --Ji8GpeD8VVTZwCCT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmUgCkUACgkQJNaLcl1U h9DirQf/ftVM53t8n7Iz/c70/XaZOa6o2/1qaxs00hlLIEkmuVk5LjL0TViJlfRw qIRUvbR8y9MkOCjJOTAErDvidq4rFwmPiuk9mFZViDpRkDxpG13xvHCHIqZ4NPUe Eve09ZqsJK5dCaW8G4/FCkSIZF2yD1lGttWRhYwckUPBSHMVZevuylvin7vdrWAr sPCe3qp4gWYgplUtfxKadGeowpldz9LRCbARrBYB1jqSXcJbskcDd0L3KUH9ElFv kYT+Iyoh0j36gEZFuwWXioYTEbQcD5qsqcftvc5LW0vRiUlKo/MUND/c07YdRoBy DfP12K7+lLpdbS17lq6f6DfTuLAwcg== =J8v2 -----END PGP SIGNATURE----- --Ji8GpeD8VVTZwCCT--