Site Home Page
The UML Wiki
UML Community Site
The UML roadmap
What it's good for
Case Studies
Kernel Capabilities
Downloading it
Running it
Compiling
Installation
Skas Mode
Incremental Patches
Test Suite
Host memory use
Building filesystems
Troubles
User Contributions
Related Links
Projects
Diary
Thanks
Contacts
Tutorials
The HOWTO (html)
The HOWTO (text)
Host file access
Device inputs
Sharing filesystems
Creating filesystems
Resizing filesystems
Virtual Networking
Management Console
Kernel Debugging
UML Honeypots
gprof and gcov
Running X
Diagnosing problems
Configuration
Installing Slackware
Porting UML
IO memory emulation
UML on 2G/2G hosts
Adding a UML system call
Running nested UMLs
How you can help
Overview
Documentation
Utilities
Kernel projects
Screenshots
A virtual network
An X session
Transcripts
A login session
A debugging session
Slackware installation
Reference
Kernel switches
Slackware README
Papers
ALS 2000 paper (html)
ALS 2000 paper (TeX)
ALS 2000 slides
LCA 2001 slides
OLS 2001 paper (html)
OLS 2001 paper (TeX)
ALS 2001 paper (html)
ALS 2001 paper (TeX)
UML security (html)
LCA 2002 (html)
WVU 2002 (html)
Security Roundtable (html)
OLS 2002 slides
LWE 2005 slides
Fun and Games
Kernel Hangman
Disaster of the Month

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.

Hosted at SourceForge Logo