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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A628C433E7 for ; Wed, 2 Sep 2020 14:00:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 43179207D3 for ; Wed, 2 Sep 2020 14:00:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727099AbgIBOAE (ORCPT ); Wed, 2 Sep 2020 10:00:04 -0400 Received: from foss.arm.com ([217.140.110.172]:38552 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727025AbgIBN6l (ORCPT ); Wed, 2 Sep 2020 09:58:41 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D830231B; Wed, 2 Sep 2020 06:58:40 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 24EBA3F71F; Wed, 2 Sep 2020 06:58:37 -0700 (PDT) Date: Wed, 2 Sep 2020 14:58:35 +0100 From: Dave Martin To: Dave Hansen Cc: Andy Lutomirski , "Yu, Yu-cheng" , "H.J. Lu" , Florian Weimer , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Weijiang Yang Subject: Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack Message-ID: <20200902135832.GD6642@arm.com> References: <20200826164604.GW6642@arm.com> <87ft892vvf.fsf@oldenburg2.str.redhat.com> <0e9996bc-4c1b-cc99-9616-c721b546f857@intel.com> <4f2dfefc-b55e-bf73-f254-7d95f9c67e5c@intel.com> <20200901102758.GY6642@arm.com> <32005d57-e51a-7c7f-4e86-612c2ff067f3@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32005d57-e51a-7c7f-4e86-612c2ff067f3@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-arch-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Tue, Sep 01, 2020 at 11:11:37AM -0700, Dave Hansen wrote: > On 9/1/20 10:45 AM, Andy Lutomirski wrote: > >>> For arm64 (and sparc etc.) we continue to use the regular mmap/mprotect > >>> family of calls. One or two additional arch-specific mmap flags are > >>> sufficient for now. > >>> > >>> Is x86 definitely not going to fit within those calls? > >> That can work for x86. Andy, what if we create PROT_SHSTK, which can > >> been seen only from the user. Once in kernel, it is translated to > >> VM_SHSTK. One question for mremap/mprotect is, do we allow a normal > >> data area to become shadow stack? > > I'm unconvinced that we want to use a somewhat precious PROT_ or VM_ > > bit for this. Using a flag bit makes sense if we expect anyone to > > ever map an fd or similar as a shadow stack, but that seems a bit odd > > in the first place. To me, it seems more logical for a shadow stack > > to be a special sort of mapping with a special vm_ops, not a normal > > mapping with a special flag set. Although I realize that we want > > shadow stacks to work like anonymous memory with respect to fork(). > > Dave? > > I actually don't like the idea of *creating* mappings much. > > I think the pkey model has worked out pretty well where we separate > creating the mapping from doing something *to* it, like changing > protections. For instance, it would be nice if we could preserve things > like using hugetlbfs or heck even doing KSM for shadow stacks. > > If we're *creating* mappings, we've pretty much ruled out things like > hugetlbfs. > > Something like mprotect_shstk() would allow an implementation today that > only works on anonymous memory *and* sets up a special vm_ops. But, the > same exact ABI could do wonky stuff in the future if we decided we > wanted to do shadow stacks on DAX or hugetlbfs or whatever. > > I don't really like the idea of PROT_SHSTK those are plumbed into a > bunch of interfaces. But, I also can't deny that it seems to be working > fine for the arm64 folks. Note, there are some rough edges, such as what happens when someone calls mprotect() on memory marked with PROT_BTI. Unless the caller knows whether PROT_BTI should be set for that page, the flag may get unintentionally cleared. Since the flag only applies to text pages though, it's not _that_ much of a concern. Software that deals with writable text pages is also usually involved in generating the code and so will know about PROT_BTI. That's was the theory anyway. In the longer term, it might be preferable to have a mprotect2() that can leave some flags unmodified, and that doesn't silently ignore unknown flags (at least one of mmap or mprotect does; I don't recall which). We attempt didn't go this far, for now. For arm64 it seemed fairly natural for the BTI flag to be a PROT_ flag, but I don't know enough detail about x86 shstk to know whether it's a natural fit there. Cheers ---Dave