Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation

Steven Rostedt
2022-07-20T18:31:55Z

On Wed, 20 Jul 2022 11:07:26 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, Jul 20, 2022 at 10:50 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > [ 2.464117] missing return thunk: lkdtm_rodata_do_nothing+0x0/0x8-lkdtm_rodata_do_nothing+0x5/0x8: e9 00 00 00 00
>
> Well, that looks like a "jmp" instruction that has never been relocated.
>
> The 'e9' is 'jmp', the four zeros after it are either "I'm jumping to
> the next instruction" or "I haven't been filled in".
>
> I'm assuming it's the second case.
>
> That lkdtm_rodata_do_nothing thing is odd, and does
>
> OBJCOPYFLAGS_rodata_objcopy.o := \
> --rename-section
> .noinstr.text=.rodata,alloc,readonly,load,contents
>
> to put the code in an odd section. I'm assuming this hackery is
> related to it then not getting relocated.
>

Right, because this looks to be some magic being done for testing purposes:

static void lkdtm_EXEC_RODATA(void)
{
execute_location(dereference_function_descriptor(lkdtm_rodata_do_nothing),
CODE_AS_IS);
}

static void *setup_function_descriptor(func_desc_t *fdesc, void *dst)
{
if (!have_function_descriptors())
return dst;

memcpy(fdesc, do_nothing, sizeof(*fdesc));
fdesc->addr = (unsigned long)dst;
barrier();

return fdesc;
}

static noinline void execute_location(void *dst, bool write)
{
void (*func)(void);
func_desc_t fdesc;
void *do_nothing_text = dereference_function_descriptor(do_nothing);

pr_info("attempting ok execution at %px\n", do_nothing_text);
do_nothing();

if (write == CODE_WRITE) {
memcpy(dst, do_nothing_text, EXEC_SIZE);
flush_icache_range((unsigned long)dst,
(unsigned long)dst + EXEC_SIZE);
}
pr_info("attempting bad execution at %px\n", dst);
func = setup_function_descriptor(&fdesc, dst);
func();
pr_err("FAIL: func returned\n");
}

And that appears that it wants to crash, as the code is located in readonly
data.

OBJCOPYFLAGS_rodata_objcopy.o := \
--rename-section .noinstr.text=.rodata,alloc,readonly,load,contents

And because the alternatives fixup tries to write to it, and fails due to
it being readonly, I'm guessing we get this warning.

Thus, is there a way to keep this file from being entered into the
return_sites section?

-- Steve