From: Ard Biesheuvel <ardb@kernel.org>

When using -fPIE codegen, the compiler will emit const global objects
(which are useless unless statically initialized) into .data.rel.ro
rather than .rodata if the object contains fields that carry absolute
addresses of other code or data objects. This permits the linker to
annotate such regions as requiring read-write access only at load time,
but not at execution time (in user space).

This distinction does not matter for the kernel, but it does imply that
const data will end up in writable memory if the .data.rel.ro sections
are not treated in a special way.

So emit .data.rel.ro into the .rodata segment.

Cc: <stable@vger.kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 include/asm-generic/vmlinux.lds.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 02a4adb4a999..0d5b186abee8 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -457,7 +457,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
 	. = ALIGN((align));						\
 	.rodata           : AT(ADDR(.rodata) - LOAD_OFFSET) {		\
 		__start_rodata = .;					\
-		*(.rodata) *(.rodata.*)					\
+		*(.rodata) *(.rodata.*) *(.data.rel.ro*)		\
 		SCHED_DATA						\
 		RO_AFTER_INIT_DATA	/* Read only after init */	\
 		. = ALIGN(8);						\
-- 
2.48.1.601.g30ceb7b040-goog

On Wed, Feb 19, 2025 at 11:55:44AM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>

BTW, I was copied on the cover letter but not the individual patches.

> When using -fPIE codegen, the compiler will emit const global objects
> (which are useless unless statically initialized) into .data.rel.ro
> rather than .rodata if the object contains fields that carry absolute
> addresses of other code or data objects. This permits the linker to
> annotate such regions as requiring read-write access only at load time,
> but not at execution time (in user space).

Hm, this sounds more like __ro_after_init, are we sure the kernel
doesn't need to write it early?

> This distinction does not matter for the kernel, but it does imply that
> const data will end up in writable memory if the .data.rel.ro sections
> are not treated in a special way.
> 
> So emit .data.rel.ro into the .rodata segment.

This is a bug fix, right?  Since the RO data wasn't actually RO?  That's
not clear in the title.

-- 
Josh

On Thu, 20 Feb 2025 at 21:55, Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Wed, Feb 19, 2025 at 11:55:44AM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
>
> BTW, I was copied on the cover letter but not the individual patches.
>
> > When using -fPIE codegen, the compiler will emit const global objects
> > (which are useless unless statically initialized) into .data.rel.ro
> > rather than .rodata if the object contains fields that carry absolute
> > addresses of other code or data objects. This permits the linker to
> > annotate such regions as requiring read-write access only at load time,
> > but not at execution time (in user space).
>
> Hm, this sounds more like __ro_after_init, are we sure the kernel
> doesn't need to write it early?
>

It does need to write to it early, for KASLR relocation. So
conceptually, it is the same as .rodata. __ro_after_init conceptually
remains writable for longer.

In practice, they are all treated the same so it doesn't really matter.

> > This distinction does not matter for the kernel, but it does imply that
> > const data will end up in writable memory if the .data.rel.ro sections
> > are not treated in a special way.
> >
> > So emit .data.rel.ro into the .rodata segment.
>
> This is a bug fix, right?  Since the RO data wasn't actually RO?  That's
> not clear in the title.
>

Yes, it is. I'll clarify that.