Re: [PATCH] arm64/module: Support for patching modules during runtime

[Mark Rutland <mark.rutland@arm.com>]

On Mon, Aug 11, 2025 at 01:05:06PM +0100, Will Deacon wrote:
> On Mon, Aug 11, 2025 at 09:01:43AM +0100, Marc Zyngier wrote:
> > On Mon, 11 Aug 2025 08:37:32 +0100,
> > fanqincui <fanqincui@163.com> wrote:
> > > 
> > > Hi will,
> > > Yes, you are right. The alternative callback function lives inside the module.
> > > This callback function is actually similar to kvm_update_va_mask in KVM;
> > > 
> > > The module's callback function calculates some values based on
> > > the current CPU features and then performs the replacement.
> > > 
> > > The .text.alternative_cb section is actually marked as SHF_EXECINSTR | SHF_ALLOC
> > > during compilation, so intersections() includes this section and sets it as executable later.
> > 
> > I'm worried there is a chicken-and-egg problem here. What if the
> > callback itself requires patching via some other alternative? Is there
> > a guarantee that this always performed in the correct order?
> 
> Maybe we should just reject loading modules that have alternative
> callbacks that don't reside in the kernel text? 

I think that would be sensible. We never *intended* to support arbitrary
callbacks in modules, and if that's something people want, they need to
provide some actual justification.

> I _think_ that should cover all the in-tree users, although I didn't
> get a reply to my question asking which module triggered this bug
> report.

To the best of my knowledge, that covers all in-tree users. From a quick
grep for 'alternative_cb' and 'ALTERNATIVE_CB' in v6.17-rc1, all of the
patching functions are non-modular. AFAICT the only one we export is
alt_cb_patch_nops().

Mark.