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 64843C636D4 for ; Wed, 15 Feb 2023 06:37:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A8CA6B0072; Wed, 15 Feb 2023 01:37:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 931BC6B0073; Wed, 15 Feb 2023 01:37:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7843E6B0074; Wed, 15 Feb 2023 01:37:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 630B56B0072 for ; Wed, 15 Feb 2023 01:37:38 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 36620C1282 for ; Wed, 15 Feb 2023 06:37:38 +0000 (UTC) X-FDA: 80468570196.07.1BBC11C Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf30.hostedemail.com (Postfix) with ESMTP id 4E12B801F5 for ; Wed, 15 Feb 2023 06:37:36 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b="S+/FEIEt"; spf=pass (imf30.hostedemail.com: domain of debug@rivosinc.com designates 209.85.208.47 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=1676443056; 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=SkGPeLz9G3QwJ7k+VnCtMU3iYf1WQRR6SOIzc6kL610=; b=wVEuSzAsUZrQLLx+YhGUQ8P6kEANphoWsRRsmWVxm5WOP1Acviq4ZEbMv0CMcmS2YK5PDc E2OJIrPYnGTAOhXGWHBAzytGEgXaMBINoMmyzyfIBgN+tui767TdLECDet17HMpVja6ub9 fFY4mXy1ptUoCE+tFk2yKBrfPAjzEn8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b="S+/FEIEt"; spf=pass (imf30.hostedemail.com: domain of debug@rivosinc.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676443056; a=rsa-sha256; cv=none; b=pO4P09tKC7BBHAk9ZhjMfYGiWojNJjvHfA6AreX5IzjqlrHujkjssEWTcLUDzv6vv8/Bny ifVRH688gI3VZX0KL6ckDpXtBZ7F2zUiMiR4hW8IDjGq+YVyhNFx8++BjH+IcfjISp529H Q8MsEGNuKexQc0GBQYA6ArnFRrdyRT4= Received: by mail-ed1-f47.google.com with SMTP id w3so13529097edc.2 for ; Tue, 14 Feb 2023 22:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SkGPeLz9G3QwJ7k+VnCtMU3iYf1WQRR6SOIzc6kL610=; b=S+/FEIEt4gy30WD7pMHIwm4gBOKP21dIzeE16rtGdoMse6JZhBIma9C1lcV1OYwgIu r1jOJVEWnKOfuiJ6deWTFg9E2OZxOjOEBClujnGijJKrsnjEvr7HdH7IpoepWZDZoh3G gFZGO3THVBdThMTwxwVj54vwrK3rOqz63DdorxFDVNHgLAXhKvoFgzHWGFG9JalNErfv 3g3UJmFfIC8mn8OBnHqgwBRJxYAPVvFqszDtc08+DPqBxGbaSfW7i2Ar+Uom8gpz1Zgm jMZ0v0B4riYMskl5qnxraB7Qu7hQbEUcletQE/G+NrK7fEAvJa3fRXfG5jg7y5v0XKfr 2yqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=SkGPeLz9G3QwJ7k+VnCtMU3iYf1WQRR6SOIzc6kL610=; b=rfuXcD79rbKt/ZWIoY28H2vZC0mj+pjRYlz0Wud6BLfzhjB5vLrUpASN3IHJdV6A51 OyjS5C6tDLGp7yVFm9tMP8SiXYiIFKso0+WAP4TTfiP+TjJ7N90C244oETqQYko3Fbki /bvhciQBRSI/WkjNTPjlhtrwn4QHY/Vzxj5ahoNlWrigSA8MWsf5MHTI0LcuctLMsk2X kX/R8yQGAua2ckEX+96nXi3LGGP+GCqc7uQSWiWSOxZWr4FjmjXBSkwn0fWzwjXh6VNG ZyNGNLhK5xFWTp/rzymIm/Fp6XW2ztFF61CJt3pLALRFrQtKEvGUyZHcT1VF+nvpBFZY Ns9Q== X-Gm-Message-State: AO0yUKUZLP3K8fMd3Bx5dt2LWc3yg8wR7o1ilJhtVZR28vjjFSnsMSjB iQlMQqdJSt+M3p4f2YZeG0R0x8DctoKDji7MgGZ1KA== X-Google-Smtp-Source: AK7set+qXiQiB9x9uCSwZk1QYwnxZY1Eg0UWlqo7Q/oouHLaAgH6SKW5Si30EzW4dwAZHuh6nm4kP34VtzMPlMZwUBk= X-Received: by 2002:a50:d717:0:b0:4ab:49b9:686d with SMTP id t23-20020a50d717000000b004ab49b9686dmr434737edi.1.1676443054782; Tue, 14 Feb 2023 22:37:34 -0800 (PST) MIME-Version: 1.0 References: <20230119212317.8324-1-rick.p.edgecombe@intel.com> <20230119212317.8324-20-rick.p.edgecombe@intel.com> <20230214000947.GB4016181@debug.ba.rivosinc.com> <1dd1c61c69739fde6db445df79ebbbbec0efe8cd.camel@intel.com> <20230214061007.GC4016181@debug.ba.rivosinc.com> <9ea047ed05d75822991325b709f583ee10b0fa34.camel@intel.com> In-Reply-To: <9ea047ed05d75822991325b709f583ee10b0fa34.camel@intel.com> From: Deepak Gupta Date: Tue, 14 Feb 2023 22:37:16 -0800 Message-ID: Subject: Re: [PATCH v5 19/39] mm: Fixup places that call pte_mkwrite() directly To: "Edgecombe, Rick P" Cc: "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Yu, Yu-cheng" , "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "bp@alien8.de" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "Yang, Weijiang" , "Lutomirski, Andy" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "linux-doc@vger.kernel.org" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "akpm@linux-foundation.org" , "pavel@ucw.cz" , "andrew.cooper3@citrix.com" , "john.allen@amd.com" , "rppt@kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: oczuojogehfqk545snrxnr4ub5uy37n1 X-Rspamd-Queue-Id: 4E12B801F5 X-HE-Tag: 1676443056-478637 X-HE-Meta: U2FsdGVkX1+ogPMFgZEQZ3YT9HGMZVv6pKWz1erFZ3Ha9iduCuet6TvAAyOXKLrUEPwrXd4WIfnSqvJnnZr3UyHWMX79VxrgBTGjr7Uim7dnpyyI7r50NdZ+NHCSCPW73cZllhh3MzH9QzDmJj9STUPyMKvkD6c+lbilTiFzD/pDq6hBUbylSaM/snNUGoJuVqb7jTlx6XN47jgLK43lbiF0hG4+BIpw2fGpyGrbzJsYlNj9Vx6ANEu5LIj7FjAzWI8ryT8L1vtmqbGxHg6e0cZb5GCxH3yxvw/kAiZqZKamdReyAUAsdRSCLuuv3Vo6NSxZ5atw+LPIfqt1j+U3s6rNriLTvxkm9ee6GM59pdnvjS5eka3bIvgcCgcqdUyO6u7xWSbruR1oCU0sdWbb6qnrOg7I9+m1GqLN+cgHdxHRyOi//QpBhSownILvDEnwEHDOFcqNgmiAerxiPsnF2xTwTPX5w7aNpC3nMBEro/y3OxlCleI+lF5Os8jh+7Lj0h83uLxlW6FINQdu+lozMZeMv9mb7pz1R76UGazxydAQEMiByA3z9zn8WRrqcGFf2U6RVp509IFKr7qBnptxLZAA5xvPfpaNl6M3rj+jyxqJjN5/vpYw+FgjBWd1bUBeNmqwZ6hgdg0bz+4wAIMHUaqHRVaGn5dQyBr5HeyNo1b/MDNqlE32vG3D+B+w4twwBZIZ/mdT+xVrdxw+zGRi/8tYvGD0lECzr0pYqcTzpUOG8xIYJevwzfyW3eSsqdXXJotesMqpLqyHvcYg36rmhxOMGBvj1HDbMui6eu6D7WwVha6cK7nyzOzgB3Kf8UmdaA03/UYJE2joQ44J2Al8I1fBArjeICQUy3JCowoivk+heQ5X43+pSJ+WFm7KsGJlq/6Yrg/PJIhwJodmR7UpSg1g4bXJGx5PYRpSHfzduA2OtSAZqcBFfaqC8jpO8EjjPznfng5jx/ScgsbhWzj u49amOlw htOTAu+l3QgUnGNkN/Tf1/zBKfAOACeg4vzjjQxtfKcy313LebzYgdpKoXdV12D++/03Kg3vwny0LJpmhdxqgyaQ47i0xaT7eIeSJXQrCidJ/0MZl46UvM9/L6GRTSG2zcB1u6hN7vzT/AKml5j79Daer8mVxc7x+QTWX/Q34N7io+bCHnYaiB6nDQqrSF3LH2twAFNi3mAH2DhvSjCYNB8QNb5NzIvSf3ahzWrYVLpH79gPvqgm4JgrOYH6KLdNj1GBkk386Z2PWj1ExlLLhRD/3zb9XXGtbenUz4Bu5nEVrvdaAZBM3giLoA/cJ2VNHTNYZCUg1W0RZEdu3CLADSs54S7YGSpAdlfwWESBPF9hFjUAQHatCAQTaHoySV6oPhAj9MjrXFdsGsTvztQ9HZGtczL3/j3TkjjDmEMq2AGEpJe5/AKlZl9FvzkIEO9uwTrKxDOy0xGCjtb5G4VasPZ6rk+zZnE5C9OMtFdprYt0G1a9DpLIMm1NW8STFAL3ET8e6hXUOG/A3cNXqF3G4hSN0UN9uww6hNeC0mktueGKVjLAKzNJPWPMwYe6uwGyv0yFL8I2OErR2Lfb7S8UaBZkGMg== 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 Tue, Feb 14, 2023 at 10:24 AM Edgecombe, Rick P wrote: > > On Mon, 2023-02-13 at 22:10 -0800, Deepak Gupta wrote: > > On Tue, Feb 14, 2023 at 01:07:24AM +0000, Edgecombe, Rick P wrote: > > > On Mon, 2023-02-13 at 16:09 -0800, Deepak Gupta wrote: > > > > Since I've a general question on outcome of discussion of how to > > > > handle > > > > `pte_mkwrite`, so I am top posting. > > > > > > > > I have posted patches yesterday targeting riscv zisslpcfi > > > > extension. > > > > > > > > > > > https://lore.kernel.org/lkml/20230213045351.3945824-1-debug@rivosinc.com/ > > > > > > > > Since there're similarities in extension(s), patches have > > > > similarity > > > > too. > > > > One of the similarity was updating `maybe_mkwrite`. I was asked > > > > (by > > > > dhildenb > > > > on my patch #11) to look at x86 approach on how to approach this > > > > so > > > > that > > > > core-mm approach fits multiple architectures along with the need > > > > to > > > > update `pte_mkwrite` to consume vma flags. > > > > In x86 CET patch series, I see that locations where `pte_mkwrite` > > > > is > > > > invoked are updated to check for shadow stack vma and not > > > > necessarily > > > > `pte_mkwrite` itself is updated to consume vma flags. Let me know > > > > if > > > > my > > > > understanding is correct and that's the current direction (to > > > > update > > > > call sites for vma check where `pte_mkwrite` is invoked) > > > > > > > > Being said that as I've mentioned in my patch series that > > > > there're > > > > similarities between x86, arm and now riscv for implementing > > > > shadow > > > > stack > > > > and indirect branch tracking, overall it'll be a good thing if we > > > > can > > > > collaborate and come up with common bits. > > > > > > Oh interesting. I've made the changes to have pte_mkwrite() take a > > > VMA. > > > It seems to work pretty well with the core MM code, but I'm letting > > > 0- > > > day chew on it for a bit because it touched so many arch's. I'll > > > include you when I send it out, hopefully later this week. > > > > Thanks. > > > > > > From just a quick look, I see some design aspects that have been > > > problematic on the x86 implementation. > > > > > > There was something like PROT_SHADOW_STACK before, but there were > > > two > > > problems: > > > 1. Writable windows while provisioning restore tokens (maybe this > > > is > > > just an x86 thing) > > > 2. Adding guard pages when a shadow stack was mprotect()ed to > > > change it > > > from writable to shadow stack. Again this might be an x86 need, > > > since > > > it needed to have it writable to add a restore token, and the guard > > > pages help with security. > > > > I've not seen your earlier patch but I am assuming when you say > > window you > > mean that shadow stack was open to regular stores (or I may be > > missing > > something here) > > > > I am wondering if mapping it as shadow stack (instead of having > > temporary > > writeable mapping) and using `wruss` was an option to put the token > > or > > you wanted to avoid it? > > > > And yes on riscv, architecture itself doesn't define token or its > > format. > > Since it's RISC, software can define the token format and thus can > > use > > either `sspush` or `ssamoswap` to put a token on `shadow stack` > > virtual > > memory. > > With WRSS a token could be created via software, but x86 shadow stack > includes instructions to create and switch to tokens in limited ways > (RSTORSSP, SAVEPREVSSP), where WRSS lets you write anything. These > other instructions are enough for glibc, except for writing a restore > token on a brand new shadow stack. > > So WRSS is made optional since it weakens the protection of the shadow > stack. Some apps may prefer to use it to do exotic things, but the > glibc implementation didn't require it. > Yes, I understand WRSS in user mode is not safe and defeat the purpose as well. I actually had meant why WRUSS couldn't be used in the kernel to manufacture the token when the kernel creates the shadow stack while parsing elf bits. But then I went through you earlier patch series now and I've a a little bit of context now. There is a lot of history and context (and mess) here. > > > > > > > > So instead this series creates a map_shadow_stack syscall that maps > > > a > > > shadow stack and writes the token from the kernel side. Then > > > mprotect() > > > is prevented from making shadow stack's conventionally writable. > > > > > > another difference is enabling shadow stack based on elf header > > > bits > > > instead of the arch_prctl()s. See the history and reasoning here > > > (section "Switch Enabling Interface"): > > > > > > > https://lore.kernel.org/lkml/20220130211838.8382-1-rick.p.edgecombe@intel.com/ > > > > > > Not sure if those two issues would be problems on riscv or not. > > > > Apart from mapping and window issue that you mentioned, I couldn't > > understand on why elf header bit is an issue only in this case for > > x86 > > shadow stack and not an issue for let's say aarch64. I can see that > > aarch64 pretty much uses elf header bit for BTI. Eventually indirect > > branch tracking also needs to be enabled which is analogous to BTI. > > Well for one, we had to deal with those old glibc's. But doesn't BTI > text need to be mapped with a special PROT as well? So it doesn't just > turn on enforcement automatically if it detects the elf bit. > > > > > BTW eventually riscv binaries plan to use `.riscv.attributes` section > > in riscv elf binary instead of `.gnu.note.property`. So I am hoping > > that > > part will go into arch specific code of elf parsing for riscv and > > will be > > contained. > > > > > > > > For sharing the prctl() interface. The other thing is that x86 also > > > has > > > this "wrss" instruction that can be enabled with shadow stack. The > > > current arch_prctl() interface supports both. I'm thinking it's > > > probably a pretty arch-specific thing. > > > > yes ability to perform writes on shadow stack absolutely are > > prevented on > > x86. So enabling that should be a arch specific prctl. > > > > > > > > ABI-wise, are you planning to automatically allocate shadow stacks > > > for > > > new tasks? If the ABI is completely different it might be best to > > > not > > > share user interfaces. But also, I wonder why is it different. > > > > Yes as of now planning both: > > - allocate shadow stack for new task based on elf header > > - task can create them using `prctls` (from glibc) > > > > And yes `fork` will get the all cfi properties (shdow stack and > > branch tracking) > > from parent. > > Have you looked at a riscv libc implementation yet? For unifying ABI I > think that might be best interface to target, for app developers. Then > each arch can implement enough kernel functionality to support libc > (for example map_shadow_stack). > >