COOPERATIVE LINUX

A SEMINAR REPORT

BY

KABIRAT
HC202001

SUBMITTED TO
Mr Fashoro

DEPARTMENT OF COMPUTER SCIENCE,

SCHOOL OF APPLIED SCIENCES,
THE FEDERAL POLYTECHNIC EDE,
EDE, OSUN STATE, NIGERIA

December, 2023
 ABSTRACT

Software development for an embedded Linux system in most cases requires a free license of
GCC (GNU C/C++ compiler) and accessories. Many developers find it disconcerting that
the GNU tools are primarily available for Linux-based PCs. Any attempt to make GCC run
under Windows in order to program an embedded Linux system has been fraught with
problems until now. The popular Cygwin – as a Unix/Linux emulation environment under
Windows – is much too slow and in most cases causes significant library and version
conflicts. Despite the high costs, commercial attempts by some companies to provide GCC as
a Windows application have not lead to any practical solutions. Even here, there are
typically significant library problems. As a result, many users have no other alternative than
to use a Linux distribution as a second operating system on the Windows PC to be able to use
GCC tools. Without some effort, this technically straightforward solution is not feasible for
large companies in particular, because an IT department is responsible for the PCs. Users
are not able to just install a new operating system to boot instead of Windows.
In this report I will describe Cooperative Linux, a port of the Linux kernel that allows it to
run as an unprivileged lightweight virtual machine in kernel mode, on top of another OS
kernel. It allows Linux to run under any operating system that supports loading drivers, such
as Windows or Linux, after minimal porting efforts. The report includes the present and
future implementation details, its applications, and its comparison with other Linux
virtualization methods. Among the technical details I’ll present the CPU-complete context
switch code, hardware interrupt forwarding, the interface between the host OS and Linux,
and the management of the VM’s pseudo physical RAM.

2
1.0 INTRODUCTION

Cooperative Linux utilizes the rather underused concept of a Cooperative Virtual Machine
(CVM), in contrast to traditional VM’s that are unprivileged and being under the complete
control of the host machine.

The term Cooperative is used to describe two entities working in parallel, e.g. coroutines. In
that sense the most plain description of Cooperative Linux is turning two operating system
kernels into two big coroutines. In that Mode, each kernel has its own complete CPU context
and address space, and each kernel decides when to give control back to its partner.

However, only one of the two kernels has control on the physical hardware, where the other
is provided only with virtual hardware abstraction. From this point on in the report I’ll refer
to these two kernels as the host operating system, and the guest Linux VM respectively. The
host can be every OS kernel that exports basic primitives that provide the Cooperative Linux
portable driver to run in CPL0 mode (ring 0) and allocate memory.

The special CPL0 approach in Cooperative Linux makes it significantly different than
traditional virtualization solutions such as VMware, plex86, Virtual PC, and other methods
such as Xen. All of these approaches work by running the guest OS in a less privileged mode
than of the host kernel. This approach allowed for the extensive simplification of Cooperative
Linux’s design and its short early beta development cycle which lasted only one month,
starting from scratch by modifying the vanilla Linux 2.4.23-pre9 release until reaching to the
point where KDE could run. The only downside to the CPL0 approach is stability and
security. If it’s unstable, it has the potential to crash the system. However, measures can be
taken, such as cleanly shutting it down on the first internal Oops or panic. Another
disadvantage is security. Acquiring root user access on a Cooperative Linux machine can
potentially lead to root on the host machine if the attacker loads specially crafted kernel
module or uses some very elaborated exploit in case which the Cooperative Linux kernel was
compiled without module support.

Most of the changes in the Cooperative Linux patch are on the i386 tree— the only supported
architecture for Cooperative at the time of this writing. The other changes are mostly
additions of virtual drivers: cobd (block device), conet (network), and cocon (console). Most
of the changes in the i386 tree involve the initialization and setup code. It is a goal of the

3
Cooperative Linux kernel design to remain as close as possible to the standalone i386 kernel,
so all changes are localized and minimized as much as possible.

2.0 COLINUX FIRST IMPRESSION

The hardware virtualized by coLinux includes a VGA text console (that is displayed in a
Windows XP window), network, hard disk drives (as normal files under Windows) and a
keyboard. When selecting the virtual hardware, a configuration was consciously selected that
is as minimal as possible in order to avoid driver problems in Linux.

