linux-kernel - Re: [PATCH 4/5] x86/xen: Avoid relocatable quantities in Xen ELF notes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <572b339b-7dab-4db0-8ee8-d805f8211aa3@amd.com>
Date: Thu, 26 Sep 2024 21:46:53 -0400
From: Jason Andryuk <jason.andryuk@....com>
To: Ard Biesheuvel <ardb+git@...gle.com>, <linux-kernel@...r.kernel.org>
CC: Ard Biesheuvel <ardb@...nel.org>, Juergen Gross <jgross@...e.com>, "Boris
 Ostrovsky" <boris.ostrovsky@...cle.com>, <x86@...nel.org>,
	<xen-devel@...ts.xenproject.org>
Subject: Re: [PATCH 4/5] x86/xen: Avoid relocatable quantities in Xen ELF
 notes

On 2024-09-26 06:41, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@...nel.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.

(I don't use QEMU PVH and I'm not that familiar with its implementation.)

Regards,
Jason