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 EC4C3C46CD4 for ; Wed, 27 Dec 2023 22:20:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77DA08D0005; Wed, 27 Dec 2023 17:20:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 72D738D0001; Wed, 27 Dec 2023 17:20:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F58F8D0005; Wed, 27 Dec 2023 17:20:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4F7A28D0001 for ; Wed, 27 Dec 2023 17:20:50 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 232D0A1AAC for ; Wed, 27 Dec 2023 22:20:50 +0000 (UTC) X-FDA: 81614019060.14.DAC71B9 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf03.hostedemail.com (Postfix) with ESMTP id 4D09B20006 for ; Wed, 27 Dec 2023 22:20:48 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=t0wiXF5i; dmarc=none; spf=pass (imf03.hostedemail.com: domain of debug@rivosinc.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=debug@rivosinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703715648; 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=2tJU9l/YnXSfJWcO+44BoHgFXGz2Qdb3kbK4CGXTYLI=; b=e/RgXJ5m5qXkuo2IhwO+rXfBeqf5NzGe3PuRJeXvGGRiRiswtlV2qe2vbh07Gz0hdH/plA SSDPuPNOxwWo9Cj4RSEvLkuJvunrY5M+LRV94LsGJNi0faH+/8P+M5YOS+OoHQCXPRr8Cc 4WIns0Bbsl/sWwI7y7F++TV6mM/dKJc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=t0wiXF5i; dmarc=none; spf=pass (imf03.hostedemail.com: domain of debug@rivosinc.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=debug@rivosinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703715648; a=rsa-sha256; cv=none; b=4qdVRrpRf0mwPC/XzTVfXFtRhK/1wgd0GkIToXbLi6LFdWHjdgN6UmEkflp86EgxNrOW7s V4Qb4aokYtwk6cY7HqrgOvYj7lESpgRY7H+Zt2dbg96iYQ2uZZZOCEMAzKFe/QEg2mJY6L 489jNRFJmDrtFUPWtyikhBhTrlI44KA= Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-db4364ecd6aso2656178276.2 for ; Wed, 27 Dec 2023 14:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1703715647; x=1704320447; darn=kvack.org; 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=2tJU9l/YnXSfJWcO+44BoHgFXGz2Qdb3kbK4CGXTYLI=; b=t0wiXF5i+lRodcgTxSj16FtBSJ//FII0ylBUn4Vi+YAVaHfD2IHWY7ZTs7i9nI3sYS CHj6qnokvn+rcZJbkPAZwaRxG18H+HCDPG7NsVzPLY9fe2E3j1Wa2HwICjewknbExCEA Af4JcJFG74egxX1lOWAAzr52ynNrg48Toi54LT0JdT5XQMxvxNkWpWeWvOU69gOEQUdG S7k9bEQU3mACEHciknNIDkoIFZamenjIj3RfFgmvo26Ly/fBUUjyI9GWe0+7/ByGchB1 QZmupAdAfVlbaqA2xpxPI/KGY7+wTrmUqPZ1f8v4+NGkVhUr3jheIreJ/pNURachv7ys 8XXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703715647; x=1704320447; 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=2tJU9l/YnXSfJWcO+44BoHgFXGz2Qdb3kbK4CGXTYLI=; b=Q7obpQQG3jGlgraOV6E9NJMY59YOzRm0twcxI6804TEIO2ygrgq1EwvX59z15NlgVh KravZoGRw+Ha0YCITmECHd+pQywnDV5BtRhBNuFhIjzj14LHrMPk9HeOnS/af7mH+V8+ 5j3nCIUlWN2bKpxhddnTPG4QLbTUY2+dtNz/M+hw8GZTDiqU5wBoMitEGGDM4Vt7JWgG +/wUzX7DFFtelruzn4itP8GMmEwV79fzGZ34bInYKCVB6cPtsKkanYTDfuPF+Z0LdTgp tfJFP9KKtfeSV7uth5FkoeCid5VoGfaccFUPxYTPl/ENsZt+wFxlYhAoV57CnrXfN82v mucw== X-Gm-Message-State: AOJu0YxzjP6R9MuZ+4p4oEgYi69Wu4w5aFpfOiZE6VQUl8EVtUJiV5ER 8ZYNGWMOyxvsNmRCvFRvNkxDQvST86/EL6h8wqDzqfIpATBv7Q== X-Google-Smtp-Source: AGHT+IEHTZhlfm58S4gMevFkW7mXC+BltaXElG8mlV1aIzlykceOCs1WQVuqtwOEARkspBUD8pMj3swGMGJFDQZ9q/0= X-Received: by 2002:a25:ff11:0:b0:dbd:998:5fbb with SMTP id c17-20020a25ff11000000b00dbd09985fbbmr3007264ybe.99.1703715647217; Wed, 27 Dec 2023 14:20:47 -0800 (PST) MIME-Version: 1.0 References: <20231222235248.576482-1-debug@rivosinc.com> <20231227134514.13629032c39decdf1dddcc75@linux-foundation.org> In-Reply-To: <20231227134514.13629032c39decdf1dddcc75@linux-foundation.org> From: Deepak Gupta Date: Wed, 27 Dec 2023 14:20:36 -0800 Message-ID: Subject: Re: [PATCH v1] mm: abstract shadow stack vma behind arch_is_shadow_stack_vma To: Andrew Morton Cc: rick.p.edgecombe@intel.com, broonie@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 3454ki1si5a3pkfpd4am4z3xcrow7557 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 4D09B20006 X-HE-Tag: 1703715648-36154 X-HE-Meta: U2FsdGVkX19ki/gQdR2MFkMKnZgfBdvbzeyjkU3O2bRfSmuWSUCkqtfAQPJG53fXmSTDyBt47sqPRhtvIBe/E0d4aWK0NwzNQttOuPrBIE98e6b+1uwEAoCtsU1elUcZnkBx1KignSAsAy1MG5j8ruTn0yB1lRIZ/rF9HFEb/u9Sn4H5MgUDV4SzfbVZOtzkKgSD8t69YdP8hx1zWl+JHgE1yyCSY6TXKRV/nWngSzreW79dEHbCtryJFoYRFgwsq4vTmu/5bFl+kJMHu4aI1k8dBs71jrcJ5HieUC09mWBt22w3zjz81TCm6SwDskfBUqsk86PbLWaLXQHEWHfDEkll5jN1O+UfSwrbTj1sN3m+eFcyPYBTxdDhipRpimgOaZYMHA5AtEa+M9jTOqvwH4D00WkRvpFTPD9hHFN1TH/sMtnamnyjbF+cluPuQHSbAs+WwOkKo8yWo7czUfpfaJ+u6uogmSU/Sie382HdLyxauNICYAOup62+dyaTGf6SmayFlU83ro4O0iGGdOQ6Fil7BydR+2WOWePjQN8PVZgkgOc5XpdHfKCqkMbnf7wkupuTe2YUZLdj6mHJaWrPFYc5qyZ+CfkTUrw7rvjQb0VdcGDFKh4UxAMYQA5oI3NuoaOT3kOMuQJzNW/tBT4Y9qVaVy9TP596Elk6w1SZI8rwhq4rzD8Y3fYjuqZPpKAsbtiRxG7zsEkhPtxYYc90vPFPADSt3ZQZnDXdZUNO0JDpiIp8ju1xLOWC/FiAdV1KkWFVmGt1hMYdh30gpLoRxzMINWVRufP+GK5PddmO7FZgIMWzcC7zEgMtAbD6RDVhFpkPR6NWtch8PiktEUr8q8/6Btvaqgvct5Yll/dB8Qdk8xpxkuSnM+e9yL9RQcvqz2TBSuUrZIV1Y5bas3Xcha37ZJKcSnr/QH7gYNrEu4HL+jwFMlj1tD7r83UhKAqMePLpjBy+IrnGyA4c6EK W66PGTBD FwNt80F0VNt+ozZGW4iCLXyXqeWshp6exkMSZa/N/4GkA0mjLl+wyBrAUJNpQapJWakxrO1rE4HDUvmCmPckqP83frfGoTA9vk2rOQ08+eM5W1iYfLHN3baRm0NU1bE5KLITu0L01x7SLUw79l39ROS7jfH0jN80zImqLsTvnh4W6fc1CFD4MESXBy6T06Xk7kMUtVekoE/k83dmu9Kgprc0GI6XJlaFMplP15uN56RtVbrUaBG4ravNik6MUcG4EljHb/WdGuxQfyyZhnsD+54PBwLfkPtvLZCwiexLbQmhw7x3WJsBXLe+8rW5ZUizwkPQf+fHgmPuLK7VNXAeYsMuagQkp40tR7lryKQQhLD2TqZ40kWBOerLJ+mP2ecYJQyOuo91LQ9JmL+BXxbymIs3+4JweEFv+AiLzQS+mDfQq2OQASowZ42g4d0vZuvhcLNAFq2+d3Gk6A3s/vElhSzK2OEKwvLIcTsi93uHvRJlM/ss= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Dec 27, 2023 at 1:45=E2=80=AFPM Andrew Morton wrote: > > On Fri, 22 Dec 2023 15:51:04 -0800 Deepak Gupta wrot= e: > > > x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow > > stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches m= ay > > need a way to encode shadow stack on 32bit and 64bit both and they may > > encode this information differently in VMAs. > > Is such a patch in the pipeline? Otherwise we're making a change that > serves no purpose. Yes I do have patches in the pipeline for riscv. On riscv, presence of only `VM_WRITE` (i.e. (flags & (VM_READ | VM_WRITE | VM_EXEC)) =3D=3D VM_WRITE) would mean a shadow stack. And yes there would be relevant patches to ensure that existing consumers = using `PROT_WRITE` gets translated to (VM_WRITE | VM_READ) > > > This patch changes checks of VM_SHADOW_STACK flag in generic code to ca= ll > > to a function `arch_is_shadow_stack_vma` which will return true if arch > > supports shadow stack and vma is shadow stack else stub returns false. > > > > ... > > > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -352,8 +352,21 @@ extern unsigned int kobjsize(const void *objp); > > * for more details on the guard size. > > */ > > # define VM_SHADOW_STACK VM_HIGH_ARCH_5 > > + > > +static inline bool arch_is_shadow_stack_vma(vm_flags_t vm_flags) > > +{ > > + return (vm_flags & VM_SHADOW_STACK) ? true : false; > > +} > > The naming seems a little wrong. I'd expect it to take a vma* arg. > Maybe just drop the "_vma"? Well I did start with taking vma* argument but then realized that `is_stack_mapping` only takes vma flags. And in order to change that I would have to change `vm_stat_account` and every place it's called. In the next version I'll either do that or drop `_vma` from the proposed function name. >