linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	platform-driver-x86@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, Borislav Petkov <bp@suse.de>,
	"David S. Miller" <davem@davemloft.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>,
	Haim Cohen <haim.cohen@intel.com>, Ingo Molnar <mingo@kernel.org>,
	Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>,
	Jim Mattson <jmattson@google.com>,
	Kan Liang <Kan.liang@intel.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Kyle Huey <me@kylehuey.com>, Len Brown <len.brown@intel.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	"open list:FILESYSTEMS (VFS and infrastructure)" 
	<linux-fsdevel@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Piotr Luc <piotr.luc@intel.com>,
	Radim Kr??m???? <rkrcmar@redhat.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Vikas Shivappa <vikas.shivappa@linux.intel.com>
Subject: Re: [PATCH v6 00/11] Intel SGX Driver
Date: Tue, 2 Jan 2018 18:59:26 -0600	[thread overview]
Message-ID: <201801030059.w030xQGD011342@wind.enjellic.com> (raw)
In-Reply-To: Pavel Machek <pavel@ucw.cz> "Re: [PATCH v6 00/11] Intel SGX Driver" (Dec 27,  9:46pm)

On Dec 27,  9:46pm, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

> Hi!

Good evening Pavel et.al., I hope the New Year has started well for
everyone.

> > > 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.

> Do you have link on "Iago threat model"?

https://cseweb.ucsd.edu/~hovav/dist/iago.pdf

> > 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.

> So ... even with SGX, host can generate bitflips in the enclave,
> right?

Correct.

Here is the reference I was trying to recall in my last e-mail:

https://sslab.gtisc.gatech.edu/assets/papers/2017/jang:sgx-bomb.pdf

> 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.

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.

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.

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.

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.

Philosophically we take the approach that for high security assurance
environments it is virtually impossible to allow any untrusted code to
run on a platform.  Which is why we focus on autonomous introspection
for these environments.

> > Unfortunately, in the security field it is way more fun, and
> > seemingly advantageous from a reputational perspective, to break
> > things then to build solutions.... :-)(

> Well, yes :-). And I believe someone is going to have fun with SGX
> ;-).
> 									Pavel

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... :-)

Best wishes for a productive New Year.

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
------------------------------------------------------------------------------
"It is difficult to produce a television documentary that is both
 incisive and probing when every twelve minutes one is interrupted by
 twelve dancing rabbits singing about toilet paper."
                                -- Rod Serling

             reply	other threads:[~2018-01-03  1:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-03  0:59 Dr. Greg Wettstein [this message]
2018-01-03  2:00 ` [PATCH v6 00/11] Intel SGX Driver Christian Stroetmann
2018-01-03  9:48 ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2018-01-09 21:50 Dr. Greg Wettstein
2018-01-10 16:16 ` Jarkko Sakkinen
2018-01-05  9:50 Dr. Greg Wettstein
2018-01-04 21:09 Dr. Greg Wettstein
2018-01-04  9:06 Dr. Greg Wettstein
2018-01-09 14:25 ` Jarkko Sakkinen
2018-01-04  8:02 Dr. Greg Wettstein
2018-01-04  9:20 ` Christian Stroetmann
2017-12-27 10:30 Dr. Greg Wettstein
2017-12-27 20:46 ` Pavel Machek
2017-11-25 19:29 Jarkko Sakkinen
2017-12-12 14:07 ` Pavel Machek
2017-12-14 11:18   ` Jarkko Sakkinen
2017-12-19 23:33   ` Jarkko Sakkinen
2017-12-20 13:18     ` Jarkko Sakkinen
2018-01-04 14:17 ` Cedric Blancher
2018-01-04 14:27   ` Greg Kroah-Hartman
2018-01-04 19:18     ` Ozgur
2018-01-04 15:08   ` James Bottomley
2018-01-09 14:27   ` Jarkko Sakkinen
2018-02-08  8:46     ` Pavel Machek
2018-02-08 13:48       ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201801030059.w030xQGD011342@wind.enjellic.com \
    --to=greg@wind.enjellic.com \
    --cc=Janakarajan.Natarajan@amd.com \
    --cc=Kan.liang@intel.com \
    --cc=bp@suse.de \
    --cc=davem@davemloft.net \
    --cc=greg@enjellic.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=grzegorz.andrejczuk@intel.com \
    --cc=haim.cohen@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jmattson@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=me@kylehuey.com \
    --cc=mingo@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=pbonzini@redhat.com \
    --cc=piotr.luc@intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=vikas.shivappa@linux.intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).