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

diff --git a/a/content_digest b/N1/content_digest
index 92d318e..08c5ac0 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -51,9 +51,7 @@
   " Nadav Amit <nadav.amit\@gmail.com>",
   " Oleg Nesterov <oleg\@redhat.com>",
   " Pavel Machek <pavel\@ucw.cz>",
-  " Peter Zijlstra <peterz\@infradead.org>",
-  " ravi.v.shankar\@intel.com",
-  " vedvyas.shanbhogue\@intel.com\0"
+  " Peter Zijlstra <peterz\@infradead>\0"
 ]
 [
   "\0000:1\0"
@@ -96,4 +94,4 @@
   "Yu-cheng"
 ]
 
-8a80fdf4b678db03b0b0a905d7b798228fdbe1da4e005baee2a3f809ccc25047
+813acb5616143317b4a4c249c9fcddc957d8078a13cfa46441e9c0a4d3a323ac

diff --git a/a/1.txt b/N2/1.txt
index d7ea33e..1ec93d3 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -5,7 +5,7 @@ On Thu, 2018-08-30 at 10:19 -0700, Dave Hansen wrote:
 > > 
 > > 1. a dirty+writable PTE is placed directly in front of B's shadow
 > > stack.
-> >    (this can happen, right? or is there a guard page?)
+> > A A A (this can happen, right? or is there a guard page?)
 > > 2. C's TLB caches the dirty+writable PTE.
 > > 3. A performs some syscall that triggers ptep_set_wrprotect().
 > > 4. A's syscall calls clear_bit().
@@ -14,15 +14,15 @@ On Thu, 2018-08-30 at 10:19 -0700, Dave Hansen wrote:
 > > 6. B recurses into the transiently-extended shadow stack
 > > 7. C overwrites the transiently-extended shadow stack area.
 > > 8. B returns through the transiently-extended shadow stack, giving
-> >     the attacker instruction pointer control in B.
+> > A A A A the attacker instruction pointer control in B.
 > > 9. A's syscall broadcasts a TLB flush.
-> Heh, that's a good point.  The shadow stack permissions are *not*
+> Heh, that's a good point.A A The shadow stack permissions are *not*
 > strictly reduced because a page getting marked as shadow-stack has
-> *increased* permissions when being used as a shadow stack.  Fun.
+> *increased* permissions when being used as a shadow stack.A A Fun.
 > 
 > For general hardening, it seems like we want to ensure that there's
 > a
-> guard page at the bottom of the shadow stack.  Yu-cheng, do we have
+> guard page at the bottom of the shadow stack.A A Yu-cheng, do we have
 > a
 > guard page?
 
diff --git a/a/content_digest b/N2/content_digest
index 92d318e..b67a2d4 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -69,7 +69,7 @@
   "> > \n",
   "> > 1. a dirty+writable PTE is placed directly in front of B's shadow\n",
   "> > stack.\n",
-  "> > \302\240\302\240\302\240(this can happen, right? or is there a guard page?)\n",
+  "> > A A A (this can happen, right? or is there a guard page?)\n",
   "> > 2. C's TLB caches the dirty+writable PTE.\n",
   "> > 3. A performs some syscall that triggers ptep_set_wrprotect().\n",
   "> > 4. A's syscall calls clear_bit().\n",
@@ -78,15 +78,15 @@
   "> > 6. B recurses into the transiently-extended shadow stack\n",
   "> > 7. C overwrites the transiently-extended shadow stack area.\n",
   "> > 8. B returns through the transiently-extended shadow stack, giving\n",
-  "> > \302\240\302\240\302\240\302\240the attacker instruction pointer control in B.\n",
+  "> > A A A A the attacker instruction pointer control in B.\n",
   "> > 9. A's syscall broadcasts a TLB flush.\n",
-  "> Heh, that's a good point.\302\240\302\240The shadow stack permissions are *not*\n",
+  "> Heh, that's a good point.A A The shadow stack permissions are *not*\n",
   "> strictly reduced because a page getting marked as shadow-stack has\n",
-  "> *increased* permissions when being used as a shadow stack.\302\240\302\240Fun.\n",
+  "> *increased* permissions when being used as a shadow stack.A A Fun.\n",
   "> \n",
   "> For general hardening, it seems like we want to ensure that there's\n",
   "> a\n",
-  "> guard page at the bottom of the shadow stack.\302\240\302\240Yu-cheng, do we have\n",
+  "> guard page at the bottom of the shadow stack.A A Yu-cheng, do we have\n",
   "> a\n",
   "> guard page?\n",
   "\n",
@@ -96,4 +96,4 @@
   "Yu-cheng"
 ]
 
-8a80fdf4b678db03b0b0a905d7b798228fdbe1da4e005baee2a3f809ccc25047
+cf090a8d3fc69ba66acc8d907ad8612bf3abaa11f6c55c2e32179eb75e43dc45

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.