From: Peter Zijlstra <peterz@infradead.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
mm-commits@vger.kernel.org, will@kernel.org, vgupta@kernel.org,
urezki@gmail.com, tsbogend@alpha.franken.de, tglx@linutronix.de,
surenb@google.com, song@kernel.org, shorne@gmail.com,
rostedt@goodmis.org, richard@nod.at, palmer@dabbelt.com,
oleg@redhat.com, mpe@ellerman.id.au, monstr@monstr.eu,
mingo@redhat.com, mhiramat@kernel.org, mcgrof@kernel.org,
mattst88@gmail.com, mark.rutland@arm.com, luto@kernel.org,
linux@armlinux.org.uk, Liam.Howlett@oracle.com,
kent.overstreet@linux.dev, kdevops@lists.linux.dev,
johannes@sipsolutions.net, jcmvbkbc@gmail.com, hch@lst.de,
guoren@kernel.org, glaubitz@physik.fu-berlin.de,
geert@linux-m68k.org, dinguyen@kernel.org, deller@gmx.de,
dave.hansen@linux.intel.com, christophe.leroy@csgroup.eu,
chenhuacai@kernel.org, catalin.marinas@arm.com, bp@alien8.de,
bcain@quicinc.com, arnd@arndb.de, ardb@kernel.org,
andreas@gaisler.com
Subject: Re: [merged mm-stable] x86-module-prepare-module-loading-for-rox-allocations-of-text.patch removed from -mm tree
Date: Thu, 5 Dec 2024 09:41:28 +0100 [thread overview]
Message-ID: <20241205084128.GH8562@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <ZysRwR29Ji8CcbXc@kernel.org>
On Wed, Nov 06, 2024 at 08:50:41AM +0200, Mike Rapoport wrote:
> Hi Andrew,
>
> Yesterday Nathan discovered and I fixed another small issue with fineibt.
> I suspect it's too late to add this as a fixup, so here's a formal patch
> with the fix.
>
> From b31fd8493c4e1b6042776642a812690f16575b51 Mon Sep 17 00:00:00 2001
> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> Date: Tue, 5 Nov 2024 10:49:57 +0200
> Subject: [PATCH] x86/alternatives: fix writable address in cfi_rewrite_endbr()
>
> Commit a159950eb69f ("x86/module: prepare module loading for ROX
> allocations of text") missed the offset that should be added to the
> writable address passed to poison_endbr() from cfi_rewrite_endbr() and
> this causes boot failures on kernels running with cfi=fineibt on
> machines that support IBT.
>
> Add required offset to wr_addr argument to fix the issue.
>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Fixes: a159950eb69f ("x86/module: prepare module loading for ROX allocations of text")
> Tested-by: Nathan Chancellor <nathan@kernel.org>
> ---
> arch/x86/kernel/alternative.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 3407efc26528..243843e44e89 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -1241,7 +1241,7 @@ static void cfi_rewrite_endbr(s32 *start, s32 *end, struct module *mod)
> void *addr = (void *)s + *s;
> void *wr_addr = module_writable_address(mod, addr);
>
> - poison_endbr(addr+16, wr_addr, false);
> + poison_endbr(addr + 16, wr_addr + 16, false);
> }
> }
So... *sigh*. I had to rebase quite a few patches on top of this, and
while doing do I got quite annoyed at how messy all this is, so I
cleaned it all up.
Only to find out that it's all broken, even with the above fix (my ADL
will currently die when it tries to load a module).
So it's a good thing these patches got an ack from the x86 people I
suppose :-(((
Anyway, while noodling with all that, I think there's a fairly
fundamental error in all of this. The mem->rw_copy should not be a whole
second allocation, it should be a (page granular) RW alias of the
(large) ROX map.
That also gets rid of that whole copy operation.
I'm having to chase a few regressions of my own first, but after that
I'll look at reworking all this.
next prev parent reply other threads:[~2024-12-05 8:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 1:00 [merged mm-stable] x86-module-prepare-module-loading-for-rox-allocations-of-text.patch removed from -mm tree Andrew Morton
2024-11-06 6:50 ` Mike Rapoport
2024-11-06 21:30 ` Andrew Morton
2024-12-05 8:41 ` Peter Zijlstra [this message]
2024-12-06 10:39 ` Mike Rapoport
2024-12-09 8:38 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241205084128.GH8562@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bcain@quicinc.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dave.hansen@linux.intel.com \
--cc=deller@gmx.de \
--cc=dinguyen@kernel.org \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=guoren@kernel.org \
--cc=hch@lst.de \
--cc=jcmvbkbc@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=kdevops@lists.linux.dev \
--cc=kent.overstreet@linux.dev \
--cc=linux@armlinux.org.uk \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mattst88@gmail.com \
--cc=mcgrof@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=mm-commits@vger.kernel.org \
--cc=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
--cc=oleg@redhat.com \
--cc=palmer@dabbelt.com \
--cc=richard@nod.at \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=shorne@gmail.com \
--cc=song@kernel.org \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=urezki@gmail.com \
--cc=vgupta@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.