[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi5z9S7x94SKYNj6qSHBqz+OD76GW=MDzo-KN2Fzm-V4Q@mail.gmail.com>
Date: Sun, 7 Feb 2021 10:15:49 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Borislav Petkov <bp@...e.de>
Cc: Dave Hansen <dave.hansen@...el.com>,
Steven Rostedt <rostedt@...dmis.org>, x86-ml <x86@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Alexei Starovoitov <ast@...nel.org>
Subject: Re: [GIT PULL] x86/urgent for v5.11-rc7
On Sun, Feb 7, 2021 at 9:58 AM Borislav Petkov <bp@...e.de> wrote:
>
> It probably is an item on some Intel manager's to-enable list. So far,
> the CET enablement concentrates only on userspace but dhansen might know
> more about future plans. CCed.
I think the new Ryzen 5000 series also supports CET, but I don't have
any machines to check.
Hopefully somebody ends up with hardware that supports it and a urge
to try to make it work in kernel land too.
I do suspect involved people should start thinking about how they want
to deal with functions starting with
endbr64
call __fentry__
instead of the call being at the very top of the function.
I _assume_ it's mostly tracing, bpf and objtool that are going to
notice, and it's going to be largely invisible to anybody else.
So hopefully the involved people can at least just try to see how
their code looks when they turn off retpoline and add
-fcf-protection=full
to the compiler command line (assuming they have a gcc that can do
it), even if they can't actually test the end result on hardware.
Linus
Powered by blists - more mailing lists