Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-12-28 08:49:42 -05:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'mfc-patch-3'

Browse Source
This commit is contained in:
Andrew David Wong 2017-10-31 04:23:57 -05:00
commit a2521e9864
No known key found for this signature in database
GPG Key ID: 8CE137352A019A17
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
basics_user/user-faq.md
View File

@ -273,7 +273,7 @@ But since you can read the whole memory, it isn't that hard.
Now, how does this apply to Qubes OS?
The above attack requires access to a PCI device, which means that it can be performed only from NetVM / UsbVM, so someone must first break into one of those VMs.
But this isn't that hard, because there is a lot of complex code handling network traffic.
Recent bugs includes DHCP client, DNS client, etc.
Recent bugs include DHCP client, DNS client, etc.
Most attacks on NetVM / UsbVM (but not all!) require being somewhat close to the target system - for example connected to the same WiFi network, or in the case of a UsbVM, having physical acccess to a USB port.
### Can I use AMD-v instead of VT-x?
@ -292,9 +292,9 @@ Open a terminal and run `sudo yum install linux-firmware` in the TemplateVM upon
### Can I install Qubes OS together with other operating system (dual-boot/multi-boot)?
You shouldn't do that, because it pose a security risk for your Qubes OS installation.
But if you understand the risk and accept it, read [documentation on multibooting](/doc/multiboot/).
It starts with explanation what is wrong with using such setup.
You shouldn't do that, because it poses a security risk for your Qubes OS installation.
But if you understand the risk and accept it, read [documentation on multibooting](/doc/multiboot/),
it begins with an explanation of the risks with such a setup.
Common Problems
---------------
@ -307,7 +307,7 @@ See [here](/doc/version-scheme/#check-installed-version).
Run `systemctl enable NetworkManager-dispatcher.service` in the TemplateVM upon which your NetVM is based.
You may have to reboot afterward for the change to take effect.
(Note: This is an upstream problem. See [here](https://bugzilla.redhat.com/show_bug.cgi?id=974811).
(Note: This is an upstream problem. See [here](https://bugzilla.redhat.com/show_bug.cgi?id=974811)).
For details, see the qubes-users mailing list threads [here](https://groups.google.com/d/topic/qubes-users/xPLGsAJiDW4/discussion) and [here](https://groups.google.com/d/topic/qubes-users/uN9G8hjKrGI/discussion).)
### My keyboard layout settings are not behaving correctly. What should I do?
@ -346,7 +346,7 @@ This is probably because one of the controllers does not support reset.
In Qubes R2 any such errors were ignored but in Qubes R3.0 they are not.
A device that does not support reset is not safe and generally should not be assigned to a VM.
Most likely the offending controller is a USB3.0 device.
Most likely the offending controller is a USB 3.0 device.
You can remove this controller from the usbVM, and see if this allows the VM to boot.
Alternatively you may be able to disable USB 3.0 in the BIOS.