All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1541524750.7839.51.camel@intel.com>

diff --git a/a/content_digest b/N1/content_digest
index b511e33..9e3c0e8 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -39,7 +39,10 @@
   linux-sgx@vger.kernel.org
   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
   Thomas Gleixner <tglx@linutronix.de>
- " Ingo\0"
+  Ingo Molnar <mingo@redhat.com>
+  Borislav Petkov <bp@alien8.de>
+  Carlos O'Donell <carlos@redhat.com>
+ " adhemerval.zanella@linaro.org\0"
  "\00:1\0"
  "b\0"
  "On Tue, 2018-11-06 at 08:57 -0800, Andy Lutomirski wrote:\n"
@@ -60,4 +63,4 @@
  "That's my understanding of things.\302\240\302\240So yeah, if it wasn't obvious before,\n"
  the trusted and untrusted parts of the SDK are very tightly coupled.
 
-4cb69f3c00440ff6c54737023d8f465d766dc5bca5f414c183da4577c1ef5b77
+ae7deb7f5bb890c5ad6a202e72cfd98cbd12c2d44bb668d9156a1a288df0167d

diff --git a/a/1.txt b/N2/1.txt
index 5a3f684..5cf65c8 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -1,17 +1,15 @@
-On Tue, 2018-11-06 at 08:57 -0800, Andy Lutomirski wrote:
->
-> So I guess the non-enclave code basically can’t trust its stack pointer
-> because of these shenanigans. And the AEP code has to live with the fact
-> that its RSP is basically arbitrary and probably can’t even be unwound
-> by a debugger?
-
-The SDK provides a Python GDB plugin to hook into the out-call flow and
-do more stack shenanigans.  From what I can tell it's fudging the stack
-to make it look like a normal stack frame so the debugger can do it's
-thing.
-
-> And the EENTER code has to deal with the fact that its red zone can be
-> blatantly violated by the enclave?
-
-That's my understanding of things.  So yeah, if it wasn't obvious before,
-the trusted and untrusted parts of the SDK are very tightly coupled.
+T24gVHVlLCAyMDE4LTExLTA2IGF0IDA4OjU3IC0wODAwLCBBbmR5IEx1dG9taXJza2kgd3JvdGU6
+DQo+DQo+IFNvIEkgZ3Vlc3MgdGhlIG5vbi1lbmNsYXZlIGNvZGUgYmFzaWNhbGx5IGNhbuKAmXQg
+dHJ1c3QgaXRzIHN0YWNrIHBvaW50ZXINCj4gYmVjYXVzZSBvZiB0aGVzZSBzaGVuYW5pZ2Fucy4g
+QW5kIHRoZSBBRVAgY29kZSBoYXMgdG8gbGl2ZSB3aXRoIHRoZSBmYWN0DQo+IHRoYXQgaXRzIFJT
+UCBpcyBiYXNpY2FsbHkgYXJiaXRyYXJ5IGFuZCBwcm9iYWJseSBjYW7igJl0IGV2ZW4gYmUgdW53
+b3VuZA0KPiBieSBhIGRlYnVnZ2VyPw0KDQpUaGUgU0RLIHByb3ZpZGVzIGEgUHl0aG9uIEdEQiBw
+bHVnaW4gdG8gaG9vayBpbnRvIHRoZSBvdXQtY2FsbCBmbG93IGFuZA0KZG8gbW9yZSBzdGFjayBz
+aGVuYW5pZ2Fucy7CoMKgRnJvbSB3aGF0IEkgY2FuIHRlbGwgaXQncyBmdWRnaW5nIHRoZSBzdGFj
+aw0KdG8gbWFrZSBpdCBsb29rIGxpa2UgYSBub3JtYWwgc3RhY2sgZnJhbWUgc28gdGhlIGRlYnVn
+Z2VyIGNhbiBkbyBpdCdzDQp0aGluZy4NCg0KPiBBbmQgdGhlIEVFTlRFUiBjb2RlIGhhcyB0byBk
+ZWFsIHdpdGggdGhlIGZhY3QgdGhhdCBpdHMgcmVkIHpvbmUgY2FuIGJlDQo+IGJsYXRhbnRseSB2
+aW9sYXRlZCBieSB0aGUgZW5jbGF2ZT8NCg0KVGhhdCdzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhp
+bmdzLsKgwqBTbyB5ZWFoLCBpZiBpdCB3YXNuJ3Qgb2J2aW91cyBiZWZvcmUsDQp0aGUgdHJ1c3Rl
+ZCBhbmQgdW50cnVzdGVkIHBhcnRzIG9mIHRoZSBTREsgYXJlIHZlcnkgdGlnaHRseSBjb3VwbGVk
+Lg0K
diff --git a/a/content_digest b/N2/content_digest
index b511e33..d7e3e20 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -15,11 +15,12 @@
  "ref\0AF4A5C77-0A79-403F-A205-0F93B7CD6E26@amacapital.net\0"
  "From\0Sean Christopherson <sean.j.christopherson@intel.com>\0"
  "Subject\0Re: RFC: userspace exception fixups\0"
- "Date\0Tue, 06 Nov 2018 09:19:10 -0800\0"
+ "Date\0Tue, 6 Nov 2018 09:19:10 -0800\0"
  "To\0Andy Lutomirski <luto@amacapital.net>\0"
  "Cc\0Andy Lutomirski <luto@kernel.org>"
   Jann Horn <jannh@google.com>
