On Fri, 27 Sept 2024 at 07:49, Ard Biesheuvel <a...@kernel.org> wrote: > > On Fri, 27 Sept 2024 at 03:47, Jason Andryuk <jason.andr...@amd.com> wrote: > > > > On 2024-09-26 06:41, Ard Biesheuvel wrote: > > > From: Ard Biesheuvel <a...@kernel.org> > > > > > > Xen puts virtual and physical addresses into ELF notes that are treated > > > by the linker as relocatable by default. Doing so is not only pointless, > > > given that the ELF notes are only intended for consumption by Xen before > > > the kernel boots. It is also a KASLR leak, given that the kernel's ELF > > > notes are exposed via the world readable /sys/kernel/notes. > > > > > > So emit these constants in a way that prevents the linker from marking > > > them as relocatable. This involves place-relative relocations (which > > > subtract their own virtual address from the symbol value) and linker > > > provided absolute symbols that add the address of the place to the > > > desired value. > > > > > > While at it, switch to a 32-bit field for XEN_ELFNOTE_PHYS32_ENTRY, > > > which better matches the intent as well as the Xen documentation and > > > source code. > > > > QEMU parses this according to the ELF bitness. It looks like this reads > > 8 bytes on 64bit, and 4 on 32. So I think this change would break its > > parsing. > > > > Indeed, well spotted. > > > (I don't use QEMU PVH and I'm not that familiar with its implementation.) > > > > This is what I used for testing, and it worked fine. > > But looking at the code, it does dereference a size_t*, which seems > bizarre but will clearly produce garbage in the upper bits if the note > is 32-bits only and followed by unrelated non-zero data. > > I'll just back out this part of the change - it isn't really necessary anyway.
... and fix QEMU as well: https://lore.kernel.org/qemu-devel/20240927071950.1458596-1-ardb+...@google.com/T/#u