Fig 2.1: The coLinux VGA text console in Windows XP window

Figure 2.1 shows the interface of coLinux to be implemented on a Debian Linux under
Windows XP. Just a simple mouse click on the previously described icon on the Windows
XP desktop is needed to start the configuration. And in just a few seconds, a complete Debian
Linux is available in a Windows XP window. The username root and password root are used
to log in.

4
 Fig 2.2:Windows and coLinux use a common directory

Windows and coLinux use a common directory on the hard disk drive (c:\colinux from the
Windows environment – the same directory is accessible under coLinux under the
name/windows). Any files in the directory are accessible from both Windows and coLinux
(Figure 2.2). However, the common hard disk drive space is managed by Windows
exclusively. coLinux does not access the hard disk drive hardware directly. Consequently,
there is no need for a separate coLinux partition. A special driver (coFS = coLinux File
System) is used by coLinux to access the Windows hard disk drive.

It should be noted, however, that the coFS involves an asynchronous file system. Write
operations within the common directory under coLinux or Windows are closed from view of
the other operating system only after context is next switched (Surrendering control of the
CPU to Windows or coLinux). For this reason, no GCC make file should directly access/wind
ows under coLinux, if files are used by the make file that were previously written under
Windows.

2.1 SYSTEM REQUIREMENTS

CoLinux requires Windows 2000, XP, or Windows Server 2003 in order to work, although I
was unsuccessful at getting it to work under Windows Server 2003. I have yet to find out
why. These NT-based operating systems include support for asynchronous operations and
include security features not found in DOS-based versions of Windows. "Asynchronous
operations" is just a fancy way of saying that the computer can work on new tasks while
waiting for other tasks to complete rather than queuing tasks up.

5
coLinux also requires the use of the TAP-Win32 virtual Ethernet adapter driver. TAP-Win32
allows processes running under a Windows server to access that Windows server as if it were
accessing it over the network and vice-versa. This probably brings some insight into how
coLinux achieves its capability of appearing to run as a separate computer. The version of the
coLinux installer I used for this article installed the TAP-Win32 driver as a part of the
installation.

Winpcap is a utility for Windows that provides packet capture and analysis functions and is
offers programmers a way to directly access a packet driver independent of Microsoft's APIs.

coLinux can be configured to be bridged to a specific physical network adapter in host

computer. This is accomplished by making changes to the coLinux configuration file, as
discussed later. For this article, the TAP-Win32 driver is used, which is installed
automatically as a part of the coLinux installation.

As far as RAM and disk space go, this is where things get a little hairy with coLinux.
Depending on how things work out, coLinux can use anywhere from 16MB to 64MB of
RAM. In the docs, the authors use the phrase "It used to default to 29MB which was
sufficient for most things, now it seems to default to 64MB", which probably doesn't inspire a
whole lot of confidence.

This doesn't mean that a system with a total of 128MB of RAM will cut it. Operating system
need to be run and other required processes, so be sure to have sufficient physical RAM to
accommodate everything. Shoot for a minimum of 512MB, which, these days, shouldn't be
much of a problem.

For disk space, a partition is required with a few gigs available, just like for a normal Linux
server. Since coLinux works using disk images we can download, we can check the size of
the image we want to use to determine exact requirements. Officially supported distributions
include Gentoo, Debian, and Fedora Core in the 2.4 series kernel and just Gentoo and Debian
if we prefer to use a kernel based on Linux 2.6.

3.0 USES OF COOPERATIVE LINUX

Cooperative Linux in its current early state can already provide some of the uses that User
Mode Linux provides, such as virtual hosting, kernel development environment, research,
and testing of new distributions or buggy software. It also enabled new uses:

6
• Relatively effortless migration path from Windows.
In the process of switching to another OS, there is the choice between Installing another
computer, dual booting, or using a virtualization software. The first option costs money,
the second is tiresome in terms of operation, But the third can be the most quick and easy
method—especially if it’s free. This is where Cooperative Linux comes in. It is already
used in workplaces to convert Windows users to Linux.
• Adding Windows machines to Linux clusters.
The Cooperative Linux patch is minimal and can be easily combined with others such as
the MOSIX or Open-MOSIX patches that add clustering capabilities to the kernel. This
work in progress allows to add Windows machines to super-computer clusters, where one
illustration could tell about a secretary Workstation computer that runs Cooperative Linux
as a screen saver—when the secretary goes home at the end of the day and leaves the
computer unattended, the office’s cluster gets more CPU cycles for free.
• Running an otherwise-dual-booted Linux system from the other OS.
The Windows port of Cooperative Linux allows it to mount real disk partitions as block
devices. Numerous people are using this in order to access, rescue, or just run their Linux
system from their ext3 or reiserfs file systems.
• Using Linux as a Windows firewall on the same machine.
As a likely competitor to other out-of-the-box Windows firewalls, iptables along with a
stripped-down Cooperative Linux system can potentially serve as a network firewall.
• Linux kernel development / debugging / research and study on another operating systems.

