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.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 1A170C388F7 for ; Sat, 7 Nov 2020 15:10:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5F00B20719 for ; Sat, 7 Nov 2020 15:10:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5F00B20719 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=enjellic.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 814146B0036; Sat, 7 Nov 2020 10:10:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C5B46B005D; Sat, 7 Nov 2020 10:10:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DB656B0068; Sat, 7 Nov 2020 10:10:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) by kanga.kvack.org (Postfix) with ESMTP id 3916C6B0036 for ; Sat, 7 Nov 2020 10:10:00 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D1A5E1EF1 for ; Sat, 7 Nov 2020 15:09:59 +0000 (UTC) X-FDA: 77457957318.14.time68_2402981272dc Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id ADA1A18229818 for ; Sat, 7 Nov 2020 15:09:59 +0000 (UTC) X-HE-Tag: time68_2402981272dc X-Filterd-Recvd-Size: 5121 Received: from wind.enjellic.com (wind.enjellic.com [76.10.64.91]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Sat, 7 Nov 2020 15:09:59 +0000 (UTC) Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.15.2/8.15.2) with ESMTP id 0A7F9XsO029629; Sat, 7 Nov 2020 09:09:33 -0600 Received: (from greg@localhost) by wind.enjellic.com (8.15.2/8.15.2/Submit) id 0A7F9UVw029628; Sat, 7 Nov 2020 09:09:30 -0600 Date: Sat, 7 Nov 2020 09:09:30 -0600 From: "Dr. Greg" To: Dave Hansen Cc: Jarkko Sakkinen , x86@kernel.org, linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org, Sean Christopherson , linux-mm@kvack.org, Andrew Morton , Matthew Wilcox , Jethro Beekman , Darren Kenny , andriy.shevchenko@linux.intel.com, asapek@google.com, bp@alien8.de, cedric.xing@intel.com, chenalexchen@google.com, conradparker@google.com, cyhanish@google.com, haitao.huang@intel.com, kai.huang@intel.com, kai.svahn@intel.com, kmoy@google.com, ludloff@google.com, luto@kernel.org, nhorman@redhat.com, npmccallum@redhat.com, puiterwijk@redhat.com, rientjes@google.com, tglx@linutronix.de, yaozhangx@google.com, mikko.ylinen@intel.com Subject: Re: [PATCH v40 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct Message-ID: <20201107150930.GA29530@wind.enjellic.com> Reply-To: "Dr. Greg" References: <20201104145430.300542-1-jarkko.sakkinen@linux.intel.com> <20201104145430.300542-11-jarkko.sakkinen@linux.intel.com> <20201106174359.GA24109@wind.enjellic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [127.0.0.1]); Sat, 07 Nov 2020 09:09:33 -0600 (CST) 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 Fri, Nov 06, 2020 at 09:54:19AM -0800, Dave Hansen wrote: Good morning, I hope the weekend is going well for everyone, beautiful weather out here in West-Cental Minnesota. > On 11/6/20 9:43 AM, Dr. Greg wrote: > > In light of this, given the decision by the driver authors to not > > fully equip the driver with EDMM support, the mprotect protection > > requirements are straight forward and minimalistic. All that is > > needed is a binary valued variable, set on the command-line, that > > either allows or denies anonymous code execution by an enclave, > > ie. access to page protection changes after initialization. > To that, I say NAK. We need more flexibility than a boot-time-fixed, > system-wide switch. To be clear, I wasn't referring to a global yes/no option in the code that implements the mprotect callout method in the vm_operations_struct. I was referring to the implementation of the hook in the SGX driver code. In all of these discussions there hasn't been a refutation of my point that the only reason this hook is needed is to stop the potential for anonymous code execution on SGX2 capable hardware. So we will assume, that while unspoken, this is the rationale for the hook. If you are NAK'ing a global enable/disable in the driver code, I think there needs to be a discussion of why the driver, in its current state, needs anything other then a yes/no decision on mprotect after enclave initialization is complete. At this point in time the driver has no intention of supporting EDMM, so the simple belt-and-suspenders approach is to deny mprotect on enclave virtual memory after initialization. Absent mprotect, the hardware is perfectly capable of enforcing page permissions that are only consistent with the initial mapping of the enclave. If and when EDMM is implemented there might be a rationale for per page mprotect interrogation. I won't waste people's time here but I believe a cogent arguement can be made that there is little utility, even under EDMM, of making per page permission decisions rather then a 'yes/no' decision by the platform owner as to whether or not they want to allow anonymous code execution. Hopefully all of this is a useful clarification. Have a good weekend. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "If you ever teach a yodeling class, probably the hardest thing is to keep the students from just trying to yodel right off. You see, we build to that." -- Jack Handey Deep Thoughts