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

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] [day] [month] [year] [list]

Message-ID: <aJnegL4HcT2evOnR@J2N7QTR9R3>
Date: Mon, 11 Aug 2025 13:13:52 +0100
From: Mark Rutland <mark.rutland@....com>
To: Will Deacon <will@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>, fanqincui <fanqincui@....com>,
	catalin.marinas@....com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, Fanqin Cui <cuifq1@...natelecom.cn>,
	hanht2@...natelecom.cn
Subject: Re: [PATCH] arm64/module: Support for patching modules during runtime

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@....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.