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 B1348EB64DD for ; Fri, 23 Jun 2023 12:17:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE1518D0002; Fri, 23 Jun 2023 08:17:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6AA48D0001; Fri, 23 Jun 2023 08:17:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE3958D0002; Fri, 23 Jun 2023 08:17:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id ABC958D0001 for ; Fri, 23 Jun 2023 08:17:37 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 70C38A05D8 for ; Fri, 23 Jun 2023 12:17:37 +0000 (UTC) X-FDA: 80933913354.13.F1AE433 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 8C17E140002 for ; Fri, 23 Jun 2023 12:17:35 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hDEa6UrV; spf=pass (imf09.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=1687522655; 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=akQ5LM2kZ15r5wYk0nrURYOsNMjO2oyEVPCccL8a6qc=; b=MOr+j3hUsO9ogPQrEJGxvU/14Wfh85aY+eb3Db0v/4gVh3/Jt/C7D/uzs6eYfNcDS9dbOv hFtjWgAqOHvAHycNQN27bmoyJXVQfxwa1fhpK6wtSp1JmtOHIDmDbHNkDSviQajfHR4StJ LiSDKTwh/FGo02xTfAjDq8o3beFgXy8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hDEa6UrV; spf=pass (imf09.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=1687522655; a=rsa-sha256; cv=none; b=UcVmjYgyiKkppi3t7d3tM9TE5xIXojsJtI+ZgdyPpW9SdFhEuLSdTZUOmctaIofq2cTNxD tRjsgqcYNVUmQRyr2+6cOy5A+s1jzkfm5xAglyyusJZcg2FROzOiPMNp9tRQ1YsqbUSNnQ N6y9PfTdUWna3vow6uuPKM7BIZfWZbw= 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 72B0661A22; Fri, 23 Jun 2023 12:17:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BAB1C433C0; Fri, 23 Jun 2023 12:17:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687522653; bh=+7+qY2pMjJYzB9xElhuCVbaU19w3qgAqAoglFmxdPOA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hDEa6UrV+PRl4gVbTIs/hZdUDvZIr/H1xBTlK856m60e8pDuMAFgtOA4E3Z+w3z2D L5qHQY1QuSFJyDb835gTkZn9vNoLgcUDeS567rvnfVqqQmxnm/U87TD/gujZr5Sawj W10+cvRXWfs9IHCtOP66qOmtqejcXkPuYGHArVW+bdHP9aRvqAkXM0pDMmVl6Df3If +SXba9qDA+VmFbFbl1P5my5mcIug+uUU/y6LYNbRZ+HRwXY55CCmpQk5FAd/mQA6V6 RfNnSnFbUxxfGDa4ALqAaV256v8TnBRhKXif0TKoHSuCMYPNVzOMh8o7h99c36o31G Jt4nQ1NE2izFA== Date: Fri, 23 Jun 2023 13:17:29 +0100 From: Mark Brown To: Mike Rapoport Cc: "Edgecombe, Rick P" , "willy@infradead.org" , "akpm@linux-foundation.org" , "Xu, Pengfei" , "tglx@linutronix.de" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "Lutomirski, Andy" , "nadav.amit@gmail.com" , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "Schimpe, Christina" , "Torvalds, Linus" , "peterz@infradead.org" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "jannh@google.com" , "dethoma@microsoft.com" , "mike.kravetz@oracle.com" , "pavel@ucw.cz" , "bp@alien8.de" , "rdunlap@infradead.org" , "linux-api@vger.kernel.org" , "john.allen@amd.com" , "arnd@arndb.de" , "jamorris@linux.microsoft.com" , "bsingharora@gmail.com" , "x86@kernel.org" , "oleg@redhat.com" , "fweimer@redhat.com" , "keescook@chromium.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" , "Yang, Weijiang" , "linux-doc@vger.kernel.org" , "dave.hansen@linux.intel.com" , "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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6xcRS/HNRY4aTkhh" Content-Disposition: inline In-Reply-To: <20230623074000.GG52412@kernel.org> X-Cookie: Slow day. Practice crawling. X-Rspamd-Queue-Id: 8C17E140002 X-Rspam-User: X-Stat-Signature: 4a5kepeudg33tjge7bg9c1hntzmmis4t X-Rspamd-Server: rspam01 X-HE-Tag: 1687522655-328685 X-HE-Meta: U2FsdGVkX1+0bVQm1dVolLFianeO/TozjskZ6TKsCf7Au8UE4gLn4AhH9MGtKg8L4OnX6q6pLdPYz35AMczZ1PiUVwPS/oP8kProh2/jFUzrmBR2B7vuWKcqGatQNXo8Zf8TjVL9L17cHX+lO+VT91Z+wiF5hbCtI0DvWG2vS47emoNuU5ylAvPc790ZPtHuYVa99KXcWKQw7ESsxTQ2HqQoHl6FsmI6mvNpzUvmvl+psb4l/CgyfGCF2sy8f8imQcuBPJYn5DhB4ZRBAEwtS6Q4kBDvgtSLQc6F2+ysATtvcIQRniLJsXmIqaYWkoaR6mhQpPs3d9BAK8Gj94VgHdEhMwolhGspElNZUZHUgCGJL5vsEEC+dxMNMqxq+sgN+Gr8eJPmGe/Djq0KbvxNJ2IMFnOp939Gh5z4nXFGtADESgpFQ+YVVJ+w+LZEbS6Q+lJW6ZrGERcdlREnSGzEIf44yu52c9MCQmZnJ7JI2CqQ/fG0uuVC/VdH32wCqrv0D5/4vJFxVYcb7q8DwoCjLP0U2PZJU2qVzmPmOEBup9Gjlk3P8yxlRTX7CQu7ueQGg5Im3tndP2tdP0FuUrItyIhOw0QGFW03d8ig70Votws/f+RI7OGngpjcLX7U4pWqMVsvLDSbiHVigRzWVA0vpwsAIkHyCRw5HH3xOcoBZ2TUkEPFmspXqhPpar8welnXz5KUAQ5/innDX/PTeHXXga7xN6TJvDZK5hAM+dQIV0QtfZb/zy9/Z/ZgLv244Bu4tIuEsDNMj42W3bAnaa+aMXrucaV6rAS5sMaNl4t8fXdJmFA8lJ9t2Q5xezd0qST4tkQr1yibKPw1nZgTtSZHgPfyP0qs4JONHIbRJC7y8amaHxq8nD58xZzl7cXauw3gwrtvxhmWQDdCz3blPRVL7wFgE/Z5FoHBz/3h6RV/wn8GEAbYH48VsJeWbAQSDafdjdfB0o+iVo0eKRZDWbx zj94MscB J4TLaDiQeqWzkMYuFUSLyjZOeppTREqX2zXnuyVU60/sp3NQDS7t06ciH9qKfwl+kka35UqXniLfUdITsZo5M+/BFn6LGRz2FhaV5qaPvQ9/VjoKXpFa8S1gXRw2ovIVnBaZVrwc0daQVksm65NNYM+5wZIvEN3986MXqTodQ4AZH6n71ZxS8stfJG4aMufkmhjdOvLaelOlFwcSNccfy/hNRQEoJkohkL8DhdZLg1NzxY2BR2G3DPDAyt2DymyjKhjvfBlvLMjjTYw53IzESeOLiTiPAf+Xcf61SkfFG6xUMSy4iUmsA9vjtxCsW9rJlp6CCW9PUL44GHI8M5e9rUXzxc/jaQcK/RB6WeY+dtSzwSh4C7zQg4HA3HCWhJWt6+L51vlu2VVzcmRx7tr42EdWiv11lDKjh91BO+HTkQ+DnCBrWRpLpsw+LDM6dr9wWPWSrv+9aN0u1BxZ8QJl2IrB2Dyu6yOcD4YBBI8L66qjozZz+ccBVQleqwQpaGMTEV+IpClTgx+b1yumISmjWs9DBMWnOwmcDp9Le 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: --6xcRS/HNRY4aTkhh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 23, 2023 at 10:40:00AM +0300, Mike Rapoport wrote: > On Thu, Jun 22, 2023 at 06:27:40PM +0000, Edgecombe, Rick P wrote: > > Yes, I couldn't find another place for it. This was the reasoning: > > https://lore.kernel.org/lkml/07deaffc10b1b68721bbbce370e145d8fec2a494.c= amel@intel.com/ > > Did you have any particular place in mind? > Since it's near CONFIG_X86_USER_SHADOW_STACK the comment in mm.h could be= =20 > /* > * VMA is used for shadow stack and implies guard pages. > * See arch/x86/kernel/shstk.c for details > */ > and the long reasoning comment can be moved near alloc_shstk in > arch/x86/kernel/shstk.h 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. 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. 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? --6xcRS/HNRY4aTkhh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSVjVUACgkQJNaLcl1U h9BV1ggAgSOn8u1kb6HeUhHTldAbqy+XWNhMN9/fILZ0CP9sw4vUhTHZa0SfygRu BJ/QiMVJ00xJd26NTnXoK5gLBGmz3qDSpX6JxHhytRM2zLh1KS8tZkEYS9kehwrl Iiqgg53zg31Ir/5LJ7PsBQ6SAd4rfE5aZKG8NAR653jLr2SRMEd3BUx8ZJj6/Re/ MpKQfBwU9ltLLEOS6xI0+f0YibTkxPcKp9+zMXWi5+xDCCxdhPxpcFok7ZcBpaOj 2ay7LhRYRsKziXpV3Y4RorbiXt7zgehqryMShTvoTswU2LbkxdP95Ob3nHVTRW+s P+ACzWi6uNUFXQ1Ko44YzoQboSpPPA== =ssEI -----END PGP SIGNATURE----- --6xcRS/HNRY4aTkhh--