Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3354816yba; Tue, 23 Apr 2019 02:15:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqxGpoKKmvEj0qM9YNFDHl1vIaf6kYL4FZ3yazEGou/xYi/lmTHInrd4FPutALrT7INPs/ir X-Received: by 2002:aa7:82c5:: with SMTP id f5mr25580878pfn.256.1556010926784; Tue, 23 Apr 2019 02:15:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556010926; cv=none; d=google.com; s=arc-20160816; b=Xj0UewM+JeLQ0kpfSESaLEz9HiP5waaNMptw8+VSntIeEqQuDjqAuIUjXmqx4C2SAz r48jLGmlmOTuERuUylGple8vC69dfUnypONqE8V+ByJLK+nFnN+1imZcNkRP+K3D3RJ/ 1EF8H3Kn8pcCsQIRv3KyZ5ynZBDR3Ppht4MMt4sgMEqrsoTSIQngP/RdbgyN2d0x2aGw MORk/Q5bZhGqGcc6TD9ttK72qgvqac9aioQtT4CI56ohMZp2c4Rhr7vKvd5KlNFYdpNj 2gUWUYD4flxmH5AxI7ceCoYLPxHlpY/PCjoPTpuQjOTFfJokqDdGcV6/miSxq58/xZjw 0D/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date; bh=1cMT3z0rrXEo4kdf4EpJK75qVnT8SwWliQvz0QonaYQ=; b=theb5Y0ugRP2GVv4VOJ+j2XlInPQUwvR/eNmh0CB+X7qSLkRq38Wp1hqmKtmQB4CWE Ldo2KyTiKXm9MP9fMMWJgUkzgoaRjfkI51zsEILEt55+SQ5RI+6mqi7dYUVOd5MkhgnV cM2tIg3r4Mm7XEU1d6jOT5Ae/V7AUrD5j6Z6JGHl4v1kteBP+kzhA4gL0Xuomh+NmPax HLnozPFau3iRMHGVtbcA4H6xGAbp6KGB1Uzhl5fovUkxBK1sBV3KBYu46heTisOegPGh Uual+GzrYvrJq8zaWaydqbSYg1QJKZxU6fnqfRiKrFgXJGWbhaCUQie0M1oeopgviuYn G7/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p10si7177728pgb.314.2019.04.23.02.15.11; Tue, 23 Apr 2019 02:15:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726995AbfDWJM0 (ORCPT + 99 others); Tue, 23 Apr 2019 05:12:26 -0400 Received: from wind.enjellic.com ([76.10.64.91]:59056 "EHLO wind.enjellic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726130AbfDWJM0 (ORCPT ); Tue, 23 Apr 2019 05:12:26 -0400 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.15.2/8.15.2) with ESMTP id x3N9Bm67006793; Tue, 23 Apr 2019 04:11:48 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.15.2/8.15.2/Submit) id x3N9BlHl006792; Tue, 23 Apr 2019 04:11:47 -0500 Date: Tue, 23 Apr 2019 04:11:47 -0500 From: "Dr. Greg" To: Sean Christopherson Cc: Linus Torvalds , Thomas Gleixner , Jethro Beekman , Andy Lutomirski , Andy Lutomirski , Dave Hansen , Jarkko Sakkinen , LKML , X86 ML , "linux-sgx@vger.kernel.org" , Andrew Morton , "nhorman@redhat.com" , "npmccallum@redhat.com" , "Ayoun, Serge" , "Katz-zamir, Shay" , "Huang, Haitao" , Andy Shevchenko , "Svahn, Kai" , Borislav Petkov , Josh Triplett , "Huang, Kai" , David Rientjes Subject: Re: [PATCH v20 00/28] Intel SGX1 support Message-ID: <20190423091147.GA6404@wind.enjellic.com> Reply-To: "Dr. Greg" References: <5854e66a-950e-1b12-5393-d9cdd15367dc@fortanix.com> <20190420160247.GA17291@wind.enjellic.com> <20190422150119.GA1236@linux.intel.com> <20190422162411.GA27389@wind.enjellic.com> <20190422164827.GC1236@linux.intel.com> <20190422171714.GE1236@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190422171714.GE1236@linux.intel.com> 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]); Tue, 23 Apr 2019 04:11:49 -0500 (CDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 22, 2019 at 10:17:15AM -0700, Sean Christopherson wrote: Good morning to everyone. > On Mon, Apr 22, 2019 at 09:55:47AM -0700, Linus Torvalds wrote: > > On Mon, Apr 22, 2019 at 9:48 AM Sean Christopherson > > wrote: > > > > > > Right, and loading a malicious enclave doesn't change those guarantees > > > (for other enclaves). Ergo, restricting which enclaves can execute is > > > orthogonal to the security provided by SGX. > > > > But it is absolutely worth noting that TSX made a lot of attacks both > > easier to _do_, and also easier to _hide_. > > > > All while being basically completely worthless technology to everybody > > except for some silly SAP benchmark. > > > > So it is definitely worth at least discussing the downsides of SGX. If > > it ends up being another technology that makes it easier to create > > malware, without actually having a lot of _good_ software use it, the > > patches to enable it should make damn sure that the upsides actually > > outweigh the downsides. > > > > And if the current setup basically is "you have to disable reasonable > > SElinux protections that lots of distros use today", I think it's > > entirely reasonable saying "the downsides are bigger than the > > upsides". > I'm not arguing against SGX playing nice with SELinux/LSMs, actually > the opposite. I completely agree that enclaves should be subject to > LSM restrictions. As do we. The point we have been making is that depending on the LSM's are depending on the fact that the platform has not been compromised. SGX is designed to provide a trusted execution environment in the face of a compromised platform. > AIUI, Dr. Greg is proposing a framework that uses SGX's launch > control mechanism to restrict what enclaves can run. My point is > that restricting what enclaves can run is about protecting the > kernel and/or platform, not the enclaves themselves, i.e. using > launch control instead of, or in addition to, LSMs doesn't change > the security guarantees of SGX. I believe current research suggests that this is not the case. From the paper we have previously cited: https://arxiv.org/pdf/1702.08719.pdf In the second paragraph of the abstract: "In this paper, we demonstrate fine-grained software-based side-channel attacks from a malicious SGX enclave targeting co-located enclaves. Our attack is the first malware running on real SGX hardware, abusing SGX protection features to conceal itself. Furthermore, we demonstrate our attack both in a native environment and across multiple Docker containers". To be perfectly clear, Dr. Greg, technically IDfusion, is not proposing the use of SGX's launch control to restrict which enclaves can run, although there are perfectly legitimate and required use cases for that technology. Dr. Greg is proposing that the kernel driver expend 1.2 pages of kernel memory to implement, at the discretion of the platform owner, cryptographically verified enclave initialization. The design we proposed is the strongest guarantee that a platform owner can implement, on FLC hardware, that only code and data of known provenance can be loaded and executed. There are only two companies that have written the entire stack of software needed to make practical SGX applications work, us and Intel. We can go into intimate detail on the issues involved but will embrace bevity at this point. Have a good day. Dr. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new." -- Niccolo Machiavelli _The Prince_, Chapter VI