Hi,
From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 6 Feb 2023 10:39:45 +0100
> On Mon, Feb 06, 2023 at 05:22:54PM +0800, Xinghui Li wrote:
> > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 于2023年2月6日周一 13:40写道：
> >
> > > If you rely on the 5.4.y kernel tree, and you need this speculation
> > > fixes and feel this is a real problem, please provide some backported
> > > patches to resolve the problem.
> > >
> > > It's been reported many times in the past, but no one seems to actually
> > > want to fix this bad enough to send in a patch :(
> > >
> > > Usually people just move to a newer kernel, what is preventing you from
> > > doing that right now?
> > >
> > > thanks,
> > >
> > > greg k-h
> > Thanks for your reply~ I am sorry about reporting the known Issue.
> > I am trying to fix this issue right now. And I met the CFA issue, so I
> > just want to discuss it with the community.
>
> Is this an actual real problem that you can detect with testing? Or is
> it just a warning message in the build?
I've just received a related report from a customer and I found the
same commit was the first bad one while investigating. I've attached
a simple repro below.
After 8afd1c7da2b0 ("x86/speculation: Change FILL_RETURN_BUFFER to
work with objtool"), calling stack_trace_save_tsk_reliable() from
the kernel module below fails with -EINVAL if CONFIG_UNWINDER_ORC=y
and CONFIG_RETPOLINE=y.
I confirmed that this issue does not happen on 5.10 and 5.15 at
least (and told the customer to use either).
Interestingly, after the commit, stack_trace_save_tsk_reliable()
fails but seems to fill the buffer with the correct stack trace.
---8<---
#include <linux/module.h>
#include <linux/kallsyms.h>
typedef int (*func_t)(struct task_struct *tsk,
unsigned long *store, unsigned int size);
static __init int buggy_orc_init(void)
{
unsigned long store[32] = {0};
func_t func;
int ret, i;
func = (func_t)kallsyms_lookup_name("stack_trace_save_tsk_reliable");
if (!func)
return -ENOENT;
ret = func(current, store, ARRAY_SIZE(store));
for (i = 0; i < ARRAY_SIZE(store); i++)
printk(KERN_ERR "%px: %pS\n", (void *)store[i], (void *)store[i]);
return ret > 0 ? 0 : ret;
}
module_init(buggy_orc_init);
MODULE_LICENSE("GPL");
---8<---
---8<---
# insmod buggy_orc.ko
[ 8.576683] buggy_orc: loading out-of-tree module taints kernel.
[ 8.578414] ffffffff810d1538: stack_trace_save_tsk_reliable+0x78/0xc0
[ 8.578414] ffffffffc000405c: buggy_orc_init+0x5c/0x1000 [buggy_orc]
[ 8.579066] ffffffff81000b56: do_one_initcall+0x46/0x1f0
[ 8.579066] ffffffff810f005c: do_init_module+0x4c/0x240
[ 8.579066] ffffffff810f2cbf: __do_sys_finit_module+0xbf/0xe0
[ 8.580379] ffffffff81002198: do_syscall_64+0x48/0x110
[ 8.580379] ffffffff81c00094: entry_SYSCALL_64_after_hwframe+0x5c/0xc1
[ 8.581328] 0000000000000000: 0x0
[ 8.581328] 0000000000000000: 0x0
[ 8.581328] 0000000000000000: 0x0
[ 8.582145] 0000000000000000: 0x0
[ 8.582145] 0000000000000000: 0x0
[ 8.582145] 0000000000000000: 0x0
[ 8.582145] 0000000000000000: 0x0
[ 8.583229] 0000000000000000: 0x0
[ 8.583229] 0000000000000000: 0x0
[ 8.583229] 0000000000000000: 0x0
[ 8.584046] 0000000000000000: 0x0
[ 8.584046] 0000000000000000: 0x0
[ 8.584046] 0000000000000000: 0x0
[ 8.584046] 0000000000000000: 0x0
[ 8.585130] 0000000000000000: 0x0
[ 8.585130] 0000000000000000: 0x0
[ 8.585130] 0000000000000000: 0x0
[ 8.585130] 0000000000000000: 0x0
[ 8.586221] 0000000000000000: 0x0
[ 8.586221] 0000000000000000: 0x0
[ 8.586221] 0000000000000000: 0x0
[ 8.587038] 0000000000000000: 0x0
[ 8.587038] 0000000000000000: 0x0
[ 8.587038] 0000000000000000: 0x0
[ 8.587038] 0000000000000000: 0x0
insmod: ERROR: could not insert module buggy_orc.ko: Invalid parameters
---8<---
Thank you,
Kuniyuki
>
> > We keep staying in v5.4 because we developed the product base on v5.4
> > 3 years ago.
> > So it is unstable and difficult to update the kernel version.
>
> That is very odd, why is it hard to update to a new kernel? What
> happens if 5.4 stops being maintained tomorrow, what are your plans to
> move to a more modern kernel? Being stuck with an old kernel version
> with no plans to move does not seem like a wise business decision:(
>
> > I will try to find out a way to fix this issue.
>
> Great, and we will be glad to review patches.
>
> thanks,
>
> greg k-h