Digging inside a running Cooperative Linux kernel, you can hardly tell the difference
between it and a standalone Linux. All virtual addresses are the Same—Oops reports look
familiar and the architecture dependent code works in the same manner excepts some
transparent conversions, which are described in the next section in this report.

3.1 WORKING OF COLINUX

Unlike in other Linux virtualization solutions such as User Mode Linux (or the
forementioned VMware), special driver software on the host operating system is used to
execute the CoLinux kernel in a privileged mode (known as ring 0 or supervisor mode).

By constantly switching the machine's state between the host OS state and the CoLinux
kernel state, CoLinux is given full control of the physical machine's MMU (i.e., paging and
protection) in its own specially allocated address space, and is able to act just like a native

7
kernel, achieving almost the same performance and functionality that can be expected from a
regular Linux which could have ran on the same machine standalone. Since CoLinux uses the
same binary format for user-space executables as native Linux, CoLinux can load and run an
existing unmodified Linux distribution concurrently with the host OS.

3.2 HARDWARE VIRTUALIZATION

To cooperatively share hardware with the host operating system, CoLinux does not access
I/O devices directly. Instead, it interfaces with emulated devices provided by the CoLinux
drivers in the host OS. For example, a regular file in Windows can be used as a block device
in CoLinux. All real hardware interrupts are transparently forwarded to the host OS, so this
way the host OS's control of the real hardware is not being disturbed and thus it continues to
run smoothly.

PORTABILITY

Unlike User Mode Linux, CoLinux always utilizes only one process of the host OS for all its
Linux processes, privately managing their scheduling, resources, and faults in a manner
which is contained and entirely independent of the way the host OS is implemented. In fact,
CoLinux only requires a very small set of commonly exported primitives from the host OS
kernel in order to work, thus, it can be rather easily ported to run under any operating system,
such as Solaris, or even Linux itself. CoLinux is being ported to run under ReactOS, a
standalone Open Source Windows implementation.

PLANNED FEATURES

Since Cooperative Linux is a new project (2004), most of its features are still waiting to be
implemented.

SUSPENSION

Software-suspending Linux is a challenge on standalone Linux systems, considering the

entire state of the hardware need to be saved and restored, along with the space that needs to
be found for storing the suspended image. On User Mode Linux suspending is easier— only
the state of a few processes needs saving, and no hardware is involved. However, in
Cooperative Linux, it will be even easier to implement suspension, because it will involve its
internal state almost entirely. The procedure will involve serializing the pseudo physical
RAM by enumerating all the page table entries that are used in Cooperative Linux, either by

8
itself (for user space and VMalloc page tables) or for itself (the page tables of the pseudo
physical RAM), and change them to contain the pseudo value instead of the real value. The
purpose of this suspension procedure is to allow no notion of the real physical memory to be
contained in any of the pages allocated for the Cooperative Linux VM, since Cooperative
Linux will be given a different set of pages when it will resume at a later time. At the
suspended state, the pages can be saved to a file and the VM could be resumed later.
Resuming will involve loading that file, allocating the memory, and fix-enumerate all the
page tables again so that the values in the page table entries point to the newly allocated
memory. 30 • Linux Symposium 2004 • Volume One Another implementation strategy will
be to just dump everything on suspension as it is, but on resume—enumerate all the page
table entries and adjust between the values of the old RPPFNs2 and new RPPFNs.

A suspended image could be created under one host OS and be resumed in another host OS
of the same architecture. One could carry a suspended Linux on a USB memory device and
resume/suspend it on almost any computer.

USER MODE LINUX INSIDE COOPERATIVE LINUX

The possibility of running UML inside Cooperative Linux is not far from being immediately
possible. It will allow bringing UML with all its glory to operating systems that cannot
support it otherwise because of their user space APIs.

