[nycbug-talk] shared hosting

[Sunny Dubey]

I have to admit, these long emails are getting really annoying

How about I simply create a XEN box that everyone can have an account on.  
Both on the VMs and the host-os itself so everyone can get a sense/feel of 
what xen from a host/client perspective ?

On Thursday 27 January 2005 16:56, Isaac Levy wrote:

[...]


> Seems like- but then what I'm still wondering is, what are the Xen
> advantages when applied to hosting common internet applications?
>

IIRC jail() can have name-space clashes when it comes to disk permissions and 
such.  This isn't possible on a XEN like system.  (I have to admit, I don't 
fully understand the scope of this clashing)Xen and the Art of Virtualization 
describes the architecture of Xen 1.x. Published at SOSP 2003 
Xen and the Art of Repeated Research is an independent paper verifying our 
SOSP results (written by a group at Clarkson University),. Published at 
FREENIX 2004 
Safe Hardware Access with the Xen Virtual Machine Monitor describes the new 
I/O infrastructure in Xen 2.0. Published at the OASIS ASPLOS 2004 workshop. 

XEN allows me to do live suspends and resumes.  I can literally take a 
snapshot of a running OS, and resume it when I desire.  I can even migrate a 
VM over the network in such a live fashion.

the availability and flexibility is clearly higher

> > If your problem *can* be solved by jail, and you trust jail enough, use
> > jail. Xen is designed to solve a different problem.
>
> What different problem?!
>

Jail() is freebsd on freebsd.  XEN is anything on XEN/linux.  Its not a 
question of different problems, its just a question of two different products 
with goals that can be very similar to each other.

[...]

> It seems to me, as Sunny and I had discussed long ago, that Linux VM
> systems really need a Kernel available to the instances more than the
> BSD's, because so much is done in Linux through the Kernel- whereas the
> converse is true across the BSD's, where much more is accomplished
> through userland tools and subsystems (if not userland, at least
> subsystems which aren't in the kernel).
>

ummm, no, I guess I came off wrongly

both the linux kernel and *bsd kernel are the same when you think of what they 
do (implement syscalls, provide drivers etc).  There is very little 
difference between the two (other than random things like NFS being done in 
user/kernel space.)

At the time UML was nothing more than a port of linux onto itself.  Meaning 
the linux kernel was given all the ELF executable stuff to make it look and 
run just like a regular binary.

Tho this is somewhat offtopic, heh

> To my knowledge, that's all there is to jailing, so that's under 16 kb
> in source code- (again, vs. the 9.2 mb of Xen- so we're actually at the
> magnitude of about 580 times the code, give or take, for the record.)

ok, I think u are looking at the wrong file:

sunny at atticus[~/files]$ ls -lh xen-2.0.3-src.tgz
-rw-r--r--  1 sunny sunny 2.1M Jan 12 07:31 xen-2.0.3-src.tgz

2.1 megs, of which contains patch for linux kernel and the tools to run xen 
too.

>
> -
> Now, diving deeper into the source, I can't find the jaill-related code
> which you state is *all-over*.
>
> I found about 550 references to jail, mostly contained in the files
> mentioned above, and some strewn about in the chroot code, in the
> source for PS, expected places-  but haven't taken the time to
> investigate *too* deeply (but did find a cute EPS diagram which grep
> ripped 'jail' out of).

see, its not a question of 550, or even 3.  Its a question of any code being 
modified or not.  With XEN only the kernel needs to be ported to a 
quasi-architecture.  There is zero editing of the userspace libraries or 
tools.

This could be a good thing, a bad thing.  Whatever floats your boat.

> <Total sidenote- top does not work in jails out of the box, for the
> this very reason, (paging memory) and this gives me a nice lead to
> actually get around to hacking a patch to make top work in jails- what
> a convienence that'd be... (but talk is cheap, so I digress)...>
>

tools like top would have to work in XEN because VMs are run a separate kernel 
addressing scheme.

> That point not understood on this end of the wire, here's why:  If a
> cracker gets through the Xen enviornment and into the host, how is the
> host *not* then compromised?  I mean, it's still all the same hardware,
> still the same system.
> I would additionally argue that a hole *could* be burrowed right
> through the OS instance, (I'd start digging at the kernel mods for Xen
> modified system calls)- and burrow straight into the host OS, precisely
> the same threat model that jail(2) faces.  Layers in between don't
> matter, big picture of this complexity, it's still the same hardware.
>
> (/me opens the door for Sunny here hoping he'll pipe in with some words
> on yummy hardware separation tech?)
>

hardware separation is more about saying I have "4 CPUs on a single CPU card, 
one can be dedicated to a single instance of linux-2.6.11, the others to 
linux-2.6.12" (or so I think.  it doesn't matter if this is wrong because 
isn't entirely relevant)

In order to break into the Host, you would first need to exploit the local 
running kernel (linux, netbsd, whatever).  Then you would have to deal with 
the domains layers that XEN sets up, and finally you then would be able to 
affect the host in any way shape or form.  Layers are very important because 
XEN is built around allowing/denying specific layers specific things.  These

Much easier said than done.

I'm sorry, but this is my last post for this thread.  If folks want to 
continue discussion, lets all meet for a cup of joe or something, heh

Sunny Dubey