From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752050AbeACJsq (ORCPT + 1 other); Wed, 3 Jan 2018 04:48:46 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:46131 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751335AbeACJsm (ORCPT ); Wed, 3 Jan 2018 04:48:42 -0500 Date: Wed, 3 Jan 2018 10:48:39 +0100 From: Pavel Machek To: greg@enjellic.com 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 Subject: Re: [PATCH v6 00/11] Intel SGX Driver Message-ID: <20180103094839.GA26610@amd> References: <201801030059.w030xQGD011342@wind.enjellic.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <201801030059.w030xQGD011342@wind.enjellic.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > Good evening Pavel et.al., I hope the New Year has started well for > everyone. :-). Stuff proceeds as usual. Too bad it is raining outside, instead of snowing. > > > > 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. >=20 > > Do you have link on "Iago threat model"? >=20 > https://cseweb.ucsd.edu/~hovav/dist/iago.pdf >=20 > > > 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. >=20 > > So ... even with SGX, host can generate bitflips in the enclave, > > right? >=20 > Correct. =2E.. 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... > > People usually assume that bitflip will lead "only" to > > denial-of-service, but rowhammer work shows that even "random" bit > > flips easily lead to priviledge escalation on javascript virtual > > machines, and in similar way you can get root if you have user and > > bit flips happen. > > > > So... I believe we should assume compromise is possible, not just > > denial-of-service. >=20 > Prudence always dictates that one assumes the worst. In this case > however, the bitflip attacks against SGX enclaves are very definitely > in the denial-of-service category. The attack is designed to trigger > a hardware self-protection feature on the processor. >=20 > Each page of memory which is initialized into an enclave has a > metadata block associated with it which contains the integrity state > of that page of memory. The MM{E,U} hardware on an SGX capable > platform checks this integrity data on each page fetch request arising > from addresses/pages inside of an enclave. >=20 > 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? So SGX protected memory is not swappable? > 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? > > Well, yes :-). And I believe someone is going to have fun with SGX > > ;-). >=20 > 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? Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlpMpvcACgkQMOfwapXb+vKJFgCeOHE+GANAbpZtWBbzwCcANtOn MTcAnR+xaqLcIQgze7OkG4B7qCpRBier =iYQr -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5--