Combining UML and Cooperative Linux cancels the security downside that running
Cooperative Linux could incur.

LIVE COOPERATIVE DISTRIBUTIONS

Live-CD distributions like KNOPPIX can be used to boot on top of another operating system
and not only as standalone, reaching a larger sector of computer users considering the host
operating system to be Windows NT/2000/XP.

3.3 ADVANTAGES AND DISADVANTAGES

ADVANTAGES

 coLinux is a great way to use and experiment with Linux. Like Cygwin, it allows you to
develop and execute Linux applications on the Windows operating system (through

9
 CoLinux). You can also maintain the Linux operating system by installing, upgrading, or
removing applications with apt-get.
 Unlike Cygwin, you can execute Linux applications on CoLinux without rebuilding. In
this respect, CoLinux is a real Linux operating system that runs (or cooperates) with the
Windows operating system.
 Another interesting advantage of CoLinux is its portability. You can have a CoLinux
distribution with a custom set of applications on a given Windows host (within the root
file system). You can move the root file system to another host, and then restart it. This
allows for a mobile development platform where the compressed root file system fits on a
standard Universal Serial Bus (USB) memory stick.
 Finally, CoLinux is fast because it's essentially running on the native hardware.
DISADVANTAGES:
 The CoLinux runs aside the Windows kernel.
 It runs on the same hardware abstraction layer that is also called ring.
 Inside this CPU abstraction layer, there is no hardware memory protection.
 This is the same situation as between the Linux or Windows kernel and their device
drivers. So a problem in the Linux kernel can bring the Windows kernel down, if Linux
violates the Windows address space.
 Also there are security implications. If a malice user gains root access inside CoLinux he
can compromise the security of the Windows system as well. Also to load and use
CoLinux the user has to have administrator rights. (There is the possibility to start
CoLinux as a service, so it is possible to start CoLinux as a normal user, if the user has
been granted the right to start the service)
 The primary disadvantage of CoLinux is that it has the ability to crash the entire machine
(all cooperating operating systems) because the guest operating system runs in a
privileged mode in the host kernel. It also has some dependencies on external software for
normal operation (windows and networking support). Outside of this, it's quite easy to
install and configure. In the many hours that I've used it, I've never seen a crash.

3.4 DESIGN OVERVIEW

This section describes the basic methods behind Cooperative Linux, which include complete
context switches, handling of hardware interrupts by forwarding, physical address translation
and the pseudo physical memory RAM.

10
3.4.1 Device Driver

The device driver port of Cooperative Linux is used for accessing kernel mode and using the
kernel primitives that are exported by the host OS kernel. Most of the driver is OS
independent code that interfaces with the OS dependent primitives that include page
allocations, debug printing, and interfacing with user space.

When a Cooperative Linux VM is created, the driver loads a kernel image from a vmlinux
file that was compiled from the patched kernel with CONFIG_COOPERATIVE. The
vmlinux file doesn’t need any cross platform tools in order to be generated, and the same
vmlinux file can be used to run a Cooperative Linux VM on several OS uses of the same
architecture.

The VM is associated with a per-process resource—a file descriptor in Linux, or a device

handle in Windows. The purpose of this association makes sense: if the process running the
VM ends abnormally in any way, all resources are cleaned up automatically from a call back
when the system frees the per- process resource.

3.4.2 Pseudo Physical RAM

In Cooperative Linux, we had to work around the Linux MM design assumption that the
entire physical RAM is bestowed upon the kernel on startup, and instead, only give
Cooperative Linux a fixed set of physical pages, and then only do the translations needed for
it to work transparently in that set. All the memory which Cooperative Linux considers as
physical is in that allocated set, which we call the Pseudo Physical RAM.

The memory is allocated in the host OS using the appropriate kernel function— alloc_pages()
in Linux and MmAllocatePagesForMdl() in Windows— so it is not mapped in any address
space on the host for not wasting PTEs. The allocated pages are always resident and not freed
until the VM is downed.

Page tables are created for mapping the allocated pages in the VM’s kernel virtual address
space. The VM’s address space resembles the address space of a regular kernel—the normal
RAM zone is mapped contiguously at 0xc0000000.

The VM address space also has its own special fix maps—the page tables themselves are
mapped at 0xfef00000 in order to provide an O(1) ability for translating PPRAM (Pseudo-
Physical RAM) addresses to physical addresses when creating PTEs for user space and

