First page Back Continue Last page Overview Graphics
UML Address space : Background
UML present in process address spaces
- Removes .5G (or more) from address space
- Writeable unless 'jail' is enabled
- 'jail' implementation is bogus
UML restricted (by default to .5G)
- constraining for some purposes
- emulating lots of disk
- Heavy COWing => lots of kernel VM consumption
Notes:
This arrangement is similar to the situation on the x86 host, which by default takes the upper 1G of the process address space, leaving 3G for the process.
UML removes another .5G of address space, which is painful for applications which want as much address space as they can get.
Also, unless 'jail' is enabled, UML kernel memory is writable, allowing a process to escape UML control if it knows what to change. The problem with making 'jail' the default is that it is extremely slow. It is implemented by write-protecting kernel memory on kernel exit and write-enabling it on kernel entry. On top of being very slow, this is complicated and subtle code, which was tough to get right,
This also constrains the size of UML virtual memory. This is a problem for some applications of UML. In particular, this will make it hard to make UML fake TB of disk. This would be done by COWing a relatively small amount of host disk space thousands of times. The problem is that the COW bitmaps are stored in UML virtual memory, and that will be the bottleneck. The limitation on the amount of disk that can be emulated will be the amount of virtual memory available for storing the COW bitmaps.