mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jacques Gelinas <jack@solucorp.qc.ca>
To: linux-kernel@vger.kernel.org
Subject: re: new virtualization syscall to improve uml performance?
Date: Fri, 18 Jan 2002 14:23:47 -0500	[thread overview]
Message-ID: <20020118142347.04f988370c19@remtk.solucorp.qc.ca> (raw)

On Fri, 18 Jan 2002 13:12:59 -0500, baccala@freesoft.org wrote

> First, kudos to everyone who worked on user mode linux.  I need to
> build distribution RPMs for a couple of pieces of free software I help
> maintain, and have this absurd dilemma about running recent RedHat
> releases (to get the latest code) or running older releases (to
> compile RPMs that will install on both older and newer systems).  I've
> been trying to accommodate both needs by selectively picking and
> choosing older and newer RPMs to install on my system, and the result
> is a mess that won't compile anything!  Anyway, I installed UML with
> the distributed RedHat 6.2 filesystem, fired it up, installed a few
> missing RPMs like make, and the software built fine.  I think I've
> solved my dilemma...

The vservers (see my sig) are pretty good to solve that. You can run any linux i386
distro and version all at once on the same box.

> would be replaced with:
>
> 	syscall trap
>
> Would this be just more kernel bloat to support one application?
> Perhaps not.  I have other utilities (a user-space HTTP file system,
> and code to do Plan 9-ish directory overlays) that need to intercept
> system calls.  I currently do this using the LD_PRELOAD function of
> the shared library.  This has the following disadvantages:
>
> 	1. a specially compiled glibc must be installed, because
> 	   the standard one doesn't export all the needed symbols,
> 	2. newer versions of the OS/glibc cause problems if they
> 	   introduce new syscalls (like open64) that don't get
> 	   caught until you add more code just for them, and

I solved this in virtualfs (http://www.solucorp.qc.ca/virtualfs) by introducing
new weak symbol.

> 	3. it's impossible to have any security, because the user
> 	   code could just bypass glibc and make the syscalls directly

Yes but the reverse is true. With the trap, you end up in your own code
with full privilege. Does it opens worst problem.

For privilege stuff, the virtualfs dispatcher connects to special server. Using
unix domain socket, credential passing and file handle passing, you can do
a lot of privileged stuff this way.

---------------------------------------------------------
Jacques Gelinas <jack@solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc

             reply	other threads:[~2002-01-18 22:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-18 19:23 Jacques Gelinas [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-01-18 18:12 baccala
2002-01-23 16:46 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020118142347.04f988370c19@remtk.solucorp.qc.ca \
    --to=jack@solucorp.qc.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®