-  Dave Hansen <dave.hansen@intel.com>
+  Hansen
+  Dave <dave.hansen@intel.com>
   Linus Torvalds <torvalds@linux-foundation.org>
   Rich Felker <dalias@libc.org>
   Dave Hansen <dave.hansen@linux.intel.com>
@@ -31,33 +32,35 @@
   linux-arch <linux-arch@vger.kernel.org>
   LKML <linux-kernel@vger.kernel.org>
   Peter Zijlstra <peterz@infradead.org>
-  nhorman@redhat.com
-  npmccallum@redhat.com
+  nhorman@redhat.com <nhorman@redhat.com>
+  npmccallum@redhat.com <npmccallum@redhat.com>
   Ayoun
   Serge <serge.ayoun@intel.com>
-  shay.katz-zamir@intel.com
-  linux-sgx@vger.kernel.org
+  Katz-zamir
+  Shay <shay.katz-zamir@intel.com>
+  linux-sgx@vger.kernel.org <linux-sgx@vger.kernel.org>
   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
   Thomas Gleixner <tglx@linutronix.de>
- " Ingo\0"
+  Ingo Molnar <mingo@redhat.com>
+  Borislav Petkov <bp@alien8.de>
+  Carlos O'Donell <carlos@redhat.com>
+ " adhemerval.zanella@linaro.org <adhemerval.zanella@linaro.org>\0"
  "\00:1\0"
  "b\0"
- "On Tue, 2018-11-06 at 08:57 -0800, Andy Lutomirski wrote:\n"
- ">\n"
- "> So I guess the non-enclave code basically can\342\200\231t trust its stack pointer\n"
- "> because of these shenanigans. And the AEP code has to live with the fact\n"
- "> that its RSP is basically arbitrary and probably can\342\200\231t even be unwound\n"
- "> by a debugger?\n"
- "\n"
- "The SDK provides a Python GDB plugin to hook into the out-call flow and\n"
- "do more stack shenanigans.\302\240\302\240From what I can tell it's fudging the stack\n"
- "to make it look like a normal stack frame so the debugger can do it's\n"
- "thing.\n"
- "\n"
- "> And the EENTER code has to deal with the fact that its red zone can be\n"
- "> blatantly violated by the enclave?\n"
- "\n"
- "That's my understanding of things.\302\240\302\240So yeah, if it wasn't obvious before,\n"
- the trusted and untrusted parts of the SDK are very tightly coupled.
+ "T24gVHVlLCAyMDE4LTExLTA2IGF0IDA4OjU3IC0wODAwLCBBbmR5IEx1dG9taXJza2kgd3JvdGU6\n"
+ "DQo+DQo+IFNvIEkgZ3Vlc3MgdGhlIG5vbi1lbmNsYXZlIGNvZGUgYmFzaWNhbGx5IGNhbuKAmXQg\n"
+ "dHJ1c3QgaXRzIHN0YWNrIHBvaW50ZXINCj4gYmVjYXVzZSBvZiB0aGVzZSBzaGVuYW5pZ2Fucy4g\n"
+ "QW5kIHRoZSBBRVAgY29kZSBoYXMgdG8gbGl2ZSB3aXRoIHRoZSBmYWN0DQo+IHRoYXQgaXRzIFJT\n"
+ "UCBpcyBiYXNpY2FsbHkgYXJiaXRyYXJ5IGFuZCBwcm9iYWJseSBjYW7igJl0IGV2ZW4gYmUgdW53\n"
+ "b3VuZA0KPiBieSBhIGRlYnVnZ2VyPw0KDQpUaGUgU0RLIHByb3ZpZGVzIGEgUHl0aG9uIEdEQiBw\n"
+ "bHVnaW4gdG8gaG9vayBpbnRvIHRoZSBvdXQtY2FsbCBmbG93IGFuZA0KZG8gbW9yZSBzdGFjayBz\n"
+ "aGVuYW5pZ2Fucy7CoMKgRnJvbSB3aGF0IEkgY2FuIHRlbGwgaXQncyBmdWRnaW5nIHRoZSBzdGFj\n"
+ "aw0KdG8gbWFrZSBpdCBsb29rIGxpa2UgYSBub3JtYWwgc3RhY2sgZnJhbWUgc28gdGhlIGRlYnVn\n"
+ "Z2VyIGNhbiBkbyBpdCdzDQp0aGluZy4NCg0KPiBBbmQgdGhlIEVFTlRFUiBjb2RlIGhhcyB0byBk\n"
+ "ZWFsIHdpdGggdGhlIGZhY3QgdGhhdCBpdHMgcmVkIHpvbmUgY2FuIGJlDQo+IGJsYXRhbnRseSB2\n"
+ "aW9sYXRlZCBieSB0aGUgZW5jbGF2ZT8NCg0KVGhhdCdzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhp\n"
+ "bmdzLsKgwqBTbyB5ZWFoLCBpZiBpdCB3YXNuJ3Qgb2J2aW91cyBiZWZvcmUsDQp0aGUgdHJ1c3Rl\n"
+ "ZCBhbmQgdW50cnVzdGVkIHBhcnRzIG9mIHRoZSBTREsgYXJlIHZlcnkgdGlnaHRseSBjb3VwbGVk\n"
+ Lg0K
 
-4cb69f3c00440ff6c54737023d8f465d766dc5bca5f414c183da4577c1ef5b77
+1f01cecddf1c2af2730817082181fde4831ed140f62d7665885ee5de93c33b95

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.