[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YZz49M/QLmMJgJA7@hirez.programming.kicks-ass.net>
Date: Tue, 23 Nov 2021 15:21:40 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Mark Rutland <mark.rutland@....com>
Cc: x86@...nel.org, joao@...rdrivepizza.com, hjl.tools@...il.com,
jpoimboe@...hat.com, andrew.cooper3@...rix.com,
linux-kernel@...r.kernel.org, ndesaulniers@...gle.com,
keescook@...omium.org, samitolvanen@...gle.com, broonie@...nel.org
Subject: Re: [RFC][PATCH 5/6] x86: Sprinkle ENDBR dust
On Tue, Nov 23, 2021 at 02:00:53PM +0000, Mark Rutland wrote:
> On Mon, Nov 22, 2021 at 06:03:06PM +0100, Peter Zijlstra wrote:
> > Kernel entry points should be having ENDBR on for IBT configs.
> >
> > The SYSCALL entry points are found through taking their respective
> > address in order to program them in the MSRs, while the exception
> > entry points are found through UNWIND_HINT_IRET_REGS.
> >
> > *Except* that latter hint is also used on exit code to denote when
> > we're down to an IRET frame. As such add an additional 'entry'
> > argument to the macro and have it default to '1' such that objtool
> > will assume it's an entry and WARN about it.
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>
> On arm64 we also added BTI (analagous to ENDBR) in our SYMC_FUNC_START()
> so what we don't miss a necessary landing pad for any assembly functions
> that can be indirectly branched to.
>
> See commits:
>
> 714a8d02ca4da147 ("arm64: asm: Override SYM_FUNC_START when building the kernel with BTI")
> 2d21889f8b5c50f6 ("arm64: Don't insert a BTI instruction at inner labels")
>
> ... do you need something similar? Or do you never indirectly branch to
> an assembly function?
With the big caveat that I've only looked at x86_64-defconfig so far, we
don't seem to be doing that.
We also have the big benefit of having a larger immediate doesn't give
us those 'spurious' indirect branches you suffer from.
Hence also that --ibt-seal option that removes as many ENDBR
instructions as possible. Minimizing ENDBR is a feasible option for us,
where I don't think it is on ARM64.
Powered by blists - more mailing lists