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 08B3CC6FD19 for ; Thu, 16 Mar 2023 19:30:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74C1A900003; Thu, 16 Mar 2023 15:30:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FD35900002; Thu, 16 Mar 2023 15:30:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C391900003; Thu, 16 Mar 2023 15:30:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4A482900002 for ; Thu, 16 Mar 2023 15:30:55 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0E6D0161525 for ; Thu, 16 Mar 2023 19:30:55 +0000 (UTC) X-FDA: 80575754070.13.C545970 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf23.hostedemail.com (Postfix) with ESMTP id 8990614001A for ; Thu, 16 Mar 2023 19:30:52 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=aZUr5Hc3; spf=pass (imf23.hostedemail.com: domain of debug@rivosinc.com designates 209.85.219.182 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=1678995052; 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=OQinqcAul9N1/k6Qm0xi6TTExDZScG0p56fu1+mj3E8=; b=38c4Gqe8KzDcbeb17fNPEGKz1k7UwwoWNnsY+LzhuLefEcf4JWbe61VemluM3wQbUN9UHy XqtgOO+SkxYR8w3dDfmDTKetM76TSDCkgyZLq35nVcjcBn74IYbKSVp8Sf+4gzDT6tp0dS P38JMvlXYUKgjE/jAUoNN7/1UyttWiI= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=aZUr5Hc3; spf=pass (imf23.hostedemail.com: domain of debug@rivosinc.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678995052; a=rsa-sha256; cv=none; b=qlhNPwd0osO0P+Zwfylu9W64nCPnjj9/1NH0z7vSHUccF/egmLYNKVaHA5xeCySiJAO/8R PSyu0R8vRaPj83VuuAKXhmjsNQm25VO7i28zes23EDdl+o6ZjmpXYnMta3VGmrY6lCEnt5 XHWfH//i4xFnFeCt/yrGCe3CdqWkCqU= Received: by mail-yb1-f182.google.com with SMTP id r1so3230507ybu.5 for ; Thu, 16 Mar 2023 12:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1678995051; 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=OQinqcAul9N1/k6Qm0xi6TTExDZScG0p56fu1+mj3E8=; b=aZUr5Hc3SSnInpRHn4QQapVy8DLcSf4/Fsji81ynnnbmxFUbqyycyen3xS68rzw2cJ csdHHzPzn1pP4Rqhq8/jlqA8dQLTAnyjBWcvBZHm6/pvneaCtKF11X0NKVPFJ6Lwuk5o 72RVceBABLTBI+tJn+l9lpq3yxow6PgeoozRTUpTU2xzCTSQilljxyWqtox7dKLQwmVh Mt7eATOZlaYVhW8nPozAkwkhKitbs3qSfS0zDDfCSHkn4bHon39z2LN2WrpJHFl7bH+u 01CLGuTfkqCSiQaPZ34ZVbtLD9fLHpC87CEEjOYCcl/1TmRK/ccg1mJnufuIL2N997aO uUJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678995051; 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=OQinqcAul9N1/k6Qm0xi6TTExDZScG0p56fu1+mj3E8=; b=G8+PfB4Y5gY2t/TdYdP0DPyiwLZlY4dC32KxJuEIgAnTyQgPvUNQ63h8Pg18wigPYl dOV+NNBW5uoP31G/U43zbnpy+M7UqcCAw6/mIoPsD2QxGT+jgbEjXYbQgN9jl+WJ0sUw 8pb/0HFCAvJfXrKkFrBBWJM++8gRsfHFSC8Lw+5mPFGK0PhP1Ly+eQjMVUtqQLFnVUVv ILg6/okbNDvsx29SNPMDJD43SHVMs+ZWKyNwIGi5c6IKIWi5Gb9LZ3a6glhuPLsLh28m fzGxD4+O9yXLBTCbztKcFvLKRY6Yx1j+o3UxddbFSdyBZ95DObq9BBArbtbGHRMugjX6 zQgg== X-Gm-Message-State: AO0yUKV03Dd4KrEm6MrkFYdpBF6AlOzPA35ma87gbXspza1ARaMl7rg7 3XbRfxdi0XFoIUtyER4wwykELu/lb4s5yxAMfNMpWA== X-Google-Smtp-Source: AK7set8XMy0ufUxFXEARzyZfU02oLy+VwPbPQAYSeIVhzA2hlPaXVJJxn8QbOjY2tiSVxh7zXiHiE5Y10vOoOFYvORc= X-Received: by 2002:a25:f507:0:b0:b3b:6576:b22b with SMTP id a7-20020a25f507000000b00b3b6576b22bmr10524766ybe.12.1678995051579; Thu, 16 Mar 2023 12:30:51 -0700 (PDT) MIME-Version: 1.0 References: <20230227222957.24501-1-rick.p.edgecombe@intel.com> <20230227222957.24501-34-rick.p.edgecombe@intel.com> <20230309185511.GA1964069@debug.ba.rivosinc.com> In-Reply-To: From: Deepak Gupta Date: Thu, 16 Mar 2023 12:30:40 -0700 Message-ID: Subject: Re: [PATCH v7 33/41] x86/shstk: Introduce map_shadow_stack syscall To: Mike Rapoport Cc: Szabolcs Nagy , 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, jamorris@linux.microsoft.com, dethoma@microsoft.com, akpm@linux-foundation.org, Andrew.Cooper3@citrix.com, christina.schimpe@intel.com, david@redhat.com, nd@arm.com, al.grant@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8990614001A X-Rspam-User: X-Stat-Signature: as5j9rxaw7kmi3iunm6em5htak9zi7u1 X-HE-Tag: 1678995052-564192 X-HE-Meta: U2FsdGVkX1+rydGAb2kG2PcQD7X1Gsz3t4xa+CTjRjqCJoK8qiuDh8tFT9ANy1bvBaJJk4vlvooSd5KoAVSM0oo8iIArlUJLo1GQp9kfMFKwXNn+rPwc738mgI9PVkfkGLZxFG0iqF+dL3hS7u32uLGTFsI1rhVuc1Dx+xPWYPyVARHlxXuh9NFaeZ1ihk9VbRHOypLuaXpPn2ocYzlwcnIwrGAwDvys9dB7SsdWmXzN87hUX0MPrYf5TVsksKy9Iuuf5Kj6RVgszeArkFQFuHHIirDsZkkHm72hHy7nqTHexgcJ36dVmlb6hOyIE4GXHfJMkzsajAYto7UTakhBJcGZ40INkFN7yoYbNcOZeItQxaq205zgvlgr6GoE2FQRoRGiNZecdXRVZ25VCtzGlk2nWtO93PuOXD6eM9Z6Fe0eLfCkONQyPmqaqhOJlchuDo37HsCfI0bEfSHRQbOGHACt83fm94aFOzlkd8K19w5KVilWDBgkoza8zJUdhiiXl3YknsXmPDYsI0dfvW8SHiItJuzG43juf9D74fVNzxGJ1c71FKBV6rCiCDg2tcTTxd62CxDsYjNAxGdgnEin+Dj5vYUalDULgr29mEq00C3UuqEqqaTGtZLBzic7yGoAYWZV90jbV6tYFwVusntU/15kNZLO5KxeRFWYtEuRBUJ5KzCTRgP8dE60vDnRTfu8rJtwqLu7J8O2Dy+x8Zt31SxFcCOTuQDGDeLy+MpRVVMUqPLf2+BYKfagqcDPlh0KaSTy3RnHo7Cj42K33pdAeUCXYSHa3fECz8hYuMRfGWuGxXaF6umBXmzUP9Kx0J8SwEQqpVsryhFnHxulUiBUn2D/jb7p3K3k7kuqLLka4qf5P8OSw+CUMznlna/sc0/3yt9LTR7v/1DMYXVVxZ8hgl7Nab3/yTGt3weBwnn6IvL/PICtNTO1BNPgAci/5fzX+pl84vwg+Q42GVUK1Yx WAqcidsB iHzCDngZTTh22IiJUHp5kMVLbeIPPbsmMvCyxFmR8npbcvvPHrfDRWjQ6VzcJNBfaHXpCl5MDs1guEXZupjNLzGYdEki7PSk2AgALxRB5BWvliSPfX0uunpCQdAZvH9DPtSnUVWAtnqp2tkfWO1Uy0M8kOY1CSV8e7XrfdLfyfHTEgR0XNZo4TAMwIEwJKSrRz6rwrDzQRiNJM4/rvkVEFD5T5cBcnYBtMmdyoKJyHaHBT4iVN7vxr1zkPyaiE2HVz7fgz9+SK7mUMqn5OKm4iZh9brJhnn2M6SzCW3IGSZteYH5kQz1LG8MKmBd7k8CjGlC6eRMOpbv0uhFznAoWooSgly4gBhPltwLtE45sp/7t96TEuloNqhjoX+oKukLbSthOPi65UB4ALl/vqJOOaob7cbVhPREeYtJ9GW5v9ZyrvFVusEZAnM0u0Sxe5bZwRlMGyWL0bGn1stuDuecyllfuEdiwGLw4JlPilvZw55TLAh+XUj859+jBzv6Jn1GMHEhnM3MVp3TqF8ydXwzRx8jjmQ== 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, Mar 14, 2023 at 12:19=E2=80=AFAM Mike Rapoport wr= ote: > > Hi, > > On Thu, Mar 09, 2023 at 10:55:11AM -0800, Deepak Gupta wrote: > > On Thu, Mar 02, 2023 at 05:22:07PM +0000, Szabolcs Nagy wrote: > > > The 02/27/2023 14:29, Rick Edgecombe wrote: > > > > Previously, a new PROT_SHADOW_STACK was attempted, > > > ... > > > > So rather than repurpose two existing syscalls (mmap, madvise) that= don't > > > > quite fit, just implement a new map_shadow_stack syscall to allow > > > > userspace to map and setup new shadow stacks in one step. While uco= ntext > > > > is the primary motivator, userspace may have other unforeseen reaso= ns to > > > > setup it's own shadow stacks using the WRSS instruction. Towards th= is > > > > provide a flag so that stacks can be optionally setup securely for = the > > > > common case of ucontext without enabling WRSS. Or potentially have = the > > > > kernel set up the shadow stack in some new way. > > > ... > > > > The following example demonstrates how to create a new shadow stack= with > > > > map_shadow_stack: > > > > void *shstk =3D map_shadow_stack(addr, stack_size, SHADOW_STACK_SET= _TOKEN); > > > > > > i think > > > > > > mmap(addr, size, PROT_READ, MAP_ANON|MAP_SHADOW_STACK, -1, 0); > > > > > > could do the same with less disruption to users (new syscalls > > > are harder to deal with than new flags). it would do the > > > guard page and initial token setup too (there is no flag for > > > it but could be squeezed in). > > > > Discussion on this topic in v6 > > https://lore.kernel.org/all/20230223000340.GB945966@debug.ba.rivosinc.c= om/ > > > > Again I know earlier CET patches had protection flag and somehow due to= pushback > > on mailing list, it was adopted to go for special syscall because no on= e else > > had shadow stack. > > > > Seeing a response from Szabolcs, I am assuming arm4 would also want to = follow > > using mmap to manufacture shadow stack. For reference RFC patches for r= isc-v shadow stack, > > use a new protection flag =3D PROT_SHADOWSTACK. > > https://lore.kernel.org/lkml/20230213045351.3945824-1-debug@rivosinc.co= m/ > > > > I know earlier discussion had been that we let this go and do a re-fact= or later as other > > arch support trickle in. But as I thought more on this and I think it m= ay just be > > messy from user mode point of view as well to have cognition of two dif= ferent ways of > > creating shadow stack. One would be special syscall (in current libc) a= nd another `mmap` > > (whenever future re-factor happens) > > > > If it's not too late, it would be more wise to take `mmap` > > approach rather than special `syscall` approach. > > I disagree. > > Having shadow stack flags for mmap() adds unnecessary complexity to the > core-mm, while having a dedicated syscall hides all the details in the > architecture specific code. Again reiterating it would've made sense if only x86 had a shadow stack. aarch64 announced support for guarded stack. risc-v spec is in development to support shadow stack. So there will be shadow stack related flow in these arches. > > Another reason to use a dedicated system call allows for better > extensibility if/when we'd need to update the way shadow stack VMA is > created. I see two valid points here - Shadow stack doesn't need conversion into different memory types (which is usually the case for address ranges created by mmap) So there is a static page permissions on shadow stack which is not mutable. - Future feature addition (if there is one needed) at the time of shadow stack creation It would avoid future tax on mmap I'll think more about this. > > As for the userspace convenience, it is anyway required to add special > code for creating the shadow stack and it wouldn't matter if that code > would use mmap(NEW_FLAG) or map_shadow_stack(). Yes *strictly* from userspace convenience, it doesn't matter which option. > > > > most of the mmap features need not be available (EINVAL) when > > > MAP_SHADOW_STACK is specified. > > > > > > the main drawback is running out of mmap flags so extension > > > is limited. (but the new syscall has limitations too). > > -- > Sincerely yours, > Mike.