mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-10-01 01:25:40 -04:00
63 lines
3.0 KiB
Markdown
63 lines
3.0 KiB
Markdown
---
|
|
layout: doc
|
|
title: Developers' FAQ
|
|
permalink: /doc/devel-faq/
|
|
redirect_from:
|
|
- /en/doc/devel-faq/
|
|
- /doc/DevelFaq/
|
|
- /wiki/DevelFaq/
|
|
---
|
|
|
|
Qubes Developers' FAQ
|
|
=====================
|
|
|
|
Why does dom0 need to be 64-bit?
|
|
--------------------------------
|
|
|
|
Since 2013 [Xen has not supported 32-bit x86 architecture](https://wiki.xenproject.org/wiki/Xen_Project_Release_Features) and Intel VT-d, which Qubes uses to isolate devices and drivers, is available on Intel 64-bit processors only.
|
|
|
|
In addition, with features like improved ASLR, it is often more difficult to exploit a bug on x64 Linux than x86 Linux.
|
|
While we designed Qubes from the beginning to limit potential attack vectors, we still realize that some of the code running in Dom0, e.g. our GUI daemon or xen-store daemon, however simple, might contain some bugs.
|
|
Plus since we haven't implemented a separate storage domain, the disk backends are in Dom0 and are "reachable" from the VMs, which adds up to the potential attack surface.
|
|
So, having faced a choice between 32-bit and 64-bit OS for Dom0, it was almost a no-brainer.
|
|
The 64-bit option provides some (little perhaps, but some) more protection against some classes of attacks, and at the same time does not have any disadvantages except the extra requirement of a 64 bit processor.
|
|
And even though Qubes now "needs" a 64 bit processor, it didn't make sense to run Qubes on a system without 3-4GB of memory, and those have 64-bit CPUs anyway.
|
|
|
|
What is the recommended build environment for Qubes OS?
|
|
------------------------------------------
|
|
|
|
Any rpm-based, 64-bit environment, the preferred OS being Fedora.
|
|
|
|
How do I build Qubes from sources?
|
|
--------------------------------
|
|
|
|
See [these instructions](/doc/qubes-builder/).
|
|
|
|
How do I submit a patch?
|
|
------------------------
|
|
|
|
See the [Qubes Source Code Repositories](/doc/source-code/) article.
|
|
|
|
What is Qubes' attitude toward changing guest distros?
|
|
------------------------------------------------------
|
|
|
|
We try to respect each distro's culture, where possible.
|
|
See the discussion on issue [#1014](https://github.com/QubesOS/qubes-issues/issues/1014) for an example.
|
|
|
|
The policy is there mostly to ease maintenance, on several levels:
|
|
|
|
* Less modifications means easier migration to new upstream distribution
|
|
releases.
|
|
* The upstream documentation matches the distribution running in the Qubes VM.
|
|
* We're less likely to introduce Qubes-specific issues.
|
|
* Each officially supported distribution (ideally) should offer the same set of
|
|
Qubes-specific features - a change in one supported distribution should be
|
|
followed also in others, including new future distributions.
|
|
|
|
Is I/O emulation component (QEMU) part of the Trusted Computing Base (TCB)?
|
|
------------------------
|
|
|
|
No. Unlike many other virtualization systems, Qubes takes special effort to keep QEMU _outside_ of the TCB.
|
|
This has been achieved thanks to the careful use of Xen's stub domain feature.
|
|
For more details about how we improved on Xen's native stub domain use, see [here](https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html).
|