paper source to Vitrics updated

AutomatedTests.md

@@ -11,7 +11,7 @@ Starting with Qubes R3 we use [python unittest](TODO) to perform automatic
 tests of Qubes OS. Regardless of the name, we use it for both [unit
 tests](https://en.wikipedia.org/wiki/Unit_tests) and [integration
 tests](https://en.wikipedia.org/wiki/Integration_tests). The main purpose is of
-course deliver much more stable releases.
+course to deliver much more stable releases.
 
 Integration tests are written with assumption to be called on dedicated
 hardware. **Do not run those test on machine where you have important data, you

BugReportingGuide.md

@@ -26,7 +26,7 @@ with the same question.
 Submitting a Bug Report (or "Issue")
 ------------------------------------
 
-In GitHub, "Bug Reports" are called "Issues."
+On GitHub, "Bug Reports" are called "Issues."
 
 Issues can be submitted to the Qubes project located at
 [https://github.com/QubesOS/qubes-issues](https://github.com/QubesOS/qubes-issues).
@@ -53,10 +53,10 @@ filing a new one.
 You should be sure to include the version the project, as well as versions
 of related software. For example, be sure to include the Qubes release
 version (R2, R3) and specific version numbers of package causing problems
-(if known)
+(if known).
 If your issue is related to hardware, provide as many details as possible
 about the hardware, which could include using commandline tools such as
-lspci.
+`lspci`.
 
 Project maintainers really appreciate thorough explanations. It usually
 helps them address the problem more quickly, so everyone wins!

CodingStyle.md

@@ -2,7 +2,9 @@
 layout: doc
 title: CodingStyle
 permalink: /doc/CodingStyle/
-redirect_from: /wiki/CodingStyle/
+redirect_from:
+- /wiki/CodingStyle/
+- /trac/wiki/CodingStyle/
 ---
 
 Coding Guidelines for Qubes Developers
@@ -18,7 +20,7 @@ Maintaining proper coding style is very important for any larger software projec
 -   It allows others to easily review the code and catch various bugs,
 -   It provides for an aesthetically pleasing experience when one reads the code...
 
-Often, developers, usually smart developers, neglect the value of proper coding style, thinking that it's most important how their code works, and expecting that if it solves some problem using a nice and neat trick, then it's all that is really required. Such thinking shows, however, immaturity and is a signal that the developer, however bright and smart, might not be a good fit for any larger project. Writing a clever exploit, that is to be used at one Black Hat show is one thing, while writing a useful software that is to be used and maintained for years, is quite a different story. If you want to show off how smart programmer you are, then you should become a researcher and write exploits. If, on the other hand, you want to be part of a team that makes real, useful software, you should ensure your coding style is impeccable. We often, at Qubes project, often took shortcuts, and often wrote nasty code, and this always back fired at us, sometime months, sometime years later, the net result being we had to spend time fixing code, rather than implementing new functionality.
+Often, developers, usually smart developers, neglect the value of proper coding style, thinking that it's most important how their code works, and expecting that if it solves some problem using a nice and neat trick, then it's all that is really required. Such thinking shows, however, immaturity and is a signal that the developer, however bright and smart, might not be a good fit for any larger project. Writing a clever exploit, that is to be used at one Black Hat show is one thing, while writing a useful software that is to be used and maintained for years, is quite a different story. If you want to show off what a smart programmer you are, then you should become a researcher and write exploits. If, on the other hand, you want to be part of a team that makes real, useful software, you should ensure your coding style is impeccable. We often, at Qubes project, often took shortcuts, and often wrote nasty code, and this always back fired at us, sometime months, sometime years later, the net result being we had to spend time fixing code, rather than implementing new functionality.
 
 And here's a [link to the real case](https://groups.google.com/forum/#!msg/qubes-devel/XgTo6L8-5XA/JLOadvBqnqMJ) (one Qubes Security Bulletin) demonstrating how the above described problem lead to a real security bug. Never assume you're smart enough that you can disregard clean and rigorous coding!
 
@@ -63,12 +65,12 @@ File naming conventions
 
 -   User commands that operate on particular VMs (also those accessible in VMs): `/usr/bin/qvm-*`
 -   User commands that apply to the whole system (Dom0 only): `/usr/bin/qubes-*`
--   Auxilary executables and scripts in `/usr/libexec/qubes/` (Note: previously we used `/usr/lib/qubes` but decided to change that)
--   Helper, non-exeutable files in `/usr/share/qubes/`
+-   Auxiliary executables and scripts in `/usr/libexec/qubes/` (Note: previously we used `/usr/lib/qubes` but decided to change that)
+-   Helper, non-executable files in `/usr/share/qubes/`
 -   Various config files in `/etc/qubes`
 -   Qubes RPC services in `/etc/qubes-rpc`. Qubes RPC Policy definitions (only in Dom0) in `/etc/qubes-rpc/policy/`
 -   All VM-related configs, images, and other files in `/var/lib/qubes/`
--   System-wide temporary files the reflect the current state of system in `/var/run/qubes`
+-   System-wide temporary files which reflect the current state of system in `/var/run/qubes`
 -   Logs: either log to the system-wide messages, or to `/var/log/qubes/`
 
 **File naming in Windows systems:**
@@ -79,9 +81,9 @@ File naming conventions
 General programming style guidelines
 ------------------------------------
 
--   Do not try to impress wit your coding kung-fu, do not use tricks to save 2 lines of code, always prefer readability over trickiness!
+-   Do not try to impress with your coding kung-fu, do not use tricks to save 2 lines of code, always prefer readability over trickiness!
 -   Make sure your code compiles and builds without warnings.
--   Always first first about interfaces (e.g. function arguments, or class methods) and data structures before you start writing the actual code.
+-   Always think first about interfaces (e.g. function arguments, or class methods) and data structures before you start writing the actual code.
 -   Use comments to explain non-trivial code fragments, or expected behavior of more complex functions, if it is not clear from their name.
 -   Do **not** use comments for code fragments where it is immediately clear what the code does. E.g. avoid constructs like this:
 
@@ -146,12 +148,12 @@ Security coding guidelines
        height = untrusted_conf.height;
     {% endhighlight %}
 
--   Use another variables, without the `untrusted_` prefix to hold the sanitized values, as seen above.
+-   Use another variables, without the `untrusted_` prefix to hold the sanitized values, as shown above.
 
 Python-specific guidelines
 --------------------------
 
--   Please follow the guidlines [here](http://www.python.org/dev/peps/pep-0008/), unless they were in conflict with what is written on this page.
+-   Please follow the guidelines [here](http://www.python.org/dev/peps/pep-0008/), unless they were in conflict with what is written on this page.
 
 C and C++ specific guidelines
 -----------------------------

ContributingHowto.md

@@ -21,6 +21,8 @@ Perhaps the best starting point is to have a look at the [issues](https://github
 
 Before you engage in some longer activity, e.g. implementing a new feature, it's always good to contact us first (preferably via the [qubes-devel](/doc/QubesLists/) list), to avoid a situation when two or more independent people would work on the same feature at the same time, doubling each others work. When you contact us and devote to a particular task, we will create a ticket for this task with info who is working on this feature and what is the expected date of some early code to be posted.
 
+When you are ready to start some work, read how to [access Qubes sources and send patches](/doc/SourceCode/).
+
 You can also contribute in other areas than coding and testing, e.g. by providing mirrors for Qubes rpm repositories, providing feedback about what features you would like to have in Qubes, or perhaps even preparing some cool You Tube videos that would demonstrate some Qubes' features. You are always encouraged to discuss your ideas on qubes-devel.
 
 You should be aware, however, that we will not blindly accept all the contributions! We will accept only the quality ones. Open source doesn't mean lack of quality control! If we reject your patch, please do not get discouraged, try fixing it so that it adheres to the required standards. We will only reject contributions in the good faith, to make Qubes a better OS.

DevelFaq.md

@@ -16,11 +16,11 @@ Qubes Developers FAQ
 
 ### Q: Why does dom0 need to be 64-bit?
 
-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 do 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).
+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: Why do you use KDE in Dom0? What is the roadmap for Gnome support?
 
-There a few things that are KDE-specific, but generally it should not be a big problem to also add Gnome support to Qubes (in Dom0 of course). Those KDE-specific things are:
+There are a few things that are KDE-specific, but generally it should not be a big problem to also add Gnome support to Qubes (in Dom0 of course). Those KDE-specific things are:
 
 -   Qubes requires KDM (KDE Login Manager), rather than GDM, for the very simple reason that GDM doesn't obey standards and start `/usr/bin/Xorg` instead of `/usr/bin/X`. This is important for Qubes, because we need to load a special "X wrapper" (to make it possible to use Linux usermode shared memory to access Xen shared memory pages in our App Viewers -- see the sources [here](https://github.com/QubesOS/qubes-gui-daemon/tree/master/shmoverride)). So, Qubes makes the `/usr/bin/X` to be a symlink to the Qubes X Wrapper, which, in turn, executes the `/usr/bin/Xorg`. This works well with KDM (and would probably also work with other X login managers), but not with GDM. If somebody succeeded in makeing GDM to execute `/usr/bin/X` instead of `/usr/bin/Xorg`, we would love to hear about it!
 
@@ -40,13 +40,4 @@ See [the instruction](/doc/QubesBuilder/)
 
 ### Q: How do I submit a patch?
 
-1.  Make all the changes in your working directory, i.e. edit files, move them around (you can use 'git mv' for this), etc.
-
-1.  Add the changes and commit them (git add, git commit). Never mix different changes into one commit! Write a good description of the commit. The first line should contain a short summary, and then, if you feel like more explanations are needed, enter an empty new line, and then start the long, detailed description (optional).
-
-1.  Test your changes NOW: check if RPMs build fine, etc.
-
-1.  Create the patch using 'git format-patch'. This has an advantage over 'git diff', because the former will also include your commit message, your name and email, so that \*your\* name will be used as a commit's author.
-
-1.  Send your patch to qubes-devel. Start the message subject with the '[PATCH]' string.
-
+See [Qubes Source Code Repositories](/doc/SourceCode/).

DevelopmentWorkflow.md

@@ -12,10 +12,11 @@ A workflow for developing Qubes OS+
 
 First things first, setup [QubesBuilder](/doc/QubesBuilder/). This guide assumes you're using qubes-builder to build Qubes.
 
-Repositories and Committing Code
+Repositories and committing Code
 --------------------------------
 
 Qubes is split into a bunch of git repos. This are all contained in the `qubes-src` directory under qubes-builder.
+FIXME(ypid): Not on github?
 
 The best way to write and contribute code is to create a git repo somewhere (e.g., github) for the repo you are interested in editing (e.g., `qubes-manager`, `core`, etc). To integrate your repo with the rest of Qubes, cd to the repo directory and add your repository as a remote in git
 
@@ -168,7 +169,8 @@ sudo cp qmemman/qmemman*.py $QUBES_PY_DIR/
 sudo cp misc/vm-template-hvm.conf /usr/share/qubes/
 sudo cp misc/qubes-start.desktop /usr/share/qubes/
 sudo cp misc/block-snapshot /etc/xen/scripts/
-sudo cp aux-tools/qubes-dom0-updates.cron /etc/cron.daily/I hope to 
+sudo cp aux-tools/qubes-dom0-updates.cron /etc/cron.daily/
+# FIXME(Abel Luck): I hope to 
 {% endhighlight %}
 
 ### Apply qvm-tools

DisposableVms.md

@@ -44,7 +44,7 @@ Starting an arbitrary application in a disposable VM via command line (from Dom0
 **Note:** Normally there should be no need for doing this -- this is just for Qubes hackers ;)
 
 {% highlight trac-wiki %}
-[joanna@dom0 ~]$ echo gnome-terminal | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
+[joanna@dom0 ~]$ echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
 {% endhighlight %}
 
 In fact the Disposable VM appmenu used for starting Firefox contains a very similar command to the above. Please note, however, that it generally makes little sense to start any other application other than a Web Browser this way...
@@ -55,7 +55,7 @@ Starting an arbitrary program in a Disposable VM from an AppVM
 Sometimes it might be useful to start an arbitrary program, such as e.g. terminal in an Disposable VM from an AppVM. This could be simply done this way:
 
 {% highlight trac-wiki %}
-[user@vault ~]$ qvm-run '$dispvm' gnome-terminal
+[user@vault ~]$ qvm-run '$dispvm' xterm
 {% endhighlight %}
 
 Note the above command is issued in an AppVM, not in Dom0. The created Disposable VM can be normally accessed via other tools, such as e.g. `qvm-copy-to-vm`, using its 'dispX' name, as shown by the Qubes Manager or `qvm-ls` tools. The created Disposable VM will inherit firewall settings of the ancestor VM, which is useful in some cases (e.g. when the original AppVM had networking cut off).

DocStyle.md

@@ -18,7 +18,25 @@ Guidelines for Documentation Contributors
    * In the event that a user is required to read the Markdown
    source directly, this will make it easier to follow, e.g., numbered steps in
    a set of instructions.
- * Use hanging indentations  
+ * Use hanging indentations
    where appropriate.
- * Use `[reference-style][ref]` links.  
+ * Use `[reference-style][ref]` links.
    `[ref]: http://daringfireball.net/projects/markdown/syntax#link`
+
+
+Sending documentation updates
+-----------------------------
+
+Main documentation repository is [qubes-doc] on [QubesOS] github account. If
+you want to add something there, clone that repository commit the changes and
+send us patches using either [github pull requests][github-forking] or [plain
+email sent to qubes-devel mailing list][patch].
+
+If you have a github account (its free!), you can simply browse [qubes-doc]
+repository and edit the files there! Github interface will automatically guide
+you through [fork & pull request creation process][github-forking].
+
+[qubes-doc]: https://github.com/QubesOS/qubes-doc
+[QubesOS]: https://github.com/QubesOS/
+[github-forking]: https://guides.github.com/activities/forking/
+[patch]: /doc/SourceCode/#sending-a-patch

Dom0SecureUpdates.md

@@ -29,15 +29,15 @@ Secure update mechanism we use in Qubes (starting from Beta 2
 
 Keeping Dom0 not connected to any network makes it hard, however, to provide updates for software in Dom0. For this reason we have come up with the following mechanism for Dom0 updates, which minimizes the amount of untrusted input processed by Dom0 software:
 
-The update process is initiated by [qvm-dom0-update script](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/qvm-tools/qvm-dom0-update;h=d6ac222fdc3850a0f1269df27746c9ed6e84c8a9;hb=HEAD), running in Dom0.
+The update process is initiated by [qvm-dom0-update script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-dom0-update), running in Dom0.
 
-Updates (\*.rpm files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes\_download\_dom0\_updates.sh script](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=common/qubes_download_dom0_updates.sh;h=dfc46123e9c0904d019d3f05008bc3adca21921d;hb=HEAD) (this script is executed using qrexec by the previously mentioned qvm-dom0-update). Note that we assume that this script might get compromised and might download a maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ```/var/lib/qubes/dom0-updates``` directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ```--installroot=``` option.
+Updates (\*.rpm files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qvm-dom0-update). Note that we assume that this script might get compromised and might download a maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ```/var/lib/qubes/dom0-updates``` directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ```--installroot=``` option.
 
-Once updates are downloaded, the update script that runs in UpdateVM requests an RPM service [qubes.ReceiveUpdates](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/aux-tools/qubes.ReceiveUpdates;h=7134323902b37a0be41b98ef8dbde61a94b1d189;hb=HEAD) to be executed in Dom0. This service is implemented by [qubes-receive-updates script](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/aux-tools/qubes-receive-updates;h=af386090b4a98de7f00736b60b9a1ca16f337822;hb=HEAD) running in Dom0. The Dom0's qvm-dom0-update script (which originally initiated the whole update process) waits until qubes-receive-updates finished.
+Once updates are downloaded, the update script that runs in UpdateVM requests an RPM service [qubes.ReceiveUpdates](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes.ReceiveUpdates) to be executed in Dom0. This service is implemented by [qubes-receive-updates script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-receive-updates) running in Dom0. The Dom0's qvm-dom0-update script (which originally initiated the whole update process) waits until qubes-receive-updates finished.
 
-The qubes-receive-updates script processes the untrusted input from Update VM: it first extracts the received \*.rpm files (that are sent over qrexec data connection) and then verifies digital signature on each file. The qubes-receive-updates script is a security-critical component of the Dom0 update process (as is the [qfile-dom0-unpacker.c](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/aux-tools/qfile-dom0-unpacker.c;h=757a2c43ba9e6780e8173b0049b2678efa0fda84;hb=HEAD) and the rpm utility, both used by the qubes-receive-updates for processing the untrusted input.
+The qubes-receive-updates script processes the untrusted input from Update VM: it first extracts the received \*.rpm files (that are sent over qrexec data connection) and then verifies digital signature on each file. The qubes-receive-updates script is a security-critical component of the Dom0 update process (as is the [qfile-dom0-unpacker.c](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qfile-dom0-unpacker.c) and the rpm utility, both used by the qubes-receive-updates for processing the untrusted input.
 
-Once qubes-receive-updates finished unpacking and verifying the updates, the updates are placed in ``qubes-receive-updates`` directory in Dom0 filesystem. Those updates are now trusted. Dom0 is configured (see /etc/yum.conf in Dom0) to use this directory as a default (and only) [yum repository](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/qubes-cached.repo;h=963a7ba524d4d63296718161fe4bcd3cad1ff5e7;hb=HEAD).
+Once qubes-receive-updates finished unpacking and verifying the updates, the updates are placed in ``qubes-receive-updates`` directory in Dom0 filesystem. Those updates are now trusted. Dom0 is configured (see /etc/yum.conf in Dom0) to use this directory as a default (and only) [yum repository](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-cached.repo).
 
 Finally, qvm-dom0-updates runs ``yum update`` that fetches the rpms from qubes-cached repo and installs them as usual.
 

Dom0Tools/QvmPrefs.md

@@ -20,6 +20,7 @@ SYNOPSIS
 --------
 
 qvm-prefs -l [options] \<vm-name\>
+qvm-prefs -g [options] \<vm-name\> \<property\>
 qvm-prefs -s [options] \<vm-name\> \<property\> [...]
 
 OPTIONS
@@ -31,6 +32,9 @@ Show this help message and exit
 -l, --list  
 List properties of a specified VM
 
+-g, --get  
+Get a single property of a specified VM
+
 -s, --set  
 Set properties of a specified VM
 
@@ -45,6 +49,11 @@ Control whenever this VM will be included in backups by default (for now works o
 pcidevs  
 PCI devices assigned to the VM. Should be edited using qvm-pci tool.
 
+pci\_strictreset  
+Accepted values: `True`, `False`
+
+Control whether prevent assigning to VM a device which does not support any reset method. Generally such devices should not be assigned to any VM, because there will be no way to reset device state after VM shutdown, so the device could attack next VM to which it will be assigned. But in some cases it could make sense - for example when the VM to which it is assigned is trusted one, or is running all the time.
+
 label  
 Accepted values: `red`, `orange`, `yellow`, `green`, `gray`, `blue`, `purple`, `black`
 
@@ -88,7 +97,7 @@ Number of CPU (cores) available to VM. Some VM types (eg DispVM) will not work p
 kernelopts  
 Accepted values: string, `default`
 
-VM kernel parameters (available only for PV VMs). This can be used to workaround some hardware specific problems (eg for NetVM). Setting to `default` will use some reasonable defaults (currently different for VMs with PCI devices and without). Some helpful options (for debugging purposes): `earlyprintk=xen`, `init=/bin/bash`
+VM kernel parameters (available only for PV VMs). This can be used to workaround some hardware specific problems (eg for NetVM). Setting to `default` will use some reasonable defaults (currently different for VMs with PCI devices and without). For VM without PCI devices `default` option means inherit this value from the VM template (if any). Some helpful options (for debugging purposes): `earlyprintk=xen`, `init=/bin/bash`
 
 name  
 Accepted values: alphanumerical name

Donations.md

@@ -23,13 +23,13 @@ FAQ
 
 ### How are you going to spend the donated Bitcoins?
 
-Our primary intention is to fund development of additional Qubes features, such as Split GPG (\#474), Qubes MIME handlers, USB PV backend, IPv6 routing between VMs, etc. Those additional features, although often very cool and appealing, are often being postponed because we need to focus on the more mainstream features, including the commercial branches for our paying customers.
+Our primary intention is to fund development of additional Qubes features, such as [Split GPG](https://github.com/QubesOS/qubes-issues/issues/474), Qubes MIME handlers, USB PV backend, IPv6 routing between VMs, etc. Those additional features, although often very cool and appealing, are often being postponed because we need to focus on the more mainstream features, including the commercial branches for our paying customers.
 
 But we cannot promise we won't spend your donated Bitcoins in some other way. Frankly, I (JR) don't believe that the income from public donations could sustain ITL in operation for even a month. If, however, ITL were in financial trouble, we would use those donations in an attempt to extend our agony ;) Generally, our goal is to make Qubes/ITL survive -- even if that means we must spend your donated Bitcoins on things other than cool open-source features. Hopefully though, this will not be necessary.
 
 ### I have donated X number of Bitcoins. Can I request that a special feature be implemented?
 
-The simple answer is: No. If everybody were to decide, then nothing would get implemented. However, if you make a substantial donation (e.g., an amount which you believe could be used to pay for several months of a developer's work), then please contact us in person or via the mailing list. You can attach a digitally signed message using the Bitcoin address you used to donate in order to prove that who made a particular donation. In that case, we will listen carefully and, in the worst case, explain to you why we can't or don't want to implement your requested feature.
+The simple answer is: No. If everybody were to decide, then nothing would get implemented. However, if you make a substantial donation (e.g., an amount which you believe could be used to pay for several months of a developer's work), then please contact us in person or via the mailing list. You can attach a digitally signed message using the Bitcoin address you used to donate in order to prove that you made a particular donation. In that case, we will listen carefully and, in the worst case, explain to you why we can't or don't want to implement your requested feature.
 
 ### Who actually owns the above Bitcoin address?
 
@@ -41,7 +41,7 @@ All Qubes developers are paid good salaries, and presently ITL is doing pretty w
 
 1.  Nobody forces or specifically asks you to donate. Qubes will (probably) survive without any donations.
 2.  The main reason to donate is to encourage the creation of additional features, i.e., to make Qubes OS more secure and/or easier to use. This should benefit most Qubes users.
-3.  Another reason to donate is to say "Thank you," as we're releasing Qubes under GPL (excluding the Windows support) and generally trying to make the world a better place. (Oh, right, I had to made this plug somewhere here;)
+3.  Another reason to donate is to say "Thank you," as we're releasing Qubes under GPL (excluding the Windows support) and generally trying to make the world a better place. (Oh, right, I had to make this plug somewhere here;)
 
 ### Are you going to provide a financial report on how you spend our donated Bitcoins?
 

FedoraTemplateUpgrade20.md

@@ -214,3 +214,8 @@ list which also apply to TemplateVM management and migration in general:
 
  * [Marek](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/dS1jbLRP9n8J)
  * [Jason M](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/5PxDfI-RKAsJ)
+
+Known issues with Fedora 21
+===========================
+
+* [The "Update VM" command in Qubes Manager does not work](https://github.com/QubesOS/qubes-issues/issues/982).

Fetchmail.md

@@ -8,7 +8,7 @@ redirect_from: /wiki/Fetchmail/
 Fetchmail
 =========
 
-Fetchmail is standalone MRA (Mail Retrieval Agent) aka "IMAP/POP3 client". Its sole purpose is to fetch your messages and store it locally or feed to local MTA (Message Transfer Agent). It cannot "read" messages — for that use MUA like Thunderbird or [Mutt](/doc/Mutt/).
+Fetchmail is standalone MRA (Mail Retrieval Agent) aka "IMAP/POP3 client". Its sole purpose is to fetch your messages and store it locally or feed to local MTA (Message Transfer Agent). It cannot "read" messages — for that, use a MUA like Thunderbird or [Mutt](/doc/Mutt/).
 
 Installation
 ------------

InstallSecurity.md

@@ -61,7 +61,7 @@ Cons:
    1. Use a USB optical drive.
    2. Attach a SATA optical drive to a secondary SATA controller, then assign
       this secondary SATA controller to an AppVM.
-   3. Use a SATA optical drive attached to dom0.  
+   3. Use a SATA optical drive attached to dom0.
       (Option 3 violates the Qubes security model since it entails transferring
       an untrusted ISO to dom0 in order to burn it to disc, which leaves only
       the other two options.)

InstallationGuideR3.0rc2.md

@@ -0,0 +1,98 @@
+---
+layout: doc
+title: Installation Guide for Qubes 3.0 rc2
+permalink: /doc/InstallationGuideR3.0rc2/
+---
+
+Installation Guide for Qubes Release 3.0 rc2
+============================================
+
+1.  [Hardware Requirements](#hardware-requirements)
+2.  [Download installer ISO](#download-installer-iso)
+3.  [Burning the ISO onto a DVD or USB stick](#burning-the-iso-onto-a-dvd-or-usb-stick)
+4.  [Upgrading](#upgrading)
+5.  [Troubleshooting problems with the installer](#troubleshooting-problems-with-the-installer)
+6.  [Known Issues](#known-issues)
+7.  [Getting Help](#getting-help)
+
+Hardware Requirements
+---------------------
+
+Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware.
+
+Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives).
+
+Download installer ISO
+----------------------
+
+See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO:
+
+    gpg -v Qubes-R3.0-rc2-x86_64-DVD.iso.asc
+
+Burning the ISO onto a DVD or USB stick
+---------------------------------------
+
+Once you verify this is an authentic ISO, you should burn it on a DVD.
+
+If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd:
+
+    dd if=Qubes-R3.0-rc2-x86_64-DVD.iso of=/dev/sdX
+
+On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator):
+
+    dd if=Qubes-R3.0-rc2-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress
+
+**Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)**
+
+Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph.
+
+Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions!
+
+The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :)
+
+Upgrading from R3.0rc1
+-----------------------
+
+If you are using Qubes R3.0rc1, just install system updates, there is no special steps required.
+
+Upgrading
+---------
+
+If you are using Qubes R2, follow instructions below.
+
+The easiest and safest way to upgrade to Qubes R3.0rc2 is to install it from scratch and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs.
+
+Users of Qubes R2 can upgrade using [experimental procedure](/doc/UpgradeToR3.0rc1/) (the same as for R3.0rc1).
+
+Troubleshooting problems with the installer
+-------------------------------------------
+
+If the installer fails for some reason, typically because of the graphics card not being correctly supported, it is possible to try booting the installer with a different kernel -- to do that, choose Troubleshooting menu in the Installer Welcome screen, and later choose an option to proceed with one of the kernels provided.
+
+The installer ships with 4 different kernels (3.12, 3.11, 3.9 and 3.7) and all those kernel will be installed (regardless of which is selected to run the installer) so it is later always possible to boot the Qubes OS using any of those kernels.
+
+Known Issues
+------------
+
+- UEFI is not supported, you need to enable "legacy boot" in BIOS before installing Qubes OS
+
+- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead.
+
+- If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system.
+
+- For other known issues take a look at [our tickets](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3.0%22+label%3Abug)
+
+It is advised to install updates just after system installation to apply bug fixes for (some of) the above problems.
+
+Getting Help
+------------
+
+-   **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!)
+
+-   Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/)
+
+-   If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below):
+    -   [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users)
+    -   `qubes-users@googlegroups.com`
+
+-   Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list.

Lenovo450Tinkering.md

@@ -0,0 +1,21 @@
+---
+layout: doc
+title: Lenovo450Tinkering
+permalink: /doc/Lenovo450Tinkering/
+redirect_from: /wiki/Lenovo450Tinkering/
+---
+
+Instructions for getting your Lenovo 450 laptop working with Qubes/Linux
+=========================================================================
+
+Lenovo 450 uses UEFI, so some settings are needed to get Qubes (or Fedora) to boot, otherwise Qubes install USB stick will reboot right after boot selector screen and not continue install.
+
+Setting UEFI options to get Qubes install to boot
+-------------------------------------------------
+
+1.  Enable Legacy USB mode
+2.  Disable all Secure Boot and UEFI options, but leave this enabled: Config / USB / USB UEFI BIOS SUPPORT
+3.  Save settings and reboot
+5.  Install Qubes
+
+... and now enjoy :) These settings may be needed also in other UEFI computers.

NetworkPrinter.md

@@ -13,7 +13,7 @@ Where to configure printers and install drivers?
 
 One would normally want to configure a printer in a template VM, rather than in particular AppVMs. This is because all the global settings made to AppVMs (those stored in its /etc, as well as binaries installed in /usr) would be discarded upon AppVM shutdown. When printer is added and configured in a template VM, then all the AppVMs based on this template should automatically be able to use it (without the need for the template VM to be running, of course).
 
-Alternatively one can add a printer in a standalone VM, but this would limit the printer usage for this particular VM.
+Alternatively one can add a printer in a standalone VM, but this would limit the printer usage to this particular VM.
 
 Security considerations for network printers and drivers
 --------------------------------------------------------
@@ -22,16 +22,16 @@ Some printers require 3rd party drivers, typically downloadable from the vendor'
 
 In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the 3rd party, unverified drivers there. Such template might then be made the default template for [Disposable VM creation](/doc/DisposableVms/), which should allow one to print any document by right-clicking on it, choosing "Open in Disposable VM" and print from there. This would allow to print documents from more trusted AppVMs (based on a trusted default template, that is not poisoned by 3rd party printer drivers).
 
-However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols. This means, that an attacker who is able to sniff the lock network, or who is controlling the (normally untrusted) Qubes NetVM, will likely be able to see the documents being printed. This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.
+However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols. This means, that an attacker who is able to sniff the local network, or who is controlling the (normally untrusted) Qubes NetVM, will likely to be able to see the documents being printed. This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.
 
 Additionally, the printer drivers as well as CUPS application itself, might be buggy and might got exploited when talking to a compromised printer (or by an attacker who controls the local network, or the default NetVM). Consider not using printing from your more trusted AppVMs for this reason.
 
-Steps to configure a network printer in a default template
+Steps to configure a network printer in a template VM
 ----------------------------------------------------------
 
 1.  Start the "Printer Settings" App in a template VM (either via Qubes "Start Menu", or by launching the `system-config-printer` in the template).
-2.  Add/Configure the printer in the same way as one would do on any normal Linux. Be sure to allow network access from the template VM to your printer, as normally the template VM is not allowed any network access, except to the special Qubes proxy for updates installation. One can use Qubes Manager to modify firewall rules for particular VMs.
-3.  Test the printer by printing a test page. If it works, shut down the template VM.
+2.  Add/Configure the printer in the same way as one would do on any normal Linux. Be sure to allow network access from the template VM to your printer, as normally the template VM is not allowed any network access, except to the Qubes proxy for software installation. One can use Qubes Manager to modify firewall rules for particular VMs.
+3.  Optional: Test the printer by printing a test page. If it works, shut down the template VM.
 4.  Open an AppVM (make sure it's based on the template where you just installed the printer, normally all AppVMs are based on the default template), and test if printing works. If it doesn't then probably the AppVM doesn't have networking access to the printer -- in that case adjust the firewall settings for that AppVM in Qubes Manager. Also, make sure that the AppVM gets restarted after the template was shutdown.
 5.  Alternatively if you do not want to modify the firewall rules of the template VM (that have security scope) you can simply shut down the template VM without trying to print the test page (which will not work), start or restart an AppVM based on the template and test printing there.
 

Qrexec.md

@@ -13,11 +13,11 @@ Qubes **qrexec** is a framework for implementing inter-VM (incl. Dom0-VM) servic
 Basic Dom0-VM command execution
 -------------------------------
 
-During domain creation a process named `qrexec-daemon` is started in dom0, and a process named `qrexec-agent` is started in the VM. They are connected over `vchan` channel.
+During each domain creation a process named `qrexec-daemon` is started in dom0, and a process named `qrexec-agent` is started in the VM. They are connected over `vchan` channel.
 
-Typically, the first thing that a `qrexec-client` instance does is to send a request to `qrexec-agent` to start a process in the VM. Since then, the stdin/stdout/stderr from this remote process is passed to the `qrexec-client` process.
+Typically, the first thing that a `qrexec-client` instance does is to send a request to `qrexec-agent` to start a process in the VM. From then on, the stdin/stdout/stderr from this remote process will be passed to the `qrexec-client` process.
 
-E.g. to start a primitive shell in a VM type the following in Dom0 console:
+E.g., to start a primitive shell in a VM type the following in Dom0 console:
 
 {% highlight trac-wiki %}
 [user@dom0 ~]$ /usr/lib/qubes/qrexec-client -d <vm name> user:bash
@@ -29,22 +29,22 @@ Adding `-e` on the `qrexec-client` command line results in mere command executio
 
 There is also the `-l <local program>` flag, which directs `qrexec-client` to pass stdin/stdout of the remote program not to its stdin/stdout, but to the (spawned for this purpose) `<local program>`.
 
-The `qvm-run` command is heavily based on `qrexec-client`. It also takes care for additional activities, e.g. starting the domain if it is not up yet, and starting the GUI daemon. Thus, it is usually more convenient to use `qvm-run`.
+The `qvm-run` command is heavily based on `qrexec-client`. It also takes care of additional activities (e.g., starting the domain, if it is not up yet, and starting the GUI daemon). Thus, it is usually more convenient to use `qvm-run`.
 
-There can be almost arbitrary number of `qrexec-client` processes for a domain (so, connected to the same `qrexec-daemon`, same domain) - their data is multiplexed independently.
+There can be almost arbitrary number of `qrexec-client` processes for a domain (i.e., `qrexec-client` processes connected to the same `qrexec-daemon`); their data is multiplexed independently.
 
 There is a similar command line utility avilable inside Linux AppVMs (note the `-vm` suffix): `qrexec-client-vm` that will be described in subsequent sections.
 
 Qubes Inter-VM Services (Qubes RPC)
 -----------------------------------
 
-Apart from simple Dom0-\>VM command executions, as discussed above, it is also useful to have more advanced infrastructure for controlled inter-VM RPC/services. This might be used for simple things like inter-VM file copy operations, as well as more complex tasks like starting a Disposable VM, and requesting it to do certain operations on a handed file(s).
+Apart from simple Dom0-\>VM command executions, as discussed above, it is also useful to have more advanced infrastructure for controlled inter-VM RPC/services. This might be used for simple things like inter-VM file copy operations, as well as more complex tasks like starting a DispVM, and requesting it to do certain operations on a handed file(s).
 
-Instead of implementing complex RPC-like mechanisms for inter-VM communication, Qubes takes a much simpler and pragmatic approach and aims to only provide simple *pipes* between the VMs, plus ability to request *pre-defined* programs (servers) to be started on the other end of such pipes, and a centralized policy (enforced in Dom0) which says which VMs can request what services from what VMs.
+Instead of implementing complex RPC-like mechanisms for inter-VM communication, Qubes takes a much simpler and pragmatic approach and aims to only provide simple *pipes* between the VMs, plus ability to request *pre-defined* programs (servers) to be started on the other end of such pipes, and a centralized policy (enforced by the `qrexec-policy` process running in dom0) which says which VMs can request what services from what VMs.
 
-Thanks to the framework and automatic stdin/stdout redirection, RPC programs are very simple - both the client and server just use their stdin/stdout to pass data. The framework does all the inner work to connect these file descriptors to each other via `qrexec-daemon` and `qrexec-agent`. Additionally, disposable VMs are tightly integrated - RPC to a DisposableVM is a simple matter of using a magic `$dispvm` keyword as the target VM name.
+Thanks to the framework and automatic stdin/stdout redirection, RPC programs are very simple; both the client and server just use their stdin/stdout to pass data. The framework does all the inner work to connect these file descriptors to each other via `qrexec-daemon` and `qrexec-agent`. Additionally, DispVMs are tightly integrated; RPC to a DispVM is a simple matter of using a magic `$dispvm` keyword as the target VM name.
 
-All services in Qubes are identified by a single string, which by convention takes a form of `qubes.ServiceName`. Each VM can provide handlers for each of the known services by providing a file in `/etc/qubes-rpc/` directory with the same name as the service it is supposed to handle. This file will be then executed by the qrexec service, if the Dom0 policy allowed service to be requested (see below). Typically the files in `/etc/qubes-rpc/` contain just one line, which is a path to the specific binary that acts as a server for the incoming request, however they might also be the actual executable themselves. Qrexec framework takes care about connecting the stdin/stdout of the server provess with the corresponding stdin/stdout of the requesting process in the requesting VM (see example Hello World service described below).
+All services in Qubes are identified by a single string, which by convention takes a form of `qubes.ServiceName`. Each VM can provide handlers for each of the known services by providing a file in `/etc/qubes-rpc/` directory with the same name as the service it is supposed to handle. This file will then be executed by the qrexec service, if the dom0 policy allowed the service to be requested (see below). Typically, the files in `/etc/qubes-rpc/` contain just one line, which is a path to the specific binary that acts as a server for the incoming request, however they might also be the actual executable themselves. Qrexec framework is careful about connecting the stdin/stdout of the server process with the corresponding stdin/stdout of the requesting process in the requesting VM (see example Hello World service described below).
 
 Qubes Services (RPC) policy
 ---------------------------
@@ -69,7 +69,7 @@ These files contain lines with the following format:
 srcvm destvm (allow|deny|ask)[,user=user_to_run_as][,target=VM_to_redirect_to]
 {% endhighlight %}
 
-You can specify `srcvm` and `destvm` by name, or by one of `$anyvm`, `$dispvm`, `dom0` reserved keywords (note string `dom0` does not match the `$anyvm` pattern; all other names do). Only `$anyvm` keyword makes sense in the `srcvm` field (service calls from dom0 are currently always allowed, `$dispvm` means "new VM created for this particular request" - so it is never a source of request). Currently there is no way to specify source VM by type, but this is planned for Qubes R3.
+You can specify `srcvm` and `destvm` by name, or by one of `$anyvm`, `$dispvm`, `dom0` reserved keywords (note string `dom0` does not match the `$anyvm` pattern; all other names do). Only `$anyvm` keyword makes sense in the `srcvm` field (service calls from dom0 are currently always allowed, `$dispvm` means "new VM created for this particular request" - so it is never a source of request). Currently, there is no way to specify source VM by type, but this is planned for Qubes R3.
 
 Whenever a RPC request for service named "XYZ" is received, the first line in `/etc/qubes-rpc/policy/XYZ` that matches the actual `srcvm`/`destvm` is consulted to determine whether to allow RPC, what user account the program should run in target VM under, and what VM to redirect the execution to. If the policy file does not exits, user is prompted to create one *manually*; if still there is no policy file after prompting, the action is denied.
 
@@ -78,7 +78,7 @@ On the target VM, the `/etc/qubes-rpc/XYZ` must exist, containing the file name
 Requesting VM-VM (and VM-Dom0) services execution
 -------------------------------------------------
 
-On src VM, one should invoke the qrexec client via the follwing command:
+In a src VM, one should invoke the qrexec client via the following command:
 
 {% highlight trac-wiki %}
 /usr/lib/qubes/qrexec-client-vm <target vm name> <service name> <local program path> [local program arguments]`
@@ -86,7 +86,7 @@ On src VM, one should invoke the qrexec client via the follwing command:
 
 Note that only stdin/stdout is passed between RPC server and client - notably, no cmdline argument are passed.
 
-The source VM name can be accessed in the server process via QREXEC\_REMOTE\_DOMAIN environment variable. (Note the source VM has *no* control over the name provided in this variable -- the name of the VM is provided by Dom0, and so is trusted).
+The source VM name can be accessed in the server process via QREXEC\_REMOTE\_DOMAIN environment variable. (Note the source VM has *no* control over the name provided in this variable--the name of the VM is provided by dom0, and so is trusted.)
 
 By default, stderr of client and server is logged to respective `/var/log/qubes/qrexec.XID` files, in each of the VM.
 
@@ -99,7 +99,7 @@ Connect directly to `/var/run/qubes/qrexec-agent-fdpass` socket as described [he
 
 ### Revoking "Yes to All" authorization
 
-Qubes RPC policy supports the "ask" action. This will prompt the user whether a given RPC call should be allowed. That prompt window has an option to click "Yes to All", which allows the action and adds a new entry to the policy file, which will unconditionally allow further calls for given service-srcVM-dstVM tuple.
+Qubes RPC policy supports an "ask" action, that will prompt the user whether a given RPC call should be allowed. It is set as default for services such as inter-VM file copy. A prompt window launches in dom0, that gives the user option to click "Yes to All", which allows the action and adds a new entry to the policy file, which will unconditionally allow further calls for given (service, srcVM, dstVM) tuple.
 
 In order to remove such authorization, issue this command from a Dom0 terminal (example below for qubes.Filecopy service):
 
@@ -107,7 +107,9 @@ In order to remove such authorization, issue this command from a Dom0 terminal (
 sudo nano /etc/qubes-rpc/policy/qubes.Filecopy
 {% endhighlight %}
 
-and then remove the first line/s (before the first \#\# comment) which are the "Yes to All" results.
+and then remove any line(s) ending in "allow" (before the first \#\# comment) which are the "Yes to All" results.
+
+A user might also want to set their own policies in this section. This may mostly serve to prevent the user from mistakenly copying files or text from a trusted to untrusted domain, or vice-versa.
 
 ### Qubes RPC "Hello World" service
 

Qrexec2Implementation.md

@@ -19,7 +19,7 @@ Players:
 -   `/usr/lib/qubes/qrexec-policy` \<- internal program used to evaluate the policy file and making the 2nd half of the connection.
 -   `/usr/lib/qubes/qrexec-client` \<- raw command line tool that talks to the daemon via unix socket (`/var/run/qubes/qrexec.XID`)
 
-Note: neither of the above tools are designed to be used by users.
+Note: none of the above tools are designed to be used by users.
 
 Linux VMs implementation
 ------------------------
@@ -30,7 +30,7 @@ Players:
 -   `/usr/lib/qubes/qubes-rpc-multiplexer` \<- executes the actual service program, as specified in VM's `/etc/qubes-rpc/qubes.XYZ`.
 -   `/usr/lib/qubes/qrexec-client-vm` \<- raw command line tool that talks to the agent.
 
-Note: neither of the above tools are designed to be used by users. `qrexec-client-vm` is designed to be wrapped up by Qubes apps.
+Note: none of the above tools are designed to be used by users. `qrexec-client-vm` is designed to be wrapped up by Qubes apps.
 
 Windows VMs implemention
 ------------------------
@@ -64,7 +64,7 @@ When a user in a source VM executes `qrexec-client-vm` utility, the following st
 -   `qrexec-policy` evaluates the policy file. If successful, creates a pair of `qrexec-client` processes, whose stdin/stdout are cross-connencted.
     -   The first `qrexec-client` connects to the src VM, using the `-c ClientID` parameter, which results in not creating a new process, but connecting to the existing process file descriptors (these are the fds of unix socket created in step 1).
     -   The second `qrexec-client` connects to the target VM, and executes `qubes-rpc-multiplexer` command there with the rpc action as the cmdline argument. Finally, `qubes-rpc-multiplexer` executes the correct rpc server on the target.
--   In the above step, if the target VM is `$dispvm`, the dispvm is created via the `qfile-daemon-dvm` program. The latter waits for the `qrexec-client` process to exit, and then destroys the dispvm.
+-   In the above step, if the target VM is `$dispvm`, the DispVM is created via the `qfile-daemon-dvm` program. The latter waits for the `qrexec-client` process to exit, and then destroys the DispVM.
 
 Protocol description ("wire-level" spec)
 ----------------------------------------

QubesDownloads.md

@@ -18,25 +18,26 @@ Qubes Downloads
 Qubes Release 3.0
 ---------------
 
--   [Qubes-R3.0-rc1-x86\_64-DVD.iso](http://sourceforge.net/projects/qubesos/files/Qubes-R3.0-rc1-x86_64-DVD.iso/download) (via sourceforge.net)
--   [Digital Signature](http://sourceforge.net/projects/qubesos/files/Qubes-R3.0-rc1-x86_64-DVD.iso.asc/download) (via sourceforge.net)
+-   [Qubes-R3.0-rc2-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc2-x86_64-DVD.iso) (mirror 1)
+-   [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc2-x86_64-DVD.iso.asc) (mirror 1)
+-   [Qubes-R3.0-rc2-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc2-x86_64-DVD.iso) (mirror 2)
+-   [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc2-x86_64-DVD.iso.asc) (mirror 2)
 
--   **[Installation Guide for Qubes R3.0 rc1](/doc/InstallationGuideR3.0rc1/)**
--   [Upgrading to Qubes R3.0 rc1](/doc/InstallationGuideR3.0rc1/#upgrading)
+-   **[Installation Guide for Qubes R3.0 rc2](/doc/InstallationGuideR3.0rc2/)**
+-   [Upgrading to Qubes R3.0 rc2](/doc/InstallationGuideR3.0rc2/#upgrading)
 
 Qubes Release 2
 ---------------
 
--   [Qubes-R2-x86\_64-DVD.iso](http://sourceforge.net/projects/qubesos/files/Qubes-R2-x86_64-DVD.iso/download) (via sourceforge.net)
--   [Digital Signature](http://sourceforge.net/projects/qubesos/files/Qubes-R2-x86_64-DVD.iso.asc/download) (via sourceforge.net)
+-   [Qubes-R2-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R2-x86_64-DVD.iso) (mirror 1)
+-   [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R2-x86_64-DVD.iso.asc) (mirror 1)
+-   [Qubes-R2-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R2-x86_64-DVD.iso) (mirror 2)
+-   [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R2-x86_64-DVD.iso.asc) (mirror 2)
 
 -   **[Installation Guide for Qubes R2](/doc/InstallationGuideR2/)**
 -   [Upgrading to Qubes R2](/doc/InstallationGuideR2/#upgrading)
 
--   [Qubes-R2-rc2-x86\_64-DVD.iso](http://sourceforge.net/projects/qubesos/files/Qubes-R2-rc2-x86_64-DVD.iso/download) (via sourceforge.net)
--   [Digital Signature](http://sourceforge.net/projects/qubesos/files/Qubes-R2-rc2-x86_64-DVD.iso.asc/download) (via sourceforge.net)
-
--   **[Installation Guide for Qubes R2 rc2](/doc/InstallationGuideR2rc2/)**
+-   **[Installation Guide for Qubes R2 rc2](/doc/InstallationGuideR2rc2/)** (deprecated)
 -   [Upgrading to Qubes R2 rc2](/doc/InstallationGuideR2rc2/#upgrading)
 
 Qubes Release 1
@@ -44,8 +45,10 @@ Qubes Release 1
 
 (This is mainly for historical reference, we strongly recommend Qubes R2 above)
 
--   [Qubes-R1-x86\_64-DVD.iso](http://sourceforge.net/projects/qubesos/files/Qubes-R1-x86_64-DVD.iso/download) (via sourceforge.net)
--   [Digital Signature](http://sourceforge.net/projects/qubesos/files/Qubes-R1-x86_64-DVD.iso.asc/download) (via sourceforge.net)
+-   [Qubes-R1-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R1-x86_64-DVD.iso) (mirror 1)
+-   [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R1-x86_64-DVD.iso.asc) (mirror 1)
+-   [Qubes-R1-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R1-x86_64-DVD.iso) (mirror 2)
+-   [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R1-x86_64-DVD.iso.asc) (mirror 2)
 
 -   **[Installation Guide](/doc/InstallationGuide/)**
 

SecurityBulletins.md

@@ -2,7 +2,9 @@
 layout: doc
 title: SecurityBulletins
 permalink: /doc/SecurityBulletins/
-redirect_from: /wiki/SecurityBulletins/
+redirect_from: 
+- /wiki/SecurityBulletins/
+- /trac/wiki/SecurityBulletins/
 ---
 
 Qubes Security Bulletins

SecurityCriticalCode.md

@@ -2,7 +2,9 @@
 layout: doc
 title: SecurityCriticalCode
 permalink: /doc/SecurityCriticalCode/
-redirect_from: /wiki/SecurityCriticalCode/
+redirect_from:
+- /wiki/SecurityCriticalCode/
+- /trac/wiki/SecurityCriticalCode/
 ---
 
 Security-Critical Code in Qubes OS

SecurityPage.md

@@ -2,7 +2,9 @@
 layout: doc
 title: SecurityPage
 permalink: /doc/SecurityPage/
-redirect_from: /wiki/SecurityPage/
+redirect_from: 
+- /wiki/SecurityPage/
+- /trac/wiki/SecurityPage/
 ---
 
 Reporting Security Issues in Qubes OS

SourceCode.md

@@ -31,7 +31,15 @@ e.g.:
 git clone git://github.com/QubesOS/qubes-core-admin.git core-admin
 {% endhighlight %}
 
-If you want to contribute to the project, there are two preferred ways:
+## Sending a patch
 
-1. Use github [fork & pull requests](https://guides.github.com/activities/forking/)
-2. [sending a patch](/doc/DevelFaq/#q-how-do-i-submit-a-patch) via the project's mailing list (`git format-patch`).
+If you want to contribute to the project, there are two ways:
+
+*  **Preferred**: Use github [fork & pull requests](https://guides.github.com/activities/forking/)
+*  Sending a patch via the project's mailing list (`git format-patch`).
+
+    1.  Make all the changes in your working directory, i.e. edit files, move them around (you can use 'git mv' for this), etc.
+    2.  Add the changes and commit them (git add, git commit). Never mix different changes into one commit! Write a good description of the commit. The first line should contain a short summary, and then, if you feel like more explanations are needed, enter an empty new line, and then start the long, detailed description (optional).
+    3.  Test your changes NOW: check if RPMs build fine, etc.
+    4.  Create the patch using 'git format-patch'. This has an advantage over 'git diff', because the former will also include your commit message, your name and email, so that \*your\* name will be used as a commit's author.
+    5.  Send your patch to qubes-devel. Start the message subject with the '[PATCH]' string.

StickMounting.md

@@ -10,47 +10,80 @@ How to Mount USB Sticks to AppVMs
 
 (**Note:** In the present context, the term "USB stick" denotes any [USB mass storage device](https://en.wikipedia.org/wiki/USB_mass_storage_device_class). In addition to smaller flash memory sticks, this includes things like USB external hard drives.)
 
-Qubes supports the ability to mount a USB stick to any AppVM easily, no matter which VM actually handles the USB controller. (The USB controller may be assigned on the **Devices** tab of an AppVM's settings page in Qubes VM Manager or by using the [qvm-pci command](/doc/AssigningDevices/).)
+Qubes supports the ability to attach a USB stick (or just one or more of its partitions) to any AppVM easily, no matter which VM actually handles the USB controller. (The USB controller may be assigned on the **Devices** tab of an AppVM's settings page in Qubes VM Manager or by using the [qvm-pci command](/doc/AssigningDevices/).)
 
-As of Qubes R2 Beta 3, USB stick mounting has been integrated into the Qubes VM Manger GUI. Simply insert your USB stick, right-click the desired AppVM in the Qubes VM Manager list, click **Attach/detach block devices**, and select your desired action and device.
+As of Qubes R2 Beta 3, USB stick mounting has been integrated into the Qubes VM Manger GUI. Simply insert your USB stick, right-click the desired AppVM in the Qubes VM Manager list, click **Attach/detach block devices**, and select your desired action and device. This, however, only works for the whole device. If you would like to attach individual partitions you must use the command-line tool (shown below). The reason for this is that when attaching a single partition, it used to be that Nautilus file manager would not see it and automatically mount it (see [this ticket](https://github.com/QubesOS/qubes-issues/issues/623)). This problem, however, seems to be resolved (see [this issue comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124270051)). If for some reason it does not show up in nautilus for you and you still need to attach just a single partition to a device, you will need to mount it manually; the device will show up as /dev/xvdi (or /dev/xvdj if there is already one device attached--/dev/xvdk and so on).
 
-A command-line tool, `qvm-block`, is also available. This tool can be used to assign a USB stick to an AppVM as follows:
+The command-line tool you may use to mount whole USB sticks or their partitions is `qvm-block`. This tool can be used to assign a USB stick to an AppVM as follows:
 
 1.  Insert your USB stick.
 
 1.  In a dom0 console (running as normal user), list all available block devices:
 
-    {% highlight trac-wiki %}
-    qvm-block -l
-    {% endhighlight %}
+        qvm-block -l
 
-> This will list all available block devices connected to any USB controller in your system, no matter in which VM hosts the controller. The name of the VM hosting the USB controller is displayed before the colon in the device name. The string after the colon is the name of the device used within the VM.
+    This will list all available block devices connected to any USB controller
+    in your system, no matter in which VM hosts the controller. The name of the
+    VM hosting the USB controller is displayed before the colon in the device
+    name. The string after the colon is the name of the device used within the
+    VM.
 
-> **Note:** If your device is not listed here, you may refresh the list by calling (from the VM to which device is connected):
->
-> {% highlight trac-wiki %}
-> sudo udevadm trigger --action=change
-> {% endhighlight %}
+    **Note:** If your device is not listed here, you may refresh the list by calling (from the VM to which device is connected):
 
-1.  Connect the device to an AppVM:
+        sudo udevadm trigger --action=change
 
-    {% highlight trac-wiki %}
-    qvm-block -a personal dom0:sda
-    {% endhighlight %}
 
-    **Note:** The order of these parameters was changed in Qubes 1.0-rc1.
+1.  Assuming our USB stick is sdb, we attach the device to an AppVM like so:
 
-> This will attach the device as "/dev/xvdi" in the AppVM.
+       qvm-block -a personal dom0:sdb
+   
+    This will attach the device as "/dev/xvdi", if not already taken by another attached device, in the AppVM. You may also mount one partition at a time by using the same command with the partition number after sdb.
+
+    **Warning: when working with single partitions, it is possible to assign the same partition to multiple VMs.** For example, you could attach sdb1 to VM1 and then sdb to VM2. It is up to the user not to make this mistake. Xen block device framework currently does not provide an easy way around this. Point 2 of [this ticket comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124119309) gives details on this.
 
 1.  The USB stick is now attached to the AppVM. If using a default AppVM, you may open Nautilus file manager in the AppVM, and your stick should be visible in the **Devices** panel on the left.
 
 1.  When you finish using your USB stick, click the eject button or right-click and select **Unmount**.
 
-1.  In a dom0 console, unmount the stick:
+1.  In a dom0 console, detach the stick:
 
-{% highlight trac-wiki %}
-qvm-block -d <device> <vmname>
-{% endhighlight %}
+        qvm-block -d <device> <vmname>
 
 1.  You may now remove the device.
 
+**Warning: Do not remove the device before detatching it from the VM!** Otherwise you
+will not be able to attach it anywhere later. See [this
+ticket](https://github.com/QubesOS/qubes-issues/issues/1082) for details.
+
+
+What if I removed the device before detaching it from the VM?
+------------------------------------------------------------
+
+Currently (until [this
+ticket](https://github.com/QubesOS/qubes-issues/issues/1082) got implemented),
+if you remove the device before detaching it from the VM, Qubes (more precisely
+- libvirtd) will think that the device is still attached to the VM and will not
+allow attaching further devices under the same name. The easiest way to recover
+from such situation is to reboot the VM to which device was attached. But if
+this isn't an option, you can manually recover from the situation by following
+this steps:
+
+1. Physically connect the device back. You can use any device as long as it
+   will be detected under the same name (for example `sdb`).
+2. Attach the device manually to the same VM using `xl block-attach` command.
+   It is important to use the same "frontend" device name (by default `xvdi`) -
+   you can get it from `qvm-block` listing:
+
+       [user@dom0 ~]$ qvm-block
+       sys-usb:sda DataTraveler_2.0 () 246 MiB (attached to 'testvm' as 'xvdi')
+       [user@dom0 ~]$ xl block-attach testvm phy:/dev/sda backend=sys-usb xvdi
+
+   In above example all `xl block-attach` parameters can be deducted from
+   `qvm-block` output. In order:
+
+   * `testvm` - name of target VM to which device was attached - listed in brackets by `qvm-block` command
+   * `phy:/dev/sda` - physical path at which device appears in source VM (just after source VM name in `qvm-block` output) 
+   * `backend=sys-usb` - name of source VM, can be omitted in case of dom0
+   * `xvdi` - "frontend" device name (listed at the end of line in `qvm-block` output
+
+3. Now properly detach the device, either using Qubes Manager, or `qvm-block -d` command.

SystemDoc/VMInterface.md

@@ -51,10 +51,60 @@ Qubes RPC
 
 Services called by dom0 to provide some VM configuration:
 
--   qubes.SetMonitorLayout - provide list of monitors, one in a line, each line contains four numbers: width height X Y
--   qubes.WaitForSession - called to wait for full VM startup
--   qubes.GetAppmenus - receive appmenus from given VM (template); TODO: describe format here
--   qubes.GetImageRGBA - receive image/application icon: TODO: describe format and parameters here
+-   `qubes.SetMonitorLayout` - provide list of monitors, one in a line, each line contains four numbers: `width height X Y`
+-   `qubes.WaitForSession` - called to wait for full VM startup
+-   `qubes.GetAppmenus` - receive appmenus from given VM (template); TODO: describe format here
+-   `qubes.GetImageRGBA` - receive image/application icon: TODO: describe format and parameters here
+-   `qubes.SetDateTime` - set VM time, called periodically by dom0 (can be
+    triggered manually from dom0 by calling `qvm-sync-clock`). The service
+    receives one line at stdin - time in format of `date -u -Iseconds`, for
+    example `2015-07-31T16:10:43+0000`.
+-   `qubes.SetGuiMode` - called in HVM to switch between fullscreen and seamless
+    GUI mode. The service receives a single word on stdin - either `FULLSCREEN`
+    or `SEAMLESS`
+
+
+Other Qrexec services installed by default:
+
+- `qubes.Backup` - store Qubes backup. The service receives location chosen by
+  the user (one line, terminated by '\n'), the backup archive ([description of
+  backup format](/doc/BackupEmergencyRestoreV2/))
+- `qubes.DetachPciDevice` - service called in reaction to `qvm-pci -d` call on
+  running VM. The service receives one word - BDF of device to detach. When the
+  service call ends, the device will be detached
+- `qubes.Filecopy` - receive some files from other VM. Files sent in [qfile format](/doc/Qfilecopy/)
+- `qubes.OpenInVM` - open a file in called VM. Service receives a single file on stdin (in
+  [qfile format](/doc/Qfilecopy/). After a file viewer/editor is terminated, if
+  the file was modified, can be sent back (just raw content, without any
+  headers); otherwise service should just terminate without sending anything.
+  This service is used by both `qvm-open-in-vm` and `qvm-open-in-dvm` tools. When
+  called in DispVM, service termination will trigger DispVM cleanup.
+- `qubes.Restore` - retrieve Qubes backup. The service receives backup location
+  entered by the user (one line, terminated by '\n'), then should output backup
+  archive in [qfile format](/doc/Qfilecopy/) (core-agent-linux component contains
+  `tar2qfile` utility to do the conversion
+- `qubes.SelectDirectory`, `qubes.SelectFile` - services which should show
+  file/directory selection dialog and return (to stdout) a single line
+  containing selected path, or nothing in case of cancellation
+- `qubes.SuspendPre` - service called in every VM with PCI device attached just
+  before system suspend
+- `qubes.SuspendPost` - service called in every VM with PCI device attached just
+  after system resume
+- `qubes.SyncNtpClock` - service called to trigger network time synchronization.
+  Service should synchronize local VM time and terminate when done.
+- `qubes.VMShell` - call any command in the VM; the command(s) is passed one per line
+
+Currently Qubes still calls few tools in VM directly, not using service
+abstraction. This will change in the future. Those tools are:
+
+- `/usr/lib/qubes/qubes-download-dom0-updates.sh` - script to download updates (or new packages to be installed) for dom0 (`qubes-dom0-update` tool)
+- `date -u -Iseconds` - called directly to retrieve time after calling `qubes.SyncNtpClock` service (`qvm-sync-clock` tool)
+- `nm-online -x` - called before `qubes.SyncNtpClock` service call by `qvm-sync-clock` tool
+- `resize2fs` - called to resize filesystem on /rw partition by `qvm-grow-private` tool
+- `gpk-update-viewer` - called by Qubes Manager to display available updates in a TemplateVM
+- `systemctl start qubes-update-check.timer` (and similarly stop) - called when enabling/disabling updates checking in given VM (`qubes-update-check` [qvm-service](/doc/QubesService/))
+
+Additionally automatic tests extensively calls various commands directly in VMs. We do not plan to change that.
 
 GUI protocol
 ------------

SystemRequirements.md

@@ -14,7 +14,7 @@ Minimum
 -   64-bit Intel or AMD processor (x86\_64 aka x64 aka AMD64)
 -   4 GB RAM
 -   32 GB disk space
--   legacy boot mode (UEFI not supported yet - \#794)
+-   legacy boot mode ([UEFI not supported yet](https://github.com/QubesOS/qubes-issues/issues/794))
 
 Recommended
 -----------

TemplateImplementation.md

@@ -10,39 +10,39 @@ Overview of VM block devices
 
 Every VM has 4 block devices connected:
 
--   **xvda** - base root device (/) - details described below
--   **xvdb** - private.img - place where VM always can write.
--   **xvdc** - volatile.img, discarded at each VM restart - here is placed swap and temporal "/" modifications (see below)
--   **xvdd** - modules.img - kernel modules and firmware
+-   **xvda** – base root device (/) – details described below
+-   **xvdb** – private.img – place where VM always can write.
+-   **xvdc** – volatile.img, discarded at each VM restart – here is placed swap and temporal "/" modifications (see below)
+-   **xvdd** – modules.img – kernel modules and firmware
 
 private.img (xvdb)
 ------------------
 
 This is mounted as /rw and here is placed all VM private data. This includes:
 
--   */home* - which is symlink to /rw/home
--   */usr/local* - which is symlink to /rw/usrlocal
+-   */home* – which is bind mounted to /rw/home
+-   */usr/local* – which is symlink to /rw/usrlocal
 -   some config files (/rw/config) called by qubes core scripts (ex /rw/config/rc.local)
 
 modules.img (xvdd)
 ------------------
 
-As kernel is chosen in dom0, not VM there must be some way to provide matching kernel modules to VM OS. Qubes kernel dir consists of 3 files:
+As the kernel is chosen in dom0, there must be some way to provide matching kernel modules to VM. Qubes kernel directory consists of 3 files:
 
--   *vmlinuz* - actual kernel
--   *initramfs* - initial ramdisk containing script to setup snapshot devices (see below) and mount /lib/modules
--   *modules.img* - filesystem image of /lib/modules with matching kernel modules and firmware (/lib/firmware/updates is symlinked to /lib/modules/firmware)
+-   *vmlinuz* – actual kernel
+-   *initramfs* – initial ramdisk containing script to setup snapshot devices (see below) and mount /lib/modules
+-   *modules.img* – filesystem image of /lib/modules with matching kernel modules and firmware (/lib/firmware/updates is symlinked to /lib/modules/firmware)
 
-Normally kernel "package" is common for many VMs (can be set using qvm-prefs). One of them can be set as default (qvm-set-default-kernel) to simplify kernel updates (by default all VMs uses default kernel). All installed kernels are placed in /var/lib/qubes/vm-kernels as separate subdirs. In this case, modules.img is attached to VM as R/O device.
+Normally kernel "package" is common for many VMs (can be set using qvm-prefs). One of them can be set as default (qvm-set-default-kernel) to simplify kernel updates (by default all VMs use the default kernel). All installed kernels are placed in /var/lib/qubes/vm-kernels as separate subdirs. In this case, modules.img is attached to the VM as R/O device.
 
-There is special case when VM can have custom kernel - when it is updateable (StandaloneVM or TemplateVM) and kernel is set to "none" (by qvm-prefs). In this case VM uses kernel from "kernels" VM subdir and modules.img is attached as R/W device. FIXME: "none" should be renamed to "custom".
+There is a special case when the VM can have a custom kernel – when it is updateable (StandaloneVM or TemplateVM) and the kernel is set to "none" (by qvm-prefs). In this case the VM uses the kernel from the "kernels" VM subdir and modules.img is attached as R/W device. FIXME: "none" should be renamed to "custom".
 
 Qubes TemplateVM implementation
 ===============================
 
 TemplateVM has a shared root.img across all AppVMs that are based on it. This mechanism has some advantages over a simple common device connected to multiple VMs:
 
--   root.img can be modified while there are AppVMs running - without corrupting the filesystem
+-   root.img can be modified while there are AppVMs running – without corrupting the filesystem
 -   multiple AppVMs that are using different versions of root.img (from various points in time) can be running concurrently
 
 There are two layers of the device-mapper snapshot device; the first one enables modifying root.img without stopping the AppVMs and the second one, which is contained in the AppVM, enables temporal modifications to its filesystem. These modifications will be discarded after a restart of the AppVM.
@@ -54,20 +54,20 @@ Snapshot device in Dom0
 
 This device consists of:
 
--   root.img - real template filesystem
--   root-cow.img - differences between the device as seen by AppVM and the current root.img
+-   root.img – real template filesystem
+-   root-cow.img – differences between the device as seen by AppVM and the current root.img
 
-The above is achieved through creating device-mapper snapshots for each version of root.img. When an AppVM is started, a xen hotplug script (/etc/xen/scripts/block-snapshot) reads the inode numbers of root.img and root-cow.img; these numbers are used as the snapshot device's name. When a device with the same name exists the new AppVM will use it - therefore, AppVMs based on the same version of root.img will use the same device. Of course, the device-mapper cannot use the files directly - it must be connected through /dev/loop\*. The same mechanism detects if there is a loop device associated with a file determined by the device and inode numbers - or if creating a new loop device is necessary.
+The above is achieved through creating device-mapper snapshots for each version of root.img. When an AppVM is started, a xen hotplug script (/etc/xen/scripts/block-snapshot) reads the inode numbers of root.img and root-cow.img; these numbers are used as the snapshot device's name. When a device with the same name exists the new AppVM will use it – therefore, AppVMs based on the same version of root.img will use the same device. Of course, the device-mapper cannot use the files directly – it must be connected through /dev/loop\*. The same mechanism detects if there is a loop device associated with a file determined by the device and inode numbers – or if creating a new loop device is necessary.
 
-When an AppVM is stopped the xen hotplug script checks whether the device is still in use - if it is not, the script removes the snapshot and frees the loop device.
+When an AppVM is stopped the xen hotplug script checks whether the device is still in use – if it is not, the script removes the snapshot and frees the loop device.
 
 ### Changes to template filesystem
 
 In order for the full potential of the snapshot device to be realized, every change in root.img must save the original version of the modified block in root-cow.img. This is achieved by a snapshot-origin device.
 
-When TemplateVM is started, it receives the snapshot-origin device connected as a root device (in read-write mode). Therefore, every change to this device is immediately saved in root.img - but remains invisible to the AppVM, which uses the snapshot.
+When TemplateVM is started, it receives the snapshot-origin device connected as a root device (in read-write mode). Therefore, every change to this device is immediately saved in root.img – but remains invisible to the AppVM, which uses the snapshot.
 
-When TemplateVM is stopped, the xen script moves root-cow.img to root-cow.img.old and creates a new one (using the qvm-template-commit tool). The snapshot device will remain untouched due to the loop device, which uses an actual file on the disk (by inode, not by name). Linux kernel frees the old root-cow.img files as soon as they are unused by all snapshot devices (to be exact, loop devices). The new root-cow.img file will get a new inode number, and so new AppVMs will get new snapshot devices (with different names).
+When TemplateVM is stopped, the xen script moves root-cow.img to root-cow.img.old and creates a new one (using the `qvm-template-commit` tool). The snapshot device will remain untouched due to the loop device, which uses an actual file on the disk (by inode, not by name). Linux kernel frees the old root-cow.img files as soon as they are unused by all snapshot devices (to be exact, loop devices). The new root-cow.img file will get a new inode number, and so new AppVMs will get new snapshot devices (with different names).
 
 ### Rollback template changes
 
@@ -80,7 +80,7 @@ Steps performed by **qvm-revert-template-changes**:
 1.  Ensure that no other VMs uses this template.
 2.  Prepare snapshot device with ***root-cow.img.old*** instead of *root-cow.img* (*/etc/xen/scripts/block-snapshot prepare*).
 3.  Replace *snapshot* device-mapper target with *snapshot-merge*, other parameters (chunk size etc) remains untouched. Now kernel starts merging changes stored in *root-cow.img.old* into *root.img*. d-m device can be used normally (if needed).
-4.  Waits for merge completed: *dmsetup status* shows used snapshot blocks - it should be equal to metadata size when completed.
+4.  Waits for merge completed: *dmsetup status* shows used snapshot blocks – it should be equal to metadata size when completed.
 5.  Replace *snapshot-merge* d-m target back to *snapshot*.
 6.  Cleanup snapshot device (if nobody uses it it the moment).
 7.  Move *root-cow.img.old* to *root-cow.img* (overriding existing file).
@@ -90,15 +90,15 @@ Snapshot device in AppVM
 
 Root device is exposed to AppVM in read-only mode. AppVM can write only in:
 
--   private.img - persistent storage (mounted in /rw) used for /home, /usr/local - in future versions, its use may be extended
--   volatile.img - temporary storage, which is discarded after an AppVM restart
+-   private.img – persistent storage (mounted in /rw) used for /home, /usr/local – in future versions, its use may be extended
+-   volatile.img – temporary storage, which is discarded after an AppVM restart
 
 volatile.img is divided into two partitions:
 
 1.  changes to root device
 2.  swap partition
 
-Inside of an AppVM, the root device is wrapped by the snapshot in the first partition of volatile.img. Therefore, the AppVM can write anything to its filesystem - however, such changes will be discarded after a restart.
+Inside of an AppVM, the root device is wrapped by the snapshot in the first partition of volatile.img. Therefore, the AppVM can write anything to its filesystem – however, such changes will be discarded after a restart.
 
 StandaloneVM
 ------------

UninstallingWindowsTools2.md

@@ -0,0 +1,123 @@
+---
+layout: doc
+title: UninstallingWindowsTools2
+permalink: /doc/UninstallingWindowsTools2/
+redirect_from: /wiki/UninstallingWindowsTools2/
+---
+
+Uninstalling Qubes Tools for Windows v2.x
+=========================================
+
+**Do not try to uninstall Qubes Tools for Windows (QTW) 2.x from Windows Control Panel. It will render your HVM unbootable and will require manual fixing.**
+
+Preface
+-------
+
+Version 2.x of QTW (used for Windows HVMs in Qubes R2) is difficult to uninstall due to issues with the Xen GPL PV drivers package that is used. However, uninstalling QTW version 2.x is required to migrate the HVM to Qubes R3.
+HVMs with QTW 2.x *will not boot normally in Qubes R3* due to Xen drivers failing. They will boot in Safe Mode. It's easier to uninstall QTW 2.x from Qubes R2, but if that's not an option it's also possible in Qubes R3 (just a bit more complicated). Details below.
+
+Uninstalling QTW 2.x in Qubes R2
+--------------------------------
+
+1. Copy the uninstall script posted at the end of this document and save it in the HVM as a .BAT file.
+2. Reboot the HVM in Safe Mode: type `bcdedit /set safeboot minimal` in a command prompt with admin privileges then restart normally. The OS will now always start in Safe Mode until the setting is reverted.
+3. In Safe Mode execute the uninstall script from step 1.
+4. Open Device Manager. Manually uninstall Qubes Video device (in 'Display adapters') and Xen PCI driver (in 'System devices'). This will prevent the (already removed) devices from showing up.
+5. Type `bcdedit /deletevalue safeboot` in a command prompt to disable Safe Mode boot.
+6. Reboot. Open Device Manager and verify that there are no active Xen PV devices:
+   - There should be one unidentified PCI device in System devices (this is the Xen PV device, not functioning because PV drivers are inactive).
+   - Disk drives should be QEMU (emulated).
+   - Network adapter should be Realtek (emulated).
+   
+Now you can backup the HVM, migrate it to Qubes R3 and install QTW 3.x there.
+
+Uninstalling QTW 2.x in Qubes R3
+--------------------------------
+
+HVMs with QTW 2.x will not boot normally in Qubes R3 due to the old Xen drivers failing. If removing QTW from Qubes R2 is not an option (see above) then you will need to boot the HVM in Safe Mode.
+
+### Preparation in dom0
+
+Disable VM tools in VM's preferences:
+* `qvm-prefs -s vmname qrexec_installed false`
+* `qvm-prefs -s vmname guiagent_installed false`
+
+### Enabling Safe Mode
+* If you're quick you can mash F8 just as the HVM boots to access Windows' advanced boot options. The timing for it is very tight though. If you manage to get the boot menu, select Safe Mode boot.
+* Alternatively, allow the HVM to (try to) boot. It will crash with a BSOD.
+* After the crash start the HVM again. Now Windows will display the recovery menu which, for some unknown reason, does not include Safe Mode boot option. We need to try harder.
+* Select **Launch Startup Repair**.
+* If you're prompted to try System Restore, **don't**. Hit cancel.
+* Grab a drink or read a book while Windows tries to do something but ultimately the repair process fails.
+* *Now* you're presented with a choice of *advanced options* that include a command prompt. Why isn't this available from the start? 
+* Launch the command prompt, log in and type `bcdedit /set {default} safeboot minimal`. The OS will now always start in Safe Mode until the setting is reverted. 
+* Reboot and proceed with the uninstallation instructions from the previous paragraph (*Uninstalling QTW 2.x in Qubes R2*).
+
+If you need network access to copy the uninstall script to the HVM, use *Safe Mode with Networking* instead of pure Safe Mode (replace `minimal` with `network` in the bcdedit commands above). Disable the Xen PV network device first. You may need to manually configure IP settings for the emulated Realtek adapter.
+
+
+The uninstall script
+====================
+
+Save it as a .BAT file in the HVM and run in Safe Mode.
+
+```
+@echo off
+
+:: This batch file uninstalls Qubes Tools for Windows version 2.x
+:: Needs to be run in safe mode
+
+:: Registry cleanup
+reg delete "HKLM\Software\Invisible Things Lab" /f
+
+:: services/drivers
+reg delete HKLM\System\CurrentControlSet\Services\ShutdownMon /f
+reg delete HKLM\System\CurrentControlSet\Services\QrexecAgent /f
+reg delete HKLM\System\CurrentControlSet\Services\QTWHelper /f
+reg delete HKLM\System\CurrentControlSet\Services\QubesNetworkSetup /f
+reg delete HKLM\System\CurrentControlSet\Services\QVideo /f
+reg delete HKLM\System\CurrentControlSet\Services\XenNet /f
+reg delete HKLM\System\CurrentControlSet\Services\XenPCI /f
+reg delete HKLM\System\CurrentControlSet\Services\XenVbd /f
+
+:: xenpci filter entries
+reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318} /v UpperFilters /f
+reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318} /v UpperFilters /f
+reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318} /v UpperFilters /f
+
+:: files
+rmdir /q /s "%ProgramFiles%\Invisible Things Lab"
+rmdir /q /s "%ProgramFiles%\Xen PV Drivers"
+
+del /q /s "%windir%\system32\move-profiles.exe"
+del /q /s "%windir%\system32\windows-utils.dll"
+del /q /s "%windir%\system32\qvgdi.dll"
+del /q /s "%windir%\system32\drivers\qvmini.sys"
+del /q /s "%windir%\system32\drivers\xennet.sys"
+del /q /s "%windir%\system32\drivers\xenpci.sys"
+del /q /s "%windir%\system32\drivers\xenvbd.sys"
+
+:: driver store entries
+FOR /F "delims=. tokens=1" %%I IN ('DIR /B "%SYSTEMROOT%\INF\OEM*.INF"') DO (
+ TYPE "%SYSTEMROOT%\INF\%%I.inf" | FIND /c /i "Xen GPL PV" >%TEMP%\qtwuninstall
+ FOR /f %%c IN (%TEMP%\qtwuninstall) DO (
+  IF /I %%c NEQ 0 (
+   DEL "%SYSTEMROOT%\INF\%%I.inf"
+   DEL "%SYSTEMROOT%\INF\%%I.pnf"
+  )
+ )
+)
+
+FOR /F "delims=. tokens=1" %%I IN ('DIR /B "%SYSTEMROOT%\INF\OEM*.INF"') DO (
+ TYPE "%SYSTEMROOT%\INF\%%I.inf" | FIND /c /i "Qubes" >%TEMP%\qtwuninstall
+ FOR /f %%c IN (%TEMP%\qtwuninstall) DO (
+  IF /I %%c NEQ 0 (
+   DEL "%SYSTEMROOT%\INF\%%I.inf"
+   DEL "%SYSTEMROOT%\INF\%%I.pnf"
+  )
+ )
+)
+
+echo.
+echo Cleanup finished. Please manually uninstall Qubes Video and Xen devices from the Device Manager.
+```

UserDoc.md

@@ -74,7 +74,9 @@ Qubes User Documentation
 
     8.  **Windows VMs**
         1.  [Installing and Using Windows-based AppVMs (Qubes R2 Beta 3 and later)](/doc/WindowsAppVms/)
-        2.  [Advanced options and troubleshooting of Qubes Tools for Windows](/doc/WindowsTools/)
+        2.  [Advanced options and troubleshooting of Qubes Tools for Windows (R3)](/doc/WindowsTools3/)
+        3.  [Advanced options and troubleshooting of Qubes Tools for Windows (R2)](/doc/WindowsTools2/)
+            1.  [Uninstalling Qubes Tools for Windows 2.x](/doc/UninstallingWindowsTools2/)
 
     9.  Advanced Topics
         1.  [Configuration files](/doc/UserDoc/ConfigFiles/)
@@ -94,6 +96,7 @@ Qubes User Documentation
     7.  Vendor-specific
         1.  [How to install an Nvidia driver in dom0](/doc/InstallNvidiaDriver/)
         2.  [Getting Sony Vaio Z laptop to work with Qubes](/doc/SonyVaioTinkering/)
+        3.  [Getting Lenovo 450 to work with Qubes](/doc/Lenovo450Tinkering/)
 
     8.  External Links
         1.  [Installing on system with new AMD GPU (missing firmware problem)](https://groups.google.com/group/qubes-devel/browse_thread/thread/e27a57b0eda62f76)

VPN.md

@@ -8,20 +8,20 @@ redirect_from: /wiki/VPN/
 How To make a VPN Gateway in Qubes
 ----------------------------------
 
-The simplest case if you set up a VPN connection using the Network Manager inside one of your VMs. Setting up such a connection is really not Qubes specific and it is documented in Your Operating system documentation. If you using the Qubes default Guest OS (Fedora): [Establishing a VPN Connection](http://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/sec-Establishing_a_VPN_Connection.html)
+The simplest case if you set up a VPN connection using the Network Manager inside one of your VMs. Setting up such a connection is really not Qubes specific and it is documented in Your operating system documentation. If you using the Qubes default Guest OS (Fedora): [Establishing a VPN Connection](http://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/sec-Establishing_a_VPN_Connection.html)
 
-The Qubes specific part is choose the right VM for the VPN client:
+The Qubes specific part is to choose the right VM for the VPN client:
 
 ### NetVM
 
-The simplest case if you set up a VPN connection using the Network Manager inside your NetVM. Because the NetworkManager already started you are ready to set up your VPN connection. However this has some disadvantages:
+The simplest case is to set up a VPN connection using the Network Manager inside your NetVM. Because the NetworkManager already started you are ready to set up your VPN connection. However this has some disadvantages:
 
--   You have to place (and probably save) Your VPN credentials inside the NetVM wich is directly connected to the outside world
--   All your AppVMs wich are connected to the NetVM will be connected to the VPN (by default)
+-   You have to place (and probably save) Your VPN credentials inside the NetVM which is directly connected to the outside world
+-   All your AppVMs which are connected to the NetVM will be connected to the VPN (by default)
 
 ### AppVM
 
-While the Network Manager is not started here (for a good reason) You can configure any kind of VPN client in your AppVM as well, however it is only suggested if you have to use a special VPN client.
+While the Network Manager is not started here (for a good reason), you can configure any kind of VPN client in your AppVM as well, however it is only suggested if you have to use a special VPN client.
 
 ### ProxyVM
 
@@ -29,10 +29,10 @@ While the Network Manager is not started here (for a good reason) You can config
 
 One of the best thing in Qubes that you can use a special type of VMs called ProxyVM (or FirewallVM). The special thing is that your AppVMs see this as a NetVM, and the NetVMs see it as an AppVM. Because of that You can place a ProxyVM between your AppVMs and Your NetVM. This is how the default firewall VM is working.
 
-Using a ProxyVM to set up a VPN client will gives you the ability to:
+Using a ProxyVM to set up a VPN client gives you the ability to:
 
 -   Separate your VPN credentials from Your AppVM data.
--   You can easily control which of your AppVMs are connected to your VPN by simply set it as a NetVM of the desired AppVM.
+-   Easily control which of your AppVMs are connected to your VPN by simply setting it as a NetVM of the desired AppVM.
 
 **To setup a ProxyVM as a VPN gateway you should:**
 

WindowsTools2.md

@@ -1,14 +1,15 @@
 ---
 layout: doc
-title: WindowsTools
-permalink: /doc/WindowsTools/
-redirect_from: /wiki/WindowsTools/
+title: WindowsTools2
+permalink: /doc/WindowsTools2/
+redirect_from: /wiki/WindowsTools2/
 ---
 
 Qubes Tools for Windows: advanced settings and troubleshooting
 ==============================================================
 
-''Only 64-bit Windows 7 (any edition) is supported currently. Windows 8+ support is under development.''
+**This document only applies to Qubes R2 (tools version 2.x)**
+*Only 64-bit Windows 7 (any edition) is supported currently. Windows 8+ support is under development.*
 
 Installable components
 ----------------------
@@ -21,7 +22,7 @@ Qubes Tools for Windows (QTW for short) contain several components than can be e
 -   GUI Windows Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop.
 -   Disable UAC: disables User Account Control prompts. *Is this still needed/wanted? Gui agent can handle UAC prompts now.*
 
-It's probably a good idea to install a VNC server in the VM before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
+**In testing VMs only** it's probably a good idea to install a VNC server before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
 
 Verbose installation
 --------------------
@@ -30,7 +31,10 @@ If the install process fails you can retry it using the command line below to ge
 
 `msiexec /i path-to-qubes-tools.msi /lv path-to-log-file.txt`
 
-Uninstalling QTW 2.x is **not recommended**. It will most likely make the OS non-bootable because drivers for Xen storage devices will be uninstalled.
+Uninstalling
+------------
+
+See [this page](/doc/UninstallingWindowsTools2/).
 
 Configuration
 -------------

WindowsTools3.md

@@ -0,0 +1,105 @@
+---
+layout: doc
+title: WindowsTools
+permalink: /doc/WindowsTools3/
+redirect_from: /wiki/WindowsTools/
+redirect_from: /doc/WindowsTools/
+---
+
+Qubes Tools for Windows: advanced settings and troubleshooting
+==============================================================
+
+**This document only applies to Qubes R3 (tools version 3.x)**
+*Only 64-bit Windows 7 (any edition) is supported currently. Windows 8+ support is under development.*
+*HVM templates are not supported yet. Specifically, user profiles are not yet moved to a VM's private image (fix incoming).*
+
+Installable components
+----------------------
+
+Qubes Tools for Windows (QTW for short) contain several components than can be enabled or disabled during installation:
+
+- Shared components (required): common libraries used by QTW components.
+- Xen PV drivers: drivers for the virtual hardware exposed by Xen.
+   - Base Xen PV Drivers (required): paravirtual bus and interface drivers.
+   - Xen PV Disk Drivers: paravirtual storage drivers.
+   - Xen PV Network Drivers: paravirtual network drivers.
+- Qubes Core Agent: qrexec agent and services. Needed for proper integration with Qubes.
+- Qubes GUI Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop.
+
+**In testing VMs only** it's probably a good idea to install a VNC server before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
+
+Verbose installation
+--------------------
+
+If the install process fails you can retry it using the command line below to get a detailed installation log (and send that to us):
+
+`msiexec /i path-to-qubes-tools.msi /lv path-to-log-file.txt`
+
+Uninstalling QTW 3.x is **not recommended**. It will most likely make the OS non-bootable because drivers for Xen storage devices will be uninstalled. This will be fixed in the future.
+
+Configuration
+-------------
+
+Starting from version 2.2.\* various aspects of Qubes Tools for Windows can be configured through registry. Main configuration key is located in `HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools`. Configuration values set on this level are global to all QTW components. It's possible to override global values with component-specific keys, this is useful mainly for setting log verbosity for troubleshooting. Possible configuration values are:
+
+|**Name**|**Type**|**Description**|**Default value**|
+|:-------|:-------|:--------------|:----------------|
+|LogDir|String|Directory where logs are created|c:\\Program Files\\Invisible Things Lab\\Qubes Tools\\log|
+|LogLevel|DWORD|Log verbosity (see below)|2 (INFO)|
+|LogRetention|DWORD|Maximum age of log files (in seconds), older logs are automatically deleted|604800 (7 days)|
+
+Possible log levels:
+
+||
+|0|Error|Serious errors that most likely cause irrecoverable failures|
+|1|Warning|Unexpected but non-fatal events|
+|2|Info|Useful information|
+|3|Debug|Internal state dumps for troubleshooting|
+|4|Verbose|Trace most function calls|
+
+Debug and Verbose levels can generate large volume of logs and are intended for development/troubleshooting only.
+
+To override global settings for a specific component, create a new key under the root key mentioned above and name it as the executable name, without `.exe` extension. For example, to change qrexec-agent's log level to Debug, set it like this:
+
+![qtw-log-level.png](/attachment/wiki/WindowsTools/qtw-log-level.png)
+
+Component-specific settings currently available:
+
+|**Component**|**Setting**|**Type**|**Description**|**Default value**|
+|:------------|:----------|:-------|:--------------|:----------------|
+|qga|UseDirtyBits|DWORD|Enable experimental feature of the gui agent/qvideo driver: use page table dirty bits to determine changed display regions. This can improve performance but may impact display responsiveness (some changes may not be detected resulting in "stale" image). Needs VM restart to apply change.|0|
+|qga|DisableCursor|DWORD|Disable cursor in the VM. Useful for integration with Qubes desktop so you don't see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since qga is restarted on desktop change).|1|
+
+Troubleshooting
+---------------
+
+If the VM is inaccessible (doesn't respond to qrexec commands, gui is not functioning), try to boot it in safe mode:
+
+-   `qvm-start --debug vmname`
+-   mash F8 on the boot screen to enable boot options and select Safe Mode (optionally with networking)
+
+Safe Mode should at least give you access to logs (see above).
+
+**Please include appropriate logs when reporting bugs/problems.** Starting from version 2.4.2 logs contain QTW version, but if you're using an earlier version be sure to mention which one. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (`qvm-start --debug vmname`). If it's not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the `memory.dmp` dump file from c:\Windows.
+Xen logs (/var/log/xen/console/guest-*) are also useful as they contain pvdrivers diagnostic output.
+
+If a specific component is malfunctioning, you can increase it's log verbosity as explained above to get more troubleshooting information. Below is a list of components:
+
+||
+|qrexec-agent|Responsible for most communication with Qubes (dom0 and other domains), secure clipboard, file copying, qrexec services.|
+|qrexec-client-vm|Used for communications by the qrexec protocol.|
+|qga|Gui agent.|
+|QgaWatchdog|Service that monitors session/desktop changes (logon/logoff/locking/UAC...) and simulates SAS sequence (ctrl-alt-del).|
+|qubesdb-daemon|Service for accessing Qubes configuration database.|
+|network-setup|Service that sets up network parameters according to VM's configuration.|
+|prepare-volume|Utility that initializes and formats the disk backed by `private.img` file. It's registered to run on next system boot during QTW setup, if that feature is selected (it can't run *during* the setup because Xen block device drivers are not yet active). It in turn registers move-profiles (see below) to run at early boot.|
+|move-profiles|Utility that moves user profiles directory to the private disk. It's registered as an early boot native executable (similar to chkdsk) so it can run before any profile files are opened by some other process. Its log is in a fixed location: `c:\move-profiles.log` (it can't use our common logger library so none of the log settings apply).|
+
+Updates
+-------
+
+When we publish new QTW version (which is announced on `qubes-users` Google Group) it's usually pushed to the `current-testing` or `unstable` repository first. To use versions from current-testing, run this in dom0:
+
+`qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools`
+
+That command will download a new QTW .iso from the testing repository. It goes without saying that you should **backup your VMs** before installing anything from testing repos.

YubiKey.md

@@ -92,3 +92,44 @@ When everything is ok, your screen will be unlocked.
 
 In any case you can still use your login password, but do it in secure location
 where no one can snoop your password.
+
+Locking the screen when YubiKey is removed
+------------------------------------------
+
+You can setup your system to automatically lock the screen when you unplug
+YubiKey. This will require creating simple qrexec service which will expose
+ability to lock the screen to your USB VM, and then adding udev hook to
+actually call that service.
+
+1. First configure the qrexec service. Create `/etc/qubes-rpc/custom.LockScreen` (in dom0)
+  with simple command to lock the screen. In case of xscreensaver (used in Xfce)
+  it would be:
+
+        DISPLAY=:0 xscreensaver-command -lock
+
+2. Allow your USB VM to call that service. Assuming that its named `sys-usb` it
+would require creating `/etc/qubes-rpc/policy/custom.LockScreen` with:
+
+        sys-usb dom0 allow
+
+3. Create udev hook in your USB VM. Store it in `/rw/config` to have it
+persistent across VM restarts. For example name the file
+`/rw/config/yubikey.rules`. Write there single line:
+
+        ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen"
+
+4. Ensure that the udev hook is placed in the right place after VM restart. Append to `/rw/config/rc.local`:
+
+        ln -s /rw/config/yubikey.rules /etc/udev/rules.d/
+        udevadm control --reload
+
+  Then make `/rw/config/rc.local` executable. For changes to take effect, you
+  need to call this script manually for the first time.
+
+If you use KDE, the command(s) in first step would be different:
+
+        # In case of USB VM being autostarted, it will not have direct access to D-Bus
+        # session bus, so find its address manually:
+        kde_pid=`pidof kdeinit4`
+        export `cat /proc/$kde_pid/environ|grep -ao 'DBUS_SESSION_BUS_ADDRESS=[[:graph:]]*'`
+        qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock

community.md

@@ -12,12 +12,12 @@ Add **Qubes OS** to refine your query, you might find just what you need.
 
 ## [QubesOS Mailing Lists]({{ site.url }}{{ site.baseurl }}/doc/QubesLists/)
 
--   Please send all the questions regarding Qubes OS to one of [these]({{ site.url }}{{ site.baseurl }}/doc/QubesLists/) mailing lists. 
+-   Please send all the questions regarding Qubes OS to one of [these]({{ site.url }}{{ site.baseurl }}/doc/QubesLists/) mailing lists.
 -   To subscribe to the user list, send a blank mail to `qubes-users+subscribe@googlegroups.com`.
--   By sending a message to the appropriate mailing list, you are not only giving others a chance to help you, 
+-   By sending a message to the appropriate mailing list, you are not only giving others a chance to help you,
 but you may also be helping others by starting a public discussion about a shared problem or interest.
--   **Please do not send questions to individual Qubes developers.** 
--   **Please do not [top-post](https://en.wikipedia.org/wiki/Posting_style), use inline replying or bottom-posting instead.** 
+-   **Please do not send questions to individual Qubes developers.**
+-   **Please do not [top-post](https://en.wikipedia.org/wiki/Posting_style), use inline replying or bottom-posting instead.**
 
 ## [QubesOS/qubes-doc]({{ site.url }}{{ site.baseurl }}/doc/UserFaq/#qubes-users-faq)