diff for duplicates of <1531504609.11680.16.camel@intel.com> diff --git a/a/content_digest b/N1/content_digest index b932cec..7fa6ac9 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -30,7 +30,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-11 at 16:16 -0700, Dave Hansen wrote:\n" @@ -94,4 +97,4 @@ "\n" Yu-cheng -f0f87aa3b5201151a11a163b38fa0bb57a2669f205ef11d6c69ce80e83b1528e +57b732ce5915883ad33545459d8628e4473a6a88fcc6cf0ad00aa3440cd20012
diff --git a/a/1.txt b/N2/1.txt index 3f000fc..9bd011b 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -58,3 +58,8 @@ partial IBT protection and no SHSTK. Do we want to consider simply turning off IBT in that case? 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 b932cec..de63577 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -30,7 +30,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-11 at 16:16 -0700, Dave Hansen wrote:\n" @@ -92,6 +95,11 @@ "partial IBT protection and no SHSTK. \302\240Do we want to consider simply turning\n" "off IBT in that case?\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 -f0f87aa3b5201151a11a163b38fa0bb57a2669f205ef11d6c69ce80e83b1528e +046425ca5f63ff98603e6e45a765aa373cdbf8c84d9bacafa13662e74cb3513d
diff --git a/a/1.txt b/N3/1.txt index 3f000fc..18c6afa 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -9,7 +9,7 @@ On Wed, 2018-07-11 at 16:16 -0700, Dave Hansen wrote: > > > > On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote: > > > > > > > > > > -> > > > > Is this feature *integral* to shadow stacks? Or, should it just +> > > > > Is this feature *integral* to shadow stacks?A A Or, should it just > > > > > be > > > > > in a > > > > > different series? @@ -17,34 +17,34 @@ On Wed, 2018-07-11 at 16:16 -0700, Dave Hansen wrote: > > > > IBT. > > > > IBT changes cannot be applied by itself without first applying > > > > SHSTK -> > > > changes. Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk, +> > > > changes. A Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk, > > > > etc.? > > > That doesn't really answer what I asked, though. > > > -> > > Do shadow stacks *require* IBT? Or, should we concentrate on merging +> > > Do shadow stacks *require* IBT?A A Or, should we concentrate on merging > > > shadow stacks themselves first and then do IBT at a later time, in a > > > different patch series? > > > > > > But, yes, better patch titles would help, although I'm not sure > > > that's > > > quite the format that Ingo and Thomas prefer. -> > Shadow stack does not require IBT, but they complement each other. If +> > Shadow stack does not require IBT, but they complement each other. A If > > we can resolve the legacy bitmap, both features can be merged at the > > same time. > As large as this patch set is, I'd really prefer to see you get shadow -> stacks merged and then move on to IBT. I say separate them. +> stacks merged and then move on to IBT.A A I say separate them. Ok, separate them. > > > -> > GLIBC does the bitmap setup. It sets bits in there. -> > I thought you wanted a smaller bitmap? One way is forcing legacy libs +> > GLIBC does the bitmap setup. A It sets bits in there. +> > I thought you wanted a smaller bitmap? A One way is forcing legacy libs > > to low address, or not having the bitmap at all, i.e. turn IBT off. > I'm concerned with two things: > 1. the virtual address space consumption, especially the *default* case -> which will be apps using 4-level address space amounts, but having -> 5-level-sized tables. +> A A A which will be apps using 4-level address space amounts, but having +> A A A 5-level-sized tables. > 2. the driving a truck-sized hole in the address space limits > > You can force legacy libs to low addresses, but you can't stop anyone @@ -54,7 +54,7 @@ Ok, separate them. So we will always reserve a big space for all CET tasks? Currently if an application does dlopen() a legacy lib, it will have only -partial IBT protection and no SHSTK. Do we want to consider simply turning +partial IBT protection and no SHSTK. A Do we want to consider simply turning off IBT in that case? Yu-cheng diff --git a/a/content_digest b/N3/content_digest index b932cec..8bffc32 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -30,7 +30,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-11 at 16:16 -0700, Dave Hansen wrote:\n" @@ -44,7 +47,7 @@ "> > > > On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:\n" "> > > > > \n" "> > > > > \n" - "> > > > > Is this feature *integral* to shadow stacks?\302\240\302\240Or, should it just\n" + "> > > > > Is this feature *integral* to shadow stacks?A A Or, should it just\n" "> > > > > be\n" "> > > > > in a\n" "> > > > > different series?\n" @@ -52,34 +55,34 @@ "> > > > IBT.\n" "> > > > IBT changes cannot be applied by itself without first applying\n" "> > > > SHSTK\n" - "> > > > changes. \302\240Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk,\n" + "> > > > changes. A Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk,\n" "> > > > etc.?\n" "> > > That doesn't really answer what I asked, though.\n" "> > > \n" - "> > > Do shadow stacks *require* IBT?\302\240\302\240Or, should we concentrate on merging\n" + "> > > Do shadow stacks *require* IBT?A A Or, should we concentrate on merging\n" "> > > shadow stacks themselves first and then do IBT at a later time, in a\n" "> > > different patch series?\n" "> > > \n" "> > > But, yes, better patch titles would help, although I'm not sure\n" "> > > that's\n" "> > > quite the format that Ingo and Thomas prefer.\n" - "> > Shadow stack does not require IBT, but they complement each other. \302\240If\n" + "> > Shadow stack does not require IBT, but they complement each other. A If\n" "> > we can resolve the legacy bitmap, both features can be merged at the\n" "> > same time.\n" "> As large as this patch set is, I'd really prefer to see you get shadow\n" - "> stacks merged and then move on to IBT.\302\240\302\240I say separate them.\n" + "> stacks merged and then move on to IBT.A A I say separate them.\n" "\n" "Ok, separate them.\n" "\n" "> \n" "> > \n" - "> > GLIBC does the bitmap setup. \302\240It sets bits in there.\n" - "> > I thought you wanted a smaller bitmap? \302\240One way is forcing legacy libs\n" + "> > GLIBC does the bitmap setup. A It sets bits in there.\n" + "> > I thought you wanted a smaller bitmap? A One way is forcing legacy libs\n" "> > to low address, or not having the bitmap at all, i.e. turn IBT off.\n" "> I'm concerned with two things:\n" "> 1. the virtual address space consumption, especially the *default* case\n" - "> \302\240\302\240\302\240which will be apps using 4-level address space amounts, but having\n" - "> \302\240\302\240\302\2405-level-sized tables.\n" + "> A A A which will be apps using 4-level address space amounts, but having\n" + "> A A A 5-level-sized tables.\n" "> 2. the driving a truck-sized hole in the address space limits\n" "> \n" "> You can force legacy libs to low addresses, but you can't stop anyone\n" @@ -89,9 +92,9 @@ "So we will always reserve a big space for all CET tasks?\n" "\n" "Currently if an application does dlopen() a legacy lib, it will have only\n" - "partial IBT protection and no SHSTK. \302\240Do we want to consider simply turning\n" + "partial IBT protection and no SHSTK. A Do we want to consider simply turning\n" "off IBT in that case?\n" "\n" Yu-cheng -f0f87aa3b5201151a11a163b38fa0bb57a2669f205ef11d6c69ce80e83b1528e +462920135c189f0889d866bd5344d69bafb5ed66c67b099c282cf2e776486a7c
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.