diff for duplicates of <f97ce234-52fa-e666-2250-098925cf3c39@linux.intel.com> diff --git a/a/content_digest b/N1/content_digest index 8ddb87f..9328eb5 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -28,7 +28,9 @@ Nadav Amit <nadav.amit@gmail.com> Oleg Nesterov <oleg@redhat.com> Pavel Machek <pavel@ucw.cz> - " Peter Zijlstra <pet>\0" + 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 07/11/2018 03:10 PM, Yu-cheng Yu wrote:\n" @@ -127,4 +129,4 @@ "data structure? Is there none because it's only every modified via\n" current->thread and it's entirely thread-local? -2f4ab9c2a2f0d6f12a5a45249f3532e1a4dc545b8f66a2e296e2f1528ce44036 +812fbc8cb768dc3a68d0662b5046bd1f472872f428ae00e263b7c94cfb44c5cc
diff --git a/a/1.txt b/N2/1.txt index c29646c..3b86c3e 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -93,3 +93,9 @@ No, I mean for code doing cet_disable_ibt() twice in a row. 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 current->thread and it's entirely thread-local? + + +-- +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 8ddb87f..00d667c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -28,7 +28,9 @@ Nadav Amit <nadav.amit@gmail.com> Oleg Nesterov <oleg@redhat.com> Pavel Machek <pavel@ucw.cz> - " Peter Zijlstra <pet>\0" + 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 07/11/2018 03:10 PM, Yu-cheng Yu wrote:\n" @@ -125,6 +127,12 @@ "\n" "No, I mean what is the in-kernel locking for the current->thread.cet\n" "data structure? Is there none because it's only every modified via\n" - current->thread and it's entirely thread-local? + "current->thread and it's entirely thread-local?\n" + "\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 -2f4ab9c2a2f0d6f12a5a45249f3532e1a4dc545b8f66a2e296e2f1528ce44036 +7da4737cfb43f06b8c549e2ae4e28a5ff1db3e22cbb22cda577c7f8f4f7a48aa
diff --git a/a/1.txt b/N3/1.txt index c29646c..07af4e4 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -1,12 +1,12 @@ On 07/11/2018 03:10 PM, Yu-cheng Yu wrote: > On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote: ->> Is this feature *integral* to shadow stacks? Or, should it just be +>> Is this feature *integral* to shadow stacks?A A Or, should it just be >> in a >> different series? > > The whole CET series is mostly about SHSTK and only a minority for 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, etc.? +> changes. A Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk, etc.? That doesn't really answer what I asked, though. @@ -30,7 +30,7 @@ quite the format that Ingo and Thomas prefer. >> 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. >> @@ -39,7 +39,7 @@ quite the format that Ingo and Thomas prefer. >> On 5-level paging systems, maybe we should just stick it up in the >> high part of the address space. > -> We do not know in advance if dlopen() needs to create the bitmap. Do +> We do not know in advance if dlopen() needs to create the bitmap. 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 they @@ -52,10 +52,10 @@ be depending on high address bits for the IBT being clear? >>> + return -ENOMEM; >>> + >>> + bitmap &= PAGE_MASK; ->> We're page-aligning the result of an mmap()? Why? +>> We're page-aligning the result of an mmap()?A A 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? +> 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. If we have mmap() returning non-page-aligned addresses, we have bigger problems. Worst-case, do @@ -75,20 +75,20 @@ bigger problems. Worst-case, do >>> + 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. >>> + 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 diff --git a/a/content_digest b/N3/content_digest index 8ddb87f..d277257 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -28,18 +28,20 @@ Nadav Amit <nadav.amit@gmail.com> Oleg Nesterov <oleg@redhat.com> Pavel Machek <pavel@ucw.cz> - " Peter Zijlstra <pet>\0" + 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 07/11/2018 03:10 PM, Yu-cheng Yu wrote:\n" "> On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:\n" - ">> Is this feature *integral* to shadow stacks?\302\240\302\240Or, should it just be\n" + ">> Is this feature *integral* to shadow stacks?A A Or, should it just be\n" ">> in a\n" ">> different series?\n" "> \n" "> The whole CET series is mostly about SHSTK and only a minority for IBT.\n" "> IBT changes cannot be applied by itself without first applying SHSTK\n" - "> changes. \302\240Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk, etc.?\n" + "> changes. A Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk, etc.?\n" "\n" "That doesn't really answer what I asked, though.\n" "\n" @@ -63,7 +65,7 @@ ">> 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" @@ -72,7 +74,7 @@ ">> On 5-level paging systems, maybe we should just stick it up in the \n" ">> high part of the address space.\n" "> \n" - "> We do not know in advance if dlopen() needs to create the bitmap. \302\240Do\n" + "> We do not know in advance if dlopen() needs to create the bitmap. A Do\n" "> we always reserve high address or force legacy libs to low address?\n" "\n" "Does it matter? Does code ever get pointers to this area? Might they\n" @@ -85,10 +87,10 @@ ">>> +\t\treturn -ENOMEM;\n" ">>> +\n" ">>> +\tbitmap &= PAGE_MASK;\n" - ">> We're page-aligning the result of an mmap()?\302\240\302\240Why?\n" + ">> We're page-aligning the result of an mmap()?A A Why?\n" "> \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" + "> 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" "\n" "No. If we have mmap() returning non-page-aligned addresses, we have\n" "bigger problems. Worst-case, do\n" @@ -108,23 +110,23 @@ ">>> +\t\treturn;\n" ">> Does this need a check for being already disabled?\n" "> \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" "\n" "No, I mean for code doing cet_disable_ibt() twice in a row.\n" "\n" ">>> +\trdmsrl(MSR_IA32_U_CET, r);\n" ">>> +\tr &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN |\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" "> \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" "\n" "No, I mean what is the in-kernel locking for the current->thread.cet\n" "data structure? Is there none because it's only every modified via\n" current->thread and it's entirely thread-local? -2f4ab9c2a2f0d6f12a5a45249f3532e1a4dc545b8f66a2e296e2f1528ce44036 +df1ab89b9c2f98c1d31217727b276520570d9bb7f9124e5d85da47260260d020
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.