diff for duplicates of <1531347019.15351.89.camel@intel.com> diff --git a/a/content_digest b/N1/content_digest index c698cb4..2cb7c7e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -26,7 +26,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 Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:\n" @@ -285,4 +288,4 @@ "\n" I will fix it. -55085cfa4c5440c5d856dc3c97e6e64fc17d630838958d4674e186b99cf2dbff +79983082794c1da7dc4ba1a97cf65194a6b522967c64dff0de62e2aae15163f9
diff --git a/a/1.txt b/N2/1.txt index 6f808f4..d55df5d 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -253,3 +253,8 @@ Now CET is not locked until the application calls ARCH_CET_LOCK. > ? I will fix it. + +-- +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 c698cb4..3b1171b 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -26,7 +26,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 Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:\n" @@ -283,6 +286,11 @@ "> \n" "> ?\n" "\n" - I will fix it. + "I will fix it.\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 -55085cfa4c5440c5d856dc3c97e6e64fc17d630838958d4674e186b99cf2dbff +f96ff9fe53bc1a1c3a85b61793a36c1e54ba5cad91896306e96fdad2964f71f1
diff --git a/a/1.txt b/N3/1.txt index 6f808f4..83bc6ef 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -1,11 +1,11 @@ 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.? > > > @@ -15,15 +15,15 @@ changes. Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk, etc.? > > --- a/arch/x86/include/asm/cet.h > > +++ b/arch/x86/include/asm/cet.h > > @@ -12,7 +12,10 @@ struct task_struct; -> > struct cet_status { -> > unsigned long shstk_base; -> > unsigned long shstk_size; +> > A struct cet_status { +> > A unsigned long shstk_base; +> > A unsigned long shstk_size; > > + unsigned long ibt_bitmap_addr; > > + unsigned long ibt_bitmap_size; -> > unsigned int shstk_enabled:1; +> > A unsigned int shstk_enabled:1; > > + unsigned int ibt_enabled:1; -> > }; -> Is there a reason we're not using pointers here? This seems like the +> > A }; +> Is there a reason we're not using pointers here?A A This seems like the > kind of place that we probably want __user pointers. Yes, I will change that. @@ -39,8 +39,8 @@ Yes, I will change that. > > + > > + down_write(&mm->mmap_sem); > > + addr = do_mmap(NULL, addr, len, PROT_READ | PROT_WRITE, -> > + MAP_ANONYMOUS | MAP_PRIVATE, -> > + VM_DONTDUMP, 0, &populate, NULL); +> > + A A A A A A A MAP_ANONYMOUS | MAP_PRIVATE, +> > + A A A A A A A VM_DONTDUMP, 0, &populate, NULL); > > + up_write(&mm->mmap_sem); > > + > > + if (populate) @@ -48,28 +48,28 @@ Yes, I will change that. > > + > > + return addr; > > +} -> We're going to have to start consolidating these at some point. We +> We're going to have to start consolidating these at some point.A A We > have > at least three of them now, maybe more. Maybe we can do the following in linux/mm.h? +static inline unsigned long do_mmap_locked(addr, len, prot, -+ flags, vm_flags) ++ A A flags, vm_flags) +{ + struct mm_struct *mm = current->mm; + unsigned long populate; + + down_write(&mm->mmap_sem); + addr = do_mmap(NULL, addr, len, prot, flags, vm_flags, -+ 0, &populate, NULL); ++ A A A A 0, &populate, NULL); + up_write(&mm->mmap_sem); + + if (populate) + mm_populate(addr, populate); + + return addr; -+} ++}A > > > > +int cet_setup_ibt_bitmap(void) @@ -85,7 +85,7 @@ Maybe we can do the following in linux/mm.h? > 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. > @@ -95,7 +95,7 @@ Maybe we can do the following in linux/mm.h? > 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? > @@ -106,18 +106,18 @@ we always reserve high address or force legacy libs to low address? > > + 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? > > > > > + rdmsrl(MSR_IA32_U_CET, r); > > + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap); > > + wrmsrl(MSR_IA32_U_CET, r); -> Comments, please. What is this doing, logically? Also, why are we -> OR'ing the results into this MSR? What are we trying to preserve? +> Comments, please.A A What is this doing, logically?A A Also, why are we +> OR'ing the results into this MSR?A A What are we trying to preserve? I will add comments. @@ -136,20 +136,20 @@ I will add comments. > > + 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. > > > > > + 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. > > > @@ -159,19 +159,19 @@ Now CET is not locked until the application calls ARCH_CET_LOCK. > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -413,7 +413,8 @@ __setup("nopku", setup_disable_pku); -> > -> > static __always_inline void setup_cet(struct cpuinfo_x86 *c) -> > { +> > A +> > A static __always_inline void setup_cet(struct cpuinfo_x86 *c) +> > A { > > - if (cpu_feature_enabled(X86_FEATURE_SHSTK)) > > + if (cpu_feature_enabled(X86_FEATURE_SHSTK) || -> > + cpu_feature_enabled(X86_FEATURE_IBT)) -> > cr4_set_bits(X86_CR4_CET); -> > } -> > +> > + A A A A cpu_feature_enabled(X86_FEATURE_IBT)) +> > A cr4_set_bits(X86_CR4_CET); +> > A } +> > A > > @@ -434,6 +435,23 @@ static __init int setup_disable_shstk(char *s) -> > __setup("no_cet_shstk", setup_disable_shstk); -> > #endif -> > +> > A __setup("no_cet_shstk", setup_disable_shstk); +> > A #endif +> > A > > +#ifdef CONFIG_X86_INTEL_BRANCH_TRACKING_USER > > +static __init int setup_disable_ibt(char *s) > > +{ @@ -189,50 +189,50 @@ Now CET is not locked until the application calls ARCH_CET_LOCK. > > +} > > +__setup("no_cet_ibt", setup_disable_ibt); > > +#endif -> > /* -> > * Some CPU features depend on higher CPUID levels, which may not +> > A /* +> > A * Some CPU features depend on higher CPUID levels, which may not > > always -> > * be available due to CPUID level capping or broken +> > A * be available due to CPUID level capping or broken > > virtualization > > diff --git a/arch/x86/kernel/elf.c b/arch/x86/kernel/elf.c > > index 233f6dad9c1f..42e08d3b573e 100644 > > --- a/arch/x86/kernel/elf.c > > +++ b/arch/x86/kernel/elf.c > > @@ -15,6 +15,7 @@ -> > #include <linux/fs.h> -> > #include <linux/uaccess.h> -> > #include <linux/string.h> +> > A #include <linux/fs.h> +> > A #include <linux/uaccess.h> +> > A #include <linux/string.h> > > +#include <linux/compat.h> -> > -> > /* -> > * The .note.gnu.property layout: +> > A +> > A /* +> > A * The .note.gnu.property layout: > > @@ -222,7 +223,8 @@ int arch_setup_features(void *ehdr_p, void > > *phdr_p, -> > -> > struct elf64_hdr *ehdr64 = ehdr_p; -> > +> > A +> > A struct elf64_hdr *ehdr64 = ehdr_p; +> > A > > - if (!cpu_feature_enabled(X86_FEATURE_SHSTK)) > > + if (!cpu_feature_enabled(X86_FEATURE_SHSTK) && -> > + !cpu_feature_enabled(X86_FEATURE_IBT)) -> > return 0; -> > -> > if (ehdr64->e_ident[EI_CLASS] == ELFCLASS64) { +> > + A A A A !cpu_feature_enabled(X86_FEATURE_IBT)) +> > A return 0; +> > A +> > A if (ehdr64->e_ident[EI_CLASS] == ELFCLASS64) { > > @@ -250,6 +252,9 @@ int arch_setup_features(void *ehdr_p, void > > *phdr_p, -> > current->thread.cet.shstk_enabled = 0; -> > current->thread.cet.shstk_base = 0; -> > current->thread.cet.shstk_size = 0; +> > A current->thread.cet.shstk_enabled = 0; +> > A current->thread.cet.shstk_base = 0; +> > A current->thread.cet.shstk_size = 0; > > + current->thread.cet.ibt_enabled = 0; > > + current->thread.cet.ibt_bitmap_addr = 0; > > + current->thread.cet.ibt_bitmap_size = 0; -> > if (cpu_feature_enabled(X86_FEATURE_SHSTK)) { -> > if (shstk) { -> > err = cet_setup_shstk(); +> > A if (cpu_feature_enabled(X86_FEATURE_SHSTK)) { +> > A if (shstk) { +> > A err = cet_setup_shstk(); > > @@ -257,6 +262,15 @@ int arch_setup_features(void *ehdr_p, void > > *phdr_p, -> > goto out; -> > } -> > } +> > A goto out; +> > A } +> > A } > > + > > + if (cpu_feature_enabled(X86_FEATURE_IBT)) { > > + if (ibt) { @@ -241,7 +241,7 @@ Now CET is not locked until the application calls ARCH_CET_LOCK. > > + goto out; > > + } > > + } -> You introduced 'ibt' before it was used. Please wait to introduce it +> You introduced 'ibt' before it was used.A A Please wait to introduce it > until you actually use it to make it easier to review. > > Also, what's wrong with: diff --git a/a/content_digest b/N3/content_digest index c698cb4..08157d5 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -26,17 +26,20 @@ 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 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" "> \n" "> > \n" @@ -46,15 +49,15 @@ "> > --- a/arch/x86/include/asm/cet.h\n" "> > +++ b/arch/x86/include/asm/cet.h\n" "> > @@ -12,7 +12,10 @@ struct task_struct;\n" - "> > \302\240struct cet_status {\n" - "> > \302\240\tunsigned long\tshstk_base;\n" - "> > \302\240\tunsigned long\tshstk_size;\n" + "> > A struct cet_status {\n" + "> > A \tunsigned long\tshstk_base;\n" + "> > A \tunsigned long\tshstk_size;\n" "> > +\tunsigned long\tibt_bitmap_addr;\n" "> > +\tunsigned long\tibt_bitmap_size;\n" - "> > \302\240\tunsigned int\tshstk_enabled:1;\n" + "> > A \tunsigned int\tshstk_enabled:1;\n" "> > +\tunsigned int\tibt_enabled:1;\n" - "> > \302\240};\n" - "> Is there a reason we're not using pointers here?\302\240\302\240This seems like the\n" + "> > A };\n" + "> Is there a reason we're not using pointers here?A A This seems like the\n" "> kind of place that we probably want __user pointers.\n" "\n" "Yes, I will change that.\n" @@ -70,8 +73,8 @@ "> > +\n" "> > +\tdown_write(&mm->mmap_sem);\n" "> > +\taddr = do_mmap(NULL, addr, len, PROT_READ | PROT_WRITE,\n" - "> > +\t\t\302\240\302\240\302\240\302\240\302\240\302\240\302\240MAP_ANONYMOUS | MAP_PRIVATE,\n" - "> > +\t\t\302\240\302\240\302\240\302\240\302\240\302\240\302\240VM_DONTDUMP, 0, &populate, NULL);\n" + "> > +\t\tA A A A A A A MAP_ANONYMOUS | MAP_PRIVATE,\n" + "> > +\t\tA A A A A A A VM_DONTDUMP, 0, &populate, NULL);\n" "> > +\tup_write(&mm->mmap_sem);\n" "> > +\n" "> > +\tif (populate)\n" @@ -79,28 +82,28 @@ "> > +\n" "> > +\treturn addr;\n" "> > +}\n" - "> We're going to have to start consolidating these at some point.\302\240\302\240We\n" + "> We're going to have to start consolidating these at some point.A A We\n" "> have\n" "> at least three of them now, maybe more.\n" "\n" "Maybe we can do the following in linux/mm.h?\n" "\n" "+static inline unsigned long do_mmap_locked(addr, len, prot,\n" - "+\t\t\t\t\t\302\240 \302\240 flags, vm_flags)\n" + "+\t\t\t\t\tA A flags, vm_flags)\n" "+{\n" "+\tstruct mm_struct *mm = current->mm;\n" "+\tunsigned long populate;\n" "+\n" "+\tdown_write(&mm->mmap_sem);\n" "+\taddr = do_mmap(NULL, addr, len, prot, flags, vm_flags,\n" - "+\t\t\302\240 \302\240 \302\240 \302\2400, &populate, NULL);\n" + "+\t\tA A A A 0, &populate, NULL);\n" "+\tup_write(&mm->mmap_sem);\n" "+\n" "+\tif (populate)\n" "+\t\tmm_populate(addr, populate);\n" "+\n" "+\treturn addr;\n" - "+}\302\240\n" + "+}A \n" "\n" "> > \n" "> > +int cet_setup_ibt_bitmap(void)\n" @@ -116,7 +119,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" @@ -126,7 +129,7 @@ "> high\n" "> 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" "> \n" @@ -137,18 +140,18 @@ "> > +\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" "> \n" "> > \n" "> > +\trdmsrl(MSR_IA32_U_CET, r);\n" "> > +\tr |= (MSR_IA32_CET_LEG_IW_EN | bitmap);\n" "> > +\twrmsrl(MSR_IA32_U_CET, r);\n" - "> Comments, please.\302\240\302\240What is this doing, logically?\302\240\302\240Also, why are we\n" - "> OR'ing the results into this MSR?\302\240\302\240What are we trying to preserve?\n" + "> Comments, please.A A What is this doing, logically?A A Also, why are we\n" + "> OR'ing the results into this MSR?A A What are we trying to preserve?\n" "\n" "I will add comments.\n" "\n" @@ -167,20 +170,20 @@ "> > +\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" "> \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" "> \n" "> > \n" @@ -190,19 +193,19 @@ "> > --- a/arch/x86/kernel/cpu/common.c\n" "> > +++ b/arch/x86/kernel/cpu/common.c\n" "> > @@ -413,7 +413,8 @@ __setup(\"nopku\", setup_disable_pku);\n" - "> > \302\240\n" - "> > \302\240static __always_inline void setup_cet(struct cpuinfo_x86 *c)\n" - "> > \302\240{\n" + "> > A \n" + "> > A static __always_inline void setup_cet(struct cpuinfo_x86 *c)\n" + "> > A {\n" "> > -\tif (cpu_feature_enabled(X86_FEATURE_SHSTK))\n" "> > +\tif (cpu_feature_enabled(X86_FEATURE_SHSTK) ||\n" - "> > +\t\302\240\302\240\302\240\302\240cpu_feature_enabled(X86_FEATURE_IBT))\n" - "> > \302\240\t\tcr4_set_bits(X86_CR4_CET);\n" - "> > \302\240}\n" - "> > \302\240\n" + "> > +\tA A A A cpu_feature_enabled(X86_FEATURE_IBT))\n" + "> > A \t\tcr4_set_bits(X86_CR4_CET);\n" + "> > A }\n" + "> > A \n" "> > @@ -434,6 +435,23 @@ static __init int setup_disable_shstk(char *s)\n" - "> > \302\240__setup(\"no_cet_shstk\", setup_disable_shstk);\n" - "> > \302\240#endif\n" - "> > \302\240\n" + "> > A __setup(\"no_cet_shstk\", setup_disable_shstk);\n" + "> > A #endif\n" + "> > A \n" "> > +#ifdef CONFIG_X86_INTEL_BRANCH_TRACKING_USER\n" "> > +static __init int setup_disable_ibt(char *s)\n" "> > +{\n" @@ -220,50 +223,50 @@ "> > +}\n" "> > +__setup(\"no_cet_ibt\", setup_disable_ibt);\n" "> > +#endif\n" - "> > \302\240/*\n" - "> > \302\240 * Some CPU features depend on higher CPUID levels, which may not\n" + "> > A /*\n" + "> > A * Some CPU features depend on higher CPUID levels, which may not\n" "> > always\n" - "> > \302\240 * be available due to CPUID level capping or broken\n" + "> > A * be available due to CPUID level capping or broken\n" "> > virtualization\n" "> > diff --git a/arch/x86/kernel/elf.c b/arch/x86/kernel/elf.c\n" "> > index 233f6dad9c1f..42e08d3b573e 100644\n" "> > --- a/arch/x86/kernel/elf.c\n" "> > +++ b/arch/x86/kernel/elf.c\n" "> > @@ -15,6 +15,7 @@\n" - "> > \302\240#include <linux/fs.h>\n" - "> > \302\240#include <linux/uaccess.h>\n" - "> > \302\240#include <linux/string.h>\n" + "> > A #include <linux/fs.h>\n" + "> > A #include <linux/uaccess.h>\n" + "> > A #include <linux/string.h>\n" "> > +#include <linux/compat.h>\n" - "> > \302\240\n" - "> > \302\240/*\n" - "> > \302\240 * The .note.gnu.property layout:\n" + "> > A \n" + "> > A /*\n" + "> > A * The .note.gnu.property layout:\n" "> > @@ -222,7 +223,8 @@ int arch_setup_features(void *ehdr_p, void\n" "> > *phdr_p,\n" - "> > \302\240\n" - "> > \302\240\tstruct elf64_hdr *ehdr64 = ehdr_p;\n" - "> > \302\240\n" + "> > A \n" + "> > A \tstruct elf64_hdr *ehdr64 = ehdr_p;\n" + "> > A \n" "> > -\tif (!cpu_feature_enabled(X86_FEATURE_SHSTK))\n" "> > +\tif (!cpu_feature_enabled(X86_FEATURE_SHSTK) &&\n" - "> > +\t\302\240\302\240\302\240\302\240!cpu_feature_enabled(X86_FEATURE_IBT))\n" - "> > \302\240\t\treturn 0;\n" - "> > \302\240\n" - "> > \302\240\tif (ehdr64->e_ident[EI_CLASS] == ELFCLASS64) {\n" + "> > +\tA A A A !cpu_feature_enabled(X86_FEATURE_IBT))\n" + "> > A \t\treturn 0;\n" + "> > A \n" + "> > A \tif (ehdr64->e_ident[EI_CLASS] == ELFCLASS64) {\n" "> > @@ -250,6 +252,9 @@ int arch_setup_features(void *ehdr_p, void\n" "> > *phdr_p,\n" - "> > \302\240\tcurrent->thread.cet.shstk_enabled = 0;\n" - "> > \302\240\tcurrent->thread.cet.shstk_base = 0;\n" - "> > \302\240\tcurrent->thread.cet.shstk_size = 0;\n" + "> > A \tcurrent->thread.cet.shstk_enabled = 0;\n" + "> > A \tcurrent->thread.cet.shstk_base = 0;\n" + "> > A \tcurrent->thread.cet.shstk_size = 0;\n" "> > +\tcurrent->thread.cet.ibt_enabled = 0;\n" "> > +\tcurrent->thread.cet.ibt_bitmap_addr = 0;\n" "> > +\tcurrent->thread.cet.ibt_bitmap_size = 0;\n" - "> > \302\240\tif (cpu_feature_enabled(X86_FEATURE_SHSTK)) {\n" - "> > \302\240\t\tif (shstk) {\n" - "> > \302\240\t\t\terr = cet_setup_shstk();\n" + "> > A \tif (cpu_feature_enabled(X86_FEATURE_SHSTK)) {\n" + "> > A \t\tif (shstk) {\n" + "> > A \t\t\terr = cet_setup_shstk();\n" "> > @@ -257,6 +262,15 @@ int arch_setup_features(void *ehdr_p, void\n" "> > *phdr_p,\n" - "> > \302\240\t\t\t\tgoto out;\n" - "> > \302\240\t\t}\n" - "> > \302\240\t}\n" + "> > A \t\t\t\tgoto out;\n" + "> > A \t\t}\n" + "> > A \t}\n" "> > +\n" "> > +\tif (cpu_feature_enabled(X86_FEATURE_IBT)) {\n" "> > +\t\tif (ibt) {\n" @@ -272,7 +275,7 @@ "> > +\t\t\t\tgoto out;\n" "> > +\t\t}\n" "> > +\t}\n" - "> You introduced 'ibt' before it was used.\302\240\302\240Please wait to introduce it\n" + "> You introduced 'ibt' before it was used.A A Please wait to introduce it\n" "> until you actually use it to make it easier to review.\n" "> \n" "> Also, what's wrong with:\n" @@ -285,4 +288,4 @@ "\n" I will fix it. -55085cfa4c5440c5d856dc3c97e6e64fc17d630838958d4674e186b99cf2dbff +53e8f821bccc8c001bddda8356e02b054d4337c589b19d647137af3550fc9e2d
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.