A holistic approach that accelerates your current vision while also making you future-proof. We help you face the future fluidically.
Digital Engineering

Value-driven and technology savvy. We future-proof your business.

Intelligent Enterprise
Helping you master your critical business applications, empowering your business to thrive.
Experience and Design
Harness the power of design to drive a whole new level of success.
Events and Webinars
Our Event Series
Featured Event
23 - 26 Jun
Booth #1692, Colorado Convention Center, Denver
Our Latest Talk
By Kanchan Ray, Dr. Sudipta Seal
video icon 60 mins
Discover more about us,
an outstanding digital
solutions developer and a
great place to work in.
Financial information,
governance, reports,
announcements, and
investor events.
News &
press releases
Catch up to what we are
doing, and what people
are talking about.
Caring &
We care for our world.
Learn about our ESG


Beyond Agility, the convergence of technology and human ingenuity.
talk to us
Welcome to digital product engineering
Thanks for your interest. How can we help?
Thomas Roka-Aardal
Thomas Roka-Aardal

A story about nostalgia, freedom, and laptops

This blog is a follow-up to part 1 of this two-part blog post, written after a couple of years of use and experience.

After living with the Librem setup mentioned in part 1 for quite some time, I felt that I wanted to learn even more, and I noticed that our security experts were using virtualization a great deal. Not just to run various operating systems on the same machine, but also to isolate certain things from others. For example, having a pentesting virtual machine (VM) with the relevant tools installed to be able to spin up and use without it messing up their development environment. Other reasons for using VMs could be to have more control over the operating system, where a certain VM could be trusted only for some things, and others could be trusted for more — almost like “isolation layers”. Thinking further ahead, those isolated components could be even more fine-grained, such as for a single application or for hardware devices, networking, etc.

