Within the pdf document, there is a description that shows a comparison of different
implementations of Xen and KVM. The Nexen version has a domain acting as ‘Secure Monitor’
which in theory could be an implementation of HVMI (Hypervisor Memory Introspection). This is the
lowest level module.
Another slice is shared services which would likely be a domain for IPC (Inter Process Communication)
which I guess would be a qrexec domain. This sits above the secure monitor. Each VM has it’s own slices
which hold data separately outside the VM.
Therefore, Nexen decomposes Xen into per-VM slices that
are naturally sandboxed from all other components in the
system. Each Xen slice is bound to one VM and serves only
this VM. VMs will only interact with their own Xen slice
during runtime. Xen slices share code but each has its own
data. They are the least privileged internal domains, and errors
in one Xen slice are not considered dangerous to the whole
system or other VMs.
Unfortunately, a simple decomposition of all functionality
into slices is untenable because subsets of functionality interact
across slice boundaries. High frequency privilege boundary
crossing cause high performance degradation. So we create
a single, slightly more privileged shared service domain—but
still not as privileged as the security monitor. Deciding what
to place in per-VM slices and the shared services domain is
non-trivial and one of the key contributions of this work
The primary goal of Nexen is to enhance Xen’s security by
deconstruction. To do this Nexen provides the core abstraction
of a slice to represent internal domain. Nexen extends the
monitor to provide a set of basic functionality that is required
to securely create, manage, and permit interactions between
internal domains. As shown by our vulnerability analysis,
isolation and minimizing privileges are effective ways to limit
the attack surface and control the damage.
Nexen enables two types of internal domains. The global
shared service and per-VM Xen slices. Components like the
scheduler and domain management are placed in the shared
service while functions related to only one VM, e.g., code
emulation and nested page table management, are replicated
to each Xen slice.
Internal Domain API: Nexen provides an internal do-
main to the shared service for the management of slices.
Shared service and the monitor are built as the system boots.
All Xen slices must be built by explicitly calling the following
interfaces provided by the monitor.
This sounds great: “We have implemented a prototype of our design which can correctly handle 107 out of 144 vulnerabilities (74%). The performance evaluation results also indicate that the overhead is negligible.”
However, the paper is from 2016 and I can’t find any more recent news about Nexen.
@huaopeng I’ve tried to collect some of your related ‘hardening’ threads into this one. Please refrain from starting any more.
You have elected to create more redundant threads (reproducible builds, dom0 distributions) that I don’t think can be harmonized at this point without becoming even more confusing.
Your enthusiasm is appreciated but please reflect before posting:
Is it on-topic? … directly relevant to Qubes OS implementation or usage?
Is there already a thread discussing it?
Does it add anything of value to the conversation?
Is it an actual support issue or a general discussion item?
Why don’t you get the Qubes Builder going and use grep?
You want to discuss details of the XEN version used in Qubes OS, yet the relatively simple task of finding out whether ‘the Xen version used by qubes’ is ‘compiled with it the XSM-FLASK module’ requires you to start yet another thread? Hm.
I’ll move this into the ‘hardening bin’ created for you.
Well, I haven’t actually checked myself, but my expectation is that Xen gets compiled as part of the Qubes OS build process. Hence I expect you’ll be able to see the sources and how they are configured to be build.
I might do this myself tomorrow to follow along. Not sure there is a point to this inquiry but it seems worth it just to prove a point and for the experience.
The point, if I may, is to check whether or not the XSM-FLASK security module is available to QubesOS users and if they are able to create their own security policies similar to SELinux as described here:
We’ve discussed securing various codebases outside of the hypervisor. But what about Xen itself? Both PV and HVM guests can attack Xen itself through the hypercall interface. While the Xen developers try to be very careful with the security of the hypercall interface, and now regularly do “fuzz testing” on it to discover potential vulnerabilities, it is inevitable that they will make some mistakes.
One of the ways to mitigate mistakes in the hypercall layer is to use the Xen Security Module (XSM) with FLASK. FLASK is a plugin for XSM written by the NSA, and is Xen’s analog of the SELinux security framework. It allows you to load policies to restrict what hypercalls a VM can try to make. Although this doesn’t guarantee that no vulnerabilities will be exposed, by restricting what hypercalls are valid, it reduces the probability of an exploitable vulnerability significantly.
FLASK is a mature piece of software, but writing policies is a very tricky and difficult task – not for the faint of heart. Xen does come with a useful set of “example” policies, which cover most roles that a typical installation would need to use; including driver domains, normal domains, stub domains, and so on. However, these example policies are not heavily tested; they should be used at your own risk.
The basic steps to use FLASK’s example policies are as follows:
Build Xen with XSM enabled
Build the example policy
Add the appropriate “labels” to the VM config files, using seclabel=[$foo], based on their role.
Please STOP creating new threads for every thought that comes to your mind. If it has to do with hardening, please post into THIS thread.
Why don’t you check? I’ve previously pointed you to the Qubes Builder. I am not sure there can be one answer for all of Qubes OS. One would expect that the kernel parts use GCC. This thread seems to indicate that at least some parts are build with GCC.
I really like your questions @huaopeng but I don’t think you’ll get any feedback worthwhile here. Maybe try asking some of them in the #qubes channel or maybe send a summary of questions as an email to qubes-devel?
Maybe state your purpose a bit more clear? Are you doing research? What’s your aim?
This forum is primarily a user community. While many here might be interested in the answers to your questions, very few will be qualified to provide any. That’s why you haven’t gotten that much feedback and I and others have tried to channel your inquires into one thread as to not overload the category with threads no one has an answer to.