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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 535DFC74A44 for ; Thu, 9 Mar 2023 18:55:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229453AbjCISzT (ORCPT ); Thu, 9 Mar 2023 13:55:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229786AbjCISzS (ORCPT ); Thu, 9 Mar 2023 13:55:18 -0500 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD6AA265A9 for ; Thu, 9 Mar 2023 10:55:16 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id ay18so2153028pfb.2 for ; Thu, 09 Mar 2023 10:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1678388116; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0KFB3WZvPj45QQFE1vG91JPQ7IHpeNLpOum3l/eyO9A=; b=h59h3vE4/2ufFxQJ24xAYjQ7i6vDw3EWfYwoHOQUniZZgxYCC2dAvg7O9KNg4qB/+x fNJ+NOnKKj1iQLTXTBqPzpcXhTK+/9SZ4MkSEIoIFNjGV0kCAr3BEIU2xsm3C7FEdj+A T/XxUJI3yE96YUHGXzcl3NneJzDNKNf8d0TBlXmFWBCT0+wU0kagQR3JnRr+dN6ZvhYN 8ReN8Ny1kOTBj0tXalrMuP3uRpkMMjxpE0gkZDV/sAcpMYA3kPTsJ7iYuY5BqM2aCYS+ svz0XeMNtQEIWJet0C8FJZktTq3PE9u9q7hGuQL4WdFUgol4tP6+KITMRimE5edYQDc8 dhTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678388116; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0KFB3WZvPj45QQFE1vG91JPQ7IHpeNLpOum3l/eyO9A=; b=fIzXiDMrQD0h/CUpZDGILUlXBr+yf2jnvt6YaQwE3/xGFNLGJT+NdvvZ2tw2kWlexX tEBR79DfwSFem0bi0RmAYU9RQ9ISt3KdrNsRSLjxfzjvfOuRarFi3MIiAPztlViq+2uY PjhhQ92gG0a7NyZR9lLm5M7Nk2k3cqDKztXuZyrsc2YsVjlknCb6uEcXdjKXmVXNlY4R bcL2S2g2WI+exHtUrGhyLx0YR2YYHci51KYMmIZCBbD4hO5dWiytDqo7o29yE7LdwBSK gbEDHjGStUxsXOwV+LZdPmi6avgKd5g79QpL1gqRtjJejOhDysYOxe8gPUgfS/MxzLel kt9w== X-Gm-Message-State: AO0yUKUYqSomt4PXHuvy0D468qDXX1fDg/5WSOz3opbLmPBu+orV1Tml 9qm/eQqkYYQewoY+6O42JeLw9Q== X-Google-Smtp-Source: AK7set/1H5/0frCN8PzNRC2CTwJPM7bfZzkBZoC0SUtpBiwsmBbJNbV+PGyPeJ21Szf11t5mXLGWBQ== X-Received: by 2002:a62:7b0c:0:b0:61d:e8bb:1cb0 with SMTP id w12-20020a627b0c000000b0061de8bb1cb0mr4545332pfc.1.1678388115841; Thu, 09 Mar 2023 10:55:15 -0800 (PST) Received: from debug.ba.rivosinc.com ([66.220.2.162]) by smtp.gmail.com with ESMTPSA id i2-20020aa787c2000000b005b34d81b010sm11804401pfo.91.2023.03.09.10.55.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 10:55:15 -0800 (PST) Date: Thu, 9 Mar 2023 10:55:11 -0800 From: Deepak Gupta To: Szabolcs Nagy 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, nd@arm.com, al.grant@arm.com Subject: Re: [PATCH v7 33/41] x86/shstk: Introduce map_shadow_stack syscall Message-ID: <20230309185511.GA1964069@debug.ba.rivosinc.com> References: <20230227222957.24501-1-rick.p.edgecombe@intel.com> <20230227222957.24501-34-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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 ucontext >> is the primary motivator, userspace may have other unforeseen reasons to >> setup it's own shadow stacks using the WRSS instruction. Towards this >> 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 = 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.com/ 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 one 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 risc-v shadow stack, use a new protection flag = PROT_SHADOWSTACK. https://lore.kernel.org/lkml/20230213045351.3945824-1-debug@rivosinc.com/ I know earlier discussion had been that we let this go and do a re-factor later as other arch support trickle in. But as I thought more on this and I think it may just be messy from user mode point of view as well to have cognition of two different ways of creating shadow stack. One would be special syscall (in current libc) and 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. > >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).