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
