From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752375AbeADJH2 (ORCPT + 1 other); Thu, 4 Jan 2018 04:07:28 -0500 Received: from wind.enjellic.com ([76.10.64.91]:55675 "EHLO wind.enjellic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752053AbeADJHY (ORCPT ); Thu, 4 Jan 2018 04:07:24 -0500 Date: Thu, 4 Jan 2018 03:06:43 -0600 From: "Dr. Greg Wettstein" Message-Id: <201801040906.w0496h39025733@wind.enjellic.com> In-Reply-To: Pavel Machek "Re: [PATCH v6 00/11] Intel SGX Driver" (Jan 3, 10:48am) Reply-To: greg@enjellic.com X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Pavel Machek Subject: Re: [PATCH v6 00/11] Intel SGX Driver Cc: Jarkko Sakkinen , 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]); Thu, 04 Jan 2018 03:06:44 -0600 (CST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Jan 3, 10:48am, Pavel Machek wrote: } Subject: Re: [PATCH v6 00/11] Intel SGX Driver > Hi! Good morning. > :-). Stuff proceeds as usual. Too bad it is raining outside, instead > of snowing. -19C here, so we have snow... :-) > > > So ... even with SGX, host can generate bitflips in the enclave, > > > right? > > Correct. > I'd say that you can't generate bitflips because if you do hardware > will kill the enclave. This seems to be significant difference from > AMD "secure" memory encryption. SGX is an entirely different class of technology compared to AME SME or the Intel equivalent TME (Total Memory Encryption). Both of these are best described as the notion of applying the concept of whole disk encryption to memory. There are lots of well understood issues surrounding this approach, whether the target is memory pages or disk sectors. I think the issue comes down to the fact that there is a desire to enable a BIOS option and become 'secure', unfortunately the world is not that simple. > > Forcing a bitflip in enclave memory causes the next page fetch > > containing the bitflipped location to fail its integrity check. > > Since this technically shouldn't be possible, this situation was > > classified as a hardware failure which is handled by the processor > > locking its execution state, thus taking the machine down. > So you can't really do bitflips on the SGX protected memory, because > MM{E,U} hardware will catch that and kill machine if you try? Correct. Which obviously has issues in a multi-tenant cloud environment, but again, it comes down to risk management. Killing a machine is problematic, a massive data compromise isn't much fun either. > So SGX protected memory is not swappable? The architecture provides support for swapping enclave pages and the Linux driver supports it. The swapped pages retain their confidentiality and integrity protections. > > It would seem to be a misfeature for the self-protection mechanism to > > not generate some type of trappable fault rather then generating a > > processor lockup but hindsight is always 20/20. Philosophically this > > is a good example of security risk managment. Locking a machine is > > obviously problematic in a cloud service environment, but it has to be > > taken in the perspective of whether or not it would be preferable to > > have a successful privilege escalation attack which could result in > > exfiltration of sensitive data. > Ok, right, it should fault. They can fix it in new version? Good question and something only Intel can answer. A large part of SGX is implemented in microcode, in part due to the complexity of the technologies involved, notably the group signing (EPID) implementation. Beyond that, there was a specific acknowledgement that this was security sensitive code and may need an upgrade, hence the microcode implementation. Since the drop and lock 'feature' is closely tied to the MM{E,U} implementation, the question would be whether or not this behavior could be changed with updated firmware. If it was easy to change the behavior of the MMU with microcode the industry would be less frantic right now... :-) If it would be possible to change the drop and lock response it would arguably improve the utility of the technology in certain environments. SGX2 would have been a great time for that. > > Arguably not as much fun as what appears to be pending, given what > > appears to be the difficulty of some Intel processors to deal with > > page faults induced by speculative memory references... :-) > Do you have more info on that? Will they actually leak information, > or is it just good for rowhammering the kernel memory? If we are talking about the issues motivating the KPTI work I don't have any useful information beyond what is raging through the industry right now. With respect to SGX, the issues giving rise to KPTI are characteristic of what this technology is designed to address. The technical 'news' sites, which are even more of an abomination then usual with this issue, are talking about privileged information such as credentials, passwords et.al being leaked by this vulnerability. Data committed to enclaves are only accessible by the enclave, even the kernel, by definition, can't access the memory. Given current events that is an arguably useful behavior. > Best regards, > Pavel Stay dry. Have a good day. 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 ------------------------------------------------------------------------------ "Lots of folks confuse bad management with destiny." -- Kin Hubbard --