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 31592C74A5B for ; Fri, 17 Mar 2023 17:28:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A72736B007B; Fri, 17 Mar 2023 13:28:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A22536B007D; Fri, 17 Mar 2023 13:28:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C28C6B007E; Fri, 17 Mar 2023 13:28:15 -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 793426B007B for ; Fri, 17 Mar 2023 13:28:15 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 41EB4C01EA for ; Fri, 17 Mar 2023 17:28:15 +0000 (UTC) X-FDA: 80579073750.04.A731F90 Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf29.hostedemail.com (Postfix) with ESMTP id 58D8B12000D for ; Fri, 17 Mar 2023 17:28:13 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=AVJAcOWp; spf=pass (imf29.hostedemail.com: domain of debug@rivosinc.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679074093; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Tgr4FzdJQUvv8sxqD3n2+NEThU5C851YsP5telCNKqc=; b=nW4tBS6IshWzMtH15fh33U8l6Z3QHfdOy875FFCZHa52qGnJpvZHrL9B/IRYqyM8mUJVpK ptbk/striAX4Ic2xZi7djG8cupaAnv916U5y4Ahk13jZH/zUE/DKULZeTJR7P1dL2VBVPs Ub044PqkDiVwFqtyy/5SfGm54xuxV6I= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=AVJAcOWp; spf=pass (imf29.hostedemail.com: domain of debug@rivosinc.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679074093; a=rsa-sha256; cv=none; b=hgUtn3NroBc67PNIsU+4hWDe7U4qkkCWKUI/K31z5DrPshzhDrWi0oDzTw/IiLEgwAXo+K 9GP4+JsVggcciNTgBfIq597JgAKzg05Z0Z2fIL6IokwylyK1YSvLGPCnCEFA36SFbcgTLo yA4gxpS7rIWKoaX0tbR6Qf5wz2by6Bo= Received: by mail-yb1-f171.google.com with SMTP id t4so6500627ybg.11 for ; Fri, 17 Mar 2023 10:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1679074092; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Tgr4FzdJQUvv8sxqD3n2+NEThU5C851YsP5telCNKqc=; b=AVJAcOWp//de/0qDhs3JXDyEG3wxRVQTCv1ru1HtbdhiRMIDKdXikzGW3RRw0fucvE VlB4zbOpDjPDB3ZElOjSCBckSPk1pFTIop+KtLRwQg6lMvKT5ZKvpMNtyfdKbzQsOhKc VDdc3Mm9tfcxn4dUeSa6w+E1LGqCBoha1ACyLYbR8J58ddMQJg+Bz8lEZjTnLAAGcaVN GcpTFBtPbde0FVM9WEaKk7OArNKido3Y4beg/x0rykBtwZCx4p5FouxY5j8foPMGD4Db BbK2BZB1Mq/I9a/AedKB6pO0RcEa0EQ8G6ApBBOp07MNGZ1ocDykMr8AoSuFPgLOuQKV udRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679074092; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Tgr4FzdJQUvv8sxqD3n2+NEThU5C851YsP5telCNKqc=; b=70DucpWzAzXd2F3Kk9uQ8Ra72BReCYT5amNqDl87vnYjHeG/jCSaERxMSXbOXwwl5s 1S0UFzw7zpH+5BABt52+qSMlYVLT2g/IR/fKNn4SStUsDO9xofUIiM8SKwipjafZeEZi qHDfTjbIAIXdHRmevQpS8XiYVh8RSb1Aa+cSCUuqtA4ZSqnEG+PMGdARUbqnVe5ZYi0v Hg2m3Sz0UeScFrarI2hJpJwHJYE4JGYOpqpFS+JGUGcmBkoy/Cdmn2wi7vn6qUwE3WxP cIdnfy0Udhr2Cpmp0/LCuxIlHaxvsIGylUJUmfzkQmlkVUsf8Tik93ywJWqzPstjqpZo YKwQ== X-Gm-Message-State: AO0yUKXKW85DjQ+l7d8MzgvWYwNBm0/jxZASriKBWQuoozKNVtXc/qBx QzX+mv1HwX2CQiyXRA87t0NOPJbbbfraDhsB9rjwUQ== X-Google-Smtp-Source: AK7set/RbsEZazIS5BwsZiaD/X/kDFc2no4aoSIrcxUs6+4E8c1A8bsJPb7czfxiV4RlDZCemGAGqyHD95or4DWx7m8= X-Received: by 2002:a25:9385:0:b0:b46:c5aa:86ef with SMTP id a5-20020a259385000000b00b46c5aa86efmr148517ybm.12.1679074092398; Fri, 17 Mar 2023 10:28:12 -0700 (PDT) MIME-Version: 1.0 References: <20230227222957.24501-1-rick.p.edgecombe@intel.com> <20230227222957.24501-23-rick.p.edgecombe@intel.com> <236ae66c-fafb-80e9-d58b-6b18a22071c1@intel.com> In-Reply-To: <236ae66c-fafb-80e9-d58b-6b18a22071c1@intel.com> From: Deepak Gupta Date: Fri, 17 Mar 2023 10:28:03 -0700 Message-ID: Subject: Re: [PATCH v7 22/41] mm/mmap: Add shadow stack pages to memory accounting To: Dave Hansen Cc: Rick Edgecombe , x86@kernel.org, "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H . J . Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , Weijiang Yang , "Kirill A . Shutemov" , John Allen , kcc@google.com, eranian@google.com, rppt@kernel.org, jamorris@linux.microsoft.com, dethoma@microsoft.com, akpm@linux-foundation.org, Andrew.Cooper3@citrix.com, christina.schimpe@intel.com, david@redhat.com, Yu-cheng Yu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 58D8B12000D X-Rspam-User: X-Stat-Signature: fsdit6p3uwnjrn8fxftkypke3fj73fcf X-HE-Tag: 1679074093-761911 X-HE-Meta: U2FsdGVkX1+uRtH8163lS/fUPO+7kKEHVomRjXcerxlZSz9CpErkxIO/05nhPc6l4flmF6Uuz4CIlUITwnbrT2HEPqa9FkHhyrXM1TiJH9JxhmncteIaBi4QxV7usM+KQxSV2++qgioIQl6nVA5tFu55ZsVJ21AtlFSstAE5q/+UeIF4mAk13MYZ+MFwzL+QUUslzVGV+m0SvV+YzgWLlR0/I3w15fkbNLOq9gQ6g+H32QEuZaAuzRvC+RS0ctuV8NZFMFaBTcn7Jkhwy5SFVqpe3XNaxEBmf5wtYT/+zWs3i/te5tjMQqnIZMYh742bjH7ha77kN6KcX6NnkF55ejnmpy1STZewujh2dfp0IyXKrW9Nv/kc8XLQzBivpxlmu6oU5AtjOq7obTCxDqR68wQo8XWU6nBWY1/h+taB7nbluHG5K3TkyMubDCBThpUYyws5Af1+sfEg5WvaUrXh9YF2A6QNE5Zlvn7OsWZXrthgAQalUD8cwu/36NRLec3ZkazJnh4xG2ohXS9KyfGo4F2D6Mdn5FCjMbPw/KD01YauxY5w/Bo0TIKIU4oSLFKZ1Nm7TW12++wwa/THOqzmjqNiXnWt3CmwElkUVj7avxlBk+WxiAUQuq1Vob8mrVEOZXKYxXYh72bHDPWcOxUvy6pgHSk0hOWA8Zj+5usu2yhvMpHbCqZJKiriiBCa90oBr9t+5IHhF8c0FDGSD9A+q3/TkOMx3jtHEZB20E7o/knopC9gpeYOuFC3vOjyu6pjFMMX1/v5hjLU0OYD4EnWXYW8anQSXmkOrdWQnAwcraDh5KHozLwrRSHwn65zSdlP+NRQwiPrtpT+HDyF0C9awo+mn4SocGNdha7v2FHgyAa30+gYVytIaIu4W9GlL4bQGWx9qAqITPfNKjZKTGaPNctXuWuYc+wVdByPzFJ6Pn+PMl4hejwZPKDBa/Cb7PgmRRfZSRmCblsAWJ0/GWU P88YKNmA Swygffd0XxhJlM8dFShhCd76FyeW6pTxjFqyVZWJG6tWsPcP0+a0PS30/7n0PhApeNWJY5wngDYz/7v4g/kxIPhF+QqKDjOGeviHQKOGhJBkiPdCX38GGsuX9q5fTl9sV23wb8PL1FFad8i4dntTDEYyjJ1vPFY3exjQIvV2H5RJzAWfTXni+QQ8DLlgVwb7yo1tSxdHZedr1eIu8XW/IQFYjKmeIuu6XfkGASyJ1RJbMoXLtpi1b9w1WsfmBP4VO7OloXsJ4gvHP7tcB/hZVP0Zc83P1yC5I+Gky8517hPiIpgIZMt+rd8EN3SR0aPtTosutI+C1DBP03yCJz9PA/PXbAZOXRK5c4+CI40cq2lMhWYvApk7BRZDybcPlq7s5UTBk 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: On Fri, Mar 17, 2023 at 10:16=E2=80=AFAM Dave Hansen wrote: > > On 3/17/23 10:12, Deepak Gupta wrote: > >> /* > >> - * Stack area - automatically grows in one direction > >> + * Stack area > >> * > >> - * VM_GROWSUP / VM_GROWSDOWN VMAs are always private anonymous: > >> - * do_mmap() forbids all other combinations. > >> + * VM_GROWSUP, VM_GROWSDOWN VMAs are always private > >> + * anonymous. do_mmap() forbids all other combinations. > >> */ > >> static inline bool is_stack_mapping(vm_flags_t flags) > >> { > >> - return (flags & VM_STACK) =3D=3D VM_STACK; > >> + return ((flags & VM_STACK) =3D=3D VM_STACK) || (flags & VM_SHA= DOW_STACK); > > Same comment here. `VM_SHADOW_STACK` is an x86 specific way of > > encoding a shadow stack. > > Instead let's have a proxy here which allows architectures to have > > their own encodings to represent a shadow stack. > > This doesn't _preclude_ another architecture from coming along and doing > that, right? I'd just prefer that shadow stack architecture #2 comes > along and refactors this in precisely the way _they_ need it. There are two issues here - Encoding of shadow stack: Another arch can choose different encoding. And yes, another architecture can come in and re-factor it. But so much thought and work has been given to x86 implementation to keep shadow stack to not impact arch agnostic parts of the kernel. So why creep it in here. - VM_SHADOW_STACK is coming out of the VM_HIGH_ARCH_XX bit position which makes it arch specific. If re-factor takes care then I would say the 2nd issue still exists, it's better to keep it away from arch agnostic code.