Path: Home.Lunix!not-for-mail
Subject: Re: [PATCH] linux-2.5.43_vsyscall_A0
Date: Sat, 19 Oct 2002 22:36:30 +0000 (UTC)
Organization: lunix confusion services
References: <200210190352.WAA05769@ccure.karaya.com>
NNTP-Posting-Host: kali.eth
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
NNTP-Posting-Date: Sat, 19 Oct 2002 22:36:30 +0000 (UTC)
Xref: Home.Lunix mail.linux.kernel:188371
Message-Id: <aosmpe$o8e$1@post.home.lunix>
From: linux-kernel@ton.iguana.be (Ton Hospel)
To: linux-kernel@vger.kernel.org
Reply-To: linux-kernel@ton.iguana.be (Ton Hospel)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1110
Lines: 18

In article <200210190352.WAA05769@ccure.karaya.com>,
	Jeff Dike <jdike@karaya.com> writes:
> 
> This needs to be virtualizable somehow, which means that apps run inside
> UML, without being changed, get the UML vsyscalls.  There are a couple of
> possiblities that I can think of:
> 	a get_vsyscall system call which is executed by libc on startup -
> UML would return a different calue from the host
> 	some mechanism for UML to map its own vsyscall area in place of
> the host's - it wouldn't necessarily need to be able to unmap it when it's
> running its own kernel code because it can probably arrange not to use the
> host's vsyscalls.
> 
> 				Jeff
> 
In case you want UML to also be able to work as a jail, it should
actually be impossible to get to the "real" systemcalls. In that case
just asking libc is not acceptable if the other area remains available
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/