11
vmalloc() space. On the other way around, a special physical-to-PPRAM map is allocated
and mapped at 0xff000000, to speed up handling of events such as pages faults which require
translation of physical addresses to PPRAM address. This bi-directional memory address
mapping allows for a negligible overhead in page faults and user space mapping operations.

3.4.3 Context Switching

The Cooperative Linux VM uses only one host OS process in order to provide a context for
itself and its processes. That one process, named colinux- daemon, can be called a Super
Process since it frequently calls the kernel driver to perform a context switch from the host
kernel to the guest Linux kernel and back. With the frequent (HZ times a second) host kernel
entries, it is able able to completely control the CPU and MMU without affecting anything
else in the host OS kernel.

On the Intel 386 architecture, a complete context switch requires that the top page directory
table pointer register—CR3—is changed. However, it is not possible to easily change both
the instruction pointer (EIP) and CR3 in one instruction, so it implies that the code that
changes CR3 must be mapped in both contexts for the change to be possible.

It’s problematic to map that code at the same virtual address in both contexts due to design
limitations—the two contexts can divide the kernel and address space differently, such that
one virtual address can contain a kernel mapped page in oneOS and a user mapped page in
another.

In Cooperative Linux the problem was solved by using an intermediate address space during
the switch. The intermediate address space is defined by a specially created page tables in
both the guest and host contexts and maps the same code that is used for the switch (passage
code) at both of the virtual addresses that are involved. When a switch occurs, first CR3 is
changed to point to the intermediate address space. Then, EIP is relocated to the other
mapping of the passage code using a jump. Finally, CR3 is changed to point to the top page
table directory of the other OS.

4.0 CONCLUSION

We have discussed how Cooperative Linux works and its benefits apart from being a
BSKH4, Cooperative Linux has the potential to become an alternative to User Mode Linux
that enhances on portability and performance, rather than on security. Moreover, the

12
implications that Cooperative Linux has on what is the media defines as ‘Linux on the
Desktop'—are massive, as the world's most dominant albeit proprietary desktop OS supports
running Linux distributions for free, as another software, with the aimed for possibility that
the Linux newbie would switch to the standalone Linux. As user friendliness of the Windows
port will improve, the exposure that Linux gets by the average computer user can increase
tremendously.

REFERENCES

http://www.reuters.com/article/2015/09/15/us-banks-blockchainidUSKCN0RF24M20150915
https://www.nasdaqprivatemarket.com/
http://chain.com/
http://www.makeuseof.com/tag/quantum-computers-end-cryptography/
http://risktech-forum.com/opinion/a-risk-based-view-of-why-banks-are-experimenting-with-
bitcoin-and-the-block
http://www.imponderablethings.com/2013/07/how-bitcoin-works-under-hood.html
http://www.imponderablethings.com/2013/07/how-bitcoin-works-under-hood.html
http://www.coindesk.com/blockchain-lottery-miners-rewarded/
E. Y. P. Gavin Wood(2017), \Ethereum: A secure decentralised generalised transaction
ledger."
Nir Kshetri,( 2017) "Can Blockchain Strengthen the Internet of Things?," IT Professional,
vol. 19, no. 4, pp. 68 – 72. Available: http://ieeexplore.ieee.org/document/8012302/
Don Tapscott and Alex Tapscott(2016), Blockchain Revolution: How the Technology Behind
Bitcoin Is Changing Money, Business, and the World, 1st ed. New York, USA: Penguin
Publishing Group.
Maaruf Ali and Mahdi H Miraz,( 2013) "Cloud Computing Applications," in Proceedings of
the International Conference on Cloud Computing and eGovernance - ICCCEG 2013,
Internet City, Dubai, United Arab Emirates, pp. 1-8, Available:
http://www.edlib.asdf.res.in/2013/iccceg/paper001.pdf
Mahdi H. Miraz,(2017) "Blockchain: Technology Fundamentals of the Trust Machine,"
Machine Lawyering, Chinese University of Hong Kong, Available:
http://dx.doi.org//10.13140/RG.2.2.22541.64480/2
G. W. Peters, E. Panayi, and A. Chapelle,(2015): “Trends in crypto-currencies and
blockchain technologies: A monetary theory and regulation perspective,”. [Online].
Available: http://dx.doi.org/10.2139/ssrn. 2646618

13