Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-07-28 01:05:56 -04:00
Code Issues Projects Releases Packages Wiki Activity

formatting, webarchive links, add icons

Browse source
This commit is contained in:
qubedmaiska 2025-02-27 16:10:31 -05:00
parent 2093a276b8
commit d4461fb4cb
No known key found for this signature in database
GPG key ID: 204BCE0FD52C0501
6 changed files with 15 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

2
developer/services/qfilecopy.md
View file

@ -24,6 +24,6 @@ This has the following disadvantages:
In modern Qubes OS releases, we have reimplemented interVM file copy using qrexec, which addresses the above mentioned disadvantages. Nowadays, even more generic solution (qubes rpc) is used. See the developer docs on qrexec and qubes rpc. In a nutshell, the file sender and the file receiver just read/write from stdin/stdout, and the qubes rpc layer passes data properly - so, no block devices are used. In modern Qubes OS releases, we have reimplemented interVM file copy using qrexec, which addresses the above mentioned disadvantages. Nowadays, even more generic solution (qubes rpc) is used. See the developer docs on qrexec and qubes rpc. In a nutshell, the file sender and the file receiver just read/write from stdin/stdout, and the qubes rpc layer passes data properly - so, no block devices are used.
The rpc action for regular file copy is *qubes.Filecopy*, the rpc client is named *qfile-agent*, the rpc server is named *qfile-unpacker*. For DispVM copy, the rpc action is *qubes.OpenInVM*, the rpc client is named *qopen-in-vm*, rpc server is named *vm-file-editor*. Note that the qubes.OpenInVM action can be done on a normal AppVM, too. The rpc action for regular file copy is *qubes.Filecopy*, the rpc client is named *qfile-agent*, the rpc server is named *qfile-unpacker*. For DispVM copy, the rpc action is *qubes.OpenInVM*, the rpc client is named *qopen-in-vm*, rpc server is named *vm-file-editor*. Note that the *qubes.OpenInVM* action can be done on a normal AppVM, too.
Being a rpc server, *qfile-unpacker* must be coded securely, as it processes potentially untrusted data format. Particularly, we do not want to use external tar or cpio and be prone to all vulnerabilities in them; we want a simplified, small utility, that handles only directory/file/symlink file type, permissions, mtime/atime, and assume user/user ownership. In the current implementation, the code that actually parses the data from srcVM has ca 100 lines of code and executes chrooted to the destination directory. The latter is hardcoded to `~user/QubesIncoming/srcVM`; because of chroot, there is no possibility to alter files outside of this directory. Being a rpc server, *qfile-unpacker* must be coded securely, as it processes potentially untrusted data format. Particularly, we do not want to use external tar or cpio and be prone to all vulnerabilities in them; we want a simplified, small utility, that handles only directory/file/symlink file type, permissions, mtime/atime, and assume user/user ownership. In the current implementation, the code that actually parses the data from srcVM has ca 100 lines of code and executes chrooted to the destination directory. The latter is hardcoded to `~user/QubesIncoming/srcVM`; because of chroot, there is no possibility to alter files outside of this directory.

12
developer/services/qmemman.md
View file

