linux-kernel - Re: [PATCH 1/7] stop_machine: Introduce stop_machine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <960d07f0-d693-4139-ba80-d622b69e6273@intel.com>
Date: Tue, 27 Jan 2026 11:15:08 -0800
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: Borislav Petkov <bp@...en8.de>, kernel test robot <lkp@...el.com>
CC: <linux-kernel@...r.kernel.org>, <oe-kbuild-all@...ts.linux.dev>,
	<x86@...nel.org>, <tglx@...utronix.de>, <mingo@...hat.com>,
	<dave.hansen@...ux.intel.com>, <peterz@...radead.org>, <david.kaplan@....com>
Subject: Re: [PATCH 1/7] stop_machine: Introduce stop_machine_nmi()

On 1/27/2026 6:49 AM, Borislav Petkov wrote:
>>
>>>> vmlinux.o: error: objtool: stop_machine_nmi_handler+0x23: call to {dynamic}() leaves .noinstr.text section
> 
> This one would be hard to fix because that's the
> 
> 	err = msdata->fn(msdata->data);
> 
> function pointer which objtool can't see through.

Yes. Under certain config, the 0-day bot tirggers this with 
CONFIG_NOINSTR_VALIDATION=y.

Objtool ends up with the following path:

tools/objtool/check.c::validation_call()
-> noinstr_call_dest()
    {
	/*
	 * We can't deal with indirect function calls at present;
	 * assume they're instrumented.
	 */
	if (!func) {
		if (file->pv_ops)
			return pv_call_dest(file, insn);

		return false;
	}
     ...
    }

So every indirect call under noinstr is conservatively treated as 
invalid except for pv_ops which seems to be investigated further. In 
this series, however, the destination code is to in .noinstr.text.

Given this, I considered something to be adjusted on the tool side, e.g. 
by whitelisting the case along the lines of

   if (!func) {
     ...

     if (!strncmp(insn_func(insn)->name, "stop_machine_nmi_handler", 24))
       return true;

     return false;
   }

The existing pv_ops handling also looks somewhat misaligned with large 
objects like vmlinux.o.

> 
> So my suggestion would be to do:
> 
> struct nmi_multi_stop_data {
> 	cpu_stop_safe_fn_t           fn;
> 
> note the different function pointer type which we will hopefully catch during
> review in the sense that only *safe* functions should be callable by the
> NMI-specific stomp_machine.
> 
> Along with:
> 
> diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> index 189b4b108d13..55a350048d4c 100644
> --- a/kernel/stop_machine.c
> +++ b/kernel/stop_machine.c
> @@ -230,7 +230,9 @@ bool noinstr stop_machine_nmi_handler(void)
>   	raw_cpu_write(stop_machine_nmi_ctrl.nmi_enabled, false);
>   
>   	msdata = raw_cpu_read(stop_machine_nmi_ctrl.msdata);
> +	instrumentation_begin();
>   	err = msdata->fn(msdata->data);
> +	instrumentation_end();
>   	raw_cpu_write(stop_machine_nmi_ctrl.err, err);
>   	return true;
>   }

I also thought this change, but I was a bit hesitant as it could be seen 
as lifting up the no-instrumentation.

Now I suppose the net effect will be the same with other workaround, 
e.g. tool-side whitelisting. So I think I can go with this as you 
suggested (with a clear note on this).

> 
> ofc.
> 
> Unless someone has a better idea ofc...

Sure.

Thanks,
Chang