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 CC625EE4997 for ; Fri, 18 Aug 2023 20:15:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52B41940074; Fri, 18 Aug 2023 16:15:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DC7D940012; Fri, 18 Aug 2023 16:15:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A39D940074; Fri, 18 Aug 2023 16:15:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2AB63940012 for ; Fri, 18 Aug 2023 16:15:28 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F15761C94E0 for ; Fri, 18 Aug 2023 20:15:27 +0000 (UTC) X-FDA: 81138330294.07.5CBC13B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id 2AEA81A0009 for ; Fri, 18 Aug 2023 20:15:26 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UWpnqpi6; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 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=1692389726; 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=CKn3q2oZDNYxBm+oH+E+03OxWlnebA5F7bNSPKOJ1Wk=; b=mM842hqYvqirZkeOEDMz43YuvUi6JNNC56/qTJjEcmmFauh0ub47PbM1x8ttRu4kVorsfu Ge0LOLILM3sJnPtzSv0QP7SOJgq454kPY2xun07shXV6Qs1+LKi5JzOoR2sd9/VNE/bwya lWPpY4K7olDSZL1YvJJtqTycLiw50h4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UWpnqpi6; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692389726; a=rsa-sha256; cv=none; b=B27cQDHwjCX15BD64jY76xdlgF4Wv3NRWW2xY/KmsZ/4L/yJs4QBOjt0VSP5oolX/LLNMc e05+Ziu5fsu+V8gBPCLbIb1qkPJFHWIp9izNVkXwcDpXlZ2ujzNgwpbaJjYuZvjspuw6G6 2VLqpp9N7BH0IN7WG5orytDc7o5TJoo= 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 456D162A5B; Fri, 18 Aug 2023 20:15:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4FBFC433C7; Fri, 18 Aug 2023 20:15:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692389724; bh=WCt+HTyPqpQoM8uuU7vN+x57RA6ZJu12mqg0CzvfAKw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UWpnqpi65SH3/qdqWBn6Zd1Ci2gAJDST/B3oTk2b0QqR4KzLEHujl/2sXAp34aaQz rYf/Hxv4pGdxI4XtXA71/BlwdSjOlALBF8+7Nh/txVG1Pr0etLTfoxWGUJ+zGSMQ13 12qmiSM3fn6coLaVe6HKubfVBJb5Z/QsLDUtopgpRJBemR/BlWB0eyjCHm7pxUeA6y yvGiBvlRhhmOnJmtqJKBgyLZHzlJhtJfhzvqoLPqNP+U1RPimemgLmIq2et3p1jWan qRLwKdKD5hl3mrqoXMp+UCe8E/WSmGnN+WQpVc/+3X3jhGCfNqyeGGCMUIAzmPI1DF i74Qa8ekO6c+g== Date: Fri, 18 Aug 2023 21:15:15 +0100 From: Mark Brown To: Catalin Marinas Cc: Will Deacon , 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 v4 19/36] arm64/gcs: Allocate a new GCS for threads with GCS enabled Message-ID: <3a01ce20-3365-421b-95ff-211946808174@sirena.org.uk> References: <20230807-arm64-gcs-v4-0-68cfa37f9069@kernel.org> <20230807-arm64-gcs-v4-19-68cfa37f9069@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="45mwPxvFeqYyCSA9" Content-Disposition: inline In-Reply-To: X-Cookie: Your aim is high and to the right. X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 2AEA81A0009 X-Stat-Signature: jmgmeogzqudngsneu5htzpapwtzm4gqw X-Rspam-User: X-HE-Tag: 1692389725-179135 X-HE-Meta: U2FsdGVkX18vjARiCgHNU0PTl1aj3dPsSquxPOxVU4CU7rb3KRxa2OY0S+lz67T867oVFXGfTQTntzTCycIyfLX6XONuFe7NaFId5ZgvWbNo5jGEqrrhcPOIWIHvn5iusUnHugQXUMRhKNuDiM0zyEZsIwi2oKvnq2gQ4j+nRd7GnLUkiHnydSdgr06b3i+GHzDg6tGMngflsvmxJQ33EEwZBpLQePVtsu4G2T7C17/lPYLpC4M9jyTNA+yYVV9JLgFsr6QX0T9FzFCYKdhtgJ+MIqsqZnmcdgvbDyhBUSI7nNIjqv4V69E3wLYjtT3EOTcuWAN8qCzjDWYEBvxpEDJj0V0gWWdYzmy7ZML32MY9n016UV+m899EQz49JMjUbdvBJwVKK+l/eqLih0mIe8RtjoA+td2fEiYlz3Nh6+3/xGnQY6hwdPAPVJeaMWnc6XjCYxeHDwnIJXVP7b5Cic/lPT1TX31jIY6IzjR/Mlk4xL2aIMlE1pVvzhVHz4LOsLm1sfz2UKe2f6lZMmw/FhR6+c3aoroabDA86LmL6iA5jgMobbol0VRbI4WaKh+EVQAOYwtJL0HaSgnyiPLLJe9RaQI88CtmZ8GGItnS0ihvEAznKDUcbZ+xdNjvv6vqGo2t1zrsk3aZNUvT8c1BJVBD5qFciwdMbojk3O+mChgfjBD2z51nKaaXoZwsMuGURIRaS31LQwTNOmmKDoLRiiMTI6T+Bfn45o2DucvR04Kv2mFXbLNUeYqvbzee1lEAnEoq84J2l9WS2tor4u5V9tRWKhwkr9Ui/ENswAfGdXfFplyqGIPrOdiBwgzM7ba/V9we1G14z8HZQKzK2V00viNkUSDPMRtxrhtryifn9b+UfHFSZeDcCT7/e1u4/I+EbIx43YSSKchuYhWXlfKW8QG8Q+O3K8vPdjF/iVmMLHwdLP0hC/n/LzZepQm0WF44aobtRA5iIgPSyWzdSKx HYvXKAsB 07pS/YAKpJ+Pf1Pl64nxyrzBm+CXBnHul+A1gWEFwobcf2TOIoaUv5LsW5j877nVkBu3FgxJh7Z/phngmIKhpn82GB7WdiwZwGWEiq+Lem3fvzb28gBlpaAz2JG+1zVpvd8jP8jT+fSOgJfbq3AmwTFZ4wzpB0baDxD+Fz8ZjSW96Lg42ai1CHFszxkPVIRGj8H3v08Wiak6TCrVdkxfykFSXLc6aWX2akDL00fIuuKcpt31R1DqeEmdAFcouE2ltjiesG1oxls3Xx3z8kjlgoIvo93A/nz0HEFddfXNpgK2uhR9fVk08kjToFRBA014qFxaB+3kduC8A7LswEGvElojwyNEnr4g2/9KeZvngRo3YVsRjr29oPlPGbFPaEne5yfow962eI2XaoiB8VOa3bxPKD98fVdXMoFzakGhRDglK4Zx5jHubVtQi7X9CAp5hixzXiwr50Yq/CI0r472Yv5oSJHvH8BLf2OZL7+4IpnVo2WrwLd/ZB6ZhFkejqy496uTN 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: --45mwPxvFeqYyCSA9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 11, 2023 at 05:26:03PM +0100, Catalin Marinas wrote: > On Mon, Aug 07, 2023 at 11:00:24PM +0100, Mark Brown wrote: > > + mmap_write_lock(mm); > > + mapped_addr = do_mmap(NULL, addr, size, PROT_READ, flags, > > + VM_SHADOW_STACK | VM_WRITE, 0, &unused, NULL); > Why not PROT_WRITE as well? I guess I need to check the x86 patches > since the do_mmap() called here has a different prototype than what's in > mainline. > This gets confusing since currently the VM_* flags are derived from the > PROT_* flags passed to mmap(). But you skip the PROT_WRITE in favour of > adding VM_WRITE directly. I have to confess that I inherited this from the x86 code and never thought too hard about it. I've got a horrible feeling the reasoning is simply the way in which x86 fits shadow stack into the page tables without having a mechanism like permission indirection, these don't apply for us. > I haven't followed the x86 discussion but did we run out of PROT_* bits > for a PROT_SHADOW_STACK? It's more that there are security concerns with having PROT_, especially in conjunction with needing to provide a token for stack pivot - we not only need to map pages for the GCS, we also need to write a cap token into it so that we can pivot to the new stack. If the GCS can ever be written to by userspace via normal means then that's an issue for the basic protection model that the feature is trying to implement. If we have the PROT_ but try to check for bad uses of it that makes everything messy and complicated which is especially non-ideal for a feature with a security focus. Having a more packaged system call is easier for everyone. More detail in the x86 patch that's currently in -next: https://lore.kernel.org/all/20230319001535.23210-34-rick.p.edgecombe@intel.com/ > > + /* Allocate RLIMIT_STACK with limits of PAGE_SIZE..4G */ > > + size = PAGE_ALIGN(min_t(unsigned long long, > > + rlimit(RLIMIT_STACK), SZ_4G)); > > + return max(PAGE_SIZE, size); > > +} > I saw Szabolcs commenting on the default size as well. Maybe we should > go for RLIMIT_STACK/2 but let's see how the other sub-thread is going. I've updated it. > > + if ((clone_flags & (CLONE_VFORK | CLONE_VM)) != CLONE_VM) > > + return 0; > Is it safe for CLONE_VFORK not to get a new shadow stack? A syscall for > exec could push something to the stack. I guess the GCS pointer in the > parent stays the same, so it wouldn't matter. Yes, pushing should be fine just as for the regular stack. > That said, I think this check should be somewhere higher up in the > caller of gcs_alloc_thread_stack(). The copy_thread_gcs() function > already does most of the above checks. Is the GCS allocation called from > elsewhere as well? That's the only place. I've moved the above check into copy_thread_gcs(), you're right that the other checks are redundant as they're done in the caller already. --45mwPxvFeqYyCSA9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmTf0VIACgkQJNaLcl1U h9AK7Af8DxBPnoklDhEt6uL9Qzwyg5iHuvMMz45iQs74RTv9fEM/vR1B1L0U0vxL LjcRxv98KB+GM2DQ+YOoQK84V2okcpKSNu9l/0CY+hvT8JChP5Ljn/b3azVF3FGY QYftbzRipJONW9pKxIZ7Svx8+iZIg03PmcwJTtLRsi36gyykxlFbYhzZm/0VbWH6 HDuDWH8yMX1/BQGizf3FM7CxbBmhcI/zzi2eUslQ3EPOoSKywy4JXRc49XAvrxbT Bu8EbBX7Oapi96h+KlZEAWSiTuD4plJ6pJQsjMdMcELiI//3sTIzNRNqmFxBIgWS O2Sp933Ku1aQm9TW9TcOY3MVq5dYiQ== =X4OS -----END PGP SIGNATURE----- --45mwPxvFeqYyCSA9--