diff for duplicates of <1541524750.7839.51.camel@intel.com> diff --git a/a/1.txt b/N1/1.txt index 5cf65c8..5a3f684 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,15 +1,17 @@ -T24gVHVlLCAyMDE4LTExLTA2IGF0IDA4OjU3IC0wODAwLCBBbmR5IEx1dG9taXJza2kgd3JvdGU6 -DQo+DQo+IFNvIEkgZ3Vlc3MgdGhlIG5vbi1lbmNsYXZlIGNvZGUgYmFzaWNhbGx5IGNhbuKAmXQg -dHJ1c3QgaXRzIHN0YWNrIHBvaW50ZXINCj4gYmVjYXVzZSBvZiB0aGVzZSBzaGVuYW5pZ2Fucy4g -QW5kIHRoZSBBRVAgY29kZSBoYXMgdG8gbGl2ZSB3aXRoIHRoZSBmYWN0DQo+IHRoYXQgaXRzIFJT -UCBpcyBiYXNpY2FsbHkgYXJiaXRyYXJ5IGFuZCBwcm9iYWJseSBjYW7igJl0IGV2ZW4gYmUgdW53 -b3VuZA0KPiBieSBhIGRlYnVnZ2VyPw0KDQpUaGUgU0RLIHByb3ZpZGVzIGEgUHl0aG9uIEdEQiBw -bHVnaW4gdG8gaG9vayBpbnRvIHRoZSBvdXQtY2FsbCBmbG93IGFuZA0KZG8gbW9yZSBzdGFjayBz -aGVuYW5pZ2Fucy7CoMKgRnJvbSB3aGF0IEkgY2FuIHRlbGwgaXQncyBmdWRnaW5nIHRoZSBzdGFj -aw0KdG8gbWFrZSBpdCBsb29rIGxpa2UgYSBub3JtYWwgc3RhY2sgZnJhbWUgc28gdGhlIGRlYnVn -Z2VyIGNhbiBkbyBpdCdzDQp0aGluZy4NCg0KPiBBbmQgdGhlIEVFTlRFUiBjb2RlIGhhcyB0byBk -ZWFsIHdpdGggdGhlIGZhY3QgdGhhdCBpdHMgcmVkIHpvbmUgY2FuIGJlDQo+IGJsYXRhbnRseSB2 -aW9sYXRlZCBieSB0aGUgZW5jbGF2ZT8NCg0KVGhhdCdzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhp -bmdzLsKgwqBTbyB5ZWFoLCBpZiBpdCB3YXNuJ3Qgb2J2aW91cyBiZWZvcmUsDQp0aGUgdHJ1c3Rl -ZCBhbmQgdW50cnVzdGVkIHBhcnRzIG9mIHRoZSBTREsgYXJlIHZlcnkgdGlnaHRseSBjb3VwbGVk -Lg0K +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. diff --git a/a/content_digest b/N1/content_digest index d7e3e20..9e3c0e8 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -15,12 +15,11 @@ "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, 6 Nov 2018 09:19:10 -0800\0" + "Date\0Tue, 06 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> - Hansen - Dave <dave.hansen@intel.com> + Dave Hansen <dave.hansen@intel.com> Linus Torvalds <torvalds@linux-foundation.org> Rich Felker <dalias@libc.org> Dave Hansen <dave.hansen@linux.intel.com> @@ -32,35 +31,36 @@ linux-arch <linux-arch@vger.kernel.org> LKML <linux-kernel@vger.kernel.org> Peter Zijlstra <peterz@infradead.org> - nhorman@redhat.com <nhorman@redhat.com> - npmccallum@redhat.com <npmccallum@redhat.com> + nhorman@redhat.com + npmccallum@redhat.com Ayoun Serge <serge.ayoun@intel.com> - Katz-zamir - Shay <shay.katz-zamir@intel.com> - linux-sgx@vger.kernel.org <linux-sgx@vger.kernel.org> + shay.katz-zamir@intel.com + linux-sgx@vger.kernel.org Andy Shevchenko <andriy.shevchenko@linux.intel.com> Thomas Gleixner <tglx@linutronix.de> 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" + " adhemerval.zanella@linaro.org\0" "\00:1\0" "b\0" - "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 + "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. -1f01cecddf1c2af2730817082181fde4831ed140f62d7665885ee5de93c33b95 +ae7deb7f5bb890c5ad6a202e72cfd98cbd12c2d44bb668d9156a1a288df0167d
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox