[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXH3RoAGQSG8KL1mkmiGbqi68CYFAuJSwBPdbt2b=7RUfA@mail.gmail.com>
Date: Thu, 20 Feb 2025 23:33:28 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org, x86@...nel.org,
Huacai Chen <chenhuacai@...nel.org>, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/2] asm-generic/vmlinux.lds: Move .data.rel.ro input
into .rodata segment
On Thu, 20 Feb 2025 at 21:55, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> On Wed, Feb 19, 2025 at 11:55:44AM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@...nel.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.
Powered by blists - more mailing lists