mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-08-01 11:06:28 -04:00
Consolidate FAQs into a single page (QubesOS/qubes-issues#2704)
This commit is contained in:
parent
08d3c91c01
commit
e3c16ae26e
2 changed files with 113 additions and 176 deletions
|
@ -1,62 +0,0 @@
|
|||
---
|
||||
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).
|
Loading…
Add table
Add a link
Reference in a new issue