On Tue, 16 Aug 2022 at 12:17, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Tue, Aug 16, 2022 at 09:04:56AM +0200, Ard Biesheuvel wrote: > > (cc Peter and Josh) > > > > On Mon, 15 Aug 2022 at 22:18, Borislav Petkov <bp@xxxxxxxxx> wrote: ... > > > For some reason, objtool is not happy here: > > > vmlinux.o: warning: objtool: efi_thunk_query_variable_info_nonblocking+0x1ba: unreachable instruction > > > > [which is the instruction right after the call to __efi_thunk64()] > > > > However, with the same config but without the patch (i.e., v6.0-rc1 > > with nothing on top), I see: > > > > vmlinux.o: warning: objtool: sme_enable+0x71: unreachable instruction > > > > It appears that objtool is making inferences about whether or not > > __efi_thunk64() returns, even though it is marked as > > STACK_FRAME_NON_STANDARD. And note that I am not seeing any of these > > with x86_64_defconfig, only with Boris's config (attached) > > STACK_FRAME_NON_STANDARD has no bearing on a call to that symbol being > noreturn or not. > > noreturn is a bit of a pain point in that the compiler leaves no clue > in the object file. Objtool has a bunch of heuristics to guess at > noreturn, but the only surefire way to make things consistent is to > annotate the function with __noreturn and add it to the > global_noreturns[] array in tools/objtool/check.c > > Alternatively, if objtool guesses wrong, you can annotate the assembler > with 'REACHABLE'. > So the problem here is that the function is *not* __noreturn, and objtool thinks it is, resulting in the instruction after the call to be misidentified as unreachable. The function is called from C code, so we cannot easily annotate the instruction after the call as REACHABLE. I've patched it up by adding a dummy, unreachable RET into __efi64_thunk(), which seems to make objtool happy for now.
