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=-6.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 DB257C433E2 for ; Tue, 8 Sep 2020 17:51:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 68A7B2145D for ; Tue, 8 Sep 2020 17:51:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68A7B2145D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7B7C76B0003; Tue, 8 Sep 2020 13:51:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 766986B0037; Tue, 8 Sep 2020 13:51:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 606816B0055; Tue, 8 Sep 2020 13:51:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id 46A756B0003 for ; Tue, 8 Sep 2020 13:51:09 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 01131824805A for ; Tue, 8 Sep 2020 17:51:09 +0000 (UTC) X-FDA: 77240635458.19.thing32_3b0bd24270d6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id CBE941AD1B0 for ; Tue, 8 Sep 2020 17:51:08 +0000 (UTC) X-HE-Tag: thing32_3b0bd24270d6 X-Filterd-Recvd-Size: 5901 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Sep 2020 17:51:07 +0000 (UTC) IronPort-SDR: JizbLE3Y0XzLXE+Rfco/Y4vemAW/8OOpXfEHQ95yQ0gPN7qJyzKGzA2Q/WxgLnm7gdOskzjm0h Ri+UlyPtnoOg== X-IronPort-AV: E=McAfee;i="6000,8403,9738"; a="155679457" X-IronPort-AV: E=Sophos;i="5.76,406,1592895600"; d="scan'208";a="155679457" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2020 10:51:05 -0700 IronPort-SDR: OSUAvkly35g4rp65YdSJ7GU5AVIkCP6KvD/KYuQfwrGEt2Td0LWP90aD6H67DVsBL5AldF/Ho5 pPWBypudfYhQ== X-IronPort-AV: E=Sophos;i="5.76,406,1592895600"; d="scan'208";a="341268799" Received: from yyu32-mobl1.amr.corp.intel.com (HELO [10.209.111.239]) ([10.209.111.239]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2020 10:51:03 -0700 Subject: Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack To: Dave Hansen , Andy Lutomirski Cc: Dave Martin , "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 References: <086c73d8-9b06-f074-e315-9964eb666db9@intel.com> <73c2211f-8811-2d9f-1930-1c5035e6129c@intel.com> <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> From: "Yu, Yu-cheng" Message-ID: <46dffdfd-92f8-0f05-6164-945f217b0958@intel.com> Date: Tue, 8 Sep 2020 10:50:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <32005d57-e51a-7c7f-4e86-612c2ff067f3@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CBE941AD1B0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 9/1/2020 11:11 AM, 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. > What about this: - Do not add any new syscall or arch_prctl for creating a new shadow stack. - Add a new arch_prctl that can turn an anonymous mapping to a shadow stack mapping. This allows the application to do whatever is necessary. It can even allow GDB or JIT code to create or fix a call stack. Yu-cheng