diff for duplicates of <1531350028.15351.102.camel@intel.com> diff --git a/a/content_digest b/N1/content_digest index 393799a..07b391d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -28,7 +28,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 15:40 -0700, Dave Hansen wrote:\n" @@ -159,4 +162,4 @@ "\n" Yes, that is the case. -7afc97fca94ac63b4e9059bee539a81fca189e6794b5daf1291a374d074ef757 +d3ec11f286d2d29a9b1b36038d2e24dccf6fae21399dc69d984891fecd0d9de0
diff --git a/a/1.txt b/N2/1.txt index d0976b3..16897a2 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -125,3 +125,8 @@ Got it. > current->thread and it's entirely thread-local? Yes, that is the case. + +-- +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 393799a..d358a55 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -28,7 +28,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 15:40 -0700, Dave Hansen wrote:\n" @@ -157,6 +160,11 @@ "> data structure?\302\240\302\240Is there none because it's only every modified via\n" "> current->thread and it's entirely thread-local?\n" "\n" - Yes, that is the case. + "Yes, that is the case.\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 -7afc97fca94ac63b4e9059bee539a81fca189e6794b5daf1291a374d074ef757 +345163f5f8fb4597711de04d14bf15cd3ae30dae823a20dbb2207bb17df98515
diff --git a/a/1.txt b/N3/1.txt index d0976b3..8a7c4a7 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -3,7 +3,7 @@ On Wed, 2018-07-11 at 15:40 -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? @@ -11,11 +11,11 @@ On Wed, 2018-07-11 at 15:40 -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? > @@ -23,7 +23,7 @@ On Wed, 2018-07-11 at 15:40 -0700, Dave Hansen wrote: > 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. @@ -44,24 +44,24 @@ same time. > > > Just a note: this table is going to be gigantic on 5-level paging > > > systems, and userspace won't, by default use any of that extra > > > address -> > > space. I think it ends up being a 512GB allocation in a 128TB +> > > space.A A I think it ends up being a 512GB allocation in a 128TB > > > address > > > space. > > > > > > Is that a problem? > > > > > > On 5-level paging systems, maybe we should just stick it up in -> > > the +> > > theA > > > high part of the address space. > > We do not know in advance if dlopen() needs to create the bitmap. -> > Do +> > A Do > > we always reserve high address or force legacy libs to low address? -> Does it matter? Does code ever get pointers to this area? Might +> Does it matter?A A Does code ever get pointers to this area?A A Might > they > be depending on high address bits for the IBT being clear? -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. > @@ -75,11 +75,11 @@ to low address, or not having the bitmap at all, i.e. turn IBT off. > > > > + return -ENOMEM; > > > > + > > > > + bitmap &= PAGE_MASK; -> > > We're page-aligning the result of an mmap()? Why? -> > This may not be necessary. The lower bits of MSR_IA32_U_CET are -> > settings and not part of the bitmap address. Is this is safer? -> No. If we have mmap() returning non-page-aligned addresses, we have -> bigger problems. Worst-case, do +> > > We're page-aligning the result of an mmap()?A A Why? +> > This may not be necessary. A The lower bits of MSR_IA32_U_CET are +> > settings and not part of the bitmap address. A Is this is safer? +> No.A A If we have mmap() returning non-page-aligned addresses, we have +> bigger problems.A A Worst-case, do > > WARN_ON_ONCE(bitmap & ~PAGE_MASK); > @@ -101,7 +101,7 @@ Ok. > > > > + if (!cpu_feature_enabled(X86_FEATURE_IBT)) > > > > + return; > > > Does this need a check for being already disabled? -> > We need that. We cannot write to those MSRs if the CPU does not +> > We need that. A We cannot write to those MSRs if the CPU does not > > support it. > No, I mean for code doing cet_disable_ibt() twice in a row. @@ -114,14 +114,14 @@ Got it. > > > > + rdmsrl(MSR_IA32_U_CET, r); > > > > + r &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN > > > > | -> > > > + MSR_IA32_CET_NO_TRACK_EN); +> > > > + A A A A A A A MSR_IA32_CET_NO_TRACK_EN); > > > > + wrmsrl(MSR_IA32_U_CET, r); > > > > + current->thread.cet.ibt_enabled = 0; > > > > +} > > > What's the locking for current->thread.cet? -> > Now CET is not locked until the application calls ARCH_CET_LOCK. +> > Now CET is not locked until the application callsA ARCH_CET_LOCK. > No, I mean what is the in-kernel locking for the current->thread.cet -> data structure? Is there none because it's only every modified via +> data structure?A A Is there none because it's only every modified via > current->thread and it's entirely thread-local? Yes, that is the case. diff --git a/a/content_digest b/N3/content_digest index 393799a..c28e3c1 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -28,7 +28,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 15:40 -0700, Dave Hansen wrote:\n" @@ -36,7 +39,7 @@ "> > \n" "> > On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:\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" @@ -44,11 +47,11 @@ "> > 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" @@ -56,7 +59,7 @@ "> that's\n" "> quite the format that Ingo and Thomas prefer.\n" "\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" "\n" @@ -77,24 +80,24 @@ "> > > Just a note: this table is going to be gigantic on 5-level paging\n" "> > > systems, and userspace won't, by default use any of that extra\n" "> > > address\n" - "> > > space.\302\240\302\240I think it ends up being a 512GB allocation in a 128TB\n" + "> > > space.A A I think it ends up being a 512GB allocation in a 128TB\n" "> > > address\n" "> > > space.\n" "> > > \n" "> > > Is that a problem?\n" "> > > \n" "> > > On 5-level paging systems, maybe we should just stick it up in\n" - "> > > the\302\240\n" + "> > > theA \n" "> > > high part of the address space.\n" "> > We do not know in advance if dlopen() needs to create the bitmap.\n" - "> > \302\240Do\n" + "> > A Do\n" "> > we always reserve high address or force legacy libs to low address?\n" - "> Does it matter?\302\240\302\240Does code ever get pointers to this area?\302\240\302\240Might\n" + "> Does it matter?A A Does code ever get pointers to this area?A A Might\n" "> they\n" "> be depending on high address bits for the IBT being clear?\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" "\n" "> \n" @@ -108,11 +111,11 @@ "> > > > +\t\treturn -ENOMEM;\n" "> > > > +\n" "> > > > +\tbitmap &= PAGE_MASK;\n" - "> > > We're page-aligning the result of an mmap()?\302\240\302\240Why?\n" - "> > This may not be necessary. \302\240The lower bits of MSR_IA32_U_CET are\n" - "> > settings and not part of the bitmap address. \302\240Is this is safer?\n" - "> No.\302\240\302\240If we have mmap() returning non-page-aligned addresses, we have\n" - "> bigger problems.\302\240\302\240Worst-case, do\n" + "> > > We're page-aligning the result of an mmap()?A A Why?\n" + "> > This may not be necessary. A The lower bits of MSR_IA32_U_CET are\n" + "> > settings and not part of the bitmap address. A Is this is safer?\n" + "> No.A A If we have mmap() returning non-page-aligned addresses, we have\n" + "> bigger problems.A A Worst-case, do\n" "> \n" "> \tWARN_ON_ONCE(bitmap & ~PAGE_MASK);\n" "> \n" @@ -134,7 +137,7 @@ "> > > > +\tif (!cpu_feature_enabled(X86_FEATURE_IBT))\n" "> > > > +\t\treturn;\n" "> > > Does this need a check for being already disabled?\n" - "> > We need that. \302\240We cannot write to those MSRs if the CPU does not\n" + "> > We need that. A We cannot write to those MSRs if the CPU does not\n" "> > support it.\n" "> No, I mean for code doing cet_disable_ibt() twice in a row.\n" "\n" @@ -147,16 +150,16 @@ "> > > > +\trdmsrl(MSR_IA32_U_CET, r);\n" "> > > > +\tr &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN\n" "> > > > |\n" - "> > > > +\t\302\240\302\240\302\240\302\240\302\240\302\240\302\240MSR_IA32_CET_NO_TRACK_EN);\n" + "> > > > +\tA A A A A A A MSR_IA32_CET_NO_TRACK_EN);\n" "> > > > +\twrmsrl(MSR_IA32_U_CET, r);\n" "> > > > +\tcurrent->thread.cet.ibt_enabled = 0;\n" "> > > > +}\n" "> > > What's the locking for current->thread.cet?\n" - "> > Now CET is not locked until the application calls\302\240ARCH_CET_LOCK.\n" + "> > Now CET is not locked until the application callsA ARCH_CET_LOCK.\n" "> No, I mean what is the in-kernel locking for the current->thread.cet\n" - "> data structure?\302\240\302\240Is there none because it's only every modified via\n" + "> data structure?A A Is there none because it's only every modified via\n" "> current->thread and it's entirely thread-local?\n" "\n" Yes, that is the case. -7afc97fca94ac63b4e9059bee539a81fca189e6794b5daf1291a374d074ef757 +1833f108d3d87b34a1c95f3ead4f533a996ce6247cdc11cb9807caa1911d4acb
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.