From: Mike Rapoport <rppt@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Andreas Larsson <andreas@gaisler.com>,
Andy Lutomirski <luto@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Borislav Petkov <bp@alien8.de>, Brian Cain <bcain@quicinc.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Christoph Hellwig <hch@infradead.org>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Dave Hansen <dave.hansen@linux.intel.com>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Guo Ren <guoren@kernel.org>, Helge Deller <deller@gmx.de>,
Huacai Chen <chenhuacai@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Johannes Berg <johannes@sipsolutions.net>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Kent Overstreet <kent.overstreet@linux.dev>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Mark Rutland <mark.rutland@arm.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Simek <monstr@monstr.eu>, Oleg Nesterov <oleg@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Peter Zijlstra <peterz@infradead.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>, Song Liu <song@kernel.org>,
Stafford Horne <shorne@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Suren Baghdasaryan <surenb@google.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Thomas Gleixner <tglx@linutronix.de>,
Uladzislau Rezki <urezki@gmail.com>,
Vineet Gupta <vgupta@kernel.org>, Will Deacon <will@kernel.org>,
bpf@vger.kernel.org, linux-alpha@vger.kernel.org,
linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-openrisc@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-sh@vger.kernel.org, linux-snps-arc@lists.infradead.org,
linux-trace-kernel@vger.kernel.org, linux-um@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
sparclinux@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v6 6/8] x86/module: prepare module loading for ROX allocations of text
Date: Thu, 24 Oct 2024 11:13:11 +0300 [thread overview]
Message-ID: <ZxoBlwkh528r-vef@kernel.org> (raw)
In-Reply-To: <20241021221519.GA3567210@thelio-3990X>
Hi Nathan,
On Mon, Oct 21, 2024 at 03:15:19PM -0700, Nathan Chancellor wrote:
> Hi Mike,
>
> On Wed, Oct 16, 2024 at 03:24:22PM +0300, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> >
> > When module text memory will be allocated with ROX permissions, the
> > memory at the actual address where the module will live will contain
> > invalid instructions and there will be a writable copy that contains the
> > actual module code.
> >
> > Update relocations and alternatives patching to deal with it.
> >
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>
> Sorry that you have to hear from me again :) It seems that module
> loading is still broken with this version of the patch, which is
> something that I missed in my earlier testing since I only test a
> monolithic kernel with my regular virtual machine testing. If I build
> and install the kernel and modules in the VM via a distribution package,
> I get the following splat at boot:
>
> Starting systemd-udevd version 256.7-1-arch
> [ 0.882312] SMP alternatives: Something went horribly wrong trying to rewrite the CFI implementation.
> [ 0.883526] CFI failure at do_one_initcall+0x128/0x380 (target: init_module+0x0/0xff0 [crc32c_intel]; expected type: 0x0c7a3a22)
> [ 0.884802] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
> [ 0.885434] CPU: 3 UID: 0 PID: 157 Comm: modprobe Tainted: G W 6.12.0-rc3-debug-next-20241021-06324-g63b3ff03d91a #1 291f0fd70f293827edec681d3c5304f5807a3c7b
> [ 0.887084] Tainted: [W]=WARN
> [ 0.887409] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
> [ 0.888241] RIP: 0010:do_one_initcall+0x128/0x380
> [ 0.888720] Code: f3 0f 1e fa 41 be ff ff ff ff e9 0f 01 00 00 0f 1f 44 00 00 41 81 e7 ff ff ff 7f 49 89 db 41 ba de c5 85 f3 45 03 53 f1 74 02 <0f> 0b 41 ff d3 0f 1f 00 41 89 c6 0f 1f 44 00 00 c6 04 24 00 65 8b
> [ 0.890598] RSP: 0018:ff3f93e5c052f970 EFLAGS: 00010217
> [ 0.891129] RAX: ffffffffb4c105b8 RBX: ffffffffc0602010 RCX: 0000000000000000
> [ 0.891850] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffc0602010
> [ 0.892588] RBP: ff3f93e5c052fc88 R08: 0000000000000020 R09: 0000000000000000
> [ 0.893305] R10: 000000002a378b84 R11: ffffffffc0602010 R12: 00000000000069c6
> [ 0.894003] R13: ff1f0090c5596900 R14: ff1f0090c15a55c0 R15: 0000000000000000
> [ 0.894693] FS: 00007ffb712c0740(0000) GS:ff1f00942fb80000(0000) knlGS:0000000000000000
> [ 0.895453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.896020] CR2: 00007ffffc4424c8 CR3: 0000000100af4002 CR4: 0000000000771ef0
> [ 0.896698] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 0.897391] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 0.898077] PKRU: 55555554
> [ 0.898337] Call Trace:
> [ 0.898577] <TASK>
> [ 0.898784] ? __die_body+0x6a/0xb0
> [ 0.899132] ? die+0xa4/0xd0
> [ 0.899413] ? do_trap+0xa6/0x180
> [ 0.899740] ? do_one_initcall+0x128/0x380
> [ 0.900130] ? do_one_initcall+0x128/0x380
> [ 0.900523] ? handle_invalid_op+0x6a/0x90
> [ 0.900917] ? do_one_initcall+0x128/0x380
> [ 0.901311] ? exc_invalid_op+0x38/0x60
> [ 0.901679] ? asm_exc_invalid_op+0x1a/0x20
> [ 0.902081] ? __cfi_init_module+0x10/0x10 [crc32c_intel 5331566c5540f82df397056699bc4ddac8be1306]
> [ 0.902933] ? __cfi_init_module+0x10/0x10 [crc32c_intel 5331566c5540f82df397056699bc4ddac8be1306]
> [ 0.903781] ? __cfi_init_module+0x10/0x10 [crc32c_intel 5331566c5540f82df397056699bc4ddac8be1306]
> [ 0.904634] ? do_one_initcall+0x128/0x380
> [ 0.905028] ? idr_alloc_cyclic+0x139/0x1d0
> [ 0.905437] ? security_kernfs_init_security+0x54/0x190
> [ 0.905958] ? __kernfs_new_node+0x1ba/0x240
> [ 0.906377] ? sysfs_create_dir_ns+0x8f/0x140
> [ 0.906795] ? kernfs_link_sibling+0xf2/0x110
> [ 0.907211] ? kernfs_activate+0x2c/0x110
> [ 0.907599] ? kernfs_add_one+0x108/0x150
> [ 0.907981] ? __kernfs_create_file+0x75/0xa0
> [ 0.908407] ? sysfs_create_bin_file+0xc6/0x120
> [ 0.908853] ? __vunmap_range_noflush+0x347/0x420
> [ 0.909313] ? _raw_spin_unlock+0xe/0x30
> [ 0.909692] ? free_unref_page+0x22c/0x4c0
> [ 0.910097] ? __kmalloc_cache_noprof+0x1a8/0x360
> [ 0.910546] do_init_module+0x60/0x250
> [ 0.910910] __se_sys_finit_module+0x316/0x420
> [ 0.911351] do_syscall_64+0x88/0x170
> [ 0.911699] ? __x64_sys_lseek+0x68/0xb0
> [ 0.912077] ? syscall_exit_to_user_mode+0x97/0xc0
> [ 0.912538] ? do_syscall_64+0x94/0x170
> [ 0.912902] ? syscall_exit_to_user_mode+0x97/0xc0
> [ 0.913353] ? do_syscall_64+0x94/0x170
> [ 0.913709] ? clear_bhb_loop+0x45/0xa0
> [ 0.914071] ? clear_bhb_loop+0x45/0xa0
> [ 0.914428] ? clear_bhb_loop+0x45/0xa0
> [ 0.914767] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 0.915089] RIP: 0033:0x7ffb713dc1fd
> [ 0.915316] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 fa 0c 00 f7 d8 64 89 01 48
> [ 0.916491] RSP: 002b:00007ffffc4454a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> [ 0.916964] RAX: ffffffffffffffda RBX: 000055f28c6a5420 RCX: 00007ffb713dc1fd
> [ 0.917413] RDX: 0000000000000000 RSI: 000055f26c40cc03 RDI: 0000000000000003
> [ 0.917858] RBP: 00007ffffc445560 R08: 0000000000000001 R09: 00007ffffc4454f0
> [ 0.918302] R10: 0000000000000040 R11: 0000000000000246 R12: 000055f26c40cc03
> [ 0.918748] R13: 0000000000060000 R14: 000055f28c6a4b50 R15: 000055f28c6ac5b0
> [ 0.919211] </TASK>
> [ 0.919356] Modules linked in: crc32c_intel(+)
> [ 0.919661] ---[ end trace 0000000000000000 ]---
>
> I also see some other WARNs interleaved along the lines of
>
> [ 0.982759] no CFI hash found at: 0xffffffffc0608000 ffffffffc0608000 cc cc cc cc cc
> [ 0.982767] WARNING: CPU: 5 PID: 170 at arch/x86/kernel/alternative.c:1204 __apply_fineibt+0xa6d/0xab0
>
> The console appears to be a bit of a mess after that initial message.
>
> If there is any more information I can provide or patches I can test, I
> am more than happy to do so.
I've got similar report from kbuild bot a few days ago:
https://lore.kernel.org/all/202410202257.b7edc376-lkp@intel.com
I fixed fineibt handling in v7:
https://lore.kernel.org/linux-mm/20241023162711.2579610-1-rppt@kernel.org
> Cheers,
> Nathan
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2024-10-24 8:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-16 12:24 [PATCH v6 0/8] x86/module: use large ROX pages for text allocations Mike Rapoport
2024-10-16 12:24 ` [PATCH v6 1/8] mm: vmalloc: group declarations depending on CONFIG_MMU together Mike Rapoport
2024-10-16 14:41 ` Uladzislau Rezki
2024-10-19 22:17 ` Luis Chamberlain
2024-10-16 12:24 ` [PATCH v6 2/8] mm: vmalloc: don't account for number of nodes for HUGE_VMAP allocations Mike Rapoport
2024-10-16 17:21 ` Uladzislau Rezki
2024-10-19 22:19 ` Luis Chamberlain
2024-10-16 12:24 ` [PATCH v6 3/8] asm-generic: introduce text-patching.h Mike Rapoport
2024-10-19 22:21 ` Luis Chamberlain
2024-10-16 12:24 ` [PATCH v6 4/8] module: prepare to handle ROX allocations for text Mike Rapoport
2024-10-19 22:30 ` Luis Chamberlain
2024-10-16 12:24 ` [PATCH v6 5/8] arch: introduce set_direct_map_valid_noflush() Mike Rapoport
2024-10-19 22:32 ` Luis Chamberlain
2024-10-16 12:24 ` [PATCH v6 6/8] x86/module: prepare module loading for ROX allocations of text Mike Rapoport
2024-10-16 21:01 ` Steven Rostedt
2024-10-17 9:35 ` Peter Zijlstra
2024-10-17 11:25 ` Mike Rapoport
2024-10-17 15:35 ` Steven Rostedt
2024-10-17 14:17 ` Steven Rostedt
2024-10-19 12:07 ` Mike Rapoport
2024-10-21 22:15 ` Nathan Chancellor
2024-10-24 8:13 ` Mike Rapoport [this message]
2024-10-16 12:24 ` [PATCH v6 7/8] execmem: add support for cache of large ROX pages Mike Rapoport
2024-10-19 22:46 ` Luis Chamberlain
2024-10-16 12:24 ` [PATCH v6 8/8] x86/module: enable ROX caches for module text on 64 bit Mike Rapoport
2024-10-19 22:46 ` Luis Chamberlain
2024-10-19 22:51 ` [PATCH v6 0/8] x86/module: use large ROX pages for text allocations Luis Chamberlain
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=ZxoBlwkh528r-vef@kernel.org \
--to=rppt@kernel.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=bpf@vger.kernel.org \
--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@infradead.org \
--cc=jcmvbkbc@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=kent.overstreet@linux.dev \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-openrisc@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--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=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
--cc=nathan@kernel.org \
--cc=oleg@redhat.com \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=richard@nod.at \
--cc=rostedt@goodmis.org \
--cc=shorne@gmail.com \
--cc=song@kernel.org \
--cc=sparclinux@vger.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 \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).