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]

Message-ID: <20070305201957.GA733@elte.hu>
Date:	Mon, 5 Mar 2007 21:19:57 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Zachary Amsden <zach@...are.com>
Cc:	Andi Kleen <ak@...e.de>, Rusty Russell <rusty@...tcorp.com.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Roland McGrath <roland@...hat.com>,
	virtualization <virtualization@...ts.osdl.org>
Subject: Re: [patch] paravirt: VDSO page is essential

* Zachary Amsden <zach@...are.com> wrote:

> [...]  I can't comment on Ingo's patch as he failed to -cc me on it,

it's on lkml, i'll bounce it to you separately.

> despite the fact that we are the only ones affected by it. [...]

actually, no, my motivation for it was KVM (a Linux based hypervisor and 
its paravirtual interface). You said that VMI wont hinder Linux 
development and design in any way and can adopt to whatever change the 
upstream kernel does, so i'm taking your word for that.

> [...] We are not concerned so much with supporting legacy user land 
> deployments, as we expect for the most part, the install scenario to 
> happen when upgrading to new distros.

that's not really the right argument. This obviously affects the host 
kernel too if it has CONFIG_PARAVIRT enabled. The other option is the 
removal (or temporary disabling) of the whole CONFIG_VMI and 
CONFIG_PARAVIRT stuff if you cannot get into minimal release shape, it's 
experimental stuff after all.

> What we really need to do is to be able to detect an old user land and 
> drop VDSO support when that is found.  [...]

no. What you need is to keep existing mechanisms and not hack off the 
vdso and CONFIG_COMPAT_VDSO...

> [...] But since we can't do that, the next best thing is to allow the 
> hypervisor to choose whatever workaround it wants when it moves the 
> fixmap and compat_vdso was enabled.  In our case, the workaround we 
> will want is a boot option to disable VDSO for old user land, [...]

there's no need to disable the VDSO for old userspace ...

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