linux-kernel - Re: [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG

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: <45FAC4EF.4060305@goop.org>
Date:	Fri, 16 Mar 2007 09:25:19 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Zachary Amsden <zach@...are.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Jan Beulich <jbeulich@...ell.com>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Chris Wright <chrisw@...s-sol.org>,
	Andrew Morton <akpm@...l.org>,
	Linus Torvalds <torvalds@...l.org>,
	Virtualization Mailing List <virtualization@...ts.osdl.org>
Subject: Re: [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT

Eric W. Biederman wrote:
> I'm not quite familiar with the context.  And I'm to lazy to look right now.
> What is the difference with COMPAT_VDSO that it doesn't do relocation?
> What are we preserving?
>
>   

The issue is that with COMPAT_VDSO, the vdso gets mapped at two places:
one random address, and one fixed address (traditionally 0xffffe000 I
think, but that's not mandatory).  The important point is that the
fixed-address is the same one that the vdso itself is linked for, so
that old broken glibcs that some vendors shipped won't explode (because
they use AT_SYSINFO but not AT_SYSINFO_EHDR, so they don't account for
the difference in link and map address).

The problem with the COMPAT_VDSO with paravirt is that the hypervisor
may steal some of the kernel address space, and so push down the address
where the fixed address vdso can be mapped.

Zach's patch relocates the immobile COMPAT_VDSO version of the vdso page
so that map=link address, regardless of where the kernel's runtime
environment puts the top of the kernel address space.

I guess the other solution is to simply put the compat_vdso mapping at
some low address (like the top of the user address space), and not worry
about it moving.  I don't know if this would work, but I seem to
remember someone mentioning that it had been done in the past.

> The practical question here is if we already have all of the relocation logic
> for the VDSO why do we need to add more?
>   

The kernel doesn't normally ever relocate the vdso; usermode can
generally cope with it where ever it gets mapped.

    J
-
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/