diff for duplicates of <1531504984.11680.21.camel@intel.com> diff --git a/a/content_digest b/N1/content_digest index 963d2ae..be2fe84 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -31,7 +31,8 @@ Oleg Nesterov <oleg@redhat.com> Pavel Machek <pavel@ucw.cz> Peter Zijlstra <peterz@infradead.org> - " ravi\0" + ravi.v.shankar@intel.com + " vedvyas.shanbhogue@intel.com\0" "\00:1\0" "b\0" "On Wed, 2018-07-11 at 15:21 -0700, Andy Lutomirski wrote:\n" @@ -103,4 +104,4 @@ "\n" Yu-cheng -c7df6af68df2c8d215f3654cbe702fd0eb5ea281f7e373bc186056ee4b439046 +caefb7c131be4fd41ce6e072e0cc960ee0d756a35819395e04f99c79eb1e88c1
diff --git a/a/1.txt b/N2/1.txt index 11974de..f36b1d6 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -65,4 +65,9 @@ On Wed, 2018-07-11 at 15:21 -0700, Andy Lutomirski wrote: We can put a NULL at both ends of a SHSTK to guard against corruption. -Yu-cheng +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 963d2ae..ada0e40 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -31,7 +31,8 @@ Oleg Nesterov <oleg@redhat.com> Pavel Machek <pavel@ucw.cz> Peter Zijlstra <peterz@infradead.org> - " ravi\0" + ravi.v.shankar@intel.com + " vedvyas.shanbhogue@intel.com\0" "\00:1\0" "b\0" "On Wed, 2018-07-11 at 15:21 -0700, Andy Lutomirski wrote:\n" @@ -101,6 +102,11 @@ "\n" "We can put a NULL at both ends of a SHSTK to guard against corruption.\n" "\n" - Yu-cheng + "Yu-cheng\302\240\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 -c7df6af68df2c8d215f3654cbe702fd0eb5ea281f7e373bc186056ee4b439046 +4e711f6356ac130b7b9a10c0b6ae1e77221034a63859fac1f9d5d4c7f6e76ebe
diff --git a/a/1.txt b/N3/1.txt index 11974de..1a557de 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -12,7 +12,7 @@ On Wed, 2018-07-11 at 15:21 -0700, Andy Lutomirski wrote: > > > > > > > > > > This patch adds basic shadow stack enabling/disabling routines. > > > > > A task's shadow stack is allocated from memory with VM_SHSTK -> > > > > flag set and read-only protection. The shadow stack is +> > > > > flag set and read-only protection.A A The shadow stack is > > > > > allocated to a fixed size. > > > > > > > > > > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> @@ -27,19 +27,19 @@ On Wed, 2018-07-11 at 15:21 -0700, Andy Lutomirski wrote: > > > > > > > > > > +static unsigned long shstk_mmap(unsigned long addr, unsigned long len) > > > > > +{ -> > > > > + struct mm_struct *mm = current->mm; -> > > > > + unsigned long populate; +> > > > > +A A A A A A A struct mm_struct *mm = current->mm; +> > > > > +A A A A A A A unsigned long populate; > > > > > + -> > > > > + down_write(&mm->mmap_sem); -> > > > > + addr = do_mmap(NULL, addr, len, PROT_READ, -> > > > > + MAP_ANONYMOUS | MAP_PRIVATE, VM_SHSTK, -> > > > > + 0, &populate, NULL); -> > > > > + up_write(&mm->mmap_sem); +> > > > > +A A A A A A A down_write(&mm->mmap_sem); +> > > > > +A A A A A A A addr = do_mmap(NULL, addr, len, PROT_READ, +> > > > > +A A A A A A A A A A A A A A A A A A A A A A MAP_ANONYMOUS | MAP_PRIVATE, VM_SHSTK, +> > > > > +A A A A A A A A A A A A A A A A A A A A A A 0, &populate, NULL); +> > > > > +A A A A A A A up_write(&mm->mmap_sem); > > > > > + -> > > > > + if (populate) -> > > > > + mm_populate(addr, populate); +> > > > > +A A A A A A A if (populate) +> > > > > +A A A A A A A A A A A A A A A mm_populate(addr, populate); > > > > > + -> > > > > + return addr; +> > > > > +A A A A A A A return addr; > > > > > +} > > [...] > > > @@ -48,21 +48,21 @@ On Wed, 2018-07-11 at 15:21 -0700, Andy Lutomirski wrote: > > > > page between them so that they can not be directly adjacent, so that > > > > if you have too much recursion, you can't end up corrupting an > > > > adjacent shadow stack? -> > > I think the answer is a qualified “no”. I would like to instead enforce a general guard page on all mmaps that don’t use MAP_FORCE. We *might* need to exempt any mmap with an address hint for +> > > I think the answer is a qualified a??noa??. I would like to instead enforce a general guard page on all mmaps that dona??t use MAP_FORCE. We *might* need to exempt any mmap with an address hint for > > > compatibility. > > I like this idea a lot. > > > > > > > > My commercial software has been manually adding guard pages on every single mmap done by tcmalloc for years, and it has caught a couple bugs and costs essentially nothing. > > > -> > > Hmm. Linux should maybe add something like Windows’ “reserved” virtual memory. It’s basically a way to ask for a VA range that explicitly contains nothing and can be subsequently be turned into +> > > Hmm. Linux should maybe add something like Windowsa?? a??reserveda?? virtual memory. Ita??s basically a way to ask for a VA range that explicitly contains nothing and can be subsequently be turned into > > > something useful with the equivalent of MAP_FORCE. > > What's the benefit over creating an anonymous PROT_NONE region? That > > the kernel won't have to scan through the corresponding PTEs when > > tearing down the mapping? -> Make it more obvious what’s happening and avoid accounting issues? What I’ve actually used is MAP_NORESERVE | PROT_NONE, but I think this still counts against the VA rlimit. But maybe that’s +> Make it more obvious whata??s happening and avoid accounting issues?A A What Ia??ve actually used is MAP_NORESERVE | PROT_NONE, but I think this still counts against the VA rlimit. But maybe thata??s > actually the desired behavior. We can put a NULL at both ends of a SHSTK to guard against corruption. -Yu-cheng +Yu-chengA diff --git a/a/content_digest b/N3/content_digest index 963d2ae..93c16cd 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -31,7 +31,8 @@ Oleg Nesterov <oleg@redhat.com> Pavel Machek <pavel@ucw.cz> Peter Zijlstra <peterz@infradead.org> - " ravi\0" + ravi.v.shankar@intel.com + " vedvyas.shanbhogue@intel.com\0" "\00:1\0" "b\0" "On Wed, 2018-07-11 at 15:21 -0700, Andy Lutomirski wrote:\n" @@ -48,7 +49,7 @@ "> > > > > \n" "> > > > > This patch adds basic shadow stack enabling/disabling routines.\n" "> > > > > A task's shadow stack is allocated from memory with VM_SHSTK\n" - "> > > > > flag set and read-only protection.\302\240\302\240The shadow stack is\n" + "> > > > > flag set and read-only protection.A A The shadow stack is\n" "> > > > > allocated to a fixed size.\n" "> > > > > \n" "> > > > > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>\n" @@ -63,19 +64,19 @@ "> > > > > \n" "> > > > > +static unsigned long shstk_mmap(unsigned long addr, unsigned long len)\n" "> > > > > +{\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240struct mm_struct *mm = current->mm;\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240unsigned long populate;\n" + "> > > > > +A A A A A A A struct mm_struct *mm = current->mm;\n" + "> > > > > +A A A A A A A unsigned long populate;\n" "> > > > > +\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240down_write(&mm->mmap_sem);\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240addr = do_mmap(NULL, addr, len, PROT_READ,\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240MAP_ANONYMOUS | MAP_PRIVATE, VM_SHSTK,\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2400, &populate, NULL);\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240up_write(&mm->mmap_sem);\n" + "> > > > > +A A A A A A A down_write(&mm->mmap_sem);\n" + "> > > > > +A A A A A A A addr = do_mmap(NULL, addr, len, PROT_READ,\n" + "> > > > > +A A A A A A A A A A A A A A A A A A A A A A MAP_ANONYMOUS | MAP_PRIVATE, VM_SHSTK,\n" + "> > > > > +A A A A A A A A A A A A A A A A A A A A A A 0, &populate, NULL);\n" + "> > > > > +A A A A A A A up_write(&mm->mmap_sem);\n" "> > > > > +\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240if (populate)\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240mm_populate(addr, populate);\n" + "> > > > > +A A A A A A A if (populate)\n" + "> > > > > +A A A A A A A A A A A A A A A mm_populate(addr, populate);\n" "> > > > > +\n" - "> > > > > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240return addr;\n" + "> > > > > +A A A A A A A return addr;\n" "> > > > > +}\n" "> > [...]\n" "> > > \n" @@ -84,23 +85,23 @@ "> > > > page between them so that they can not be directly adjacent, so that\n" "> > > > if you have too much recursion, you can't end up corrupting an\n" "> > > > adjacent shadow stack?\n" - "> > > I think the answer is a qualified \342\200\234no\342\200\235. I would like to instead enforce a general guard page on all mmaps that don\342\200\231t use MAP_FORCE. We *might* need to exempt any mmap with an address hint for\n" + "> > > I think the answer is a qualified a??noa??. I would like to instead enforce a general guard page on all mmaps that dona??t use MAP_FORCE. We *might* need to exempt any mmap with an address hint for\n" "> > > compatibility.\n" "> > I like this idea a lot.\n" "> > \n" "> > > \n" "> > > My commercial software has been manually adding guard pages on every single mmap done by tcmalloc for years, and it has caught a couple bugs and costs essentially nothing.\n" "> > > \n" - "> > > Hmm. Linux should maybe add something like Windows\342\200\231 \342\200\234reserved\342\200\235 virtual memory. It\342\200\231s basically a way to ask for a VA range that explicitly contains nothing and can be subsequently be turned into\n" + "> > > Hmm. Linux should maybe add something like Windowsa?? a??reserveda?? virtual memory. Ita??s basically a way to ask for a VA range that explicitly contains nothing and can be subsequently be turned into\n" "> > > something useful with the equivalent of MAP_FORCE.\n" "> > What's the benefit over creating an anonymous PROT_NONE region? That\n" "> > the kernel won't have to scan through the corresponding PTEs when\n" "> > tearing down the mapping?\n" - "> Make it more obvious what\342\200\231s happening and avoid accounting issues?\302\240\302\240What I\342\200\231ve actually used is MAP_NORESERVE | PROT_NONE, but I think this still counts against the VA rlimit. But maybe that\342\200\231s\n" + "> Make it more obvious whata??s happening and avoid accounting issues?A A What Ia??ve actually used is MAP_NORESERVE | PROT_NONE, but I think this still counts against the VA rlimit. But maybe thata??s\n" "> actually the desired behavior.\n" "\n" "We can put a NULL at both ends of a SHSTK to guard against corruption.\n" "\n" - Yu-cheng + Yu-chengA -c7df6af68df2c8d215f3654cbe702fd0eb5ea281f7e373bc186056ee4b439046 +448465ed330b4ee833aa86ce686b28c7055e6f35a8eaf5398880608b6d6c787b
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.