umlwin32.sf.net is where you will find the UML/Win32 port. It's almost functional, as far as I can tell. I think the only major thing lacking is process signal delivery. That and lots of exercise and bug fixing.
Unfortunately, it's been somewhat dormant over the last few months as the people working on it have had other demands on their time.
Dan Aloni is working on the cygwin port of UML. So far, he's got most of the kernel compiling. The holdouts are mostly OS-specific stuff which we're knocking off one piece at a time.
If you're interested in helping, contact me or him at karrde at callisto.yi.org.
Jeff
Re:this has been around for quite a while...
on
User Mode Linux
·
· Score: 3
I'll also guarantee that no thought has been put into making a user-mode Linux port for Windows, so you can stop wishing...
Actually people have thought about it. No one has coughed up any actual code, though.
Jeff
Re:Security and GPL Considerations Of User Mode Li
on
User Mode Linux
·
· Score: 2
A more troubling question is how much of "User Mode Linux" can be run entirely independent of root. Even creating a new SLIP device for the virtualized OS requires non-user priviledges, so the best case scenario remains that an attacker, knowing they're behind a false root, attempts to corrupt or attack the parent kernel by feeding bad bytes down the network interface.
Everything except access to the host networking can be done as non-root. At this point, setting up networking requires a suid helper. After the network is setup, everything is non-privileged.
FreeBSD/NetBSD have system call interception. That's how their Linux/BSDi/etc "emulation" works.
Could you point me at the code in the kernel that implements it? Or anything on a FreeBSD system that uses it?
I looked at the FreeBSD system call path and saw no sign of any kind of tracing or interception. Also, the ptrace headers contain nothing resembling PTRACE_SYSCALL, and strace doesn't exist on the system I looked at.
How hard would it be to make Linux do that? I'd think that User Mode Linux would be a very good start.
Shouldn't be too hard. The host OS needs the ability to intercept and annull system calls. There are some other things which would be nice to have, but probably can be worked around if they're not there.
NT allegedly has the capabilities, 98 is iffy, and 95 is out. I've looked at FreeBSD (and one other, I think NetBSD) and they don't seem to have system call interception. I don't know about the other Unices.
> However, valuable as UMK is for some > applications, it's (yet) not in the same league > as mainframe partitioning.
True enough. I never claimed I was creating the next VM.
> UMKs, too, can be upgraded, but if the real > kernel has to be upgraded, the whole > machine goes down.
Yup. But if you ever have a setup where essentially everything is inside a UMK, and the hosting kernel is stripped down to the point that it's just providing processes, device drivers, and a filesystem, then you can run that forever, and just upgrade the UMKs.
> How well does the UMK protect the underlying > real kernel (and thus other user-space apps) > for excessive resource consumption? For > example, what if an errant application running > in an active UMK (or just buggy code in the > kernel used by the UMK) starts spawning threads > like crazy, will the UMK protect the rest of > the real machine from adverse effects?
The UMK, just like a native kernel, runs in a constant amount of memory. You configure it with 64M, that's all it will ever use. You configure it with 4 processors, it will never have more than four processes running at once. So, you can protect the native kernel from excessive resource consumption by sticking things inside a virtual machine.
> The UMK kernel, valuable as it is, is still > limited in it's ability to differ from the true > underlying kernel.
No it's not.
> For example, can a kernel within a UMK provide a > different thread-scheduling policy that the > underlying real kernel?
You seem to think that the UMK is somehow not a full kernel. It is. The underlying kernel is just a provider of resources. If a new version of the kernel provided a funky new scheduling policy, UMK would support it, regardless of what is supported by the underlying kernel.
> However, my whole point is to emphasize how in > IBM's mainframe environment complete isolation > of distinct partitions is very easy
Yeah. Nothing comes close. Not even Linux plus UMK. Maybe this is a small step in that direction and maybe some people will find that useful, but there is a long way to go.
> efforts such as the User Mode Kernel do not > achieve quite the same results: the "partitions" > or "user mode kernels" still share the same > underlying kernel data structures. If one UMK > craps out, it could potentially bring down the > whole machine.
Wrong. If one umk craps out, it affects nothing else. Every umk has its own data structures, completely separate from every other kernel on the system.
> It seems to me to be like a VMWare that only > does Linux (to put it simplistically).
That's sort of the effect from the user's point of view, but if I understand vmware, it slides underneath the two OS's and makes them run side-by-side with one appearing in a window in the other. With the user-mode port, it is really Linux inside Linux. If you run it and do a ps, you will see a whole bunch of "linux" processes, plus what they really are inside the virtual machine.
> trying out new > kernels/distributions/configurations without > needing to mess with your current setup.
This part is fun. The kernel boots out of a file in your normal filesystem. I've got Red Hat, Debian, Slackware, and SuSE filesystems. This makes it a lot easier to play with new distros.
> One also wonders then if Linux could be ported > to other call interfaces
There's been talk of a windows port. According to one of the guys on my mailing lists, 95 is out, but 98 and NT look possible. The really important thing is the ability to intercept and annull system calls. If that's there, everything else can probably be made to work.
Sorry about the blatant self-promotion here, but if you want to run the new kernel, but don't have a spare machine and are worried about what it might do, check out my user-mode port. It is the 2.3.51 kernel running in a set of Linux processes. No need for a spare machine, and it doesn't have access to your hardware or filesystems, so it's less worrisome than a native kernel. Downloads are available here. Jeff
This is something I've been thinking about for a while. I might give a go once my current project (the user-mode kernel port) settles down.
This my current thinking on cfs (cluster fs)
All members of the cluster share a filesystem, which potentially uses all the available storage on the cluster (although you might want to keep stuff like your home directory on a separate device that you don't share with the cluster).
Files are duplicated on multiple machines for speed and redundancy. Files will tend to be located on the machines that are accessing them, so most I/O is local.
cfs will just be the networking part. Local storage will be handled by a local fs (like ext2). cfs metadata will be stored in local files with funky names (which are made invisible by cfs anyway)
There are multiple levels of membership in a cluster. Primary members can read and write everything. Secondary members can only read. They can have read copies of files locally, but they can't hand those out to other machines. Machines wanting to read a file have to go to a primary member for a copy. This is for sysadmins who don't necessarily trust their users to prevent them from becoming root and modifying files (like/etc/passwd) behind the back of cfs and then handing the new/etc/passwd out to everybody else.
Machines can be members of multiple clusters./etc might come from a cluster that everyone is a member of,/bin might come from a cluster of machines of the architecture,/projects might come from a third cluster, etc.
Files can be marked "local" which means that they permanently live on that machine, override whatever file comes from the cluster, and aren't shared with the cluster. This would be useful for config files which are only relevant to your machine, or your email directory.
A machine's/dev would mapped into the cluster filesystem as/dev/aa.bb.cc.dd/ rather than being marked local. This gives transparent access to every device in the cluster.
A machine which a writing a file is designated the file's owner. While writes are in progress, all reads have to go to that machine. Once the writes have stopped, the machine remains the owner, but it can start spreading the new data around the cluster. It can also designate secondary owners, who would come into play if the primary owner crashes. One of them would become the new owner. If it turns out that the old owner had changes which it didn't manage to propagate and the new owner made changes, then my current thinking is that this is brought to the attention of a human, who straightens things out. If this is not acceptable for a particular file for some reason, then that file can be marked in such a way that accesses to it hang or fail until the owner comes back.
Slashdot Mirror
Unfortunately, it's been somewhat dormant over the last few months as the people working on it have had other demands on their time.
Jeff
If you're interested in helping, contact me or him at karrde at callisto.yi.org.
Jeff
Actually people have thought about it. No one has coughed up any actual code, though.
Jeff
Everything except access to the host networking can be done as non-root. At this point, setting up networking requires a suid helper. After the network is setup, everything is non-privileged.
Jeff
Could you point me at the code in the kernel that implements it? Or anything on a FreeBSD system that uses it?
I looked at the FreeBSD system call path and saw no sign of any kind of tracing or interception. Also, the ptrace headers contain nothing resembling PTRACE_SYSCALL, and strace doesn't exist on the system I looked at.
Jeff
Shouldn't be too hard. The host OS needs the ability to intercept and annull system calls. There are some other things which would be nice to have, but probably can be worked around if they're not there.
NT allegedly has the capabilities, 98 is iffy, and 95 is out. I've looked at FreeBSD (and one other, I think NetBSD) and they don't seem to have system call interception. I don't know about the other Unices.
Jeff
> However, valuable as UMK is for some
> applications, it's (yet) not in the same league
> as mainframe partitioning.
True enough. I never claimed I was creating the next VM.
> UMKs, too, can be upgraded, but if the real
> kernel has to be upgraded, the whole
> machine goes down.
Yup. But if you ever have a setup where essentially everything is inside a UMK, and the hosting kernel is stripped down to the point that it's just providing processes, device drivers, and a filesystem, then you can run that forever, and just upgrade the UMKs.
> How well does the UMK protect the underlying
> real kernel (and thus other user-space apps)
> for excessive resource consumption? For
> example, what if an errant application running
> in an active UMK (or just buggy code in the
> kernel used by the UMK) starts spawning threads
> like crazy, will the UMK protect the rest of
> the real machine from adverse effects?
The UMK, just like a native kernel, runs in a constant amount of memory. You configure it with 64M, that's all it will ever use. You configure it with 4 processors, it will never have more than four processes running at once. So, you can protect the native kernel from excessive resource consumption by sticking things inside a virtual machine.
> The UMK kernel, valuable as it is, is still
> limited in it's ability to differ from the true
> underlying kernel.
No it's not.
> For example, can a kernel within a UMK provide a
> different thread-scheduling policy that the
> underlying real kernel?
You seem to think that the UMK is somehow not a full kernel. It is. The underlying kernel is just a provider of resources. If a new version of the kernel provided a funky new scheduling policy, UMK would support it, regardless of what is supported by the underlying kernel.
> However, my whole point is to emphasize how in
> IBM's mainframe environment complete isolation
> of distinct partitions is very easy
Yeah. Nothing comes close. Not even Linux plus UMK. Maybe this is a small step in that direction and maybe some people will find that useful, but there is a long way to go.
Jeff
> efforts such as the User Mode Kernel do not
> achieve quite the same results: the "partitions"
> or "user mode kernels" still share the same
> underlying kernel data structures. If one UMK
> craps out, it could potentially bring down the
> whole machine.
Wrong. If one umk craps out, it affects nothing else. Every umk has its own data structures, completely separate from every other kernel on the system.
Jeff
>That's simply not true. If you have win98 running
>in Linux, then VMWare is a Linux process that
>emulates a virtual machine for win98.
So, if you do a ps, you will see a process that has win98 running inside it? Cute.
In that case, that is fairly similar in effect to the user-mode port. The basic design is entirely different, though.
Jeff
> It seems to me to be like a VMWare that only
> does Linux (to put it simplistically).
That's sort of the effect from the user's point of view, but if I understand vmware, it slides underneath the two OS's and makes them run side-by-side with one appearing in a window in the other. With the user-mode port, it is really Linux inside Linux. If you run it and do a ps, you will see a whole bunch of "linux" processes, plus what they really are inside the virtual machine.
> trying out new
> kernels/distributions/configurations without
> needing to mess with your current setup.
This part is fun. The kernel boots out of a file in your normal filesystem. I've got Red Hat, Debian, Slackware, and SuSE filesystems. This makes it a lot easier to play with new distros.
> One also wonders then if Linux could be ported
> to other call interfaces
There's been talk of a windows port. According to one of the guys on my mailing lists, 95 is out, but 98 and NT look possible. The really important thing is the ability to intercept and annull system calls. If that's there, everything else can probably be made to work.
Jeff
Sorry about the blatant self-promotion here, but if you want to run the new kernel, but don't have a spare machine and are worried about what it might do, check out my user-mode port.
It is the 2.3.51 kernel running in a set of Linux processes. No need for a spare machine, and it doesn't have access to your hardware or filesystems, so it's less worrisome than a native kernel.
Downloads are available here.
Jeff
Which version are you using?
Can I have a look at the console output?
As far as I know, the latest (2.3.36) user-mode kernel is stable. If you know otherwise, then tell me what's happening, and I'll fix it.
Jeff
This is something I've been thinking about for a while. I might give a go once my current project (the user-mode kernel port) settles down.
This my current thinking on cfs (cluster fs)
All members of the cluster share a filesystem, which potentially uses all the available storage on the cluster (although you might want to keep stuff like your home directory on a separate device that you don't share with the cluster).
Files are duplicated on multiple machines for speed and redundancy. Files will tend to be located on the machines that are accessing them, so most I/O is local.
cfs will just be the networking part. Local storage will be handled by a local fs (like ext2). cfs metadata will be stored in local files with funky names (which are made invisible by cfs anyway)
There are multiple levels of membership in a cluster. Primary members can read and write everything. Secondary members can only read. They can have read copies of files locally, but they can't hand those out to other machines. Machines wanting to read a file have to go to a primary member for a copy. This is for sysadmins who don't necessarily trust their users to prevent them from becoming root and modifying files (like /etc/passwd) behind the back of cfs and then handing the new /etc/passwd out to everybody else.
Machines can be members of multiple clusters. /etc might come from a cluster that everyone is a member of, /bin might come from a cluster of machines of the architecture, /projects might come from a third cluster, etc.
Files can be marked "local" which means that they permanently live on that machine, override whatever file comes from the cluster, and aren't shared with the cluster. This would be useful for config files which are only relevant to your machine, or your email directory.
A machine's /dev would mapped into the cluster filesystem as /dev/aa.bb.cc.dd/ rather than being marked local. This gives transparent access to every device in the cluster.
A machine which a writing a file is designated the file's owner. While writes are in progress, all reads have to go to that machine. Once the writes have stopped, the machine remains the owner, but it can start spreading the new data around the cluster. It can also designate secondary owners, who would come into play if the primary owner crashes. One of them would become the new owner. If it turns out that the old owner had changes which it didn't manage to propagate and the new owner made changes, then my current thinking is that this is brought to the attention of a human, who straightens things out. If this is not acceptable for a particular file for some reason, then that file can be marked in such a way that accesses to it hang or fail until the owner comes back.
You should have stopped right there, while you were still ahead.