[linuxkernelnewbies] skas mode

[Peter Teoh]

http://user-mode-linux.sourceforge.net/old/skas.html skas mode Introduction Traditionally, UML has had the following design 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 address space This was forced by the limited support for UML in Linux and has a number of problems 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. 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. 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. Using skas mode 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 download page. 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 mode. Skas effects on UML 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. Skas effects on the host 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 The UML kernel thread, which runs in the separate kernel address space, executes kernel code, and does system call interception on UML processes 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 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. Skas present 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. Skas future 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 kernel pools.