Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-12-29 09:16:22 -05:00
Code Issues Packages Projects Releases Wiki Activity

Remove "Q:" prefixes

Browse Source
This commit is contained in:
Andrew David Wong 2017-02-16 18:56:19 -08:00
parent bc9abfe80e
commit 764cbe1946
No known key found for this signature in database
GPG Key ID: 8CE137352A019A17
1 changed files with 12 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
basics_dev/devel-faq.md
View File

@ -11,30 +11,30 @@ redirect_from:
Qubes Developers' FAQ Qubes Developers' FAQ
===================== =====================
Q: Why does dom0 need to be 64-bit? Why does dom0 need to be 64-bit?
----------------------------------- --------------------------------
Since 2013 [Xen has not supported 32-bit x86 architecture](http://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. Since 2013 [Xen has not supported 32-bit x86 architecture](http://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, often it is more difficult to exploit a bug on the x64 Linux than it is on x86 Linux (e.g. ASLR is sometimes harder to get around). While we designed Qubes with the emphasis on limiting any potential attack vectors in the first place, still we realize that some of the code running in Dom0, e.g. our GUI daemon or xen-store daemon, even though it is very simple code, might contain some bugs. Plus currently we haven't implemented a separate storage domain, so also 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, as the 64-bit option provides some (little perhaps, but still) more protection against some classes of attacks, and at the same time does not have any disadvantages (except that it requires a 64-bit processor, but all systems on which it makes sense to run Qubes, e.g. that have at least 3-4GB memory, they do have 64-bit CPUs anyway). In addition, often it is more difficult to exploit a bug on the x64 Linux than it is on x86 Linux (e.g. ASLR is sometimes harder to get around). While we designed Qubes with the emphasis on limiting any potential attack vectors in the first place, still we realize that some of the code running in Dom0, e.g. our GUI daemon or xen-store daemon, even though it is very simple code, might contain some bugs. Plus currently we haven't implemented a separate storage domain, so also 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, as the 64-bit option provides some (little perhaps, but still) more protection against some classes of attacks, and at the same time does not have any disadvantages (except that it requires a 64-bit processor, but all systems on which it makes sense to run Qubes, e.g. that have at least 3-4GB memory, they do have 64-bit CPUs anyway).
Q: What is the recommended build environment? What is the recommended build environment?
--------------------------------------------- ------------------------------------------
Any rpm-based, 64-bit. Preferred Fedora. Any rpm-based, 64-bit. Preferred Fedora.
Q: How to build Qubes from sources? How to build Qubes from sources?
----------------------------------- --------------------------------
See [the instruction](/doc/qubes-builder/) See [the instruction](/doc/qubes-builder/)
Q: How do I submit a patch? How do I submit a patch?
--------------------------- ------------------------
See [Qubes Source Code Repositories](/doc/source-code/). See [Qubes Source Code Repositories](/doc/source-code/).
Q: What is Qubes' attitude toward changing guest distros? What is Qubes' attitude toward changing guest distros?
--------------------------------------------------------- ------------------------------------------------------
We try to respect each distro's culture, where possible. See the discussion on 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 issue [#1014](https://github.com/QubesOS/qubes-issues/issues/1014) for an
@ -50,3 +50,5 @@ The policy is there mostly to ease maintenance, on several levels:
Qubes-specific features - a change in one supported distribution should be Qubes-specific features - a change in one supported distribution should be
followed also in others (including some new in the future) followed also in others (including some new in the future)