On Thu, 20 Feb 2025 at 21:55, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > On Wed, Feb 19, 2025 at 11:55:44AM +0100, Ard Biesheuvel wrote: > > From: Ard Biesheuvel <ardb@xxxxxxxxxx> > > 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.
