Re: [PATCH v7 8/8] [DO NOT MERGE] x86/kexec: Add CFI type information to relocate_kernel()

[Josh Poimboeuf]

On Wed, Mar 19, 2025 at 01:04:20PM +0000, David Woodhouse wrote:
> On 18 March 2025 22:41:43 GMT, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> >On Tue, Mar 18, 2025 at 09:06:58PM +0000, David Woodhouse wrote:
> >> On Tue, 2025-03-18 at 10:14 -0700, Josh Poimboeuf wrote:
> >> > On Tue, Mar 18, 2025 at 03:56:36PM +0000, David Woodhouse wrote:
> >> > > For the relocate_kernel() case I don't think we care much about the
> >> > > first. Without a CFI prologue, no *other* code can be tricked into
> >> > > calling relocate_kernel()
> >> > 
> >> > But for FineIBT the hash is checked on the callee side.  So it loses
> >> > FineIBT protection.
> >> 
> >> Right now the relocate_kernel() code doesn't even have an endbr, does
> >> it? So it isn't a useful gadget?
> >
> >In that case wouldn't IBT explode when you indirect call it?  Or is IBT
> >getting disabled beforehand?
> 
> Not sure of the details. The machine_kexec() function which is the
> *caller* is currently marked with the __nocfi tag which stops any
> software checks. I guess any hardware feature which requires an endbr
> to be the target of an indirect branch has to already disabled on the
> way down? What specifically am I looking for, to check that? Or the
> hardware support has just never worked with kexec, perhaps?

Looking at machine_kexec(), it calls cet_disable() before the indirect
call.  So yeah, it seems fine for relocate_kernel() to not have a CFI
prologue or ENDBR.

-- 
Josh