And once I started researching that, I found the Qubes OS project ( Based on research from 2010, the project defines a new computing platform based on bare-metal virtualization (Xen) and modern technologies such as VT-d and Trusted Execution Technology to create a complete compartmentalized operating system. (Note: To run Qubes you need supported hardware — check out this link to run it yourself)

If your browser is compromised today because of a certain exploited bug, the operating system is usually not able to protect the rest of your system. Also, if something lower in the stack (like your network driver) gets compromised, something running on top of it cannot be easily defended.

The Qubes research project decided that modern operating systems are so complex and intertwined that they simply cannot be made secure. The project took “VM isolation” to another level and paved the way for choosing how to separate various computing, storage, device, and networking components.

Illustration depicting Qubes OS Architecture from early research_computer OS securityThe Qubes OS architecture from their early research


Using the isolation approach, a user can define certain VMs which are given different levels of trust, and the Qubes OS makes sure the VM interaction is prohibited or strictly controlled. In the above diagram from the 2010 research paper, the VMs are given colors to represent risk, so the “red” VM is used for insecure things like surfing the internet on various sites. The “yellow” VM could be your business apps, e-mail, etc. And the “green” could be your banking VM with a secure SSH key, perhaps. So far, so good. But what does this look like in practice, and can it really be productive?

Before answering that, let’s look at how Qubes OS of 2021 has evolved:

Illustration depicting Qubes OS virtual machine landscape in 2021Landscape and trust levels of the Qubes OS virtual machine


The operating system has an administrative VM (called “dom0”), a bare-bones OS running the Xen hypervisor and having access to the lower-level hardware. It is very limited because any vulnerability there might spread easily to the other VMs due to its somewhat elevated access and control.

Then there is the GuiVM, which controls the display and graphics hardware. Above it are VMs one can create for any purpose — there is a concept of a “template VM”, almost like a VM golden image, which you can use as a template for “AppVMs”, which are the VMs you run and use. The template VMs can be spun up, but that is only so they can be configured as you want, so your App VMs have what they need. Anything in the Template VM is available to all App VMs using that template.

Then there are certain VMs which the Qubes OS system has prepared for special purposes. You can choose from these VMs to use if you want — and these are very interesting: the “sys-net” VM (for networking), “sys-firewall” VM (for firewall rules), “sys-usb” VM (for USB device access), and the “sys-whonix” VM (for anonymous access to the internet). All of these are also VMs that can be modified, upgraded, changed, copied, etc.

When you then create an AppVM, you choose a Template VM (templates can be any operating system you can install, like “Windows 7”), select which VM should provide networking, which one should provide upgrades, and more. In this way, you can create endless combinations and complexity (or simplicity) in your VMs and isolation.

The “sys-whonix” VM is a very interesting one. Qubes has mentioned in its research that “fingerprinting” is a serious privacy issue that is very difficult to avoid. Mechanisms out there try to look at every single little breadcrumb we leave behind, piece a lot of those together, and find out who we are (or as close to that as is practical) even though we have taken many precautions. This VM uses the Tor browser and network to route internet traffic and is used by special Qubes VMs for upgrades. That means when you do your “apt upgrade” or your Microsoft update, it can route you through anonymous channels to avoid as much fingerprinting as possible, which you would normally leave behind in your default VM.

Being anonymous on the internet is hard, sometimes (for certain sites) impossible, and in some cases, not even desirable. But the ability to be as anonymous as possible is definitely a value we should cherish and protect. I also want to add that it doesn’t help to just “anonymize” your laptop configuration (even though you do things like randomize your hex device codes and more) if you are still leaking DNS information or want to filter information. If you want to look into this, check out using Pi-hole or other similar sandboxes for more DNS control.

Getting back to the thread — now, with modern technology, it is possible (as many virtualization vendors already do) to present virtualized apps “natively” in a single desktop environment.

Isolating VMs but keeping them integrated from a desktop perspective_Qubes OSIsolating VMs but keeping them integrated from a desktop perspective


Qubes integrates and displays the separate VM apps on your desktop while still enforcing the isolation rules in place for each of them. For example, if you try to “copy-paste” between them, rules kick in and ask you if this is what you really mean (if at all enabled).

To visualize this even more, Qubes gives you the ability to assign a specific color to your individual VMs. This color is reflected in all applications running under that VM, showing you physically that these are different, isolated components.

1_Ope0QoOKDHyH-g8Sj3OY3gExample of applications running in different VMs with different colored frames


Imagine creating a complete stack of template VMs, which use a certain networking stack, another stack that uses a completely different networking setup, a specific VPN, etc. And because of the isolation, you are not routing your network through the customer VPN for your business email (subject to certain hardware limitations). Amazing!

Also, storage is equally isolated and partitioned so that there is no “shared disk”; everything is either direct storage or through another VM. So, whether you want to isolate based on work vs. personal, secure vs. insecure, travel vs. home is entirely up to you.

Illustration depicting example of custom VM configuration for work, personal, shopping, etc.Example of custom VM configuration for work, personal, shopping, etc.


By the way, these kinds of setups are often used by security professionals, as mentioned initially, since they provide many benefits for them. They also allow you to do ethical hacking where you will need to avoid any form of cross-contamination between customer environments and many other use cases involving isolation. All you need to do is to throw away the compromised VM and fire up a new one.

Another very cool thing is the concept of “disposable” VMs. Such a VM works like any other VM, except that when it is stopped, everything is removed. These VMs usually have very limited privileges but are extremely useful for things like reading a USB drive that could contain malicious code or browsing a potentially harmful website. You can be reasonably confident that whatever happens, nothing can harm the rest of your VMs, and once you kill it, it is gone.

So, I went for this setup on my Purism laptop: Librem hardware, the Heads anti-evil-maid setup, and the Qubes operating system. While the combination did work, it took a little while to get used to, and I must admit the threshold is a little high for a newbie. But after using Qubes for a while, I really liked it, and just like the Librem laptop, it makes for very good conversation once people see weird desktop things like different colored window frames.

After the setup was tried and tested for a while, I found the first thing I wanted to do was to have a more customized template VM setup. I created multiple Debian and Windows templates for various use cases. Note that Windows 10 is not a huge fan of Xen and needs full virtualization, which eats more resources. The “pass-through” hardware functionality is also not ideal, so if you depend on a certain VM for doing Teams calls, it could be a case of hit-and-miss as to whether your webcam works.

I created various work and personal VMs, and used different ones for various customer engagements or for similar requirements. All in all, very interesting and a steep but valuable learning curve, and one that worked quite well in a business setting for a year.

Using Qubes on the Librem worked fairly well but there were a couple of things for me that ultimately made me switch back to PureOS:

  • Xen does not like hibernation, so the VMs never go to sleep, which means if you are moving around with a laptop a lot, you will need power.
  • Qubes isolation restrictions can be annoying for normal usage. Simple things like changing the desktop background image need to be done on the dom0 (most trusted) VM, which is highly discouraged.
  • If something stops working (like the microphone) for some reason, it won’t come back unless you reboot. This might be due to my somewhat non-standard hardware, but it made me less productive and more stressed.

Also, to be honest, my threat model really does not require me to go this far, so there is no real need for me to live with this restricted setup. But I do understand the use cases for our pentesters, journalists, and those who really have that kind of threat model to deal with.
So Qubes OS is not really for the faint of heart, but I can definitively recommend a great learning experience for those interested. For more information, look at the main website at and the various sites (like on Reddit) that discuss Qubes and privacy.



All images © 2021 The Qubes OS Project and others

Originally published here.

Thomas Roka-Aardal
Thomas Roka-Aardal