Traditionally, UML has had the following design
This was forced by the limited support for UML in Linux and has a
number of problems
each UML process gets a process on the host
there is a special thread, the tracing thread, which does system call
tracing on the UML processes
the tracing thread nullified system calls, and caused the process to
enter the UML kernel, which is mapped into the upper part of its
During the fall of 2002, I started fixing these problems by adding
support in the host Linux for features that would solve these
problems. The result is now stable, and is being used by a number of
people with good results.
The UML kernel is present in the address space of each of its
processes, and, by default, is writeable. This is obviously a
security problem, since, with write access to kernel data, a process
can break out to the host. UML's 'jail' mode fixes this problem by
making UML data readonly while a process is running, but this imposes
a huge performance penalty. Also, the kernel is still there, and can
be read, so this isn't acceptable for honeypots, since a bad guy can
easily tell that the system is a UML.
UML uses signals to force control to the UML kernel during a system
call or interrupt. Signal delivery and return are slow, and impose a
noticable performance hit.
In short, the changes cause the UML kernel to run in an entirely
different host address space from its processes. This solves the
security and honeypot fingerprinting problems by making the UML kernel
totally inaccessible to UML processes. Their address spaces are
identical to what they would be on the host. This also provides a
noticable speedup by eliminating the signal delivery that used to
happen for every UML system call.
The old mode is now called 'tt mode', for Tracing Thread, and the new
mode is called 'skas mode', for Separate Kernel Address Space.
Skas mode requires that a patch be applied to the host kernel. This
patch implements the address space support needed by skas mode, plus
some additions to ptrace which are necessary. The patch is available
from the UML
These patches are against 2.4.19, but are fairly non-intrusive, and
should apply to any nearby kernel. You should get the latest host skas
patch and run the latest UML on it. You should only use an older
host skas patch if you need to run an older UML for some reason.
With the patch applied to the host, all you need to do is make sure
that CONFIG_MODE_SKAS is enabled in UML, and run it. It will detect
the host support and use it. If the host support isn't there, it will
fall back to tt mode. It will also fall back to tt mode if it doesn't
detect a specific version of the host skas support. It will tell you
during the early boot which version it's looking for:
Checking for the skas3 patch in the host...found
Checking for /proc/mm...found
Once you see this, you're all set. UML is happily running in skas
This is simple - you shouldn't really notice any difference, except
for performance. Inside UML, skas mode causes no changes in
functionality. For most uses, you should see a noticable improvement
in performance. My favorite benchmark, a kernel build, is almost
twice as fast with skas mode as with tt mode, and is within 30% of the
host's time. Bill Stearns saw a script's running time drop from ~50
seconds to ~14 seconds, almost a quadrupling in speed.
You will notice some differences on the host. If you run ps, you will
notice only four processes per UML rather than the dozens that you see
in tt mode. They are
If you are running many UMLs on the host, and you convert them over to
skas mode, you will also notice a large reduction in the host load.
The UML server that I am most familiar with, which runs 25-30 UMLs at
any given time, reduced its typical load average from 2 - 5 with tt
mode to .1 - .5 with skas mode.
The UML kernel thread, which runs in the separate kernel address
space, executes kernel code, and does system call interception on UML
The UML userspace thread, which runs all UML process code and switches
between host address spaces on each UML context switch
The ubd driver asynchronous IO thread
The write SIGIO emulation thread
I know of only one bug in the current skas patch, which only affects
running nested UMLs as far as I know. I have been running the skas3
patch continuously since the fall with no problems. Other people
have, as well, and I've heard of no problems from them. It's
SMP-safe, and it's running stably on SMP hosts.
There is going to be a skas4 patch at some point. There will be no
real functional changes. The bug mentioned above will be fixed, and a
performance tweak or two will be added.
The major change will be the interface to the new stuff. Currently,
new address spaces are created by opening /proc/mm, and they are
modified by writing to the returned file descriptor. Linus hates this
interface (and I wasn't very fond of it, either). After some
discussion, he proposed adding two new system calls, one which creates
new address spaces, and another which executes an arbitrary system
call in the context of one of these address spaces.
The skas4 patch will implement these new system calls, and UML will
use them at that point. After that, when the patch has had some
testing, I will think about how and when to get it into the main