@ -15,7 +15,7 @@ Rationale
Traditionally, Xen VMs are assigned a fixed amount of memory. It is not the optimal solution, as some VMs may require more memory than assigned initially, while others underutilize memory. Thus, there is a need for solution capable of shifting free memory from VM to another VM. Traditionally, Xen VMs are assigned a fixed amount of memory. It is not the optimal solution, as some VMs may require more memory than assigned initially, while others underutilize memory. Thus, there is a need for solution capable of shifting free memory from VM to another VM.
The [tmem](https://oss.oracle.com/projects/tmem/) project provides a "pseudo-RAM" that is assigned on per-need basis. However this solution has some disadvantages: The [tmem](https://web.archive.org/web/20210712161104/https://oss.oracle.com/projects/tmem/) project provides a "pseudo-RAM" that is assigned on per-need basis. However this solution has some disadvantages:
- It does not provide real RAM, just an interface to copy memory to/from fast, RAM-based storage. It is perfect for swap, good for file cache, but not ideal for many tasks. - It does not provide real RAM, just an interface to copy memory to/from fast, RAM-based storage. It is perfect for swap, good for file cache, but not ideal for many tasks.
- It is deeply integrated with the Linux kernel. When Qubes will support Windows guests natively, we would have to port *tmem* to Windows, which may be challenging. - It is deeply integrated with the Linux kernel. When Qubes will support Windows guests natively, we would have to port *tmem* to Windows, which may be challenging.
@ -24,13 +24,19 @@ Therefore, in Qubes another solution is used. There is the *qmemman* dom0 daemon
Similarly, when there is need for Xen free memory (for instance, in order to create a new VM), traditionally the memory is obtained from dom0 only. When *qmemman* is running, it offers an interface to obtain memory from all domains. Similarly, when there is need for Xen free memory (for instance, in order to create a new VM), traditionally the memory is obtained from dom0 only. When *qmemman* is running, it offers an interface to obtain memory from all domains.
To sum up, *qmemman* pros and cons. Pros: To sum up, *qmemman* pros and cons.
<div class="focus">
<i class="fa fa-check"></i> <strong>Pros</strong>
</div>
- provides automatic balancing of memory across participating PV and HVM domains, based on their memory demand - provides automatic balancing of memory across participating PV and HVM domains, based on their memory demand
- works well in practice, with less than 1% CPU consumption in the idle case - works well in practice, with less than 1% CPU consumption in the idle case
- simple, concise implementation - simple, concise implementation
Cons: <div class="focus">
<i class="fa fa-times"></i> <strong>Cons</strong>
</div>
- the algorithm to calculate the memory requirement for a domain is necessarily simple, and may not closely reflect reality - the algorithm to calculate the memory requirement for a domain is necessarily simple, and may not closely reflect reality
- *qmemman* is notified by a VM about memory usage change not more often than 10 times per second (to limit CPU overhead in VM). Thus, there can be up to 0.1s delay until qmemman starts to react to the new memory requirements - *qmemman* is notified by a VM about memory usage change not more often than 10 times per second (to limit CPU overhead in VM). Thus, there can be up to 0.1s delay until qmemman starts to react to the new memory requirements

2
user/advanced-topics/bind-dirs.md
View file

@ -19,7 +19,7 @@ In an app qube all of the file system comes from the template except `/home`, `/
This means that changes in the rest of the filesystem are lost when the app qube is shutdown. This means that changes in the rest of the filesystem are lost when the app qube is shutdown.
bind-dirs provides a mechanism whereby files usually taken from the template can be persisted across reboots. bind-dirs provides a mechanism whereby files usually taken from the template can be persisted across reboots.
For example, in Whonix, Tor's data dir `/var/lib/tor` [has been made persistent](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5) in the TemplateBased ProxyVM sys-whonix. In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a standalone. For example, in Whonix, Tor's data dir `/var/lib/tor` [has been made persistent in the TemplateBased ProxyVM sys-whonix](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5). In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a standalone.
## How to use bind-dirs.sh? ## How to use bind-dirs.sh?

4
user/advanced-topics/gui-configuration.md
View file

@ -42,8 +42,8 @@ You might face issues when playing video, if the video is choppy instead of
smooth display this could be because the X server doesn't work. You can use the smooth display this could be because the X server doesn't work. You can use the
Linux terminal (Ctrl-Alt-F2) after starting the virtual machine, login. You can Linux terminal (Ctrl-Alt-F2) after starting the virtual machine, login. You can
look at the Xorg logs file. As an option you can have the below config as look at the Xorg logs file. As an option you can have the below config as
well present in `/etc/X11/xorg.conf.d/90-intel.conf`, depends on HD graphics well present in `/etc/X11/xorg.conf.d/90-intel.conf` (depends on HD graphics
though - though).
```bash ```bash
Section "Device" Section "Device"

2
user/advanced-topics/mount-from-other-os.md
View file

@ -90,7 +90,7 @@ Reverting Changes
----------------------------------------- -----------------------------------------
Any changes which were made to the system in the above steps will need to be reverted before the disk will properly boot. Any changes which were made to the system in the above steps will need to be reverted before the disk will properly boot.
However, LVM will not allow an VG to be renamed to a name already in use. However, LVM will not allow a VG to be renamed to a name already in use.
Thes steps must occur either in an app qube or using recovery media. Thes steps must occur either in an app qube or using recovery media.
1. Unmount any disks that were accessed. 1. Unmount any disks that were accessed.

2
user/reference/glossary.md
View file

@ -137,7 +137,7 @@ its net qube.
## policies ## policies
In Qubes OS, "policies" govern interactions between qubes, powered by [Qubes' qrexec system](https://www.qubes-os.org/doc/qrexec/). In Qubes OS, "policies" govern interactions between qubes, powered by [Qubes' qrexec system](/doc/qrexec/).
A single policy is a rule applied to a qube or set of qubes, that governs how and when information or assets may be shared with other qubes. A single policy is a rule applied to a qube or set of qubes, that governs how and when information or assets may be shared with other qubes.
An example is the rules governing how files can be copied between qubes. An example is the rules governing how files can be copied between qubes.
Policy rules are grouped together in files under `/etc/qubes/policy.d` Policy rules are grouped together in files under `/etc/qubes/policy.d`