Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751862AbdL0KsD (ORCPT ); Wed, 27 Dec 2017 05:48:03 -0500 Received: from wind.enjellic.com ([76.10.64.91]:54548 "EHLO wind.enjellic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751028AbdL0KsB (ORCPT ); Wed, 27 Dec 2017 05:48:01 -0500 X-Greylist: delayed 943 seconds by postgrey-1.27 at vger.kernel.org; Wed, 27 Dec 2017 05:48:00 EST Date: Wed, 27 Dec 2017 04:30:50 -0600 From: "Dr. Greg Wettstein" Message-Id: <201712271030.vBRAUo3o027896@wind.enjellic.com> In-Reply-To: Pavel Machek "Re: [PATCH v6 00/11] Intel SGX Driver" (Dec 12, 3:07pm) Reply-To: greg@enjellic.com X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Pavel Machek , Jarkko Sakkinen Subject: Re: [PATCH v6 00/11] Intel SGX Driver Cc: platform-driver-x86@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, Borislav Petkov , "David S. Miller" , Greg Kroah-Hartman , Grzegorz Andrejczuk , Haim Cohen , Ingo Molnar , Janakarajan Natarajan , Jim Mattson , Kan Liang , "Kirill A. Shutemov" , Kyle Huey , Len Brown , "open list:DOCUMENTATION" , "open list:FILESYSTEMS (VFS and infrastructure)" , Mauro Carvalho Chehab , Paolo Bonzini , Piotr Luc , Radim Kr??m???? , Randy Dunlap , Sean Christopherson , Thomas Gleixner , Tom Lendacky , Vikas Shivappa X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Wed, 27 Dec 2017 04:30:52 -0600 (CST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5085 Lines: 112 On Dec 12, 3:07pm, Pavel Machek wrote: } Subject: Re: [PATCH v6 00/11] Intel SGX Driver Good morning, I hope this note finds the holiday season going well for everyone. This note is a bit delayed due to the holidays, my apologies. Pretty wide swath on this e-mail but will include the copy list due to the possible general interest and impact of these issues. We have done an independent implementation of Intel's platform software (PSW), directed at the use of SGX on intelligent network endpoint devices, so we have some experience with the issues under discussion. > On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote: > > Intel(R) SGX is a set of CPU instructions that can be used by > > applications to set aside private regions of code and data. The > > code outside the enclave is disallowed to access the memory inside > > the enclave by the CPU access control. In a way you can think > > that SGX provides inverted sandbox. It protects the application > > from a malicious host. > Would you list guarantees provided by SGX? Obviously, confidentiality and integrity. SGX was designed to address an Iago threat model, a very difficult challenge to address in reality. On SGX capable platforms, the Memory Encryption Engine (MEE) is an integrated component of the hardware MMU, as SGX is a virtual memory play. As a result, the executable code and data are encrypted in main memory and only decrypted when the data is fed from memory onto the hardware fetch queues. Irregardless of anything else, this has implications with respect to cold boot attacks, if an architect chooses to worry about that threat modality. In reality, we believe the guarantee that is most important is integrity, given the issues below. > For example, host can still observe timing of cachelines being > accessed by "protected" app, right? Can it also introduce bit flips? Timing attacks are the bane of SGX, just as they are throughout the rest of the commodity architectures. Jarkko cited Beecham's work, which is a good reference. Oakland's work on controlled side-channel attacks is also a very good, and fundamental, read on the issues involved. Microsoft Research and Georgia Tech have a paper out discussing the use of transactional memory to mitigate these. I don't have the citation immediately available, but a bit-flip attack has also been described on enclaves. Due to the nature of the architecture, they tend to crash the enclave so they are more in the category of a denial-of-service attack, rather then a functional confidentiality or integrity compromise. At the end of the day, giving up complete observational and functional control to an adversary is a difficult challenge to address. There is also a large difference between attacks that can be conducted in a carefully controlled lab environment and what an adversary or malware can implement in practice. Platforms which require security assurances ultimately need a root of trust. That either comes from a TPM or a Trusted Execution Environment like SGX. Realistically, we think the future involves an integration of both technologies. The only other alternative is perfect software and I think the jury has already weighed in on that. The advantage of SGX over a TPM is that it is blindingly fast with respect to performance. The IMA community has been involved in a debate over the list digest patches in order to overcome performance issues with TPM based extension measurements. We lifted most of the IMA infrastructure into an SGX enclave and demonstrated significant performance impacts as a result. The bigger question, for community integration, is the availability of hardware. I see Jarkko's patches are based on the notion of having flexible launch control available, ie. the ability to program the relevant MSR's with the checksum of the identity modulus which is to serve as the root of trust. I'm not sure there is any hardware in the wild that currently supports this, Jarkko comments? Even with that, the question arises as to what is going to be trusted to program those registers. The obvious candidate for this is TXT/tboot which underscores a future involving the integration of these technologies. Unfortunately, in the security field it is way more fun, and seemingly advantageous from a reputational perspective, to break things then to build solutions.... :-)( > Pavel I hope the above clarifications are helpful. Best wishes for a pleasant holiday weekend to everyone. Dr. Greg }-- End of excerpt from Pavel Machek 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 ------------------------------------------------------------------------------ "I suppose that could could happen but he wouldn't know a Galois Field if it kicked him in the nuts." -- Anonymous mathematician Resurrection.