Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp290822rdh; Thu, 23 Nov 2023 04:17:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IExzDqzgZTAd1V2xojS3k9WD6jye1xG2y+c22T8NHK1HI1e2hjPtqFKwjBAuFnaI3eqLxX+ X-Received: by 2002:a05:6a20:158b:b0:18b:3401:5c56 with SMTP id h11-20020a056a20158b00b0018b34015c56mr4043674pzj.22.1700741855074; Thu, 23 Nov 2023 04:17:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700741855; cv=none; d=google.com; s=arc-20160816; b=ugagFgKq+wEri6ujllSV5QE7VMx2pfkZ2Z11mHfFreDLbg7K/oGjZkYnUq+iJpoQSi s0pyxHmHrYxdaUYAxr2qvXoTeTLjIXPr5u27z9YGMqvDjP46JwuEnEsSF15aGpsYgIuA qCRBQdGHNTVIsuMrJ4lu+uiV8dVL4Ze3HYeLezwiWgaM27EMjcJROmA6/Lc1zd/y1Syw zyE0CPl1wchmFbHyku3q3hHExU1eaAFDi+/JYnPfvGBGELs4Gcntm6+QD5dpk+GgXW2M g+2Hx0eVPdhuSVwDj3FfTUAgcX2ts9T+5+a+Ou52+Ct8+2fX3by0KBj04jt2C9ee/MO+ mT7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=OXH13Nr+IfU80N/+D4iKssBb116/cAGr6eOO9dew9ac=; fh=/NGAuUPd0B8+OZEhPfy37TvYhCStcl0T+pBeZos5FWE=; b=fCLfLcz3KKqkcRz4cV5IqVEqZ8SbRRJfkhy+k9/F2rMi9bMH9RWAR+TdIcwUm0hKr5 x8LaoIG8CHLgDHTAXWZuXYGNV6LYU5Ku6B2k4uZqEtwIpi/OIKV48bj5Li+WszqOJydi aCv9WU+yHqrrP9c9QosCfSLM0c5duUkANMDdSICWFe+TPIngTFeMTVrlnAXQWm8lCDo6 acmBTa3qDUXX6BD0IzmuyhWuR6r3jHjtOEeQyGCx2WpDByz6D9AEFbUo9vqhV0hewJWv ZB1dSloIkvxJnT5ZbG+gWN+0B9NWQYw9BzrLOlYbayULIYzEu97c6CtnWODiDCZPyt6l puMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DnQ+IN2C; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id y31-20020a056a00181f00b006c4ddeb9694si1173633pfa.229.2023.11.23.04.17.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Nov 2023 04:17:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DnQ+IN2C; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 452AF80D6ADA; Thu, 23 Nov 2023 04:17:32 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345252AbjKWMRR (ORCPT + 99 others); Thu, 23 Nov 2023 07:17:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345168AbjKWMRP (ORCPT ); Thu, 23 Nov 2023 07:17:15 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C491191 for ; Thu, 23 Nov 2023 04:17:22 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC58CC433C8; Thu, 23 Nov 2023 12:17:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700741842; bh=xCCEkCoA+F5EPxb6wixFuv+Y++MgTfZXWFP2tS5YmbI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DnQ+IN2CmzxBZAQar7A0chcph0OEoFG6VnV6a6nmioVv2J/i9XwLKSaBn/FSInAxx LjQyETOrquG0xUVyofz8IdDiXc+65v47aEFJYrkyp94Rhr7Qn+wXpibKXsoCuej9tn F9i+QRgxqAqc9qAEbQWB9alRJo7ThMiX5NTqYAA9/Mh1bDV5X8D1VGlgfY80qTWKKf JCh2pnKtcOgJ+INkcur5VZYKBtiXwOINvTJSzfLQt4T0OQuqIdxQRaxPK/lz3TIlRy gkPRtHSBxj21quDA8+JA3AfWf+aq3ofiXoJd0+8V6+G+YhgnXpTiH4S/qtZjio0SiG 1qQaNC4hl1CSg== Date: Thu, 23 Nov 2023 12:17:19 +0000 From: Mark Brown To: Christian Brauner Cc: "Rick P. Edgecombe" , Deepak Gupta , Szabolcs Nagy , "H.J. Lu" , Florian Weimer , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , Shuah Khan , linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Kees Cook , jannh@google.com, linux-kselftest@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH RFT v3 2/5] fork: Add shadow stack support to clone3() Message-ID: References: <20231120-clone3-shadow-stack-v3-0-a7b8ed3e2acc@kernel.org> <20231120-clone3-shadow-stack-v3-2-a7b8ed3e2acc@kernel.org> <20231123-derivate-freikarte-6de8984caf85@brauner> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AJGmcN2ZtlBWZhny" Content-Disposition: inline In-Reply-To: <20231123-derivate-freikarte-6de8984caf85@brauner> X-Cookie: Slow day. Practice crawling. X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 23 Nov 2023 04:17:32 -0800 (PST) --AJGmcN2ZtlBWZhny Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 23, 2023 at 11:28:47AM +0100, Christian Brauner wrote: > On Mon, Nov 20, 2023 at 11:54:30PM +0000, Mark Brown wrote: > Any reasonably maximum that should be assumed here? IOW, what happens if > userspace starts specifying 4G shadow_stack_size with each clone3() call > for lolz? I guess we could impose RLIMIT_STACK? > > + } else { > > + /* > > + * For CLONE_VFORK the child will share the parents > > + * shadow stack. Make sure to clear the internal > > + * tracking of the thread shadow stack so the freeing > > + * logic run for child knows to leave it alone. > > + */ > > + if (clone_flags & CLONE_VFORK) { > > + shstk->base = 0; > > + shstk->size = 0; > > + return 0; > > + } > Why is the CLONE_VFORK handling only necessary if shadow_stack_size is > unset? In general, a comment or explanation on the interaction between > CLONE_VFORK and shadow_stack_size would be helpful. This is the existing implicit behaviour that clone() has, it's current ABI for x86. The intent is that if the user has explicitly configured a shadow stack then we just do whatever they asked us to do, if they didn't we try to guess something sensible. The comment at the top of this block when where we check if shadow_stack_size is set is intended to capture this requirement: /* * If the user specified a shadow stack then do some basic * validation and use it, otherwise fall back to a default * shadow stack size if the clone_flags don't indicate an * allocation is unneeded. */ if (args->shadow_stack_size) { size = args->shadow_stack_size; if (size < 8) return (unsigned long)ERR_PTR(-EINVAL); } else { I'm not immediately seeing somewhere else to add something? --AJGmcN2ZtlBWZhny Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmVfQswACgkQJNaLcl1U h9DRagf/Qr+aRzdrHJh9fSSLcdVyPWWetGTynP7apYTbfIJNAFGrD8vDR4FbXIgo 3zI00sIHLkRQiHWty6m4u9AJ8XMLCYFmQimJNZLz7I25IjHPsLRBGP17h4VGUFKp MXKiwwy/MXn13Mt1wXsn+sizlovYp5rfd4+ta7JRpNb8w35xKAn/U9fvMeUgK/NT OGwo4JdB/YCubVh7D7diPSYIxrsmxqCn7Y3d2g5YODah+bndYUvTUvobke1ncRiT Z/MA21qSDAjVZ9izHDZOuR0/D0P0KhIELHWgYmVfrYYKDjQh2oG20edjGnd0KBBP RefBRVldWZfRr0LBmg/sGFYHxzOX9w== =EwkF -----END PGP SIGNATURE----- --AJGmcN2ZtlBWZhny--