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 F1CE9EB64D7 for ; Mon, 26 Jun 2023 12:45:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F88F8D0002; Mon, 26 Jun 2023 08:45:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A8988D0001; Mon, 26 Jun 2023 08:45:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44A518D0002; Mon, 26 Jun 2023 08:45:49 -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 3691E8D0001 for ; Mon, 26 Jun 2023 08:45:49 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EC1581604D7 for ; Mon, 26 Jun 2023 12:45:48 +0000 (UTC) X-FDA: 80944870776.03.822874C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id 7629EC000F for ; Mon, 26 Jun 2023 12:45:46 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Nr+VZhRu; spf=pass (imf10.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687783546; a=rsa-sha256; cv=none; b=bzyE2pz+vht1PSrabw/P2trn4N8M1e23emLt9XF3L5HUFd6aP3kGsaAe2VbMU44/uV0LEe qnwNawA+dHHA3YzsJCnsrJ4yhd58fQXvPivnHBt5Zvnn042nnFlO7Q7VGwP+QafG73ZzyW iOdodq/ZQq4bQG/a+nLR4FET+2abKS0= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Nr+VZhRu; spf=pass (imf10.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@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=1687783546; 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=ad7qXuxyTVm3Hup4TPrwUJSUzMHj6o5DDbnqUq5bBhE=; b=4kuSz1lYmGW/i1NM2VCD/YWCpSOLOExTAwT6nCVaFbr7//P4z0khyBqxAbDWgEJodINhtk f8BCrxraTMrkMQVO8IFzvxEwP7JJBlnlcuNmqQvFwdhGdAE+Q+o2Ctj64CrLKx1Xiy8jW3 +2YzMeu6WUlTDiLz6/w5fXmCi9tiAd0= 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 1D58160DFB; Mon, 26 Jun 2023 12:45:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9F70C433C0; Mon, 26 Jun 2023 12:45:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687783544; bh=ad7qXuxyTVm3Hup4TPrwUJSUzMHj6o5DDbnqUq5bBhE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Nr+VZhRu1S8TdcgB1G3LwUYdS5Mevc1gEG6wluGez0PuFw8p/4IWpVNl6aqJ1TIxN F1/LkWsR08SV4KNW5tSrRuJZt7z34scYrn27JUm9WtSj8gMjLja7ZndbPeUkbFvBgK 1GE5ZE40gU4zjajLs9XFuMXc9QVj7iXibAFLI08/a+NWNxkLulw1CB6n+0vhgCsx9h 13jHCc35DHf0VHZ186ZcCP1u1zY318iTOjEr6LgU4EA6z0nrS3N6DIUqli3Ero4CYr GguqwF7vUjUX8TmvlOgjhvtzHM0QK68M/Hs52b9FyPFG97Eq+mPCwcXXf5e09fH3gP k7KSDnuO7JCHA== Date: Mon, 26 Jun 2023 13:45:32 +0100 From: Mark Brown To: "Edgecombe, Rick P" Cc: "rppt@kernel.org" , "Xu, Pengfei" , "tglx@linutronix.de" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "Lutomirski, Andy" , "nadav.amit@gmail.com" , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "Schimpe, Christina" , "linux-doc@vger.kernel.org" , "peterz@infradead.org" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "dethoma@microsoft.com" , "jannh@google.com" , "mike.kravetz@oracle.com" , "pavel@ucw.cz" , "bp@alien8.de" , "rdunlap@infradead.org" , "linux-api@vger.kernel.org" , "john.allen@amd.com" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "bsingharora@gmail.com" , "x86@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "willy@infradead.org" , "gorcunov@gmail.com" , "Yu, Yu-cheng" , "andrew.cooper3@citrix.com" , "hpa@zytor.com" , "mingo@redhat.com" , "szabolcs.nagy@arm.com" , "hjl.tools@gmail.com" , "debug@rivosinc.com" , "linux-mm@kvack.org" , "Syromiatnikov, Eugene" , "Torvalds, Linus" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "Yang, Weijiang" , "Eranian, Stephane" Subject: Re: [PATCH v9 16/42] mm: Add guard pages around a shadow stack. Message-ID: References: <20230613001108.3040476-1-rick.p.edgecombe@intel.com> <20230613001108.3040476-17-rick.p.edgecombe@intel.com> <20230623074000.GG52412@kernel.org> <10673dd87c27ea9def60ff841ebd261d31b46568.camel@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FlQ2BtIHgZ0V+5nj" Content-Disposition: inline In-Reply-To: <10673dd87c27ea9def60ff841ebd261d31b46568.camel@intel.com> X-Cookie: Nihilism should commence with oneself. X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7629EC000F X-Stat-Signature: 3wpr5iytdhom8zqk6oewiw6az5bbqbpy X-Rspam-User: X-HE-Tag: 1687783546-460243 X-HE-Meta: U2FsdGVkX19qFUYJY8f/RmriQd8R8NdHfPwKO9SFTZM1cKxsZs9DyFuuyaajVVACtJTJ/qMvNyVfoj2AvkNuRojHw0KfmXhhQMUN1/ekjdgU3bPJ32W7v1OAydWcEziwLSpdr/nAVcHrdhgbtpVum0MRJMxgQhJ5UeC2G9TFYau2kxy5gL/pJWfJehV+CSBKtGKp+GR/lsp4V7O6aSDLFU29rQd3U5AiPcWbfr6I96PasooeC75genCjw7mXdcE8+UZXQFY9mDENZsGCWgGCJEWQrp/5hphungmoFMg+fgfaOFsRx/CcX9Do5HReeC6GPDXYDMSI4gqNyGM/ae7gTtAfjkMfgUUvlOlI1S1OyG0k7Wwty0HBkdlen1qczcY6eybvIHxWF5LE29dEIbA0GI4cx+oFOmh7gxaVLHFf64EIgrWm3rmP6Sy5XVBDOoSJwTViS69oVFPjthJxLEmdKZ07GQ2CZnWMTIG0mhWC22TdZAEWJsk9j4wynNzElvSHRY/hXMOy5JRgGgh0qaFKPGJYmhHvPlwl/CLGyILQCdTbfKoooYk71lRL1WlSgtj7zwuwE2iRuK17keAwSPtXuBx2XLe4PrWfb4rxFYlKTPRFAXGhnR6sP7dYQ7JMPyeusbrl4SgyqTsZQ8AXidCZA0NmnEFYHBOiUdS3a/3AJWVqguOdB6i+Hr/rY2DMqRgu2huIGPM/1e1Slriy6d3hzwftfbJ6hvF/37Cy4f7tsBvX5ZkXMuxuntyu3PzoWG74AWjiMerASPNnrEY1/XnGTiPfLOrS5EP/BNJ+JHHsWCLapOKPQ2YnbNB7FKAZeN7pG8Z4fUGS+gcv6O7nOEcpelg93eLa6vrfZ0kNs8y0knvsILLebueTJ5IFCfj9NEFn/wB5WmcUaL4ty1ur1jq1mexrtj74KhKoJOQufk2e7tQ2R98/xPK5fYMEmouBrJKyfJa4elKQwICCn9qb2Sl aDlODDLM CX2d6GT+wkAdbwoxvYUn14XeVg3k1jzVO7RyWkSUKLFTcWTYuVuewqfub5rpSxKIhMdgbg+qjf7pE3IwWgSJFTSk7rebosZ8MLSQLpbsugAg5Re6lgoM65YRhgYN9cCbU5XQkb5V1XTONOHOegWe6GmsUUsD28d2fzlXQ1alwAFkz8IHZsvJ9rFmZzKSyZtmZ/b2YHrBvEFUZxddv+u0T0n31m3QljTr5YPV2zwrh2InDLolVpq9hQRLFRd7l6DK61Z1cms8xNK1kGHbgk+FYtUJBTdmewNwMPu+wMn6fbhaw5AoScRNaDu1LuBwKgMWimrdvoaunlUH8QBEE+PJlFrfZ377csZ9DJ755dAGBSEgSlfSI0oahKtY17PvYMJ6JfD30YgmZ/WVjy99Yjdde30OUnGtd169PmHTuzdXGRE44xeM8+83MuVpfyOaRbNCC038UNsg8msTwdexzqGIwRDwikw== 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: --FlQ2BtIHgZ0V+5nj Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 25, 2023 at 04:44:32PM +0000, Edgecombe, Rick P wrote: > On Fri, 2023-06-23 at 13:17 +0100, Mark Brown wrote: > > This isn't an x86 specific concept, arm64 has a very similar > > extension > > called Guarded Control Stack (which I should be publishing changes > > for > > in the not too distant future) and riscv also has something.=A0 For > > arm64 > > I'm using the generic mm changes wholesale, we have a similar need > > for > > guard pages around the GCS and while the mechanics of accessing are > > different the requirement ends up being the same.=A0 Perhaps we could > > just > > rewrite the comment to say that guard pages prevent over/underflow of > > the stack by userspace and that a single page is sufficient for all > > current architectures, with the details of the working for x86 put in > > some x86 specific place? > Something sort of similar came up in regards to the riscv series, about > adding something like an is_shadow_stack_vma() helper. The plan was to > not make too many assumptions about the final details of the other > shadow stack features and leave that for refactoring. I think some kind > of generic comment like you suggest makes sense, but I don't want to > try to assert any arch specifics for features that are not upstream. It > should be very easy to tweak the comment when the time comes. > The points about x86 details not belonging in non-arch headers and > having some arch generic explanation in the file are well taken though. I think a statement to the effect that "this works for currently supported architectures" is fine, if something comes along with additional requirements then the comment can be adjusted as part of merging the new thing. --FlQ2BtIHgZ0V+5nj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSZiGsACgkQJNaLcl1U h9B3DAf+LWSA4bx8fTIOePWjXu2L6LeG9YG2PswlY0EfvmEvZtaSKmIszPhtMDUb 06vPe7GHKtgxB2gXQ0wUveNXqXUQRVDsuHmg7hAMEXzTGl+Ael3P1MSzNFV94LIQ Z3BXNKJk0egBAthRbZmyGcpj1sfp082RpsdI1a6dViRJwjd+ODTNI089CvNemY6b MJvmuMEJdjaRlrTGdfIBTdCKDNCqQQxqhMXBOcY5Hr7d9JLNa5JaWwfgyO0PbipH L20yRdqFhM5cEJ70RuHtQuyAJB/cDQlQZKUGJhTXwys+xbYjkZ9Dad1CvN4N1+SS E1ZXpzd5bzwITEKsBrkm9meQGQuK9A== =kRl4 -----END PGP SIGNATURE----- --FlQ2BtIHgZ0V+5nj--