linux-kernel - Re: [patch] paravirt: VDSO page is essential

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]

Date:	Mon,  5 Mar 2007 13:58:37 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Andi Kleen <ak@...e.de>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [patch] paravirt: VDSO page is essential

Does the old userland compatibility you're concerned about really need the
vdso to be at 0xfffffe000 in particular, or just need it to be at a fixed
address that matches the phdrs inside the image?  My recollection of the old
glibc's limitation was that it expected the image's phdrs to match its load
address.  The xen kernels used to change this to 0xffffd000 or something,
and AFAIK that was fine.  If that's all that's needed, it is not so hard to
adjust the vDSO contents at boot time (phdrs, shdrs, and symbols; no code
contents use the absolute address).  Under CONFIG_COMPAT_VDSO, it can see
where the paravirt moved the fixmap to, and apply adjustments.

That said, I don't think this is worth all that much effort since
CONFIG_COMPAT_VDSO is not really desireable for most people.  I think
disabling the vdso under CONFIG_COMPAT_VDSO+CONFIG_PARAVIRT is survivable
(just don't set CONFIG_COMPAT_VDSO for a system you want to be optimal).

Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/