Messages in this thread | | | From | Linus Walleij <> | Date | Mon, 22 Mar 2021 12:45:45 +0100 | Subject | Re: [PATCH v5] ARM: Implement SLS mitigation |
| |
On Wed, Mar 10, 2021 at 5:43 AM Jian Cai <jiancai@google.com> wrote: > On Sat, Mar 6, 2021 at 4:25 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Fri, Mar 5, 2021 at 12:23 AM Jian Cai <jiancai@google.com> wrote: > > > On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > I think gcc also has these options. > > > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html > > > > And how does that work with this part of your patch: > > > > +#define SLS_TEXT \ > > + ALIGN_FUNCTION(); \ > > + *(.text.__llvm_slsblr_thunk_*) > > > > This does not look compiler agnostic? > > You are right, GCC does generate different oraphan section names. I > will address it in the next version of the patch. Also it seems only > arm64 gcc supports -mharden-sls=* at this moment, arm32 gcc does not > support it yet. I don't know if there is any plan to implement it for > 32-bit gcc, but should we patch arm32 linker script preemptively, > assuming the sections will be named with the same pattern like how > clang does so the kernel would not fail to boot when the flag is > implemented?
I think the best thing is to have something like this: Implement a macro such as this in include/linux/compiler-clang.h
#define SLS_TEXT_SECTION *(.text.__llvm_slsblr_thunk_*)
then the corresponding in include/linux/compiler-gcc.h but here also add a
#define SLS_TEXT_SECTION #error "no compiler support"
if the compiler version does not have this.
I don't know the exact best approach sadly, as the patch looks now it seems a bit fragile, I wonder if you get linker warnings when this section is unused?
Yours, Linus Walleij
| |