diff for duplicates of <1532019963.16711.61.camel@intel.com> diff --git a/a/content_digest b/N1/content_digest index 210d319..9878bc3 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -34,7 +34,10 @@ Mike Kravetz <mike.kravetz@oracle.com> Nadav Amit <nadav.amit@gmail.com> Oleg Nesterov <oleg@redhat.com> - " Pavel Machek <pavel@ucw.cz>Peter\0" + Pavel Machek <pavel@ucw.cz> + Peter Zijlstra <peterz@infradead.org> + Ravi V. Shankar <ravi.v.shankar@intel.com> + " Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>\0" "\00:1\0" "b\0" "On Wed, 2018-07-18 at 17:06 -0700, Dave Hansen wrote:\n" @@ -121,4 +124,4 @@ "\n" Yu-cheng -639b5076f1a30b53c3f0641e0ac4cb74bcff2e69b1468346636a3e33b10b4156 +091ed5b23db5882f804370d7ad994c70c9d67cde7b66449b5bcf58a1ce588283
diff --git a/a/1.txt b/N2/1.txt index 766a015..4367ba6 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -81,3 +81,8 @@ int pte_write_2(pte) { } Yu-cheng + +-- +To unsubscribe from this list: send the line "unsubscribe linux-doc" in +the body of a message to majordomo@vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N2/content_digest index 210d319..fe482bb 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -34,7 +34,10 @@ Mike Kravetz <mike.kravetz@oracle.com> Nadav Amit <nadav.amit@gmail.com> Oleg Nesterov <oleg@redhat.com> - " Pavel Machek <pavel@ucw.cz>Peter\0" + Pavel Machek <pavel@ucw.cz> + Peter Zijlstra <peterz@infradead.org> + Ravi V. Shankar <ravi.v.shankar@intel.com> + " Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>\0" "\00:1\0" "b\0" "On Wed, 2018-07-18 at 17:06 -0700, Dave Hansen wrote:\n" @@ -119,6 +122,11 @@ "\treturn (_PAGE_RW set) || is_shstk_pte(pte);\n" "}\n" "\n" - Yu-cheng + "Yu-cheng\n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-doc\" in\n" + "the body of a message to majordomo@vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -639b5076f1a30b53c3f0641e0ac4cb74bcff2e69b1468346636a3e33b10b4156 +1b3e5138d8797c0a9d15a4bdddb13dd6176cceae178e9b3d7b78fad7132c4f4d
diff --git a/a/1.txt b/N3/1.txt index 766a015..78c747f 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -6,9 +6,9 @@ On Wed, 2018-07-18 at 17:06 -0700, Dave Hansen wrote: > > > > int flags) > > > > +static inline bool can_follow_write(pte_t pte, unsigned int > > > > flags, -> > > > + struct vm_area_struct +> > > > + A A A A struct vm_area_struct > > > > *vma) -> > > > { +> > > > A { > > > > - return pte_write(pte) || > > > > - ((flags & FOLL_FORCE) && (flags & FOLL_COW) > > > > && pte_dirty(pte)); @@ -18,9 +18,9 @@ On Wed, 2018-07-18 at 17:06 -0700, Dave Hansen wrote: > > > Let me see if I can say this another way. > > > > > > The bigger issue is that these patches change the semantics of -> > > pte_write(). Before these patches, it meant that you *MUST* +> > > pte_write().A A Before these patches, it meant that you *MUST* > > > have this -> > > bit set to write to the page controlled by the PTE. Now, it +> > > bit set to write to the page controlled by the PTE.A A Now, it > > > means: you > > > can write if this bit is set *OR* the shadowstack bit > > > combination is set. @@ -28,15 +28,15 @@ On Wed, 2018-07-18 at 17:06 -0700, Dave Hansen wrote: > > PTE; or > > (2) if the page is pointed by a RO PTE (data or SHSTK) and it has > > been -> > copied and it still exists. We are not trying to +> > copied and it still exists. A We are not trying to > > determine if the > > SHSTK PTE is writable (we know it is not). -> Please think about the big picture. I'm not just talking about this +> Please think about the big picture.A A I'm not just talking about this > patch, but about every use of pte_write() in the kernel. > > > > > > -> > > That's the fundamental problem. We need some code in the kernel +> > > That's the fundamental problem.A A We need some code in the kernel > > > that > > > logically represents the concept of "is this PTE a shadowstack > > > PTE or a @@ -44,7 +44,7 @@ On Wed, 2018-07-18 at 17:06 -0700, Dave Hansen wrote: > > > or maybe > > > pte_writable(). > > > -> > > You *have* to somehow rectify this situation. We can absolutely +> > > You *have* to somehow rectify this situation.A A We can absolutely > > > no > > > leave pte_write() in its current, ambiguous state where it has > > > no real @@ -52,9 +52,9 @@ On Wed, 2018-07-18 at 17:06 -0700, Dave Hansen wrote: > > > context. > > True, the processor can always write to a page through a shadow > > stack -> > PTE, but it must do that with a CALL instruction. Can we define -> > a -> > write operation as: MOV r1, *(r2). Then we don't have any doubt +> > PTE, but it must do that with a CALL instruction. A Can we define +> > aA +> > write operation as: MOV r1, *(r2). A Then we don't have any doubt > > on > > pte_write() any more. > No, we can't just move the target. :) diff --git a/a/content_digest b/N3/content_digest index 210d319..2938921 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -34,7 +34,10 @@ Mike Kravetz <mike.kravetz@oracle.com> Nadav Amit <nadav.amit@gmail.com> Oleg Nesterov <oleg@redhat.com> - " Pavel Machek <pavel@ucw.cz>Peter\0" + Pavel Machek <pavel@ucw.cz> + Peter Zijlstra <peterz@infradead.org> + Ravi V. Shankar <ravi.v.shankar@intel.com> + " Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>\0" "\00:1\0" "b\0" "On Wed, 2018-07-18 at 17:06 -0700, Dave Hansen wrote:\n" @@ -45,9 +48,9 @@ "> > > > int flags)\n" "> > > > +static inline bool can_follow_write(pte_t pte, unsigned int\n" "> > > > flags,\n" - "> > > > +\t\t\t\t\302\240\302\240\302\240\302\240struct vm_area_struct\n" + "> > > > +\t\t\t\tA A A A struct vm_area_struct\n" "> > > > *vma)\n" - "> > > > \302\240{\n" + "> > > > A {\n" "> > > > -\treturn pte_write(pte) ||\n" "> > > > -\t\t((flags & FOLL_FORCE) && (flags & FOLL_COW)\n" "> > > > && pte_dirty(pte));\n" @@ -57,9 +60,9 @@ "> > > Let me see if I can say this another way.\n" "> > > \n" "> > > The bigger issue is that these patches change the semantics of\n" - "> > > pte_write().\302\240\302\240Before these patches, it meant that you *MUST*\n" + "> > > pte_write().A A Before these patches, it meant that you *MUST*\n" "> > > have this\n" - "> > > bit set to write to the page controlled by the PTE.\302\240\302\240Now, it\n" + "> > > bit set to write to the page controlled by the PTE.A A Now, it\n" "> > > means: you\n" "> > > can write if this bit is set *OR* the shadowstack bit\n" "> > > combination is set.\n" @@ -67,15 +70,15 @@ "> > PTE; or\n" "> > (2) if the page is pointed by a RO PTE (data or SHSTK) and it has\n" "> > been\n" - "> > copied and it still exists. \302\240We are not trying to\n" + "> > copied and it still exists. A We are not trying to\n" "> > determine if the\n" "> > SHSTK PTE is writable (we know it is not).\n" - "> Please think about the big picture.\302\240\302\240I'm not just talking about this\n" + "> Please think about the big picture.A A I'm not just talking about this\n" "> patch, but about every use of pte_write() in the kernel.\n" "> \n" "> > \n" "> > > \n" - "> > > That's the fundamental problem.\302\240\302\240We need some code in the kernel\n" + "> > > That's the fundamental problem.A A We need some code in the kernel\n" "> > > that\n" "> > > logically represents the concept of \"is this PTE a shadowstack\n" "> > > PTE or a\n" @@ -83,7 +86,7 @@ "> > > or maybe\n" "> > > pte_writable().\n" "> > > \n" - "> > > You *have* to somehow rectify this situation.\302\240\302\240We can absolutely\n" + "> > > You *have* to somehow rectify this situation.A A We can absolutely\n" "> > > no\n" "> > > leave pte_write() in its current, ambiguous state where it has\n" "> > > no real\n" @@ -91,9 +94,9 @@ "> > > context.\n" "> > True, the processor can always write to a page through a shadow\n" "> > stack\n" - "> > PTE, but it must do that with a CALL instruction. \302\240Can we define\n" - "> > a\302\240\n" - "> > write operation as: MOV r1, *(r2). \302\240Then we don't have any doubt\n" + "> > PTE, but it must do that with a CALL instruction. A Can we define\n" + "> > aA \n" + "> > write operation as: MOV r1, *(r2). A Then we don't have any doubt\n" "> > on\n" "> > pte_write() any more.\n" "> No, we can't just move the target. :)\n" @@ -121,4 +124,4 @@ "\n" Yu-cheng -639b5076f1a30b53c3f0641e0ac4cb74bcff2e69b1468346636a3e33b10b4156 +8670324e59bd680048067ddbee043e5a9e27fa837bdc38cba48a32ef17090030
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.