https://wiki.archlinux.org/api.php?action=feedcontributions&user=Ivank&feedformat=atomArchWiki - User contributions [en]2024-03-28T15:02:52ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:QEMU&diff=575669Talk:QEMU2019-06-15T18:48:42Z<p>Ivank: /* Options for fstab with 9p */ wording</p>
<hr />
<div>== Linear RAID ==<br />
<br />
When I was updating the article yesterday, I had tried to fit the section about linear raid (boot a VM from a partition by prepending a MBR to it) into the article better. But I'm not sure the technique described is the right one at all. It looks like it works, but wouldn't it be easier to install a bootloader directly to the partition (e.g. syslinux)? Then the VM could be booted directly from the partition simply by using it as its virtual disk.<br />
--[[User:Synchronicity|Synchronicity]] ([[User talk:Synchronicity|talk]]) 19:23, 9 May 2012 (UTC)<br />
<br />
:What about Windows installations then? [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 09:18, 4 October 2016 (UTC)<br />
<br />
== Creating bridge manually ==<br />
<br />
I really don't know what to do with this section. I'd say it has been superseded by [[QEMU#Creating bridge using qemu-bridge-helper]] (available since qemu-1.1, we now have qemu-1.5) - or is someone still using this method? Perhaps link to https://en.wikibooks.org/wiki/QEMU/Networking#TAP_interfaces or http://wiki.qemu.org/Documentation/Networking/NAT is sufficient. What do you think? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:42, 22 July 2013 (UTC)<br />
<br />
:Actually, I've become a happy user of this method. I've written some scripts to easily create bridge interface, TAP interface, and combined with Xyne's [http://xyne.archlinux.ca/notes/network/dhcp_with_dns.html excellent scripts] to set up NAT and launch DHCP server, I have complete solution to easily manage multiple VMs on one (or even more) bridge.<br />
:My scripts are available on github: [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-launcher.sh], [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-tap-helper.sh], [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-mac-hasher.py] but I won't probably integrate them into the wiki, I'l just leave a note when I do some more testing.<br />
:The thing is, what to do with the current content? Personally I think that links to [https://en.wikibooks.org/wiki/QEMU/Networking#TAP_interfaces], [http://wiki.qemu.org/Documentation/Networking/NAT] and my scripts are sufficient (of course others are welcome). I'd also leave the note at the end to ''disable the firewall on the bridge'', I find it extremely useful.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:24, 5 September 2013 (UTC)<br />
<br />
:I would not remove something that works still heh.--[[User:Webdawg|Webdawg]] ([[User talk:Webdawg|talk]]) 07:31, 17 July 2016 (UTC)<br />
<br />
== Kexec Hackery When Using a Real Partition ==<br />
<br />
After banging my head against a wall long enough and figuring out what {{ic|-kernel}} and {{ic|-initrd}} were really calling, I put a note above the appropriate section and mentioned two ways to use the guest's images. (Otherwise, you'll have to worry if the host and guest images match.) The first -- mount the partition(s) -- is more appropriate for "low-volume-handling" of VMs. The second -- using kexec -- becomes more useful when you're juggling more than a few VMs.<br />
<br />
I'm only mentioning this hack because (as of now) [[Kexec]] only mentions use for rebooting into another kernel, not switching out the kernel before the system is even up. This hack comes from from https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader- which has two suggestions. The most recent, using systemd units by jkuan, doesn't work because jkuan tried to copy a {{ic|.target}} file into a {{ic|.service}} file and systemd wants {{ic|ExecStart}} in a {{ic|.service}} file. The second one, replacing {{ic|/usr/bin/init}} by andrew_sparks, works for me on my Arch instance at DigitalOcean.<br />
<br />
Adaptation from said post:<br />
<br />
# pacman -S kexec-tools<br />
# pacman -R systemd-sysvcompat<br />
<br />
{{hc|1=/tmp/init|2=<br />
#!/bin/sh<br />
<br />
kexec --load /boot/vmlinuz-linux --initrd=/boot/initramfs-linux.img --append="root=/dev/sda init=/usr/lib/systemd/systemd" &&<br />
mount -o ro,remount / && kexec -e<br />
exec /usr/lib/systemd/systemd<br />
}}<br />
<br />
# cd [/path/to/vm]/usr/bin<br />
# mv init init.dist<br />
# cp /tmp/init ./<br />
# chmod 755 init<br />
<br />
I'm leaving this on the Talk page as I haven't even tried it out in QEMU myself. Also, my eyes are about ready to pop out of my head, so I'm barring myself from figuring out the appropriate way to edit this in for the time being. [[User:BrainwreckedTech|BrainwreckedTech]] ([[User talk:BrainwreckedTech|talk]]) 21:23, 14 January 2014 (UTC)<br />
<br />
== Replace -net with -netdev ==<br />
<br />
The {{ic|-net}} option is deprecated and replaced by {{ic|-netdev}}. I think this article should be modified to reflect that.<br />
http://en.wikibooks.org/wiki/QEMU/Networking#cite_ref-1<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 18:12, 1 July 2014 (UTC)<br />
<br />
:Yes {{ic|-net}} is the old syntax as stated in [https://wiki.gentoo.org/wiki/QEMU/Options#Pass-through Gentoo's Wiki] where we should use {{ic|1=-netdev user,id=vmnic -device virtio-net,netdev=vmnic}} [[User:Pickfire|Pickfire]] ([[User talk:Pickfire|talk]]) 04:11, 31 March 2017 (UTC)<br />
<br />
== I'm rewriting the network section ==<br />
<br />
https://wiki.archlinux.org/index.php/User:Axper/sandbox/qemu_network<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 20:07, 2 July 2014 (UTC)<br />
<br />
::I think a lot of networking topics could be moved outside of the QEMU page. Many virtualization applications share the same basic principles with regards to networking, such as tun/tap creating, bridges, VDE, etc. There are a few networking schemes that are QEMU-specific, for example multicast sockets and {{ic|-net socket,...}}, and these could be mentioned on the QEMU page, although these are less reliable and rarely used in comparison to tap devices. We should also of course note the QEMU-specific command line options in the QEMU page, but for general concepts and commands independent of the virtualization applications, they could go on pages dedicated to the task. The best example is VDE, which is in no way limited to QEMU, yet it still doesn't have its own page on the Arch wiki.<br />
<br />
::Incidentally, I'm planning on rewriting [[User Mode Linux]] (yes, I promise I will get around to it), which happens to share the "tap with bridge" and VDE concepts with QEMU. It would be nice if I could link to pages dedicated to those topics and only write UML-specific commands in the page, instead of duplicating a bunch of general information. I'm not familiar very familiar with Xen or LXC or Docker or the like, but I would suspect that they also share some networking infrastructure. We could possibly even create a category just for these types of pages, for example "Virtual Networking" or "Advanced Networking". [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 13:32, 19 February 2015 (UTC)<br />
<br />
== -enable-kvm vs -machine type=pc,accel=kvm ==<br />
<br />
The section [[QEMU#Enabling_KVM]] recommends {{ic|-enable-kvm}}, while [[QEMU#Virtual_machine_runs_too_slowly]] recommends {{ic|1=-machine type=pc,accel=kvm}}. Is there any difference between the two? Is one preferred over the other? Should we just link to the former section from the latter (and possibly move both command line switches to the same section)? [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 17:23, 18 January 2015 (UTC)<br />
<br />
:2.5 years later... Has anyone found an answer to the question of `-enable-kvm` VS `-machine type=pc,accel=kvm`? -[[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 19:32, 3 August 2017 (UTC)<br />
<br />
::Yes. They're equivalent. [https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00132.html Discussion on the QEMU mailing list] about marking {{ic|-enable-kvm}} deprecated didn't result in that; {{ic|-enable-hax}} did get deprecated. Confusing, especially when checking whether e.g. libvirt has actually started the machine with KVM enabled. [[User:MacGyver|MacGyver]] ([[User talk:MacGyver|talk]]) 16:24, 4 December 2018 (UTC)<br />
<br />
== virtio-gpu ==<br />
<br />
Any tutorial on using the new virtio-gpu which is introduced in qemu-2.4 and kernel 4.2? [[User:Adam900710|Adam900710]] ([[User talk:Adam900710|talk]]) 02:44, 19 August 2015 (UTC)<br />
<br />
:Should be "plug and play" with recent kernel and other packages: [https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/ article]. The article is about libvirt, but I've run Arch guest on Arch host successfully with qemu script. [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 09:24, 4 October 2016 (UTC)<br />
<br />
== host only networking ==<br />
<br />
I added a quick and easy method but it was deleted. I found errors in what is here. Is it worth my time to correct them or will they be deleted? {{unsigned|16:39, 4 January 2016|Netskink}}<br />
<br />
:You are welcome to make any corrections. Nobody can tell you if they will be kept or reverted beforehand, but if you're afraid to waste your time feel free to just point them out using an [[Help:Template|Article status templates|article status template]] (should be less time consuming). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:28, 21 February 2016 (UTC)<br />
<br />
== Windows 7 specific issues ==<br />
<br />
I have noticed that for me, any attempts at installing Windows 7 using qemu with virt-manager as a frontend stalls on "Starting Windows." This is immediately after booting the computer for the first time. In Virt-manager, I am able to change the Display from QXL to Cirrus to fix the issue. I'm not sure if this applies to this page in particular, but if so, might be worth adding to the "Troubleshooting" section -- [[User:Ephreal|Ephreal]] ([[User talk:Ephreal|talk]]) 14:25, 10 August 2016 (UTC)<br />
<br />
== Using existing partition on GPT disk (with linear RAID or otherwise) ==<br />
<br />
[https://wiki.archlinux.org/index.php/QEMU#Simulate_virtual_disk_with_MBR_using_linear_RAID Section on using existing partition] is pretty awesome, but it is MBR-specific. Can someone with enough knowledge create a similar section about GPT disk please?<br />
<br />
== Could not access KVM kernel module: Permission denied ==<br />
<br />
Simply changing {{ic|1=group = "78"}} to {{ic|1=group = "kvm"}} in {{ic|/etc/libvirt/qemu.conf}} was not enough for me to fix this issue. Indeed, some files were still installed with gid 78, which you can confirm with:<br />
<br />
find / -gid 78<br />
<br />
So in the end, I still had to change the group id of kvm to workaround this issue:<br />
<br />
groupmod -g 78 kvm<br />
<br />
{{unsigned|17:15, 1 September 2017|Nivata}}<br />
<br />
== Starting QEMU virtual machines with systemd in 2018 ==<br />
<br />
The custom service script uses KillMethod=none to avoid the virtual machine being killed before shutdown. Here is an example to avoid this logic using {{Pkg|socat}}:<br />
<br />
ExecStart=/usr/bin/env qemu-system-x86_64 -name %i … -monitor unix:/var/run/qemu-%i.monitor,server,nowait<br />
ExecStop=/bin/sh -c 'echo system_powerdown | socat stdio,ignoreeof /var/run/qemu-%i.monitor'<br />
<br />
In this way, the stop command will exit when the QEMU monitor closes the socket. Other options, e.g. PIDFile or KillMode are not necessary.<br />
<br />
While a unix socket is used for this example, it works as well with telnet/tcp-connect.<br />
[[User:Ypnos|Ypnos]] ([[User talk:Ypnos|talk]]) 18:29, 30 January 2018 (UTC)<br />
<br />
I've tested using {{Pkg|openbsd-netcat}}, and that variant seems to keep the connection open after issuing the command as well. So there are a couple options to avoid using the KillMethod, which I agree is not a good idea.<br />
[[User:Djmoch|Djmoch]] ([[User talk:Djmoch|talk]]) 13:21, 2 March 2019 (UTC)<br />
<br />
== e1000e: waiting for carrier... timed out ==<br />
<br />
my physical host is an ArchLinux with 4.14.40-1-lts kernel and Qemu 2.12.0.<br />
<br />
in my first virtualisation case, my guest is an ArchLinux with 4.9.36-1-lts kernel (e1000e ver. 3.2.6-k) : everything works normally when I request the assignment of a network address with dhcpcd (after a few seconds, my guest gets the 10.0.2.15 intended address).<br />
<br />
in my second virtualisation case, my guest is an ArchLinux with 4.14.40-1-lts kernel (e1000e ver. 3.2.6-k) : no carrier is detected and therefore no address is assigned to the enp0s2 network card.<br />
<br />
I think the problem would rather come from the virtualized 4.14.40-1-lts kernel side because I do not meet it on my physical host which also uses the e1000e module...<br />
<br />
does anyone have an idea or a lead ?<br />
<br />
(this problem does not appear if I add in both cases the parameter "-machine pc" which forces the use of the module e1000/ens3 instead of the module e1000e/enp0s2).<br />
<br />
[[User:Lacsap|Lacsap]] ([[User talk:Lacsap|talk]]) 16:09, 28 May 2018 (UTC)<br />
<br />
== Options for fstab with 9p ==<br />
https://wiki.archlinux.org/index.php?title=QEMU&diff=next&oldid=573709<br />
<br />
Maybe the options are not very hard to deduce, but they are not obvious, and having them written down is very useful as a "cheat sheet".<br />
<br />
[[User:Marmistrz|Marmistrz]] ([[User talk:Marmistrz|talk]]) 15:19, 15 June 2019 (UTC)<br />
<br />
:The options (and more) are written on the page which is linked from the section: https://wiki.qemu.org/Documentation/9psetup -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:23, 15 June 2019 (UTC)<br />
<br />
: +1 to keep the options. I suggest also to mention <tt>msize=512000</tt> option necessary to achieve satisfactory performance, this is something qemu docs fail to mention [[User:Ivank|Ivank]] ([[User talk:Ivank|talk]]) 17:39, 15 June 2019 (UTC)<br />
<br />
::{{ic|msize}} is also mentioned on the linked page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:13, 15 June 2019 (UTC)<br />
<br />
::: Yes, in a totally useless way, just that msize exists and 8192 is the default. msize=512000 (max) vs msize=8192 (default) is 10x throughput difference in my testing, that's not mentioned and I'd argue is a much more important and helpful fact to know for a user. [[User:Ivank|Ivank]] ([[User talk:Ivank|talk]]) 18:40, 15 June 2019 (UTC)</div>Ivankhttps://wiki.archlinux.org/index.php?title=Talk:QEMU&diff=575665Talk:QEMU2019-06-15T18:40:14Z<p>Ivank: /* Options for fstab with 9p */ reply</p>
<hr />
<div>== Linear RAID ==<br />
<br />
When I was updating the article yesterday, I had tried to fit the section about linear raid (boot a VM from a partition by prepending a MBR to it) into the article better. But I'm not sure the technique described is the right one at all. It looks like it works, but wouldn't it be easier to install a bootloader directly to the partition (e.g. syslinux)? Then the VM could be booted directly from the partition simply by using it as its virtual disk.<br />
--[[User:Synchronicity|Synchronicity]] ([[User talk:Synchronicity|talk]]) 19:23, 9 May 2012 (UTC)<br />
<br />
:What about Windows installations then? [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 09:18, 4 October 2016 (UTC)<br />
<br />
== Creating bridge manually ==<br />
<br />
I really don't know what to do with this section. I'd say it has been superseded by [[QEMU#Creating bridge using qemu-bridge-helper]] (available since qemu-1.1, we now have qemu-1.5) - or is someone still using this method? Perhaps link to https://en.wikibooks.org/wiki/QEMU/Networking#TAP_interfaces or http://wiki.qemu.org/Documentation/Networking/NAT is sufficient. What do you think? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:42, 22 July 2013 (UTC)<br />
<br />
:Actually, I've become a happy user of this method. I've written some scripts to easily create bridge interface, TAP interface, and combined with Xyne's [http://xyne.archlinux.ca/notes/network/dhcp_with_dns.html excellent scripts] to set up NAT and launch DHCP server, I have complete solution to easily manage multiple VMs on one (or even more) bridge.<br />
:My scripts are available on github: [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-launcher.sh], [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-tap-helper.sh], [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-mac-hasher.py] but I won't probably integrate them into the wiki, I'l just leave a note when I do some more testing.<br />
:The thing is, what to do with the current content? Personally I think that links to [https://en.wikibooks.org/wiki/QEMU/Networking#TAP_interfaces], [http://wiki.qemu.org/Documentation/Networking/NAT] and my scripts are sufficient (of course others are welcome). I'd also leave the note at the end to ''disable the firewall on the bridge'', I find it extremely useful.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:24, 5 September 2013 (UTC)<br />
<br />
:I would not remove something that works still heh.--[[User:Webdawg|Webdawg]] ([[User talk:Webdawg|talk]]) 07:31, 17 July 2016 (UTC)<br />
<br />
== Kexec Hackery When Using a Real Partition ==<br />
<br />
After banging my head against a wall long enough and figuring out what {{ic|-kernel}} and {{ic|-initrd}} were really calling, I put a note above the appropriate section and mentioned two ways to use the guest's images. (Otherwise, you'll have to worry if the host and guest images match.) The first -- mount the partition(s) -- is more appropriate for "low-volume-handling" of VMs. The second -- using kexec -- becomes more useful when you're juggling more than a few VMs.<br />
<br />
I'm only mentioning this hack because (as of now) [[Kexec]] only mentions use for rebooting into another kernel, not switching out the kernel before the system is even up. This hack comes from from https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader- which has two suggestions. The most recent, using systemd units by jkuan, doesn't work because jkuan tried to copy a {{ic|.target}} file into a {{ic|.service}} file and systemd wants {{ic|ExecStart}} in a {{ic|.service}} file. The second one, replacing {{ic|/usr/bin/init}} by andrew_sparks, works for me on my Arch instance at DigitalOcean.<br />
<br />
Adaptation from said post:<br />
<br />
# pacman -S kexec-tools<br />
# pacman -R systemd-sysvcompat<br />
<br />
{{hc|1=/tmp/init|2=<br />
#!/bin/sh<br />
<br />
kexec --load /boot/vmlinuz-linux --initrd=/boot/initramfs-linux.img --append="root=/dev/sda init=/usr/lib/systemd/systemd" &&<br />
mount -o ro,remount / && kexec -e<br />
exec /usr/lib/systemd/systemd<br />
}}<br />
<br />
# cd [/path/to/vm]/usr/bin<br />
# mv init init.dist<br />
# cp /tmp/init ./<br />
# chmod 755 init<br />
<br />
I'm leaving this on the Talk page as I haven't even tried it out in QEMU myself. Also, my eyes are about ready to pop out of my head, so I'm barring myself from figuring out the appropriate way to edit this in for the time being. [[User:BrainwreckedTech|BrainwreckedTech]] ([[User talk:BrainwreckedTech|talk]]) 21:23, 14 January 2014 (UTC)<br />
<br />
== Replace -net with -netdev ==<br />
<br />
The {{ic|-net}} option is deprecated and replaced by {{ic|-netdev}}. I think this article should be modified to reflect that.<br />
http://en.wikibooks.org/wiki/QEMU/Networking#cite_ref-1<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 18:12, 1 July 2014 (UTC)<br />
<br />
:Yes {{ic|-net}} is the old syntax as stated in [https://wiki.gentoo.org/wiki/QEMU/Options#Pass-through Gentoo's Wiki] where we should use {{ic|1=-netdev user,id=vmnic -device virtio-net,netdev=vmnic}} [[User:Pickfire|Pickfire]] ([[User talk:Pickfire|talk]]) 04:11, 31 March 2017 (UTC)<br />
<br />
== I'm rewriting the network section ==<br />
<br />
https://wiki.archlinux.org/index.php/User:Axper/sandbox/qemu_network<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 20:07, 2 July 2014 (UTC)<br />
<br />
::I think a lot of networking topics could be moved outside of the QEMU page. Many virtualization applications share the same basic principles with regards to networking, such as tun/tap creating, bridges, VDE, etc. There are a few networking schemes that are QEMU-specific, for example multicast sockets and {{ic|-net socket,...}}, and these could be mentioned on the QEMU page, although these are less reliable and rarely used in comparison to tap devices. We should also of course note the QEMU-specific command line options in the QEMU page, but for general concepts and commands independent of the virtualization applications, they could go on pages dedicated to the task. The best example is VDE, which is in no way limited to QEMU, yet it still doesn't have its own page on the Arch wiki.<br />
<br />
::Incidentally, I'm planning on rewriting [[User Mode Linux]] (yes, I promise I will get around to it), which happens to share the "tap with bridge" and VDE concepts with QEMU. It would be nice if I could link to pages dedicated to those topics and only write UML-specific commands in the page, instead of duplicating a bunch of general information. I'm not familiar very familiar with Xen or LXC or Docker or the like, but I would suspect that they also share some networking infrastructure. We could possibly even create a category just for these types of pages, for example "Virtual Networking" or "Advanced Networking". [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 13:32, 19 February 2015 (UTC)<br />
<br />
== -enable-kvm vs -machine type=pc,accel=kvm ==<br />
<br />
The section [[QEMU#Enabling_KVM]] recommends {{ic|-enable-kvm}}, while [[QEMU#Virtual_machine_runs_too_slowly]] recommends {{ic|1=-machine type=pc,accel=kvm}}. Is there any difference between the two? Is one preferred over the other? Should we just link to the former section from the latter (and possibly move both command line switches to the same section)? [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 17:23, 18 January 2015 (UTC)<br />
<br />
:2.5 years later... Has anyone found an answer to the question of `-enable-kvm` VS `-machine type=pc,accel=kvm`? -[[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 19:32, 3 August 2017 (UTC)<br />
<br />
::Yes. They're equivalent. [https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00132.html Discussion on the QEMU mailing list] about marking {{ic|-enable-kvm}} deprecated didn't result in that; {{ic|-enable-hax}} did get deprecated. Confusing, especially when checking whether e.g. libvirt has actually started the machine with KVM enabled. [[User:MacGyver|MacGyver]] ([[User talk:MacGyver|talk]]) 16:24, 4 December 2018 (UTC)<br />
<br />
== virtio-gpu ==<br />
<br />
Any tutorial on using the new virtio-gpu which is introduced in qemu-2.4 and kernel 4.2? [[User:Adam900710|Adam900710]] ([[User talk:Adam900710|talk]]) 02:44, 19 August 2015 (UTC)<br />
<br />
:Should be "plug and play" with recent kernel and other packages: [https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/ article]. The article is about libvirt, but I've run Arch guest on Arch host successfully with qemu script. [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 09:24, 4 October 2016 (UTC)<br />
<br />
== host only networking ==<br />
<br />
I added a quick and easy method but it was deleted. I found errors in what is here. Is it worth my time to correct them or will they be deleted? {{unsigned|16:39, 4 January 2016|Netskink}}<br />
<br />
:You are welcome to make any corrections. Nobody can tell you if they will be kept or reverted beforehand, but if you're afraid to waste your time feel free to just point them out using an [[Help:Template|Article status templates|article status template]] (should be less time consuming). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:28, 21 February 2016 (UTC)<br />
<br />
== Windows 7 specific issues ==<br />
<br />
I have noticed that for me, any attempts at installing Windows 7 using qemu with virt-manager as a frontend stalls on "Starting Windows." This is immediately after booting the computer for the first time. In Virt-manager, I am able to change the Display from QXL to Cirrus to fix the issue. I'm not sure if this applies to this page in particular, but if so, might be worth adding to the "Troubleshooting" section -- [[User:Ephreal|Ephreal]] ([[User talk:Ephreal|talk]]) 14:25, 10 August 2016 (UTC)<br />
<br />
== Using existing partition on GPT disk (with linear RAID or otherwise) ==<br />
<br />
[https://wiki.archlinux.org/index.php/QEMU#Simulate_virtual_disk_with_MBR_using_linear_RAID Section on using existing partition] is pretty awesome, but it is MBR-specific. Can someone with enough knowledge create a similar section about GPT disk please?<br />
<br />
== Could not access KVM kernel module: Permission denied ==<br />
<br />
Simply changing {{ic|1=group = "78"}} to {{ic|1=group = "kvm"}} in {{ic|/etc/libvirt/qemu.conf}} was not enough for me to fix this issue. Indeed, some files were still installed with gid 78, which you can confirm with:<br />
<br />
find / -gid 78<br />
<br />
So in the end, I still had to change the group id of kvm to workaround this issue:<br />
<br />
groupmod -g 78 kvm<br />
<br />
{{unsigned|17:15, 1 September 2017|Nivata}}<br />
<br />
== Starting QEMU virtual machines with systemd in 2018 ==<br />
<br />
The custom service script uses KillMethod=none to avoid the virtual machine being killed before shutdown. Here is an example to avoid this logic using {{Pkg|socat}}:<br />
<br />
ExecStart=/usr/bin/env qemu-system-x86_64 -name %i … -monitor unix:/var/run/qemu-%i.monitor,server,nowait<br />
ExecStop=/bin/sh -c 'echo system_powerdown | socat stdio,ignoreeof /var/run/qemu-%i.monitor'<br />
<br />
In this way, the stop command will exit when the QEMU monitor closes the socket. Other options, e.g. PIDFile or KillMode are not necessary.<br />
<br />
While a unix socket is used for this example, it works as well with telnet/tcp-connect.<br />
[[User:Ypnos|Ypnos]] ([[User talk:Ypnos|talk]]) 18:29, 30 January 2018 (UTC)<br />
<br />
I've tested using {{Pkg|openbsd-netcat}}, and that variant seems to keep the connection open after issuing the command as well. So there are a couple options to avoid using the KillMethod, which I agree is not a good idea.<br />
[[User:Djmoch|Djmoch]] ([[User talk:Djmoch|talk]]) 13:21, 2 March 2019 (UTC)<br />
<br />
== e1000e: waiting for carrier... timed out ==<br />
<br />
my physical host is an ArchLinux with 4.14.40-1-lts kernel and Qemu 2.12.0.<br />
<br />
in my first virtualisation case, my guest is an ArchLinux with 4.9.36-1-lts kernel (e1000e ver. 3.2.6-k) : everything works normally when I request the assignment of a network address with dhcpcd (after a few seconds, my guest gets the 10.0.2.15 intended address).<br />
<br />
in my second virtualisation case, my guest is an ArchLinux with 4.14.40-1-lts kernel (e1000e ver. 3.2.6-k) : no carrier is detected and therefore no address is assigned to the enp0s2 network card.<br />
<br />
I think the problem would rather come from the virtualized 4.14.40-1-lts kernel side because I do not meet it on my physical host which also uses the e1000e module...<br />
<br />
does anyone have an idea or a lead ?<br />
<br />
(this problem does not appear if I add in both cases the parameter "-machine pc" which forces the use of the module e1000/ens3 instead of the module e1000e/enp0s2).<br />
<br />
[[User:Lacsap|Lacsap]] ([[User talk:Lacsap|talk]]) 16:09, 28 May 2018 (UTC)<br />
<br />
== Options for fstab with 9p ==<br />
https://wiki.archlinux.org/index.php?title=QEMU&diff=next&oldid=573709<br />
<br />
Maybe the options are not very hard to deduce, but they are not obvious, and having them written down is very useful as a "cheat sheet".<br />
<br />
[[User:Marmistrz|Marmistrz]] ([[User talk:Marmistrz|talk]]) 15:19, 15 June 2019 (UTC)<br />
<br />
:The options (and more) are written on the page which is linked from the section: https://wiki.qemu.org/Documentation/9psetup -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:23, 15 June 2019 (UTC)<br />
<br />
: +1 to keep the options. I suggest also to mention <tt>msize=512000</tt> option necessary to achieve satisfactory performance, this is something qemu docs fail to mention [[User:Ivank|Ivank]] ([[User talk:Ivank|talk]]) 17:39, 15 June 2019 (UTC)<br />
<br />
::{{ic|msize}} is also mentioned on the linked page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:13, 15 June 2019 (UTC)<br />
<br />
::: Yes, in a totally useless way. msize=512000 vs msize=8192 (default) is 10x speed difference, that's not mentioned and more important to the user. [[User:Ivank|Ivank]] ([[User talk:Ivank|talk]]) 18:40, 15 June 2019 (UTC)</div>Ivankhttps://wiki.archlinux.org/index.php?title=Data-at-rest_encryption&diff=575649Data-at-rest encryption2019-06-15T17:42:41Z<p>Ivank: /* Comparison table */ integrity an option in luks2; fix padding</p>
<hr />
<div>[[Category:Disk encryption]]<br />
[[es:Disk encryption]]<br />
[[it:Disk encryption]]<br />
[[ja:ディスク暗号化]]<br />
[[pl:Disk encryption]]<br />
[[zh-hans:Disk encryption]]<br />
{{Related articles start}}<br />
{{Related|dm-crypt}}<br />
{{Related|TrueCrypt}}<br />
{{Related|eCryptfs}}<br />
{{Related|EncFS}}<br />
{{Related|gocryptfs}}<br />
{{Related|Tomb}}<br />
{{Related|tcplay}}<br />
{{Related|GnuPG}}<br />
{{Related|Self-Encrypting Drives}}<br />
{{Related articles end}}<br />
This article discusses [[Wikipedia:Disk encryption|disk encryption]] software, which on-the-fly encrypts / decrypts data written to / read from a [[block device]], [[disk partition]] or directory. Examples for block devices are hard drives, flash drives and DVDs.<br />
<br />
Disk encryption should only be viewed as an adjunct to the existing security mechanisms of the operating system - focused on securing physical access, while relying on ''other'' parts of the system to provide things like network security and user-based access control.<br />
<br />
For Full-disk encryption (FDE), see [[dm-crypt/Encrypting an entire system]].<br />
<br />
==Why use encryption?==<br />
<br />
Disk encryption ensures that files are always stored on disk in an encrypted form. The files only become available to the operating system and applications in readable form while the system is running and unlocked by a trusted user. An unauthorized person looking at the disk contents directly, will only find garbled random-looking data instead of the actual files.<br />
<br />
For example, this can prevent unauthorized viewing of the data when the computer or hard-disk is:<br />
* located in a place to which non-trusted people might gain access while you are away<br />
* lost or stolen, as with laptops, netbooks or external storage devices<br />
* in the repair shop<br />
* discarded after its end-of-life<br />
<br />
In addition, disk encryption can also be used to add some security against unauthorized attempts to tamper with your operating system – for example, the installation of keyloggers or Trojan horses by attackers who can gain physical access to the system while you are away.<br />
<br />
{{Warning|Disk encryption does '''not''' protect your data from all threats.}}<br />
You will still be vulnerable to:<br />
* Attackers who can break into your system (e.g. over the Internet) while it is running and after you have already unlocked and mounted the encrypted parts of the disk.<br />
* Attackers who are able to gain physical access to the computer while it is running (even if you use a screenlocker), or very shortly ''after'' it was running, if they have the resources to perform a [[Wikipedia:Cold boot attack|cold boot attack]].<br />
* A government entity, which not only has the resources to easily pull off the above attacks, but also may simply force you to give up your keys/passphrases using various techniques of [[Wikipedia:Coercion|coercion]]. In most non-democratic countries around the world, as well as in the USA and UK, it may be legal for law enforcement agencies to do so if they have suspicions that you might be hiding something of interest.<br />
<br />
A very strong disk encryption setup (e.g. full system encryption with authenticity checking and no plaintext boot partition) is required to stand a chance against professional attackers who are able to tamper with your system ''before'' you use it. And even then it cannot prevent all types of tampering (e.g. hardware keyloggers). The best remedy might be [[Wikipedia:Hardware-based full disk encryption|hardware-based full disk encryption]] and [[Wikipedia:Trusted_Computing|Trusted Computing]].<br />
<br />
{{Warning|Disk encryption also will not protect you against someone simply [[Securely wipe disk|wiping your disk]]. [[Backup programs|Regular backups]] are recommended to keep your data safe.}}<br />
<br />
== System data encryption ==<br />
<br />
While encrypting only the user data itself (often located within the home directory, or on removable media like a data DVD), is the simplest and least intrusive method, it has some significant drawbacks.<br />
In modern computer systems, there are many background processes that may cache and store information about user data or parts of the data itself in non-encrypted areas of the hard drive, like:<br />
<br />
:* swap partitions<br />
:** (potential remedies: disable swapping, or use [[encrypted swap]] as well)<br />
:* {{ic|/tmp}} (temporary files created by user applications)<br />
:** (potential remedies: avoid such applications; mount {{ic|/tmp}} inside a [[ramdisk]])<br />
:* {{ic|/var}} (log files and databases and such; for example, [[mlocate]] stores an index of all file names in {{ic|/var/lib/mlocate/mlocate.db}})<br />
<br />
The solution is to encrypt both system and user data, preventing unauthorized physical access to private data that may be cached by the system. This however comes with the disadvantage that unlocking of the encrypted parts of the disk has to happen at boot time. Another benefit of system data encryption is that it complicates the installation of malware like [[Wikipedia:Keystroke logging|keyloggers]] or rootkits for someone with physical access.<br />
<br />
== Available methods ==<br />
<br />
{{Expansion|[[Ext4]], [[ZFS]] and possible other filesystems offer (native) encryption.}}<br />
<br />
All disk encryption methods operate in such a way that even though the disk actually holds encrypted data, the operating system and applications "see" it as the corresponding normal readable data as long as the cryptographic container (i.e. the logical part of the disk that holds the encrypted data) has been "unlocked" and mounted.<br />
<br />
For this to happen, some "secret information" (usually in the form of a keyfile and/or passphrase) needs to be supplied by the user, from which the actual encryption key can be derived (and stored in the kernel keyring for the duration of the session).<br />
<br />
If you are completely unfamiliar with this sort of operation, please also read the [[#How the encryption works]] section below.<br />
<br />
The available disk encryption methods can be separated into two types by their layer of operation:<br />
<br />
=== Stacked filesystem encryption ===<br />
<br />
Stacked filesystem encryption solutions are implemented as a layer that stacks on top of an existing filesystem, causing all files written to an encryption-enabled folder to be encrypted on-the-fly before the underlying filesystem writes them to disk, and decrypted whenever the filesystem reads them from disk. This way, the files are stored in the host filesystem in encrypted form (meaning that their contents, and usually also their file/folder names, are replaced by random-looking data of roughly the same length), but other than that they still exist in that filesystem as they would without encryption, as normal files / symlinks / hardlinks / etc.<br />
<br />
The way it is implemented, is that to unlock the folder storing the raw encrypted files in the host filesystem ("lower directory"), it is mounted (using a special stacked pseudo-filesystem) onto itself or optionally a different location ("upper directory"), where the same files then appear in readable form - until it is unmounted again, or the system is turned off.<br />
<br />
Available solutions in this category are [[eCryptfs]] and [[EncFS]].<br />
<br />
==== Cloud-storage optimized ====<br />
<br />
If you are deploying stacked filesystem encryption to achieve zero-knowledge synchronization with third-party-controlled locations such as cloud-storage services, you may want to consider alternatives to eCryptfs and EncFS, since these are not optimized for transmission of files over the Internet. There are some solutions designed for this purpose instead:<br />
<br />
* [[gocryptfs]]<br />
* {{aur|cryptomator}} (multi-platform)<br />
* {{pkg|cryfs}}<br />
<br />
Note that some cloud-storage services offer zero-knowledge encryption directly through their own [[List of applications/Internet#Cloud synchronization clients|client applications]].<br />
<br />
=== Block device encryption ===<br />
<br />
Block device encryption methods, on the other hand, operate ''below'' the filesystem layer and make sure that everything written to a certain block device (i.e. a whole disk, or a partition, or a file acting as a [[Wikipedia:loop device|loop device]]) is encrypted. This means that while the block device is offline, its whole content looks like a large blob of random data, with no way of determining what kind of filesystem and data it contains. Accessing the data happens, again, by mounting the protected container (in this case the block device) to an arbitrary location in a special way.<br />
<br />
The following "block device encryption" solutions are available in Arch Linux:<br />
<br />
;loop-AES: loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption. However, loop-AES is considered less user-friendly than other options as it requires non-standard kernel support. <br />
<br />
;dm-crypt: [[dm-crypt]] is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management. The management of dm-crypt is done with the {{Pkg|cryptsetup}} userspace utility. It can be used for the following types of block-device encryption: ''LUKS'' (default), ''plain'', and has limited features for ''loopAES'' and ''Truecrypt'' devices. <br />
:* LUKS, used by default, is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use and cryptographic security. <br />
:* plain dm-crypt mode, being the original kernel functionality, does not employ the convenience layer. It is more difficult to apply the same cryptographic strength with it. When doing so, longer keys (passphrases or keyfiles) are the result. It has, however, other advantages, described in the following [[#Block device vs stacked filesystem encryption]]. <br />
<br />
;TrueCrypt/VeraCrypt: A portable format, supporting encryption of whole disks/partitions or file containers, with compatibility across all major operating systems. [[TrueCrypt]] was discontinued by its developers in May 2014. The VeraCrypt fork was audited in 2016.<br />
<br />
For practical implications of the chosen layer of operation, see the [[#Block device vs stacked filesystem encryption]] below, as well as the general write up for [https://www.systutorials.com/docs/linux/packages/ecryptfs-utils-111/ecryptfs-faq.html#compare eCryptfs]. See [[:Category:Encryption]] for the available content of the methods compared below, as well as other tools not included in the table.<br />
<br />
=== Block device vs stacked filesystem encryption ===<br />
<br />
{| class="wikitable left-align-row-headers" style="text-align:center;"<br />
! Aspect<br />
! {{B|Block device encryption}}<br />
! {{V|Stacked filesystem encryption}}<br />
|-<br />
! Encrypts<br />
| whole block devices<br />
| files<br />
|-<br />
! Container for encrypted data may be...<br />
| a disk or disk partition / a file acting as a virtual partition<br />
| a directory in an existing file system<br />
|-<br />
! Relation to filesystem<br />
| operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else<br />
| adds an additional layer to an existing filesystem, to automatically encrypt/decrypt files whenever they are written/read<br />
|-<br />
! File metadata (number of files, dir structure, file sizes, permissions, mtimes, etc.) is encrypted<br />
| {{Ya}}<br />
| {{Na}}<br>(file and dir names can be encrypted though)<br />
|-<br />
! Can be used to custom-encrypt whole hard drives (including partition tables)<br />
| {{Ya}}<br />
| {{Na}}<br />
|-<br />
! Can be used to encrypt swap space<br />
| {{Ya}}<br />
| {{Na}}<br />
|-<br />
<br />
! Can be used without pre-allocating a fixed amount of space for the encrypted data container<br />
| {{Na}}<br />
| {{Ya}}<br />
|-<br />
! Can be used to protect existing filesystems without block device access, e.g. NFS or Samba shares, cloud storage, etc.<br />
| {{Na}}<br />
| {{Ya}}<br />
|-<br />
! Allows offline file-based backups of encrypted files<br />
| {{Na}}<br />
| {{Ya}}<br />
|}<br />
<br />
=== Comparison table ===<br />
<br />
{{Expansion|Fill in blanks. Add sources to checkmarks / crosses. What is ''salt'', ''key-slot diffusion'' or ''key scrubbing''?}}<br />
<br />
The column "dm-crypt +/- LUKS" denotes features of dm-crypt for both LUKS ("+") and plain ("-") encryption modes. If a specific feature requires using LUKS, this is indicated by "(with LUKS)". Likewise "(without LUKS)" indicates usage of LUKS is counter-productive to achieve the feature and plain mode should be used.<br />
<br />
{| class="wikitable left-align-row-headers" style="text-align:center; cell-padding:100px; "<br />
!{{Grey|Summary}}<br />
! Loop-AES<br />
! [[dm-crypt]] +/- LUKS<br />
! [[TrueCrypt]]<br />
! VeraCrypt<br />
! [[eCryptfs]]<br />
! [[EncFS]]<br />
! [[gocryptfs]]<br />
|-<br />
! Encryption type<br />
| {{B|block device}}<br />
| {{B|block device}}<br />
| {{B|block device}}<br />
| {{B|block device}}<br />
| {{V|stacked filesystem}}<br />
| {{V|stacked filesystem}}<br />
| {{V|stacked filesystem}}<br />
|-<br />
! Note<br />
| longest-existing one; possibly the fastest; works on legacy systems<br />
| de-facto standard for block device encryption on Linux; very flexible<br />
| very portable, well-polished but abandoned<br />
| maintained fork of TrueCrypt<br />
| slightly faster than EncFS; individual encrypted files portable between systems<br />
| easiest one to use; supports non-root administration<br />
| aspiring successor of EncFS<br />
|-<br />
! Availability in Arch Linux<br />
| requires manually compiled, custom kernel<br />
| ''kernel modules:'' already shipped with default kernel; ''tools:'' {{Pkg|device-mapper}}, {{Pkg|cryptsetup}}<br />
| {{Pkg|truecrypt}}<br />
| {{Pkg|veracrypt}}<br />
| ''kernel module:'' already shipped with default kernel; ''tools:'' {{Pkg|ecryptfs-utils}}<br />
| {{Pkg|encfs}}<br />
| {{Pkg|gocryptfs}}<br />
|-<br />
! License<br />
| GPL<br />
| GPL<br />
| TrueCrypt License 3.1<br />
| Apache License 2.0, parts subject to TrueCrypt License v3.0<br />
| GPL<br />
| GPL<br />
| MIT<br />
|-<br />
! Encryption implemented in...<br />
| kernelspace<br />
| kernelspace<br />
| kernelspace<br />
| kernelspace<br />
| kernelspace<br />
| userspace ([[FUSE]])<br />
| userspace ([[FUSE]])<br />
|-<br />
! Cryptographic metadata stored in...<br />
| ?<br />
| with LUKS: LUKS Header <br />
| begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format]){{Dead link|2018|07|15}}<br />
| begin/end of (decrypted) device ([https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format%20Specification.html format spec])<br />
| header of each encrypted file<br />
| control file at the top level of each EncFs container<br />
|-<br />
! Wrapped encryption key stored in...<br />
| ?<br />
| with LUKS: LUKS header <br />
| begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format spec]){{Dead link|2018|07|15}}<br />
| begin/end of (decrypted) device ([https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format%20Specification.html format spec])<br />
| key file that can be stored anywhere<br />
| key file that can be stored anywhere<br />
[https://github.com/rfjakob/encfs/blob/next/encfs/encfs.pod#environment-variables][https://github.com/vgough/encfs/issues/48#issuecomment-69301831]<br />
|<br />
|-<br />
! {{Grey|Usability features}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Non-root users can create/destroy containers for encrypted data<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Na}}<br />
| limited<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! Provides a GUI<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Na}}<br />
| {{Ya}}<br />
[[EncFS#Gnome Encfs Manager|optional]]<br />
| {{Na}}<br />
|-<br />
! Support for automounting on login<br />
| ?<br />
| {{Ya}}<br />
| {{Ya}}<br />
with [[TrueCrypt#Automounting_using_.2Fetc.2Fcrypttab|systemd and /etc/crypttab]]<br />
| {{Ya}}<br />
with [[TrueCrypt#Automounting_using_.2Fetc.2Fcrypttab|systemd and /etc/crypttab]]<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! Support for automatic unmounting in case of inactivity<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
| ?<br />
|-<br />
! {{Grey|Security features}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Supported ciphers<br />
| AES<br />
| AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish,… (every cipher the kernel Crypto API offers)<br />
| AES, Twofish, Serpent<br />
| AES, Twofish, Serpernt, Camellia, Kuznyechik<br />
| AES, Blowfish, Twofish...<br />
| AES, Blowfish, Twofish, and any other ciphers available on the system<br />
| AES<br />
|-<br />
! Integrity<br />
| none<br />
| optional in LUKS2<br />
| none<br />
| none<br />
| none<br />
| none (default mode)<br>HMAC (paranoia mode)<br />
| GCM<br />
|-<br />
! Support for salting<br />
| ?<br />
| {{Ya}}<br>(with LUKS)<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| {{Ya}}<br />
|-<br />
! Support for cascading multiple ciphers<br />
| ?<br />
| Not in one device, but blockdevices can be cascaded<br />
| {{Ya}}<br />
AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent<br />
| {{Ya}}<br />
AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent<br />
| ?<br />
| {{Na}}<br />
| {{Na}}<br />
|-<br />
! Support for key-slot diffusion<br />
| ?<br />
| {{Ya}}<br>(with LUKS)<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
! Protection against key scrubbing<br />
| {{Ya}}<br />
| {{Ya}}<br>(without LUKS)<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
! Support for multiple (independently revocable) keys for the same encrypted data<br />
| ?<br />
| {{Ya}}<br>(with LUKS)<br />
| ?<br />
| ?<br />
| ?<br />
| {{Na}}<br />
| ?<br />
|-<br />
! {{Grey|Performance features}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Multithreading support<br />
| ?<br />
| {{Ya}}<br>[http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c]<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
|-<br />
! Hardware-accelerated encryption support<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br>[https://github.com/vgough/encfs/issues/118]<br />
| {{Ya}}<br />
|-<br />
! {{Grey|Block device encryption specific}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! colspan=3 rowspan=2 {{Grey|}}<br />
|-<br />
! Support for (manually) resizing the encrypted block device in-place<br />
| ?<br />
| {{Ya}}<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Na}}<br />
|-<br />
! {{Grey|Stacked filesystem encryption specific}}<br />
! colspan=4 rowspan=5 {{Grey|}}<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Supported file systems<br />
| ext3, ext4, xfs (with caveats), jfs, nfs...<br />
| ext3, ext4, xfs (with caveats), jfs, nfs, cifs...<br />
[https://github.com/vgough/encfs]<br />
| any<br />
|-<br />
! Ability to encrypt filenames<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! Ability to ''not'' encrypt filenames<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Na}}<br />
|-<br />
! Optimized handling of sparse files<br />
| {{Na}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! {{Grey|Compatibility & prevalence}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Supported Linux kernel versions<br />
| 2.0 or newer<br />
| CBC-mode since 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24<br />
| ?<br />
| ?<br />
| ?<br />
| 2.4 or newer<br />
| ?<br />
|-<br />
! Encrypted data can also be accessed from Windows<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| {{Ya}}<br>[https://github.com/vgough/encfs/wiki/Windows]<br />
| {{Ya}} (cppcryptfs port)<br />
|-<br />
! Encrypted data can also be accessed from Mac OS X<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| {{Ya}}<br>[https://sites.google.com/a/arg0.net/www/encfs-mac-build]<br />
| {{Ya}} (beta quality)<br />
|-<br />
! Encrypted data can also be accessed from FreeBSD<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
(with VeraCrypt)<br />
| {{Ya}}<br><br />
| ?<br />
| {{Ya}}<br>[http://www.freshports.org/sysutils/fusefs-encfs/]<br />
| ?<br />
|-<br />
<br />
! Used by<br />
| ?<br />
| Debian/Ubuntu installer (system encryption)<br>Fedora installer <br />
| ?<br />
| ?<br />
| Ubuntu installer (home dir encryption)<br>Chromium OS (encryption of cached user data [https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data])<br />
| ?<br />
| ?<br />
|}<br />
<br />
# well, a single file in those filesystems could be used as a container (virtual loop-back device!) but then one would not actually be using the filesystem (and the features it provides) anymore<br />
<br />
==Preparation==<br />
<br />
===Choosing a setup===<br />
<br />
Which disk encryption setup is appropriate for you will depend on your goals (please read [[#Why use encryption?]] above) and system parameters.<br />
<br />
Among other things, you will need to answer the following questions:<br />
<br />
;What kind of "attacker" do you want to protect against?<br />
<br />
* Casual computer user snooping around your disk when your system is turned off / stolen / etc.<br />
* Professional cryptanalyst who can get repeated read/write access to your system before and after you use it<br />
* Anything in between<br />
<br />
;What do you want to encrypt?<br />
<br />
* only user data<br />
* user data and system data<br />
* something in between<br />
<br />
;How should swap, {{ic|/tmp}}, etc. be taken care of?<br />
<br />
* Ignore, and hope no data is leaked<br />
* Disable or mount as ramdisk<br />
* Encrypt ''(as part of full disk encryption, or separately)''<br />
<br />
;How should encrypted parts of the disk be unlocked?<br />
<br />
* Passphrase ''(same as login password, or separate)''<br />
* Keyfile ''(e.g. on a USB stick, that you keep in a safe place or carry around with yourself)''<br />
* Both<br />
<br />
;''When'' should encrypted parts of the disk be unlocked?<br />
<br />
* Before boot<br />
* During boot<br />
* At login<br />
* Manually on demand ''(after login)''<br />
<br />
;How should multiple users be accommodated?<br />
<br />
* Not at all<br />
* Using a shared passphrase/key<br />
* Independently issued and revocable passphrases/keys for the same encrypted part of the disk<br />
* Separate encrypted parts of the disk for different users<br />
<br />
Then you can go on to make the required technical choices (see [[#Available methods]] above, and [[#How the encryption works]] below), regarding:<br />
<br />
* stacked filesystem encryption vs. blockdevice encryption<br />
* key management<br />
* cipher and mode of operation<br />
* metadata storage<br />
* location of the "lower directory" (in case of stacked filesystem encryption)<br />
<br />
=== Examples ===<br />
<br />
In practice, it could turn out something like:<br />
<br />
;Example 1: Simple user data encryption (internal hard drive) using a virtual folder called {{ic|~/Private}} in the user's home directory encrypted with [[EncFS]]<br />
:* encrypted versions of the files stored on-disk in {{ic|~/.Private}}<br />
:* unlocked on demand with dedicated passphrase<br />
<br />
;Example 2: Partial system encryption with each user's home directory encrypted with [[ECryptfs]]<br />
:* unlocked on respective user login, using login passphrase<br />
:* {{ic|swap}} and {{ic|/tmp}} partitions encrypted with [[Dm-crypt with LUKS]], using an automatically generated per-session throwaway key<br />
:* indexing/caching of contents of {{ic|/home}} by ''slocate'' (and similar apps) disabled.<br />
<br />
;Example 3: System encryption - whole hard drive except {{ic|/boot}} partition (however, {{ic|/boot}} can be encrypted with [[Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29|GRUB]]) encrypted with [[Dm-crypt with LUKS]]<br />
:* unlocked during boot, using passphrases or USB stick with keyfiles<br />
:* Maybe different passphrases/keys per user - independently revocable<br />
:* Maybe encryption spanning multiple drives or partition layout flexibility with [[Dm-crypt/Encrypting an entire system#LUKS on LVM|LUKS on LVM]]<br />
<br />
;Example 4: Hidden/plain system encryption - whole hard drive encrypted with [[dm-crypt|plain dm-crypt]]<br />
:* USB-boot, using dedicated passphrase plus USB stick with keyfile<br />
:* data integrity checked before mounting<br />
:* {{ic|/boot}} partition located on aforementioned USB stick<br />
<br />
Many other combinations are of course possible. You should carefully plan what kind of setup will be appropriate for your system.<br />
<br />
===Choosing a strong passphrase===<br />
<br />
See [[Security#Passwords]].<br />
<br />
===Preparing the disk===<br />
<br />
Before setting up disk encryption on a (part of a) disk, consider securely wiping it first. This consists of overwriting the entire drive or partition with a stream of zero bytes or random bytes, and is done for one or both of the following reasons:<br />
<br />
;Prevent recovery of previously stored data<br />
<br />
Disk encryption does not change the fact that individual sectors are only overwritten on demand, when the file system creates or modifies the data those particular sectors hold (see [[#How the encryption works]] below). Sectors which the filesystem considers "not currently used" are not touched, and may still contain remnants of data from previous filesystems. The only way to make sure that all data which you previously stored on the drive can not be [[Wikipedia:Data_recovery|recovered]], is to manually erase it.<br />
For this purpose it does not matter whether zero bytes or random bytes are used (although wiping with zero bytes will be much faster).<br />
<br />
;Prevent disclosure of usage patterns on the encrypted drive<br />
<br />
Ideally, the whole encrypted part of the disk should be indistinguishable from uniformly random data. This way, no unauthorized person can know which and how many sectors actually contain encrypted data - which may be a desirable goal in itself (as part of true confidentiality), and also serves as an additional barrier against attackers trying to break the encryption.<br />
In order to satisfy this goal, wiping the disk using high-quality random bytes is crucial.<br />
<br />
The second goal only makes sense in combination with block device encryption, because in the case of stacked filesystem encryption the encrypted data can easily be located anyways (in the form of distinct encrypted files in the host filesystem). Also note that even if you only intend to encrypt a particular folder, you will have to erase the whole partition if you want to get rid of files that were previously stored in that folder in unencrypted form (due to [[Wikipedia::File_system_fragmentation|disk fragmentation]]). If there are other folders on the same partition, you will have to back them up and move them back afterwards.<br />
<br />
Once you have decided which kind of disk erasure you want to perform, refer to the [[Securely wipe disk]] article for technical instructions.<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
==How the encryption works==<br />
<br />
This section is intended as a high-level introduction to the concepts and processes which are at the heart of usual disk encryption setups.<br />
<br />
It does not go into technical or mathematical details (consult the appropriate literature for that), but should provide a system administrator with a rough understanding of how different setup choices (especially regarding key management) can affect usability and security.<br />
<br />
===Basic principle===<br />
<br />
For the purposes of disk encryption, each blockdevice (or individual file in the case of stacked filesystem encryption) is divided into '''sectors''' of equal length, for example 512 bytes (4,096 bits). The encryption/decryption then happens on a per-sector basis, so the n'th sector of the blockdevice/file on disk will store the encrypted version of the n'th sector of the original data.<br />
<br />
Whenever the operating system or an application requests a certain fragment of data from the blockdevice/file, the whole sector (or sectors) that contains the data will be read from disk, decrypted on-the-fly, and temporarily stored in memory:<br />
<br />
{{Text art|<nowiki><br />
╔═══════╗<br />
sector 1 ║"???.."║<br />
╠═══════╣ ╭┈┈┈┈┈╮<br />
sector 2 ║"???.."║ ┊ key ┊<br />
╠═══════╣ ╰┈┈┬┈┈╯<br />
: : │<br />
╠═══════╣ ▼ ┣┉┉┉┉┉┉┉┫<br />
sector n ║"???.."║━━━━━━━(decryption)━━━━━━▶┋"abc.."┋ sector n<br />
╠═══════╣ ┣┉┉┉┉┉┉┉┫<br />
: :<br />
╚═══════╝<br />
<br />
encrypted unencrypted<br />
blockdevice or data in RAM<br />
file on disk<br />
</nowiki>}}<br />
<br />
Similarly, on each write operation, all sectors that are affected must be re-encrypted completely (while the rest of the sectors remain untouched). <br />
<br />
In order to be able to de/encrypt data, the disk encryption system needs to know the unique secret "key" associated with it. Whenever the encrypted block device or folder in question is to be mounted, its corresponding key (called henceforth its "master key") must be supplied. <br />
<br />
The entropy of the key is of utmost importance for the security of the encryption. A randomly generated byte string of a certain length, for example 32 bytes (256 bits), has desired properties but is not feasible to remember and apply manually during the mount. <br />
<br />
For that reason two techniques are used as aides. The first is the application of cryptography to increase the entropic property of the master key, usually involving a separate human-friendly passphrase. For the different types of encryption the [[#Comparison table]] lists respective features. The second method is to create a keyfile with high entropy and store it on a medium separate from the data drive to be encrypted. <br />
<br />
See also [[Wikipedia:Authenticated encryption]].<br />
<br />
===Keys, keyfiles and passphrases===<br />
<br />
The following are examples how to store and cryptographically secure a master key with a keyfile:<br />
<br />
;Stored in a plaintext keyfile<br />
<br />
Simply storing the master key in a file (in readable form) is the simplest option. The file - called a "keyfile" - can be placed on a USB stick that you keep in a secure location and only connect to the computer when you want to mount the encrypted parts of the disk (e.g. during boot or login).<br />
<br />
;Stored in passphrase-protected form in a keyfile or on the disk itself<br />
<br />
The master key (and thus the encrypted data) can be protected with a secret passphrase, which you will have to remember and enter each time you want to mount the encrypted block device or folder. See [[#Cryptographic metadata]] below for details.<br />
<br />
;Randomly generated on-the-fly for each session<br />
<br />
In some cases, e.g. when encrypting swap space or a {{ic|/tmp}} partition, it is not necessary to keep a persistent master key at all. A new throwaway key can be randomly generated for each session, without requiring any user interaction. This means that once unmounted, all files written to the partition in question can never be decrypted again by ''anyone'' - which in those particular use-cases is perfectly fine.<br />
<br />
===Cryptographic metadata===<br />
<br />
Frequently the encryption techniques use cryptographic functions to enhance the security of the master key itself. On mount of the encrypted device the passphrase or keyfile is passed through these and only the result can unlock the master key to decrypt the data. <br />
<br />
A common setup is to apply so-called "key stretching" to the passphrase (via a "key derivation function"), and use the resulting enhanced passphrase as the mount key for decrypting the actual master key (which has been previously stored in encrypted form):<br />
<br />
{{Text art|<nowiki><br />
╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮ ╭┈┈┈┈┈┈┈┈┈┈┈╮<br />
┊ mount passphrase ┊━━━━━⎛key derivation⎞━━━▶┊ mount key ┊<br />
╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,───⎝ function ⎠ ╰┈┈┈┈┈┬┈┈┈┈┈╯<br />
╭──────╮ ╱ │<br />
│ salt │───────────´ │<br />
╰──────╯ │<br />
╭─────────────────────╮ ▼ ╭┈┈┈┈┈┈┈┈┈┈┈┈╮<br />
│ encrypted master key│━━━━━━━━━━━━━━━━━━━━━━(decryption)━━━▶┊ master key ┊<br />
╰─────────────────────╯ ╰┈┈┈┈┈┈┈┈┈┈┈┈╯<br />
</nowiki>}}<br />
<br />
The '''key derivation function''' (e.g. PBKDF2 or scrypt) is deliberately slow (it applies many iterations of a hash function, e.g. 1000 iterations of HMAC-SHA-512), so that brute-force attacks to find the passphrase are rendered infeasible. For the normal use-case of an authorized user, it will only need to be calculated once per session, so the small slowdown is not a problem.<br />
It also takes an additional blob of data, the so-called "'''salt'''", as an argument - this is randomly generated once during set-up of the disk encryption and stored unprotected as part of the cryptographic metadata. Because it will be a different value for each setup, this makes it infeasible for attackers to speed up brute-force attacks using precomputed tables for the key derivation function.<br />
<br />
The '''encrypted master key''' can be stored on disk together with the encrypted data. This way, the confidentiality of the encrypted data depends completely on the secret passphrase. <br />
<br />
Additional security can be attained by instead storing the encrypted master key in a keyfile on e.g. a USB stick. This provides '''two-factor authentication''': Accessing the encrypted data now requires something only you ''know'' (the passphrase), and additionally something only you ''have'' (the keyfile).<br />
<br />
Another way of achieving two-factor authentication is to augment the above key retrieval scheme to mathematically "combine" the passphrase with byte data read from one or more external files (located on a USB stick or similar), before passing it to the key derivation function.The files in question can be anything, e.g. normal JPEG images, which can be beneficial for [[#Plausible deniability]]. They are still called "keyfiles" in this context, though.<br />
<br />
After it has been derived, the master key is securely stored in memory (e.g. in a kernel keyring), for as long as the encrypted block device or folder is mounted.<br />
<br />
It is usually not used for de/encrypting the disk data directly, though.<br />
For example, in the case of stacked filesystem encryption, each file can be automatically assigned its own encryption key. Whenever the file is to be read/modified, this file key first needs to be decrypted using the main key, before it can itself be used to de/encrypt the file contents:<br />
<br />
{{Text art|<nowiki><br />
╭┈┈┈┈┈┈┈┈┈┈┈┈╮<br />
┊ master key ┊<br />
file on disk: ╰┈┈┈┈┈┬┈┈┈┈┈┈╯<br />
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │<br />
╎╭───────────────────╮╎ ▼ ╭┈┈┈┈┈┈┈┈┈┈╮<br />
╎│ encrypted file key│━━━━(decryption)━━━▶┊ file key ┊<br />
╎╰───────────────────╯╎ ╰┈┈┈┈┬┈┈┈┈┈╯<br />
╎┌───────────────────┐╎ ▼ ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐<br />
╎│ encrypted file │◀━━━━━━━━━━━━━━━━━(de/encryption)━━━▶┊ readable file ┊<br />
╎│ contents │╎ ┊ contents ┊<br />
╎└───────────────────┘╎ └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘<br />
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘<br />
</nowiki>}}<br />
<br />
In a similar manner, a separate key (e.g. one per folder) may be used for the encryption of file names in the case of stacked filesystem encryption.<br />
<br />
In the case of block device encryption one master key is used per device and, hence, all data. Some methods offer features to assign multiple passphrases/keyfiles for the same device and others not. Some use above mentioned functions to secure the master key and others give the control over the key security fully to the user. Two examples are explained by the cryptographic parameters used by [[dm-crypt]] in plain or LUKS modes. <br />
<br />
When comparing the parameters used by both modes one notes that dm-crypt plain mode has parameters relating to how to locate the keyfile (e.g. {{ic|--keyfile-size}}, {{ic|--keyfile-offset}}). The dm-crypt LUKS mode does not need these, because each blockdevice contains a header with the cryptographic metadata at the beginning. The header includes the used cipher, the encrypted master-key itself and parameters required for its derivation for decryption. The latter parameters in turn result from options used during initial encryption of the master-key (e.g. {{ic|--iter-time}}, {{ic|--use-random}}). <br />
<br />
For the dis-/advantages of the different techniques, please refer back to [[#Comparison table]] or browse the specific pages. <br />
<br />
See also:<br />
* [[Wikipedia:Passphrase]]<br />
* [[Wikipedia:Key (cryptography)]]<br />
* [[Wikipedia:Key management]]<br />
* [[Wikipedia:Key derivation function]]<br />
<br />
===Ciphers and modes of operation===<br />
<br />
The actual algorithm used for translating between pieces of unencrypted and encrypted data (so-called "plaintext" and "ciphertext") which correspond to each other with respect to a given encryption key, is called a "'''cipher'''".<br />
<br />
Disk encryption employs "block ciphers", which operate on fixed-length blocks of data, e.g. 16 bytes (128 bits). At the time of this writing, the predominantly used ones are:<br />
{| class="wikitable" style="margin:0 5em 1.5em 5em;"<br />
! scope="col" style="text-align:left" | <br />
! scope="col" style="text-align:left" | block&nbsp;size<br />
! scope="col" style="text-align:left" | key&nbsp;size<br />
! scope="col" style="text-align:left" | comment<br />
|-<br />
! scope="row" style="text-align:right" | [[Wikipedia:Advanced_Encryption_Standard|AES]]<br />
| 128 bits<br />
| 128, 192 or 256 bits<br />
| approved by the NSA for protecting "SECRET" and "TOP SECRET" classified US-government information (when used with a key size of 192 or 256 bits)<br />
|-<br />
! scope="row" style="text-align:right" | [[wikipedia:Blowfish (cipher)|Blowfish]]<br />
| 64 bits<br />
| 32–448 bits<br />
| one of the first patent-free secure ciphers that became publicly available, hence very well established on Linux<br />
|-<br />
! scope="row" style="text-align:right" | [[Wikipedia:Twofish|Twofish]]<br />
| 128 bits<br />
| 128, 192 or 256 bits<br />
| developed as successor of Blowfish, but has not attained as much widespread usage<br />
|-<br />
! scope="row" style="text-align:right" | [[wikipedia:Serpent (cipher)|Serpent]]<br />
| 128 bits<br />
| 128, 192 or 256 bits<br />
| Considered the most secure of the five AES-competition finalists[http://csrc.nist.gov/archive/aes/round2/r2report.pdf][https://www.cl.cam.ac.uk/~rja14/Papers/serpentcase.pdf][https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf].<br />
|}<br />
<br />
Encrypting/decrypting a sector ([[#Basic principle|see above]]) is achieved by dividing it into small blocks matching the cipher's block-size, and following a certain rule-set (a so-called "'''mode of operation'''") for how to consecutively apply the cipher to the individual blocks.<br />
<br />
Simply applying it to each block separately without modification (dubbed the "''electronic codebook (ECB)''" mode) would not be secure, because if the same 16 bytes of plaintext always produce the same 16 bytes of ciphertext, an attacker could easily recognize patterns in the ciphertext that is stored on disk.<br />
<br />
The most basic (and common) mode of operation used in practice is "''cipher-block chaining (CBC)''". When encrypting a sector with this mode, each block of plaintext data is combined in a mathematical way with the ciphertext of the previous block, before encrypting it using the cipher. For the first block, since it has no previous ciphertext to use, a special pre-generated data block stored with the sector's cryptographic metadata and called an "'''initialization vector (IV)'''" is used:<br />
<br />
{{Text art|<nowiki><br />
╭──────────────╮<br />
│initialization│<br />
│vector │<br />
╰────────┬─────╯<br />
╭ ╠══════════╣ ╭─key │ ┣┉┉┉┉┉┉┉┉┉┉┫ <br />
│ ║ ║ ▼ ▼ ┋ ┋ . START<br />
┴ ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"Hello, W"┋ block ╱╰────┐<br />
sector n ║ ║ ┋ ┋ 1 ╲╭────┘<br />
of file or ║ ║──────────────────╮ ┋ ┋ ' <br />
blockdevice ╟──────────╢ ╭─key │ ┠┈┈┈┈┈┈┈┈┈┈┨<br />
┬ ║ ║ ▼ ▼ ┋ ┋<br />
│ ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"orld !!!"┋ block<br />
│ ║ ║ ┋ ┋ 2<br />
│ ║ ║──────────────────╮ ┋ ┋<br />
│ ╟──────────╢ │ ┠┈┈┈┈┈┈┈┈┈┈┨<br />
│ ║ ║ ▼ ┋ ┋<br />
: : ... : ... ... : ... : ...<br />
<br />
ciphertext plaintext<br />
on disk in RAM<br />
</nowiki>}}<br />
<br />
When decrypting, the procedure is reversed analogously.<br />
<br />
One thing worth noting is the generation of the unique initialization vector for each sector. The simplest choice is to calculate it in a predictable fashion from a readily available value such as the sector number. However, this might allow an attacker with repeated access to the system to perform a so-called [[wikipedia:Watermarking_attack|watermarking attack]]. To prevent that, a method called "Encrypted salt-sector initialization vector ('''ESSIV''')" can be used to generate the initialization vectors in a way that makes them look completely random to a potential attacker.<br />
<br />
There are also a number of other, more complicated modes of operation available for disk encryption, which already provide built-in security against such attacks (and hence do not require ESSIV).<br />
Some can also additionally guarantee authenticity of the encrypted data (i.e. confirm that it has not been modified/corrupted by someone who does not have access to the key).<br />
<br />
See also:<br />
* [[Wikipedia:Disk encryption theory]]<br />
* [[Wikipedia:Block cipher]]<br />
* [[Wikipedia:Block cipher modes of operation]]<br />
<br />
===Plausible deniability===<br />
<br />
See [[Wikipedia:Plausible deniability]].</div>Ivankhttps://wiki.archlinux.org/index.php?title=Talk:QEMU&diff=575648Talk:QEMU2019-06-15T17:39:05Z<p>Ivank: /* Options for fstab with 9p */ reply</p>
<hr />
<div>== Linear RAID ==<br />
<br />
When I was updating the article yesterday, I had tried to fit the section about linear raid (boot a VM from a partition by prepending a MBR to it) into the article better. But I'm not sure the technique described is the right one at all. It looks like it works, but wouldn't it be easier to install a bootloader directly to the partition (e.g. syslinux)? Then the VM could be booted directly from the partition simply by using it as its virtual disk.<br />
--[[User:Synchronicity|Synchronicity]] ([[User talk:Synchronicity|talk]]) 19:23, 9 May 2012 (UTC)<br />
<br />
:What about Windows installations then? [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 09:18, 4 October 2016 (UTC)<br />
<br />
== Creating bridge manually ==<br />
<br />
I really don't know what to do with this section. I'd say it has been superseded by [[QEMU#Creating bridge using qemu-bridge-helper]] (available since qemu-1.1, we now have qemu-1.5) - or is someone still using this method? Perhaps link to https://en.wikibooks.org/wiki/QEMU/Networking#TAP_interfaces or http://wiki.qemu.org/Documentation/Networking/NAT is sufficient. What do you think? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:42, 22 July 2013 (UTC)<br />
<br />
:Actually, I've become a happy user of this method. I've written some scripts to easily create bridge interface, TAP interface, and combined with Xyne's [http://xyne.archlinux.ca/notes/network/dhcp_with_dns.html excellent scripts] to set up NAT and launch DHCP server, I have complete solution to easily manage multiple VMs on one (or even more) bridge.<br />
:My scripts are available on github: [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-launcher.sh], [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-tap-helper.sh], [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-mac-hasher.py] but I won't probably integrate them into the wiki, I'l just leave a note when I do some more testing.<br />
:The thing is, what to do with the current content? Personally I think that links to [https://en.wikibooks.org/wiki/QEMU/Networking#TAP_interfaces], [http://wiki.qemu.org/Documentation/Networking/NAT] and my scripts are sufficient (of course others are welcome). I'd also leave the note at the end to ''disable the firewall on the bridge'', I find it extremely useful.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:24, 5 September 2013 (UTC)<br />
<br />
:I would not remove something that works still heh.--[[User:Webdawg|Webdawg]] ([[User talk:Webdawg|talk]]) 07:31, 17 July 2016 (UTC)<br />
<br />
== Kexec Hackery When Using a Real Partition ==<br />
<br />
After banging my head against a wall long enough and figuring out what {{ic|-kernel}} and {{ic|-initrd}} were really calling, I put a note above the appropriate section and mentioned two ways to use the guest's images. (Otherwise, you'll have to worry if the host and guest images match.) The first -- mount the partition(s) -- is more appropriate for "low-volume-handling" of VMs. The second -- using kexec -- becomes more useful when you're juggling more than a few VMs.<br />
<br />
I'm only mentioning this hack because (as of now) [[Kexec]] only mentions use for rebooting into another kernel, not switching out the kernel before the system is even up. This hack comes from from https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader- which has two suggestions. The most recent, using systemd units by jkuan, doesn't work because jkuan tried to copy a {{ic|.target}} file into a {{ic|.service}} file and systemd wants {{ic|ExecStart}} in a {{ic|.service}} file. The second one, replacing {{ic|/usr/bin/init}} by andrew_sparks, works for me on my Arch instance at DigitalOcean.<br />
<br />
Adaptation from said post:<br />
<br />
# pacman -S kexec-tools<br />
# pacman -R systemd-sysvcompat<br />
<br />
{{hc|1=/tmp/init|2=<br />
#!/bin/sh<br />
<br />
kexec --load /boot/vmlinuz-linux --initrd=/boot/initramfs-linux.img --append="root=/dev/sda init=/usr/lib/systemd/systemd" &&<br />
mount -o ro,remount / && kexec -e<br />
exec /usr/lib/systemd/systemd<br />
}}<br />
<br />
# cd [/path/to/vm]/usr/bin<br />
# mv init init.dist<br />
# cp /tmp/init ./<br />
# chmod 755 init<br />
<br />
I'm leaving this on the Talk page as I haven't even tried it out in QEMU myself. Also, my eyes are about ready to pop out of my head, so I'm barring myself from figuring out the appropriate way to edit this in for the time being. [[User:BrainwreckedTech|BrainwreckedTech]] ([[User talk:BrainwreckedTech|talk]]) 21:23, 14 January 2014 (UTC)<br />
<br />
== Replace -net with -netdev ==<br />
<br />
The {{ic|-net}} option is deprecated and replaced by {{ic|-netdev}}. I think this article should be modified to reflect that.<br />
http://en.wikibooks.org/wiki/QEMU/Networking#cite_ref-1<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 18:12, 1 July 2014 (UTC)<br />
<br />
:Yes {{ic|-net}} is the old syntax as stated in [https://wiki.gentoo.org/wiki/QEMU/Options#Pass-through Gentoo's Wiki] where we should use {{ic|1=-netdev user,id=vmnic -device virtio-net,netdev=vmnic}} [[User:Pickfire|Pickfire]] ([[User talk:Pickfire|talk]]) 04:11, 31 March 2017 (UTC)<br />
<br />
== I'm rewriting the network section ==<br />
<br />
https://wiki.archlinux.org/index.php/User:Axper/sandbox/qemu_network<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 20:07, 2 July 2014 (UTC)<br />
<br />
::I think a lot of networking topics could be moved outside of the QEMU page. Many virtualization applications share the same basic principles with regards to networking, such as tun/tap creating, bridges, VDE, etc. There are a few networking schemes that are QEMU-specific, for example multicast sockets and {{ic|-net socket,...}}, and these could be mentioned on the QEMU page, although these are less reliable and rarely used in comparison to tap devices. We should also of course note the QEMU-specific command line options in the QEMU page, but for general concepts and commands independent of the virtualization applications, they could go on pages dedicated to the task. The best example is VDE, which is in no way limited to QEMU, yet it still doesn't have its own page on the Arch wiki.<br />
<br />
::Incidentally, I'm planning on rewriting [[User Mode Linux]] (yes, I promise I will get around to it), which happens to share the "tap with bridge" and VDE concepts with QEMU. It would be nice if I could link to pages dedicated to those topics and only write UML-specific commands in the page, instead of duplicating a bunch of general information. I'm not familiar very familiar with Xen or LXC or Docker or the like, but I would suspect that they also share some networking infrastructure. We could possibly even create a category just for these types of pages, for example "Virtual Networking" or "Advanced Networking". [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 13:32, 19 February 2015 (UTC)<br />
<br />
== -enable-kvm vs -machine type=pc,accel=kvm ==<br />
<br />
The section [[QEMU#Enabling_KVM]] recommends {{ic|-enable-kvm}}, while [[QEMU#Virtual_machine_runs_too_slowly]] recommends {{ic|1=-machine type=pc,accel=kvm}}. Is there any difference between the two? Is one preferred over the other? Should we just link to the former section from the latter (and possibly move both command line switches to the same section)? [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 17:23, 18 January 2015 (UTC)<br />
<br />
:2.5 years later... Has anyone found an answer to the question of `-enable-kvm` VS `-machine type=pc,accel=kvm`? -[[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 19:32, 3 August 2017 (UTC)<br />
<br />
::Yes. They're equivalent. [https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00132.html Discussion on the QEMU mailing list] about marking {{ic|-enable-kvm}} deprecated didn't result in that; {{ic|-enable-hax}} did get deprecated. Confusing, especially when checking whether e.g. libvirt has actually started the machine with KVM enabled. [[User:MacGyver|MacGyver]] ([[User talk:MacGyver|talk]]) 16:24, 4 December 2018 (UTC)<br />
<br />
== virtio-gpu ==<br />
<br />
Any tutorial on using the new virtio-gpu which is introduced in qemu-2.4 and kernel 4.2? [[User:Adam900710|Adam900710]] ([[User talk:Adam900710|talk]]) 02:44, 19 August 2015 (UTC)<br />
<br />
:Should be "plug and play" with recent kernel and other packages: [https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/ article]. The article is about libvirt, but I've run Arch guest on Arch host successfully with qemu script. [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 09:24, 4 October 2016 (UTC)<br />
<br />
== host only networking ==<br />
<br />
I added a quick and easy method but it was deleted. I found errors in what is here. Is it worth my time to correct them or will they be deleted? {{unsigned|16:39, 4 January 2016|Netskink}}<br />
<br />
:You are welcome to make any corrections. Nobody can tell you if they will be kept or reverted beforehand, but if you're afraid to waste your time feel free to just point them out using an [[Help:Template|Article status templates|article status template]] (should be less time consuming). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:28, 21 February 2016 (UTC)<br />
<br />
== Windows 7 specific issues ==<br />
<br />
I have noticed that for me, any attempts at installing Windows 7 using qemu with virt-manager as a frontend stalls on "Starting Windows." This is immediately after booting the computer for the first time. In Virt-manager, I am able to change the Display from QXL to Cirrus to fix the issue. I'm not sure if this applies to this page in particular, but if so, might be worth adding to the "Troubleshooting" section -- [[User:Ephreal|Ephreal]] ([[User talk:Ephreal|talk]]) 14:25, 10 August 2016 (UTC)<br />
<br />
== Using existing partition on GPT disk (with linear RAID or otherwise) ==<br />
<br />
[https://wiki.archlinux.org/index.php/QEMU#Simulate_virtual_disk_with_MBR_using_linear_RAID Section on using existing partition] is pretty awesome, but it is MBR-specific. Can someone with enough knowledge create a similar section about GPT disk please?<br />
<br />
== Could not access KVM kernel module: Permission denied ==<br />
<br />
Simply changing {{ic|1=group = "78"}} to {{ic|1=group = "kvm"}} in {{ic|/etc/libvirt/qemu.conf}} was not enough for me to fix this issue. Indeed, some files were still installed with gid 78, which you can confirm with:<br />
<br />
find / -gid 78<br />
<br />
So in the end, I still had to change the group id of kvm to workaround this issue:<br />
<br />
groupmod -g 78 kvm<br />
<br />
{{unsigned|17:15, 1 September 2017|Nivata}}<br />
<br />
== Starting QEMU virtual machines with systemd in 2018 ==<br />
<br />
The custom service script uses KillMethod=none to avoid the virtual machine being killed before shutdown. Here is an example to avoid this logic using {{Pkg|socat}}:<br />
<br />
ExecStart=/usr/bin/env qemu-system-x86_64 -name %i … -monitor unix:/var/run/qemu-%i.monitor,server,nowait<br />
ExecStop=/bin/sh -c 'echo system_powerdown | socat stdio,ignoreeof /var/run/qemu-%i.monitor'<br />
<br />
In this way, the stop command will exit when the QEMU monitor closes the socket. Other options, e.g. PIDFile or KillMode are not necessary.<br />
<br />
While a unix socket is used for this example, it works as well with telnet/tcp-connect.<br />
[[User:Ypnos|Ypnos]] ([[User talk:Ypnos|talk]]) 18:29, 30 January 2018 (UTC)<br />
<br />
I've tested using {{Pkg|openbsd-netcat}}, and that variant seems to keep the connection open after issuing the command as well. So there are a couple options to avoid using the KillMethod, which I agree is not a good idea.<br />
[[User:Djmoch|Djmoch]] ([[User talk:Djmoch|talk]]) 13:21, 2 March 2019 (UTC)<br />
<br />
== e1000e: waiting for carrier... timed out ==<br />
<br />
my physical host is an ArchLinux with 4.14.40-1-lts kernel and Qemu 2.12.0.<br />
<br />
in my first virtualisation case, my guest is an ArchLinux with 4.9.36-1-lts kernel (e1000e ver. 3.2.6-k) : everything works normally when I request the assignment of a network address with dhcpcd (after a few seconds, my guest gets the 10.0.2.15 intended address).<br />
<br />
in my second virtualisation case, my guest is an ArchLinux with 4.14.40-1-lts kernel (e1000e ver. 3.2.6-k) : no carrier is detected and therefore no address is assigned to the enp0s2 network card.<br />
<br />
I think the problem would rather come from the virtualized 4.14.40-1-lts kernel side because I do not meet it on my physical host which also uses the e1000e module...<br />
<br />
does anyone have an idea or a lead ?<br />
<br />
(this problem does not appear if I add in both cases the parameter "-machine pc" which forces the use of the module e1000/ens3 instead of the module e1000e/enp0s2).<br />
<br />
[[User:Lacsap|Lacsap]] ([[User talk:Lacsap|talk]]) 16:09, 28 May 2018 (UTC)<br />
<br />
== Options for fstab with 9p ==<br />
https://wiki.archlinux.org/index.php?title=QEMU&diff=next&oldid=573709<br />
<br />
Maybe the options are not very hard to deduce, but they are not obvious, and having them written down is very useful as a "cheat sheet".<br />
<br />
[[User:Marmistrz|Marmistrz]] ([[User talk:Marmistrz|talk]]) 15:19, 15 June 2019 (UTC)<br />
<br />
:The options (and more) are written on the page which is linked from the section: https://wiki.qemu.org/Documentation/9psetup -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:23, 15 June 2019 (UTC)<br />
<br />
: +1 to keep the options. I suggest also to mention <tt>msize=512000</tt> option necessary to achieve satisfactory performance, this is something qemu docs fail to mention [[User:Ivank|Ivank]] ([[User talk:Ivank|talk]]) 17:39, 15 June 2019 (UTC)</div>Ivankhttps://wiki.archlinux.org/index.php?title=Data-at-rest_encryption&diff=574517Data-at-rest encryption2019-06-04T08:33:00Z<p>Ivank: /* Comparison table */ typo</p>
<hr />
<div>[[Category:Disk encryption]]<br />
[[es:Disk encryption]]<br />
[[it:Disk encryption]]<br />
[[ja:ディスク暗号化]]<br />
[[pl:Disk encryption]]<br />
[[zh-hans:Disk encryption]]<br />
{{Related articles start}}<br />
{{Related|dm-crypt}}<br />
{{Related|TrueCrypt}}<br />
{{Related|eCryptfs}}<br />
{{Related|EncFS}}<br />
{{Related|gocryptfs}}<br />
{{Related|Tomb}}<br />
{{Related|tcplay}}<br />
{{Related|GnuPG}}<br />
{{Related|Self-Encrypting Drives}}<br />
{{Related articles end}}<br />
This article discusses [[Wikipedia:Disk encryption|disk encryption]] software, which on-the-fly encrypts / decrypts data written to / read from a [[block device]], [[disk partition]] or directory. Examples for block devices are hard drives, flash drives and DVDs.<br />
<br />
Disk encryption should only be viewed as an adjunct to the existing security mechanisms of the operating system - focused on securing physical access, while relying on ''other'' parts of the system to provide things like network security and user-based access control.<br />
<br />
For Full-disk encryption (FDE), see [[dm-crypt/Encrypting an entire system]].<br />
<br />
==Why use encryption?==<br />
<br />
Disk encryption ensures that files are always stored on disk in an encrypted form. The files only become available to the operating system and applications in readable form while the system is running and unlocked by a trusted user. An unauthorized person looking at the disk contents directly, will only find garbled random-looking data instead of the actual files.<br />
<br />
For example, this can prevent unauthorized viewing of the data when the computer or hard-disk is:<br />
* located in a place to which non-trusted people might gain access while you are away<br />
* lost or stolen, as with laptops, netbooks or external storage devices<br />
* in the repair shop<br />
* discarded after its end-of-life<br />
<br />
In addition, disk encryption can also be used to add some security against unauthorized attempts to tamper with your operating system – for example, the installation of keyloggers or Trojan horses by attackers who can gain physical access to the system while you are away.<br />
<br />
{{Warning|Disk encryption does '''not''' protect your data from all threats.}}<br />
You will still be vulnerable to:<br />
* Attackers who can break into your system (e.g. over the Internet) while it is running and after you have already unlocked and mounted the encrypted parts of the disk.<br />
* Attackers who are able to gain physical access to the computer while it is running (even if you use a screenlocker), or very shortly ''after'' it was running, if they have the resources to perform a [[Wikipedia:Cold boot attack|cold boot attack]].<br />
* A government entity, which not only has the resources to easily pull off the above attacks, but also may simply force you to give up your keys/passphrases using various techniques of [[Wikipedia:Coercion|coercion]]. In most non-democratic countries around the world, as well as in the USA and UK, it may be legal for law enforcement agencies to do so if they have suspicions that you might be hiding something of interest.<br />
<br />
A very strong disk encryption setup (e.g. full system encryption with authenticity checking and no plaintext boot partition) is required to stand a chance against professional attackers who are able to tamper with your system ''before'' you use it. And even then it cannot prevent all types of tampering (e.g. hardware keyloggers). The best remedy might be [[Wikipedia:Hardware-based full disk encryption|hardware-based full disk encryption]] and [[Wikipedia:Trusted_Computing|Trusted Computing]].<br />
<br />
{{Warning|Disk encryption also will not protect you against someone simply [[Securely wipe disk|wiping your disk]]. [[Backup programs|Regular backups]] are recommended to keep your data safe.}}<br />
<br />
== System data encryption ==<br />
<br />
While encrypting only the user data itself (often located within the home directory, or on removable media like a data DVD), is the simplest and least intrusive method, it has some significant drawbacks.<br />
In modern computer systems, there are many background processes that may cache and store information about user data or parts of the data itself in non-encrypted areas of the hard drive, like:<br />
<br />
:* swap partitions<br />
:** (potential remedies: disable swapping, or use [[encrypted swap]] as well)<br />
:* {{ic|/tmp}} (temporary files created by user applications)<br />
:** (potential remedies: avoid such applications; mount {{ic|/tmp}} inside a [[ramdisk]])<br />
:* {{ic|/var}} (log files and databases and such; for example, [[mlocate]] stores an index of all file names in {{ic|/var/lib/mlocate/mlocate.db}})<br />
<br />
The solution is to encrypt both system and user data, preventing unauthorized physical access to private data that may be cached by the system. This however comes with the disadvantage that unlocking of the encrypted parts of the disk has to happen at boot time. Another benefit of system data encryption is that it complicates the installation of malware like [[Wikipedia:Keystroke logging|keyloggers]] or rootkits for someone with physical access.<br />
<br />
== Available methods ==<br />
<br />
{{Expansion|[[Ext4]], [[ZFS]] and possible other filesystems offer (native) encryption.}}<br />
<br />
All disk encryption methods operate in such a way that even though the disk actually holds encrypted data, the operating system and applications "see" it as the corresponding normal readable data as long as the cryptographic container (i.e. the logical part of the disk that holds the encrypted data) has been "unlocked" and mounted.<br />
<br />
For this to happen, some "secret information" (usually in the form of a keyfile and/or passphrase) needs to be supplied by the user, from which the actual encryption key can be derived (and stored in the kernel keyring for the duration of the session).<br />
<br />
If you are completely unfamiliar with this sort of operation, please also read the [[#How the encryption works]] section below.<br />
<br />
The available disk encryption methods can be separated into two types by their layer of operation:<br />
<br />
=== Stacked filesystem encryption ===<br />
<br />
Stacked filesystem encryption solutions are implemented as a layer that stacks on top of an existing filesystem, causing all files written to an encryption-enabled folder to be encrypted on-the-fly before the underlying filesystem writes them to disk, and decrypted whenever the filesystem reads them from disk. This way, the files are stored in the host filesystem in encrypted form (meaning that their contents, and usually also their file/folder names, are replaced by random-looking data of roughly the same length), but other than that they still exist in that filesystem as they would without encryption, as normal files / symlinks / hardlinks / etc.<br />
<br />
The way it is implemented, is that to unlock the folder storing the raw encrypted files in the host filesystem ("lower directory"), it is mounted (using a special stacked pseudo-filesystem) onto itself or optionally a different location ("upper directory"), where the same files then appear in readable form - until it is unmounted again, or the system is turned off.<br />
<br />
Available solutions in this category are [[eCryptfs]] and [[EncFS]].<br />
<br />
==== Cloud-storage optimized ====<br />
<br />
If you are deploying stacked filesystem encryption to achieve zero-knowledge synchronization with third-party-controlled locations such as cloud-storage services, you may want to consider alternatives to eCryptfs and EncFS, since these are not optimized for transmission of files over the Internet. There are some solutions designed for this purpose instead:<br />
<br />
* [[gocryptfs]]<br />
* {{aur|cryptomator}} (multi-platform)<br />
* {{pkg|cryfs}}<br />
<br />
Note that some cloud-storage services offer zero-knowledge encryption directly through their own [[List of applications/Internet#Cloud synchronization clients|client applications]].<br />
<br />
=== Block device encryption ===<br />
<br />
Block device encryption methods, on the other hand, operate ''below'' the filesystem layer and make sure that everything written to a certain block device (i.e. a whole disk, or a partition, or a file acting as a [[Wikipedia:loop device|loop device]]) is encrypted. This means that while the block device is offline, its whole content looks like a large blob of random data, with no way of determining what kind of filesystem and data it contains. Accessing the data happens, again, by mounting the protected container (in this case the block device) to an arbitrary location in a special way.<br />
<br />
The following "block device encryption" solutions are available in Arch Linux:<br />
<br />
;loop-AES: loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption. However, loop-AES is considered less user-friendly than other options as it requires non-standard kernel support. <br />
<br />
;dm-crypt: [[dm-crypt]] is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management. The management of dm-crypt is done with the {{Pkg|cryptsetup}} userspace utility. It can be used for the following types of block-device encryption: ''LUKS'' (default), ''plain'', and has limited features for ''loopAES'' and ''Truecrypt'' devices. <br />
:* LUKS, used by default, is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use and cryptographic security. <br />
:* plain dm-crypt mode, being the original kernel functionality, does not employ the convenience layer. It is more difficult to apply the same cryptographic strength with it. When doing so, longer keys (passphrases or keyfiles) are the result. It has, however, other advantages, described in the following [[#Block device vs stacked filesystem encryption]]. <br />
<br />
;TrueCrypt/VeraCrypt: A portable format, supporting encryption of whole disks/partitions or file containers, with compatibility across all major operating systems. [[TrueCrypt]] was discontinued by its developers in May 2014. The VeraCrypt fork was audited in 2016.<br />
<br />
For practical implications of the chosen layer of operation, see the [[#Block device vs stacked filesystem encryption]] below, as well as the general write up for [https://www.systutorials.com/docs/linux/packages/ecryptfs-utils-111/ecryptfs-faq.html#compare eCryptfs]. See [[:Category:Encryption]] for the available content of the methods compared below, as well as other tools not included in the table.<br />
<br />
=== Block device vs stacked filesystem encryption ===<br />
<br />
{| class="wikitable left-align-row-headers" style="text-align:center;"<br />
! Aspect<br />
! {{B|Block device encryption}}<br />
! {{V|Stacked filesystem encryption}}<br />
|-<br />
! Encrypts<br />
| whole block devices<br />
| files<br />
|-<br />
! Container for encrypted data may be...<br />
| a disk or disk partition / a file acting as a virtual partition<br />
| a directory in an existing file system<br />
|-<br />
! Relation to filesystem<br />
| operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else<br />
| adds an additional layer to an existing filesystem, to automatically encrypt/decrypt files whenever they are written/read<br />
|-<br />
! File metadata (number of files, dir structure, file sizes, permissions, mtimes, etc.) is encrypted<br />
| {{Ya}}<br />
| {{Na}}<br>(file and dir names can be encrypted though)<br />
|-<br />
! Can be used to custom-encrypt whole hard drives (including partition tables)<br />
| {{Ya}}<br />
| {{Na}}<br />
|-<br />
! Can be used to encrypt swap space<br />
| {{Ya}}<br />
| {{Na}}<br />
|-<br />
<br />
! Can be used without pre-allocating a fixed amount of space for the encrypted data container<br />
| {{Na}}<br />
| {{Ya}}<br />
|-<br />
! Can be used to protect existing filesystems without block device access, e.g. NFS or Samba shares, cloud storage, etc.<br />
| {{Na}}<br />
| {{Ya}}<br />
|-<br />
! Allows offline file-based backups of encrypted files<br />
| {{Na}}<br />
| {{Ya}}<br />
|}<br />
<br />
=== Comparison table ===<br />
<br />
{{Expansion|Fill in blanks. Add sources to checkmarks / crosses. What is ''salt'', ''key-slot diffusion'' or ''key scrubbing''?}}<br />
<br />
The column "dm-crypt +/- LUKS" denotes features of dm-crypt for both LUKS ("+") and plain ("-") encryption modes. If a specific feature requires using LUKS, this is indicated by "(with LUKS)". Likewise "(without LUKS)" indicates usage of LUKS is counter-productive to achieve the feature and plain mode should be used.<br />
<br />
{| class="wikitable left-align-row-headers" style="text-align:center; cell-padding:100px; "<br />
!{{Grey|Summary}}<br />
! Loop-AES<br />
! [[dm-crypt]] +/- LUKS<br />
! [[TrueCrypt]]<br />
! VeraCrypt<br />
! [[eCryptfs]]<br />
! [[EncFS]]<br />
! [[gocryptfs]]<br />
|-<br />
! Encryption type<br />
| {{B|block device}}<br />
| {{B|block device}}<br />
| {{B|block device}}<br />
| {{B|block device}}<br />
| {{V|stacked filesystem}}<br />
| {{V|stacked filesystem}}<br />
| {{V|stacked filesystem}}<br />
|-<br />
! Note<br />
| longest-existing one; possibly the fastest; works on legacy systems<br />
| de-facto standard for block device encryption on Linux; very flexible<br />
| very portable, well-polished but abandoned<br />
| maintained fork of TrueCrypt<br />
| slightly faster than EncFS; individual encrypted files portable between systems<br />
| easiest one to use; supports non-root administration<br />
| aspiring successor of EncFS<br />
|-<br />
! Availability in Arch Linux<br />
| requires manually compiled, custom kernel<br />
| ''kernel modules:'' already shipped with default kernel; ''tools:'' {{Pkg|device-mapper}}, {{Pkg|cryptsetup}}<br />
| {{Pkg|truecrypt}}<br />
| {{Pkg|veracrypt}}<br />
| ''kernel module:'' already shipped with default kernel; ''tools:'' {{Pkg|ecryptfs-utils}}<br />
| {{Pkg|encfs}}<br />
| {{Pkg|gocryptfs}}<br />
|-<br />
! License<br />
| GPL<br />
| GPL<br />
| TrueCrypt License 3.1<br />
| Apache License 2.0, parts subject to TrueCrypt License v3.0<br />
| GPL<br />
| GPL<br />
| MIT<br />
|-<br />
! Encryption implemented in...<br />
| kernelspace<br />
| kernelspace<br />
| kernelspace<br />
| kernelspace<br />
| kernelspace<br />
| userspace ([[FUSE]])<br />
| userspace ([[FUSE]])<br />
|-<br />
! Cryptographic metadata stored in...<br />
| ?<br />
| with LUKS: LUKS Header <br />
| begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format]){{Dead link|2018|07|15}}<br />
| begin/end of (decrypted) device ([https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format%20Specification.html format spec])<br />
| header of each encrypted file<br />
| control file at the top level of each EncFs container<br />
|-<br />
! Wrapped encryption key stored in...<br />
| ?<br />
| with LUKS: LUKS header <br />
| begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format spec]){{Dead link|2018|07|15}}<br />
| begin/end of (decrypted) device ([https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format%20Specification.html format spec])<br />
| key file that can be stored anywhere<br />
| key file that can be stored anywhere<br />
[https://github.com/rfjakob/encfs/blob/next/encfs/encfs.pod#environment-variables][https://github.com/vgough/encfs/issues/48#issuecomment-69301831]<br />
|<br />
|-<br />
! {{Grey|Usability features}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Non-root users can create/destroy containers for encrypted data<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Na}}<br />
| limited<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! Provides a GUI<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Na}}<br />
| {{Ya}}<br />
[[EncFS#Gnome Encfs Manager|optional]]<br />
| {{Na}}<br />
|-<br />
! Support for automounting on login<br />
| ?<br />
| {{Ya}}<br />
| {{Ya}}<br />
with [[TrueCrypt#Automounting_using_.2Fetc.2Fcrypttab|systemd and /etc/crypttab]]<br />
| {{Ya}}<br />
with [[TrueCrypt#Automounting_using_.2Fetc.2Fcrypttab|systemd and /etc/crypttab]]<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! Support for automatic unmounting in case of inactivity<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
| ?<br />
|-<br />
! {{Grey|Security features}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Supported ciphers<br />
| AES<br />
| AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish,… (every cipher the kernel Crypto API offers)<br />
| AES, Twofish, Serpent<br />
| AES, Twofish, Serpernt, Camellia, Kuznyechik<br />
| AES, Blowfish, Twofish...<br />
| AES, Blowfish, Twofish, and any other ciphers available on the system<br />
| AES<br />
|-<br />
! Integrity<br />
| none<br />
| none<br />
| none<br />
| none<br />
| none<br />
| none (default mode)<br>HMAC (paranoia mode)<br />
| GCM<br />
|-<br />
! Support for salting<br />
| ?<br />
| {{Ya}}<br>(with LUKS)<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| {{Ya}}<br />
|-<br />
! Support for cascading multiple ciphers<br />
| ?<br />
| Not in one device, but blockdevices can be cascaded<br />
| {{Ya}}<br />
AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent<br />
| {{Ya}}<br />
AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent<br />
| ?<br />
| {{Na}}<br />
| {{Na}}<br />
|-<br />
! Support for key-slot diffusion<br />
| ?<br />
| {{Ya}}<br>(with LUKS)<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
! Protection against key scrubbing<br />
| {{Ya}}<br />
| {{Ya}}<br>(without LUKS)<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
! Support for multiple (independently revocable) keys for the same encrypted data<br />
| ?<br />
| {{Ya}}<br>(with LUKS)<br />
| ?<br />
| ?<br />
| ?<br />
| {{Na}}<br />
| ?<br />
|-<br />
! {{Grey|Performance features}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Multithreading support<br />
| ?<br />
| {{Ya}}<br>[http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c]<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
|-<br />
! Hardware-accelerated encryption support<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br>[https://github.com/vgough/encfs/issues/118]<br />
| {{Ya}}<br />
|-<br />
! {{Grey|Block device encryption specific}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! colspan=2 rowspan=2 {{Grey|}}<br />
|-<br />
! Support for (manually) resizing the encrypted block device in-place<br />
| ?<br />
| {{Ya}}<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Na}}<br />
|-<br />
! {{Grey|Stacked filesystem encryption specific}}<br />
! colspan=4 rowspan=5 {{Grey|}}<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Supported file systems<br />
| ext3, ext4, xfs (with caveats), jfs, nfs...<br />
| ext3, ext4, xfs (with caveats), jfs, nfs, cifs...<br />
[https://github.com/vgough/encfs]<br />
| any<br />
|-<br />
! Ability to encrypt filenames<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! Ability to ''not'' encrypt filenames<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Na}}<br />
|-<br />
! Optimized handling of sparse files<br />
| {{Na}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! {{Grey|Compatibility & prevalence}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Supported Linux kernel versions<br />
| 2.0 or newer<br />
| CBC-mode since 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24<br />
| ?<br />
| ?<br />
| ?<br />
| 2.4 or newer<br />
| ?<br />
|-<br />
! Encrypted data can also be accessed from Windows<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| {{Ya}}<br>[https://github.com/vgough/encfs/wiki/Windows]<br />
| {{Ya}} (cppcryptfs port)<br />
|-<br />
! Encrypted data can also be accessed from Mac OS X<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| {{Ya}}<br>[https://sites.google.com/a/arg0.net/www/encfs-mac-build]<br />
| {{Ya}} (beta quality)<br />
|-<br />
! Encrypted data can also be accessed from FreeBSD<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
(with VeraCrypt)<br />
| {{Ya}}<br><br />
| ?<br />
| {{Ya}}<br>[http://www.freshports.org/sysutils/fusefs-encfs/]<br />
| ?<br />
|-<br />
<br />
! Used by<br />
| ?<br />
| Debian/Ubuntu installer (system encryption)<br>Fedora installer <br />
| ?<br />
| ?<br />
| Ubuntu installer (home dir encryption)<br>Chromium OS (encryption of cached user data [https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data])<br />
| ?<br />
| ?<br />
|}<br />
<br />
# well, a single file in those filesystems could be used as a container (virtual loop-back device!) but then one would not actually be using the filesystem (and the features it provides) anymore<br />
<br />
==Preparation==<br />
<br />
===Choosing a setup===<br />
<br />
Which disk encryption setup is appropriate for you will depend on your goals (please read [[#Why use encryption?]] above) and system parameters.<br />
<br />
Among other things, you will need to answer the following questions:<br />
<br />
;What kind of "attacker" do you want to protect against?<br />
<br />
* Casual computer user snooping around your disk when your system is turned off / stolen / etc.<br />
* Professional cryptanalyst who can get repeated read/write access to your system before and after you use it<br />
* Anything in between<br />
<br />
;What do you want to encrypt?<br />
<br />
* only user data<br />
* user data and system data<br />
* something in between<br />
<br />
;How should swap, {{ic|/tmp}}, etc. be taken care of?<br />
<br />
* Ignore, and hope no data is leaked<br />
* Disable or mount as ramdisk<br />
* Encrypt ''(as part of full disk encryption, or separately)''<br />
<br />
;How should encrypted parts of the disk be unlocked?<br />
<br />
* Passphrase ''(same as login password, or separate)''<br />
* Keyfile ''(e.g. on a USB stick, that you keep in a safe place or carry around with yourself)''<br />
* Both<br />
<br />
;''When'' should encrypted parts of the disk be unlocked?<br />
<br />
* Before boot<br />
* During boot<br />
* At login<br />
* Manually on demand ''(after login)''<br />
<br />
;How should multiple users be accommodated?<br />
<br />
* Not at all<br />
* Using a shared passphrase/key<br />
* Independently issued and revocable passphrases/keys for the same encrypted part of the disk<br />
* Separate encrypted parts of the disk for different users<br />
<br />
Then you can go on to make the required technical choices (see [[#Available methods]] above, and [[#How the encryption works]] below), regarding:<br />
<br />
* stacked filesystem encryption vs. blockdevice encryption<br />
* key management<br />
* cipher and mode of operation<br />
* metadata storage<br />
* location of the "lower directory" (in case of stacked filesystem encryption)<br />
<br />
=== Examples ===<br />
<br />
In practice, it could turn out something like:<br />
<br />
;Example 1: Simple user data encryption (internal hard drive) using a virtual folder called {{ic|~/Private}} in the user's home directory encrypted with [[EncFS]]<br />
:* encrypted versions of the files stored on-disk in {{ic|~/.Private}}<br />
:* unlocked on demand with dedicated passphrase<br />
<br />
;Example 2: Partial system encryption with each user's home directory encrypted with [[ECryptfs]]<br />
:* unlocked on respective user login, using login passphrase<br />
:* {{ic|swap}} and {{ic|/tmp}} partitions encrypted with [[Dm-crypt with LUKS]], using an automatically generated per-session throwaway key<br />
:* indexing/caching of contents of {{ic|/home}} by ''slocate'' (and similar apps) disabled.<br />
<br />
;Example 3: System encryption - whole hard drive except {{ic|/boot}} partition (however, {{ic|/boot}} can be encrypted with [[Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29|GRUB]]) encrypted with [[Dm-crypt with LUKS]]<br />
:* unlocked during boot, using passphrases or USB stick with keyfiles<br />
:* Maybe different passphrases/keys per user - independently revocable<br />
:* Maybe encryption spanning multiple drives or partition layout flexibility with [[Dm-crypt/Encrypting an entire system#LUKS on LVM|LUKS on LVM]]<br />
<br />
;Example 4: Hidden/plain system encryption - whole hard drive encrypted with [[dm-crypt|plain dm-crypt]]<br />
:* USB-boot, using dedicated passphrase plus USB stick with keyfile<br />
:* data integrity checked before mounting<br />
:* {{ic|/boot}} partition located on aforementioned USB stick<br />
<br />
Many other combinations are of course possible. You should carefully plan what kind of setup will be appropriate for your system.<br />
<br />
===Choosing a strong passphrase===<br />
<br />
See [[Security#Passwords]].<br />
<br />
===Preparing the disk===<br />
<br />
Before setting up disk encryption on a (part of a) disk, consider securely wiping it first. This consists of overwriting the entire drive or partition with a stream of zero bytes or random bytes, and is done for one or both of the following reasons:<br />
<br />
;Prevent recovery of previously stored data<br />
<br />
Disk encryption does not change the fact that individual sectors are only overwritten on demand, when the file system creates or modifies the data those particular sectors hold (see [[#How the encryption works]] below). Sectors which the filesystem considers "not currently used" are not touched, and may still contain remnants of data from previous filesystems. The only way to make sure that all data which you previously stored on the drive can not be [[Wikipedia:Data_recovery|recovered]], is to manually erase it.<br />
For this purpose it does not matter whether zero bytes or random bytes are used (although wiping with zero bytes will be much faster).<br />
<br />
;Prevent disclosure of usage patterns on the encrypted drive<br />
<br />
Ideally, the whole encrypted part of the disk should be indistinguishable from uniformly random data. This way, no unauthorized person can know which and how many sectors actually contain encrypted data - which may be a desirable goal in itself (as part of true confidentiality), and also serves as an additional barrier against attackers trying to break the encryption.<br />
In order to satisfy this goal, wiping the disk using high-quality random bytes is crucial.<br />
<br />
The second goal only makes sense in combination with block device encryption, because in the case of stacked filesystem encryption the encrypted data can easily be located anyways (in the form of distinct encrypted files in the host filesystem). Also note that even if you only intend to encrypt a particular folder, you will have to erase the whole partition if you want to get rid of files that were previously stored in that folder in unencrypted form (due to [[Wikipedia::File_system_fragmentation|disk fragmentation]]). If there are other folders on the same partition, you will have to back them up and move them back afterwards.<br />
<br />
Once you have decided which kind of disk erasure you want to perform, refer to the [[Securely wipe disk]] article for technical instructions.<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
==How the encryption works==<br />
<br />
This section is intended as a high-level introduction to the concepts and processes which are at the heart of usual disk encryption setups.<br />
<br />
It does not go into technical or mathematical details (consult the appropriate literature for that), but should provide a system administrator with a rough understanding of how different setup choices (especially regarding key management) can affect usability and security.<br />
<br />
===Basic principle===<br />
<br />
For the purposes of disk encryption, each blockdevice (or individual file in the case of stacked filesystem encryption) is divided into '''sectors''' of equal length, for example 512 bytes (4,096 bits). The encryption/decryption then happens on a per-sector basis, so the n'th sector of the blockdevice/file on disk will store the encrypted version of the n'th sector of the original data.<br />
<br />
Whenever the operating system or an application requests a certain fragment of data from the blockdevice/file, the whole sector (or sectors) that contains the data will be read from disk, decrypted on-the-fly, and temporarily stored in memory:<br />
<br />
{{Text art|<nowiki><br />
╔═══════╗<br />
sector 1 ║"???.."║<br />
╠═══════╣ ╭┈┈┈┈┈╮<br />
sector 2 ║"???.."║ ┊ key ┊<br />
╠═══════╣ ╰┈┈┬┈┈╯<br />
: : │<br />
╠═══════╣ ▼ ┣┉┉┉┉┉┉┉┫<br />
sector n ║"???.."║━━━━━━━(decryption)━━━━━━▶┋"abc.."┋ sector n<br />
╠═══════╣ ┣┉┉┉┉┉┉┉┫<br />
: :<br />
╚═══════╝<br />
<br />
encrypted unencrypted<br />
blockdevice or data in RAM<br />
file on disk<br />
</nowiki>}}<br />
<br />
Similarly, on each write operation, all sectors that are affected must be re-encrypted completely (while the rest of the sectors remain untouched). <br />
<br />
In order to be able to de/encrypt data, the disk encryption system needs to know the unique secret "key" associated with it. Whenever the encrypted block device or folder in question is to be mounted, its corresponding key (called henceforth its "master key") must be supplied. <br />
<br />
The entropy of the key is of utmost importance for the security of the encryption. A randomly generated byte string of a certain length, for example 32 bytes (256 bits), has desired properties but is not feasible to remember and apply manually during the mount. <br />
<br />
For that reason two techniques are used as aides. The first is the application of cryptography to increase the entropic property of the master key, usually involving a separate human-friendly passphrase. For the different types of encryption the [[#Comparison table]] lists respective features. The second method is to create a keyfile with high entropy and store it on a medium separate from the data drive to be encrypted. <br />
<br />
See also [[Wikipedia:Authenticated encryption]].<br />
<br />
===Keys, keyfiles and passphrases===<br />
<br />
The following are examples how to store and cryptographically secure a master key with a keyfile:<br />
<br />
;Stored in a plaintext keyfile<br />
<br />
Simply storing the master key in a file (in readable form) is the simplest option. The file - called a "keyfile" - can be placed on a USB stick that you keep in a secure location and only connect to the computer when you want to mount the encrypted parts of the disk (e.g. during boot or login).<br />
<br />
;Stored in passphrase-protected form in a keyfile or on the disk itself<br />
<br />
The master key (and thus the encrypted data) can be protected with a secret passphrase, which you will have to remember and enter each time you want to mount the encrypted block device or folder. See [[#Cryptographic metadata]] below for details.<br />
<br />
;Randomly generated on-the-fly for each session<br />
<br />
In some cases, e.g. when encrypting swap space or a {{ic|/tmp}} partition, it is not necessary to keep a persistent master key at all. A new throwaway key can be randomly generated for each session, without requiring any user interaction. This means that once unmounted, all files written to the partition in question can never be decrypted again by ''anyone'' - which in those particular use-cases is perfectly fine.<br />
<br />
===Cryptographic metadata===<br />
<br />
Frequently the encryption techniques use cryptographic functions to enhance the security of the master key itself. On mount of the encrypted device the passphrase or keyfile is passed through these and only the result can unlock the master key to decrypt the data. <br />
<br />
A common setup is to apply so-called "key stretching" to the passphrase (via a "key derivation function"), and use the resulting enhanced passphrase as the mount key for decrypting the actual master key (which has been previously stored in encrypted form):<br />
<br />
{{Text art|<nowiki><br />
╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮ ╭┈┈┈┈┈┈┈┈┈┈┈╮<br />
┊ mount passphrase ┊━━━━━⎛key derivation⎞━━━▶┊ mount key ┊<br />
╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,───⎝ function ⎠ ╰┈┈┈┈┈┬┈┈┈┈┈╯<br />
╭──────╮ ╱ │<br />
│ salt │───────────´ │<br />
╰──────╯ │<br />
╭─────────────────────╮ ▼ ╭┈┈┈┈┈┈┈┈┈┈┈┈╮<br />
│ encrypted master key│━━━━━━━━━━━━━━━━━━━━━━(decryption)━━━▶┊ master key ┊<br />
╰─────────────────────╯ ╰┈┈┈┈┈┈┈┈┈┈┈┈╯<br />
</nowiki>}}<br />
<br />
The '''key derivation function''' (e.g. PBKDF2 or scrypt) is deliberately slow (it applies many iterations of a hash function, e.g. 1000 iterations of HMAC-SHA-512), so that brute-force attacks to find the passphrase are rendered infeasible. For the normal use-case of an authorized user, it will only need to be calculated once per session, so the small slowdown is not a problem.<br />
It also takes an additional blob of data, the so-called "'''salt'''", as an argument - this is randomly generated once during set-up of the disk encryption and stored unprotected as part of the cryptographic metadata. Because it will be a different value for each setup, this makes it infeasible for attackers to speed up brute-force attacks using precomputed tables for the key derivation function.<br />
<br />
The '''encrypted master key''' can be stored on disk together with the encrypted data. This way, the confidentiality of the encrypted data depends completely on the secret passphrase. <br />
<br />
Additional security can be attained by instead storing the encrypted master key in a keyfile on e.g. a USB stick. This provides '''two-factor authentication''': Accessing the encrypted data now requires something only you ''know'' (the passphrase), and additionally something only you ''have'' (the keyfile).<br />
<br />
Another way of achieving two-factor authentication is to augment the above key retrieval scheme to mathematically "combine" the passphrase with byte data read from one or more external files (located on a USB stick or similar), before passing it to the key derivation function.The files in question can be anything, e.g. normal JPEG images, which can be beneficial for [[#Plausible deniability]]. They are still called "keyfiles" in this context, though.<br />
<br />
After it has been derived, the master key is securely stored in memory (e.g. in a kernel keyring), for as long as the encrypted block device or folder is mounted.<br />
<br />
It is usually not used for de/encrypting the disk data directly, though.<br />
For example, in the case of stacked filesystem encryption, each file can be automatically assigned its own encryption key. Whenever the file is to be read/modified, this file key first needs to be decrypted using the main key, before it can itself be used to de/encrypt the file contents:<br />
<br />
{{Text art|<nowiki><br />
╭┈┈┈┈┈┈┈┈┈┈┈┈╮<br />
┊ master key ┊<br />
file on disk: ╰┈┈┈┈┈┬┈┈┈┈┈┈╯<br />
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │<br />
╎╭───────────────────╮╎ ▼ ╭┈┈┈┈┈┈┈┈┈┈╮<br />
╎│ encrypted file key│━━━━(decryption)━━━▶┊ file key ┊<br />
╎╰───────────────────╯╎ ╰┈┈┈┈┬┈┈┈┈┈╯<br />
╎┌───────────────────┐╎ ▼ ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐<br />
╎│ encrypted file │◀━━━━━━━━━━━━━━━━━(de/encryption)━━━▶┊ readable file ┊<br />
╎│ contents │╎ ┊ contents ┊<br />
╎└───────────────────┘╎ └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘<br />
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘<br />
</nowiki>}}<br />
<br />
In a similar manner, a separate key (e.g. one per folder) may be used for the encryption of file names in the case of stacked filesystem encryption.<br />
<br />
In the case of block device encryption one master key is used per device and, hence, all data. Some methods offer features to assign multiple passphrases/keyfiles for the same device and others not. Some use above mentioned functions to secure the master key and others give the control over the key security fully to the user. Two examples are explained by the cryptographic parameters used by [[dm-crypt]] in plain or LUKS modes. <br />
<br />
When comparing the parameters used by both modes one notes that dm-crypt plain mode has parameters relating to how to locate the keyfile (e.g. {{ic|--keyfile-size}}, {{ic|--keyfile-offset}}). The dm-crypt LUKS mode does not need these, because each blockdevice contains a header with the cryptographic metadata at the beginning. The header includes the used cipher, the encrypted master-key itself and parameters required for its derivation for decryption. The latter parameters in turn result from options used during initial encryption of the master-key (e.g. {{ic|--iter-time}}, {{ic|--use-random}}). <br />
<br />
For the dis-/advantages of the different techniques, please refer back to [[#Comparison table]] or browse the specific pages. <br />
<br />
See also:<br />
* [[Wikipedia:Passphrase]]<br />
* [[Wikipedia:Key (cryptography)]]<br />
* [[Wikipedia:Key management]]<br />
* [[Wikipedia:Key derivation function]]<br />
<br />
===Ciphers and modes of operation===<br />
<br />
The actual algorithm used for translating between pieces of unencrypted and encrypted data (so-called "plaintext" and "ciphertext") which correspond to each other with respect to a given encryption key, is called a "'''cipher'''".<br />
<br />
Disk encryption employs "block ciphers", which operate on fixed-length blocks of data, e.g. 16 bytes (128 bits). At the time of this writing, the predominantly used ones are:<br />
{| class="wikitable" style="margin:0 5em 1.5em 5em;"<br />
! scope="col" style="text-align:left" | <br />
! scope="col" style="text-align:left" | block&nbsp;size<br />
! scope="col" style="text-align:left" | key&nbsp;size<br />
! scope="col" style="text-align:left" | comment<br />
|-<br />
! scope="row" style="text-align:right" | [[Wikipedia:Advanced_Encryption_Standard|AES]]<br />
| 128 bits<br />
| 128, 192 or 256 bits<br />
| approved by the NSA for protecting "SECRET" and "TOP SECRET" classified US-government information (when used with a key size of 192 or 256 bits)<br />
|-<br />
! scope="row" style="text-align:right" | [[wikipedia:Blowfish (cipher)|Blowfish]]<br />
| 64 bits<br />
| 32–448 bits<br />
| one of the first patent-free secure ciphers that became publicly available, hence very well established on Linux<br />
|-<br />
! scope="row" style="text-align:right" | [[Wikipedia:Twofish|Twofish]]<br />
| 128 bits<br />
| 128, 192 or 256 bits<br />
| developed as successor of Blowfish, but has not attained as much widespread usage<br />
|-<br />
! scope="row" style="text-align:right" | [[wikipedia:Serpent (cipher)|Serpent]]<br />
| 128 bits<br />
| 128, 192 or 256 bits<br />
| Considered the most secure of the five AES-competition finalists[http://csrc.nist.gov/archive/aes/round2/r2report.pdf][https://www.cl.cam.ac.uk/~rja14/Papers/serpentcase.pdf][https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf].<br />
|}<br />
<br />
Encrypting/decrypting a sector ([[#Basic principle|see above]]) is achieved by dividing it into small blocks matching the cipher's block-size, and following a certain rule-set (a so-called "'''mode of operation'''") for how to consecutively apply the cipher to the individual blocks.<br />
<br />
Simply applying it to each block separately without modification (dubbed the "''electronic codebook (ECB)''" mode) would not be secure, because if the same 16 bytes of plaintext always produce the same 16 bytes of ciphertext, an attacker could easily recognize patterns in the ciphertext that is stored on disk.<br />
<br />
The most basic (and common) mode of operation used in practice is "''cipher-block chaining (CBC)''". When encrypting a sector with this mode, each block of plaintext data is combined in a mathematical way with the ciphertext of the previous block, before encrypting it using the cipher. For the first block, since it has no previous ciphertext to use, a special pre-generated data block stored with the sector's cryptographic metadata and called an "'''initialization vector (IV)'''" is used:<br />
<br />
{{Text art|<nowiki><br />
╭──────────────╮<br />
│initialization│<br />
│vector │<br />
╰────────┬─────╯<br />
╭ ╠══════════╣ ╭─key │ ┣┉┉┉┉┉┉┉┉┉┉┫ <br />
│ ║ ║ ▼ ▼ ┋ ┋ . START<br />
┴ ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"Hello, W"┋ block ╱╰────┐<br />
sector n ║ ║ ┋ ┋ 1 ╲╭────┘<br />
of file or ║ ║──────────────────╮ ┋ ┋ ' <br />
blockdevice ╟──────────╢ ╭─key │ ┠┈┈┈┈┈┈┈┈┈┈┨<br />
┬ ║ ║ ▼ ▼ ┋ ┋<br />
│ ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"orld !!!"┋ block<br />
│ ║ ║ ┋ ┋ 2<br />
│ ║ ║──────────────────╮ ┋ ┋<br />
│ ╟──────────╢ │ ┠┈┈┈┈┈┈┈┈┈┈┨<br />
│ ║ ║ ▼ ┋ ┋<br />
: : ... : ... ... : ... : ...<br />
<br />
ciphertext plaintext<br />
on disk in RAM<br />
</nowiki>}}<br />
<br />
When decrypting, the procedure is reversed analogously.<br />
<br />
One thing worth noting is the generation of the unique initialization vector for each sector. The simplest choice is to calculate it in a predictable fashion from a readily available value such as the sector number. However, this might allow an attacker with repeated access to the system to perform a so-called [[wikipedia:Watermarking_attack|watermarking attack]]. To prevent that, a method called "Encrypted salt-sector initialization vector ('''ESSIV''')" can be used to generate the initialization vectors in a way that makes them look completely random to a potential attacker.<br />
<br />
There are also a number of other, more complicated modes of operation available for disk encryption, which already provide built-in security against such attacks (and hence do not require ESSIV).<br />
Some can also additionally guarantee authenticity of the encrypted data (i.e. confirm that it has not been modified/corrupted by someone who does not have access to the key).<br />
<br />
See also:<br />
* [[Wikipedia:Disk encryption theory]]<br />
* [[Wikipedia:Block cipher]]<br />
* [[Wikipedia:Block cipher modes of operation]]<br />
<br />
===Plausible deniability===<br />
<br />
See [[Wikipedia:Plausible deniability]].</div>Ivankhttps://wiki.archlinux.org/index.php?title=Data-at-rest_encryption&diff=574516Data-at-rest encryption2019-06-04T08:31:52Z<p>Ivank: /* Comparison table */ added gocryptfs</p>
<hr />
<div>[[Category:Disk encryption]]<br />
[[es:Disk encryption]]<br />
[[it:Disk encryption]]<br />
[[ja:ディスク暗号化]]<br />
[[pl:Disk encryption]]<br />
[[zh-hans:Disk encryption]]<br />
{{Related articles start}}<br />
{{Related|dm-crypt}}<br />
{{Related|TrueCrypt}}<br />
{{Related|eCryptfs}}<br />
{{Related|EncFS}}<br />
{{Related|gocryptfs}}<br />
{{Related|Tomb}}<br />
{{Related|tcplay}}<br />
{{Related|GnuPG}}<br />
{{Related|Self-Encrypting Drives}}<br />
{{Related articles end}}<br />
This article discusses [[Wikipedia:Disk encryption|disk encryption]] software, which on-the-fly encrypts / decrypts data written to / read from a [[block device]], [[disk partition]] or directory. Examples for block devices are hard drives, flash drives and DVDs.<br />
<br />
Disk encryption should only be viewed as an adjunct to the existing security mechanisms of the operating system - focused on securing physical access, while relying on ''other'' parts of the system to provide things like network security and user-based access control.<br />
<br />
For Full-disk encryption (FDE), see [[dm-crypt/Encrypting an entire system]].<br />
<br />
==Why use encryption?==<br />
<br />
Disk encryption ensures that files are always stored on disk in an encrypted form. The files only become available to the operating system and applications in readable form while the system is running and unlocked by a trusted user. An unauthorized person looking at the disk contents directly, will only find garbled random-looking data instead of the actual files.<br />
<br />
For example, this can prevent unauthorized viewing of the data when the computer or hard-disk is:<br />
* located in a place to which non-trusted people might gain access while you are away<br />
* lost or stolen, as with laptops, netbooks or external storage devices<br />
* in the repair shop<br />
* discarded after its end-of-life<br />
<br />
In addition, disk encryption can also be used to add some security against unauthorized attempts to tamper with your operating system – for example, the installation of keyloggers or Trojan horses by attackers who can gain physical access to the system while you are away.<br />
<br />
{{Warning|Disk encryption does '''not''' protect your data from all threats.}}<br />
You will still be vulnerable to:<br />
* Attackers who can break into your system (e.g. over the Internet) while it is running and after you have already unlocked and mounted the encrypted parts of the disk.<br />
* Attackers who are able to gain physical access to the computer while it is running (even if you use a screenlocker), or very shortly ''after'' it was running, if they have the resources to perform a [[Wikipedia:Cold boot attack|cold boot attack]].<br />
* A government entity, which not only has the resources to easily pull off the above attacks, but also may simply force you to give up your keys/passphrases using various techniques of [[Wikipedia:Coercion|coercion]]. In most non-democratic countries around the world, as well as in the USA and UK, it may be legal for law enforcement agencies to do so if they have suspicions that you might be hiding something of interest.<br />
<br />
A very strong disk encryption setup (e.g. full system encryption with authenticity checking and no plaintext boot partition) is required to stand a chance against professional attackers who are able to tamper with your system ''before'' you use it. And even then it cannot prevent all types of tampering (e.g. hardware keyloggers). The best remedy might be [[Wikipedia:Hardware-based full disk encryption|hardware-based full disk encryption]] and [[Wikipedia:Trusted_Computing|Trusted Computing]].<br />
<br />
{{Warning|Disk encryption also will not protect you against someone simply [[Securely wipe disk|wiping your disk]]. [[Backup programs|Regular backups]] are recommended to keep your data safe.}}<br />
<br />
== System data encryption ==<br />
<br />
While encrypting only the user data itself (often located within the home directory, or on removable media like a data DVD), is the simplest and least intrusive method, it has some significant drawbacks.<br />
In modern computer systems, there are many background processes that may cache and store information about user data or parts of the data itself in non-encrypted areas of the hard drive, like:<br />
<br />
:* swap partitions<br />
:** (potential remedies: disable swapping, or use [[encrypted swap]] as well)<br />
:* {{ic|/tmp}} (temporary files created by user applications)<br />
:** (potential remedies: avoid such applications; mount {{ic|/tmp}} inside a [[ramdisk]])<br />
:* {{ic|/var}} (log files and databases and such; for example, [[mlocate]] stores an index of all file names in {{ic|/var/lib/mlocate/mlocate.db}})<br />
<br />
The solution is to encrypt both system and user data, preventing unauthorized physical access to private data that may be cached by the system. This however comes with the disadvantage that unlocking of the encrypted parts of the disk has to happen at boot time. Another benefit of system data encryption is that it complicates the installation of malware like [[Wikipedia:Keystroke logging|keyloggers]] or rootkits for someone with physical access.<br />
<br />
== Available methods ==<br />
<br />
{{Expansion|[[Ext4]], [[ZFS]] and possible other filesystems offer (native) encryption.}}<br />
<br />
All disk encryption methods operate in such a way that even though the disk actually holds encrypted data, the operating system and applications "see" it as the corresponding normal readable data as long as the cryptographic container (i.e. the logical part of the disk that holds the encrypted data) has been "unlocked" and mounted.<br />
<br />
For this to happen, some "secret information" (usually in the form of a keyfile and/or passphrase) needs to be supplied by the user, from which the actual encryption key can be derived (and stored in the kernel keyring for the duration of the session).<br />
<br />
If you are completely unfamiliar with this sort of operation, please also read the [[#How the encryption works]] section below.<br />
<br />
The available disk encryption methods can be separated into two types by their layer of operation:<br />
<br />
=== Stacked filesystem encryption ===<br />
<br />
Stacked filesystem encryption solutions are implemented as a layer that stacks on top of an existing filesystem, causing all files written to an encryption-enabled folder to be encrypted on-the-fly before the underlying filesystem writes them to disk, and decrypted whenever the filesystem reads them from disk. This way, the files are stored in the host filesystem in encrypted form (meaning that their contents, and usually also their file/folder names, are replaced by random-looking data of roughly the same length), but other than that they still exist in that filesystem as they would without encryption, as normal files / symlinks / hardlinks / etc.<br />
<br />
The way it is implemented, is that to unlock the folder storing the raw encrypted files in the host filesystem ("lower directory"), it is mounted (using a special stacked pseudo-filesystem) onto itself or optionally a different location ("upper directory"), where the same files then appear in readable form - until it is unmounted again, or the system is turned off.<br />
<br />
Available solutions in this category are [[eCryptfs]] and [[EncFS]].<br />
<br />
==== Cloud-storage optimized ====<br />
<br />
If you are deploying stacked filesystem encryption to achieve zero-knowledge synchronization with third-party-controlled locations such as cloud-storage services, you may want to consider alternatives to eCryptfs and EncFS, since these are not optimized for transmission of files over the Internet. There are some solutions designed for this purpose instead:<br />
<br />
* [[gocryptfs]]<br />
* {{aur|cryptomator}} (multi-platform)<br />
* {{pkg|cryfs}}<br />
<br />
Note that some cloud-storage services offer zero-knowledge encryption directly through their own [[List of applications/Internet#Cloud synchronization clients|client applications]].<br />
<br />
=== Block device encryption ===<br />
<br />
Block device encryption methods, on the other hand, operate ''below'' the filesystem layer and make sure that everything written to a certain block device (i.e. a whole disk, or a partition, or a file acting as a [[Wikipedia:loop device|loop device]]) is encrypted. This means that while the block device is offline, its whole content looks like a large blob of random data, with no way of determining what kind of filesystem and data it contains. Accessing the data happens, again, by mounting the protected container (in this case the block device) to an arbitrary location in a special way.<br />
<br />
The following "block device encryption" solutions are available in Arch Linux:<br />
<br />
;loop-AES: loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption. However, loop-AES is considered less user-friendly than other options as it requires non-standard kernel support. <br />
<br />
;dm-crypt: [[dm-crypt]] is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management. The management of dm-crypt is done with the {{Pkg|cryptsetup}} userspace utility. It can be used for the following types of block-device encryption: ''LUKS'' (default), ''plain'', and has limited features for ''loopAES'' and ''Truecrypt'' devices. <br />
:* LUKS, used by default, is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use and cryptographic security. <br />
:* plain dm-crypt mode, being the original kernel functionality, does not employ the convenience layer. It is more difficult to apply the same cryptographic strength with it. When doing so, longer keys (passphrases or keyfiles) are the result. It has, however, other advantages, described in the following [[#Block device vs stacked filesystem encryption]]. <br />
<br />
;TrueCrypt/VeraCrypt: A portable format, supporting encryption of whole disks/partitions or file containers, with compatibility across all major operating systems. [[TrueCrypt]] was discontinued by its developers in May 2014. The VeraCrypt fork was audited in 2016.<br />
<br />
For practical implications of the chosen layer of operation, see the [[#Block device vs stacked filesystem encryption]] below, as well as the general write up for [https://www.systutorials.com/docs/linux/packages/ecryptfs-utils-111/ecryptfs-faq.html#compare eCryptfs]. See [[:Category:Encryption]] for the available content of the methods compared below, as well as other tools not included in the table.<br />
<br />
=== Block device vs stacked filesystem encryption ===<br />
<br />
{| class="wikitable left-align-row-headers" style="text-align:center;"<br />
! Aspect<br />
! {{B|Block device encryption}}<br />
! {{V|Stacked filesystem encryption}}<br />
|-<br />
! Encrypts<br />
| whole block devices<br />
| files<br />
|-<br />
! Container for encrypted data may be...<br />
| a disk or disk partition / a file acting as a virtual partition<br />
| a directory in an existing file system<br />
|-<br />
! Relation to filesystem<br />
| operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else<br />
| adds an additional layer to an existing filesystem, to automatically encrypt/decrypt files whenever they are written/read<br />
|-<br />
! File metadata (number of files, dir structure, file sizes, permissions, mtimes, etc.) is encrypted<br />
| {{Ya}}<br />
| {{Na}}<br>(file and dir names can be encrypted though)<br />
|-<br />
! Can be used to custom-encrypt whole hard drives (including partition tables)<br />
| {{Ya}}<br />
| {{Na}}<br />
|-<br />
! Can be used to encrypt swap space<br />
| {{Ya}}<br />
| {{Na}}<br />
|-<br />
<br />
! Can be used without pre-allocating a fixed amount of space for the encrypted data container<br />
| {{Na}}<br />
| {{Ya}}<br />
|-<br />
! Can be used to protect existing filesystems without block device access, e.g. NFS or Samba shares, cloud storage, etc.<br />
| {{Na}}<br />
| {{Ya}}<br />
|-<br />
! Allows offline file-based backups of encrypted files<br />
| {{Na}}<br />
| {{Ya}}<br />
|}<br />
<br />
=== Comparison table ===<br />
<br />
{{Expansion|Fill in blanks. Add sources to checkmarks / crosses. What is ''salt'', ''key-slot diffusion'' or ''key scrubbing''?}}<br />
<br />
The column "dm-crypt +/- LUKS" denotes features of dm-crypt for both LUKS ("+") and plain ("-") encryption modes. If a specific feature requires using LUKS, this is indicated by "(with LUKS)". Likewise "(without LUKS)" indicates usage of LUKS is counter-productive to achieve the feature and plain mode should be used.<br />
<br />
{| class="wikitable left-align-row-headers" style="text-align:center; cell-padding:100px; "<br />
!{{Grey|Summary}}<br />
! Loop-AES<br />
! [[dm-crypt]] +/- LUKS<br />
! [[TrueCrypt]]<br />
! VeraCrypt<br />
! [[eCryptfs]]<br />
! [[EncFS]]<br />
! [[gocryptfs]]<br />
|-<br />
! Encryption type<br />
| {{B|block device}}<br />
| {{B|block device}}<br />
| {{B|block device}}<br />
| {{B|block device}}<br />
| {{V|stacked filesystem}}<br />
| {{V|stacked filesystem}}<br />
| {{V|stacked filesystem}}<br />
|-<br />
! Note<br />
| longest-existing one; possibly the fastest; works on legacy systems<br />
| de-facto standard for block device encryption on Linux; very flexible<br />
| very portable, well-polished but abandoned<br />
| maintained fork of TrueCrypt<br />
| slightly faster than EncFS; individual encrypted files portable between systems<br />
| easiest one to use; supports non-root administration<br />
| aspiring successor of EncFS<br />
|-<br />
! Availability in Arch Linux<br />
| requires manually compiled, custom kernel<br />
| ''kernel modules:'' already shipped with default kernel; ''tools:'' {{Pkg|device-mapper}}, {{Pkg|cryptsetup}}<br />
| {{Pkg|truecrypt}}<br />
| {{Pkg|veracrypt}}<br />
| ''kernel module:'' already shipped with default kernel; ''tools:'' {{Pkg|ecryptfs-utils}}<br />
| {{Pkg|encfs}}<br />
| {{Pkg|gocryptfs}}<br />
|-<br />
! License<br />
| GPL<br />
| GPL<br />
| TrueCrypt License 3.1<br />
| Apache License 2.0, parts subject to TrueCrypt License v3.0<br />
| GPL<br />
| GPL<br />
| MIT<br />
|-<br />
! Encryption implemented in...<br />
| kernelspace<br />
| kernelspace<br />
| kernelspace<br />
| kernelspace<br />
| kernelspace<br />
| userspace ([[FUSE]])<br />
| userspace ([[FUSE]])<br />
|-<br />
! Cryptographic metadata stored in...<br />
| ?<br />
| with LUKS: LUKS Header <br />
| begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format]){{Dead link|2018|07|15}}<br />
| begin/end of (decrypted) device ([https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format%20Specification.html format spec])<br />
| header of each encrypted file<br />
| control file at the top level of each EncFs container<br />
|-<br />
! Wrapped encryption key stored in...<br />
| ?<br />
| with LUKS: LUKS header <br />
| begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format spec]){{Dead link|2018|07|15}}<br />
| begin/end of (decrypted) device ([https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format%20Specification.html format spec])<br />
| key file that can be stored anywhere<br />
| key file that can be stored anywhere<br />
[https://github.com/rfjakob/encfs/blob/next/encfs/encfs.pod#environment-variables][https://github.com/vgough/encfs/issues/48#issuecomment-69301831]<br />
|<br />
|-<br />
! {{Grey|Usability features}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Non-root users can create/destroy containers for encrypted data<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Na}}<br />
| limited<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! Provides a GUI<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Na}}<br />
| {{Ya}}<br />
[[EncFS#Gnome Encfs Manager|optional]]<br />
| {{Na}}<br />
|-<br />
! Support for automounting on login<br />
| ?<br />
| {{Ya}}<br />
| {{Ya}}<br />
with [[TrueCrypt#Automounting_using_.2Fetc.2Fcrypttab|systemd and /etc/crypttab]]<br />
| {{Ya}}<br />
with [[TrueCrypt#Automounting_using_.2Fetc.2Fcrypttab|systemd and /etc/crypttab]]<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! Support for automatic unmounting in case of inactivity<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
| ?<br />
|-<br />
! {{Grey|Security features}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Supported ciphers<br />
| AES<br />
| AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish,… (every cipher the kernel Crypto API offers)<br />
| AES, Twofish, Serpent<br />
| AES, Twofish, Serpernt, Camellia, Kuznyechik<br />
| AES, Blowfish, Twofish...<br />
| AES, Blowfish, Twofish, and any other ciphers available on the system<br />
| AES<br />
|-<br />
! Integrity<br />
| none<br />
| none<br />
| none<br />
| none<br />
| none<br />
| none (defauly) / HMAC (paranoia mode)<br />
| GCM<br />
|-<br />
! Support for salting<br />
| ?<br />
| {{Ya}}<br>(with LUKS)<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| {{Ya}}<br />
|-<br />
! Support for cascading multiple ciphers<br />
| ?<br />
| Not in one device, but blockdevices can be cascaded<br />
| {{Ya}}<br />
AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent<br />
| {{Ya}}<br />
AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent<br />
| ?<br />
| {{Na}}<br />
| {{Na}}<br />
|-<br />
! Support for key-slot diffusion<br />
| ?<br />
| {{Ya}}<br>(with LUKS)<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
! Protection against key scrubbing<br />
| {{Ya}}<br />
| {{Ya}}<br>(without LUKS)<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
! Support for multiple (independently revocable) keys for the same encrypted data<br />
| ?<br />
| {{Ya}}<br>(with LUKS)<br />
| ?<br />
| ?<br />
| ?<br />
| {{Na}}<br />
| ?<br />
|-<br />
! {{Grey|Performance features}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Multithreading support<br />
| ?<br />
| {{Ya}}<br>[http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c]<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
|-<br />
! Hardware-accelerated encryption support<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br>[https://github.com/vgough/encfs/issues/118]<br />
| {{Ya}}<br />
|-<br />
! {{Grey|Block device encryption specific}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! colspan=2 rowspan=2 {{Grey|}}<br />
|-<br />
! Support for (manually) resizing the encrypted block device in-place<br />
| ?<br />
| {{Ya}}<br />
| {{Na}}<br />
| {{Na}}<br />
| {{Na}}<br />
|-<br />
! {{Grey|Stacked filesystem encryption specific}}<br />
! colspan=4 rowspan=5 {{Grey|}}<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Supported file systems<br />
| ext3, ext4, xfs (with caveats), jfs, nfs...<br />
| ext3, ext4, xfs (with caveats), jfs, nfs, cifs...<br />
[https://github.com/vgough/encfs]<br />
| any<br />
|-<br />
! Ability to encrypt filenames<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! Ability to ''not'' encrypt filenames<br />
| {{Ya}}<br />
| {{Ya}}<br />
| {{Na}}<br />
|-<br />
! Optimized handling of sparse files<br />
| {{Na}}<br />
| {{Ya}}<br />
| {{Ya}}<br />
|-<br />
! {{Grey|Compatibility & prevalence}}<br />
! Loop-AES<br />
! dm-crypt +/- LUKS<br />
! TrueCrypt<br />
! VeraCrypt<br />
! eCryptfs<br />
! EncFs<br />
! gocryptfs<br />
|-<br />
! Supported Linux kernel versions<br />
| 2.0 or newer<br />
| CBC-mode since 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24<br />
| ?<br />
| ?<br />
| ?<br />
| 2.4 or newer<br />
| ?<br />
|-<br />
! Encrypted data can also be accessed from Windows<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| {{Ya}}<br>[https://github.com/vgough/encfs/wiki/Windows]<br />
| {{Ya}} (cppcryptfs port)<br />
|-<br />
! Encrypted data can also be accessed from Mac OS X<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
| {{Ya}}<br />
| ?<br />
| {{Ya}}<br>[https://sites.google.com/a/arg0.net/www/encfs-mac-build]<br />
| {{Ya}} (beta quality)<br />
|-<br />
! Encrypted data can also be accessed from FreeBSD<br />
| ?<br />
| ?<br />
| {{Ya}}<br />
(with VeraCrypt)<br />
| {{Ya}}<br><br />
| ?<br />
| {{Ya}}<br>[http://www.freshports.org/sysutils/fusefs-encfs/]<br />
| ?<br />
|-<br />
<br />
! Used by<br />
| ?<br />
| Debian/Ubuntu installer (system encryption)<br>Fedora installer <br />
| ?<br />
| ?<br />
| Ubuntu installer (home dir encryption)<br>Chromium OS (encryption of cached user data [https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data])<br />
| ?<br />
| ?<br />
|}<br />
<br />
# well, a single file in those filesystems could be used as a container (virtual loop-back device!) but then one would not actually be using the filesystem (and the features it provides) anymore<br />
<br />
==Preparation==<br />
<br />
===Choosing a setup===<br />
<br />
Which disk encryption setup is appropriate for you will depend on your goals (please read [[#Why use encryption?]] above) and system parameters.<br />
<br />
Among other things, you will need to answer the following questions:<br />
<br />
;What kind of "attacker" do you want to protect against?<br />
<br />
* Casual computer user snooping around your disk when your system is turned off / stolen / etc.<br />
* Professional cryptanalyst who can get repeated read/write access to your system before and after you use it<br />
* Anything in between<br />
<br />
;What do you want to encrypt?<br />
<br />
* only user data<br />
* user data and system data<br />
* something in between<br />
<br />
;How should swap, {{ic|/tmp}}, etc. be taken care of?<br />
<br />
* Ignore, and hope no data is leaked<br />
* Disable or mount as ramdisk<br />
* Encrypt ''(as part of full disk encryption, or separately)''<br />
<br />
;How should encrypted parts of the disk be unlocked?<br />
<br />
* Passphrase ''(same as login password, or separate)''<br />
* Keyfile ''(e.g. on a USB stick, that you keep in a safe place or carry around with yourself)''<br />
* Both<br />
<br />
;''When'' should encrypted parts of the disk be unlocked?<br />
<br />
* Before boot<br />
* During boot<br />
* At login<br />
* Manually on demand ''(after login)''<br />
<br />
;How should multiple users be accommodated?<br />
<br />
* Not at all<br />
* Using a shared passphrase/key<br />
* Independently issued and revocable passphrases/keys for the same encrypted part of the disk<br />
* Separate encrypted parts of the disk for different users<br />
<br />
Then you can go on to make the required technical choices (see [[#Available methods]] above, and [[#How the encryption works]] below), regarding:<br />
<br />
* stacked filesystem encryption vs. blockdevice encryption<br />
* key management<br />
* cipher and mode of operation<br />
* metadata storage<br />
* location of the "lower directory" (in case of stacked filesystem encryption)<br />
<br />
=== Examples ===<br />
<br />
In practice, it could turn out something like:<br />
<br />
;Example 1: Simple user data encryption (internal hard drive) using a virtual folder called {{ic|~/Private}} in the user's home directory encrypted with [[EncFS]]<br />
:* encrypted versions of the files stored on-disk in {{ic|~/.Private}}<br />
:* unlocked on demand with dedicated passphrase<br />
<br />
;Example 2: Partial system encryption with each user's home directory encrypted with [[ECryptfs]]<br />
:* unlocked on respective user login, using login passphrase<br />
:* {{ic|swap}} and {{ic|/tmp}} partitions encrypted with [[Dm-crypt with LUKS]], using an automatically generated per-session throwaway key<br />
:* indexing/caching of contents of {{ic|/home}} by ''slocate'' (and similar apps) disabled.<br />
<br />
;Example 3: System encryption - whole hard drive except {{ic|/boot}} partition (however, {{ic|/boot}} can be encrypted with [[Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29|GRUB]]) encrypted with [[Dm-crypt with LUKS]]<br />
:* unlocked during boot, using passphrases or USB stick with keyfiles<br />
:* Maybe different passphrases/keys per user - independently revocable<br />
:* Maybe encryption spanning multiple drives or partition layout flexibility with [[Dm-crypt/Encrypting an entire system#LUKS on LVM|LUKS on LVM]]<br />
<br />
;Example 4: Hidden/plain system encryption - whole hard drive encrypted with [[dm-crypt|plain dm-crypt]]<br />
:* USB-boot, using dedicated passphrase plus USB stick with keyfile<br />
:* data integrity checked before mounting<br />
:* {{ic|/boot}} partition located on aforementioned USB stick<br />
<br />
Many other combinations are of course possible. You should carefully plan what kind of setup will be appropriate for your system.<br />
<br />
===Choosing a strong passphrase===<br />
<br />
See [[Security#Passwords]].<br />
<br />
===Preparing the disk===<br />
<br />
Before setting up disk encryption on a (part of a) disk, consider securely wiping it first. This consists of overwriting the entire drive or partition with a stream of zero bytes or random bytes, and is done for one or both of the following reasons:<br />
<br />
;Prevent recovery of previously stored data<br />
<br />
Disk encryption does not change the fact that individual sectors are only overwritten on demand, when the file system creates or modifies the data those particular sectors hold (see [[#How the encryption works]] below). Sectors which the filesystem considers "not currently used" are not touched, and may still contain remnants of data from previous filesystems. The only way to make sure that all data which you previously stored on the drive can not be [[Wikipedia:Data_recovery|recovered]], is to manually erase it.<br />
For this purpose it does not matter whether zero bytes or random bytes are used (although wiping with zero bytes will be much faster).<br />
<br />
;Prevent disclosure of usage patterns on the encrypted drive<br />
<br />
Ideally, the whole encrypted part of the disk should be indistinguishable from uniformly random data. This way, no unauthorized person can know which and how many sectors actually contain encrypted data - which may be a desirable goal in itself (as part of true confidentiality), and also serves as an additional barrier against attackers trying to break the encryption.<br />
In order to satisfy this goal, wiping the disk using high-quality random bytes is crucial.<br />
<br />
The second goal only makes sense in combination with block device encryption, because in the case of stacked filesystem encryption the encrypted data can easily be located anyways (in the form of distinct encrypted files in the host filesystem). Also note that even if you only intend to encrypt a particular folder, you will have to erase the whole partition if you want to get rid of files that were previously stored in that folder in unencrypted form (due to [[Wikipedia::File_system_fragmentation|disk fragmentation]]). If there are other folders on the same partition, you will have to back them up and move them back afterwards.<br />
<br />
Once you have decided which kind of disk erasure you want to perform, refer to the [[Securely wipe disk]] article for technical instructions.<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
==How the encryption works==<br />
<br />
This section is intended as a high-level introduction to the concepts and processes which are at the heart of usual disk encryption setups.<br />
<br />
It does not go into technical or mathematical details (consult the appropriate literature for that), but should provide a system administrator with a rough understanding of how different setup choices (especially regarding key management) can affect usability and security.<br />
<br />
===Basic principle===<br />
<br />
For the purposes of disk encryption, each blockdevice (or individual file in the case of stacked filesystem encryption) is divided into '''sectors''' of equal length, for example 512 bytes (4,096 bits). The encryption/decryption then happens on a per-sector basis, so the n'th sector of the blockdevice/file on disk will store the encrypted version of the n'th sector of the original data.<br />
<br />
Whenever the operating system or an application requests a certain fragment of data from the blockdevice/file, the whole sector (or sectors) that contains the data will be read from disk, decrypted on-the-fly, and temporarily stored in memory:<br />
<br />
{{Text art|<nowiki><br />
╔═══════╗<br />
sector 1 ║"???.."║<br />
╠═══════╣ ╭┈┈┈┈┈╮<br />
sector 2 ║"???.."║ ┊ key ┊<br />
╠═══════╣ ╰┈┈┬┈┈╯<br />
: : │<br />
╠═══════╣ ▼ ┣┉┉┉┉┉┉┉┫<br />
sector n ║"???.."║━━━━━━━(decryption)━━━━━━▶┋"abc.."┋ sector n<br />
╠═══════╣ ┣┉┉┉┉┉┉┉┫<br />
: :<br />
╚═══════╝<br />
<br />
encrypted unencrypted<br />
blockdevice or data in RAM<br />
file on disk<br />
</nowiki>}}<br />
<br />
Similarly, on each write operation, all sectors that are affected must be re-encrypted completely (while the rest of the sectors remain untouched). <br />
<br />
In order to be able to de/encrypt data, the disk encryption system needs to know the unique secret "key" associated with it. Whenever the encrypted block device or folder in question is to be mounted, its corresponding key (called henceforth its "master key") must be supplied. <br />
<br />
The entropy of the key is of utmost importance for the security of the encryption. A randomly generated byte string of a certain length, for example 32 bytes (256 bits), has desired properties but is not feasible to remember and apply manually during the mount. <br />
<br />
For that reason two techniques are used as aides. The first is the application of cryptography to increase the entropic property of the master key, usually involving a separate human-friendly passphrase. For the different types of encryption the [[#Comparison table]] lists respective features. The second method is to create a keyfile with high entropy and store it on a medium separate from the data drive to be encrypted. <br />
<br />
See also [[Wikipedia:Authenticated encryption]].<br />
<br />
===Keys, keyfiles and passphrases===<br />
<br />
The following are examples how to store and cryptographically secure a master key with a keyfile:<br />
<br />
;Stored in a plaintext keyfile<br />
<br />
Simply storing the master key in a file (in readable form) is the simplest option. The file - called a "keyfile" - can be placed on a USB stick that you keep in a secure location and only connect to the computer when you want to mount the encrypted parts of the disk (e.g. during boot or login).<br />
<br />
;Stored in passphrase-protected form in a keyfile or on the disk itself<br />
<br />
The master key (and thus the encrypted data) can be protected with a secret passphrase, which you will have to remember and enter each time you want to mount the encrypted block device or folder. See [[#Cryptographic metadata]] below for details.<br />
<br />
;Randomly generated on-the-fly for each session<br />
<br />
In some cases, e.g. when encrypting swap space or a {{ic|/tmp}} partition, it is not necessary to keep a persistent master key at all. A new throwaway key can be randomly generated for each session, without requiring any user interaction. This means that once unmounted, all files written to the partition in question can never be decrypted again by ''anyone'' - which in those particular use-cases is perfectly fine.<br />
<br />
===Cryptographic metadata===<br />
<br />
Frequently the encryption techniques use cryptographic functions to enhance the security of the master key itself. On mount of the encrypted device the passphrase or keyfile is passed through these and only the result can unlock the master key to decrypt the data. <br />
<br />
A common setup is to apply so-called "key stretching" to the passphrase (via a "key derivation function"), and use the resulting enhanced passphrase as the mount key for decrypting the actual master key (which has been previously stored in encrypted form):<br />
<br />
{{Text art|<nowiki><br />
╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮ ╭┈┈┈┈┈┈┈┈┈┈┈╮<br />
┊ mount passphrase ┊━━━━━⎛key derivation⎞━━━▶┊ mount key ┊<br />
╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,───⎝ function ⎠ ╰┈┈┈┈┈┬┈┈┈┈┈╯<br />
╭──────╮ ╱ │<br />
│ salt │───────────´ │<br />
╰──────╯ │<br />
╭─────────────────────╮ ▼ ╭┈┈┈┈┈┈┈┈┈┈┈┈╮<br />
│ encrypted master key│━━━━━━━━━━━━━━━━━━━━━━(decryption)━━━▶┊ master key ┊<br />
╰─────────────────────╯ ╰┈┈┈┈┈┈┈┈┈┈┈┈╯<br />
</nowiki>}}<br />
<br />
The '''key derivation function''' (e.g. PBKDF2 or scrypt) is deliberately slow (it applies many iterations of a hash function, e.g. 1000 iterations of HMAC-SHA-512), so that brute-force attacks to find the passphrase are rendered infeasible. For the normal use-case of an authorized user, it will only need to be calculated once per session, so the small slowdown is not a problem.<br />
It also takes an additional blob of data, the so-called "'''salt'''", as an argument - this is randomly generated once during set-up of the disk encryption and stored unprotected as part of the cryptographic metadata. Because it will be a different value for each setup, this makes it infeasible for attackers to speed up brute-force attacks using precomputed tables for the key derivation function.<br />
<br />
The '''encrypted master key''' can be stored on disk together with the encrypted data. This way, the confidentiality of the encrypted data depends completely on the secret passphrase. <br />
<br />
Additional security can be attained by instead storing the encrypted master key in a keyfile on e.g. a USB stick. This provides '''two-factor authentication''': Accessing the encrypted data now requires something only you ''know'' (the passphrase), and additionally something only you ''have'' (the keyfile).<br />
<br />
Another way of achieving two-factor authentication is to augment the above key retrieval scheme to mathematically "combine" the passphrase with byte data read from one or more external files (located on a USB stick or similar), before passing it to the key derivation function.The files in question can be anything, e.g. normal JPEG images, which can be beneficial for [[#Plausible deniability]]. They are still called "keyfiles" in this context, though.<br />
<br />
After it has been derived, the master key is securely stored in memory (e.g. in a kernel keyring), for as long as the encrypted block device or folder is mounted.<br />
<br />
It is usually not used for de/encrypting the disk data directly, though.<br />
For example, in the case of stacked filesystem encryption, each file can be automatically assigned its own encryption key. Whenever the file is to be read/modified, this file key first needs to be decrypted using the main key, before it can itself be used to de/encrypt the file contents:<br />
<br />
{{Text art|<nowiki><br />
╭┈┈┈┈┈┈┈┈┈┈┈┈╮<br />
┊ master key ┊<br />
file on disk: ╰┈┈┈┈┈┬┈┈┈┈┈┈╯<br />
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │<br />
╎╭───────────────────╮╎ ▼ ╭┈┈┈┈┈┈┈┈┈┈╮<br />
╎│ encrypted file key│━━━━(decryption)━━━▶┊ file key ┊<br />
╎╰───────────────────╯╎ ╰┈┈┈┈┬┈┈┈┈┈╯<br />
╎┌───────────────────┐╎ ▼ ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐<br />
╎│ encrypted file │◀━━━━━━━━━━━━━━━━━(de/encryption)━━━▶┊ readable file ┊<br />
╎│ contents │╎ ┊ contents ┊<br />
╎└───────────────────┘╎ └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘<br />
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘<br />
</nowiki>}}<br />
<br />
In a similar manner, a separate key (e.g. one per folder) may be used for the encryption of file names in the case of stacked filesystem encryption.<br />
<br />
In the case of block device encryption one master key is used per device and, hence, all data. Some methods offer features to assign multiple passphrases/keyfiles for the same device and others not. Some use above mentioned functions to secure the master key and others give the control over the key security fully to the user. Two examples are explained by the cryptographic parameters used by [[dm-crypt]] in plain or LUKS modes. <br />
<br />
When comparing the parameters used by both modes one notes that dm-crypt plain mode has parameters relating to how to locate the keyfile (e.g. {{ic|--keyfile-size}}, {{ic|--keyfile-offset}}). The dm-crypt LUKS mode does not need these, because each blockdevice contains a header with the cryptographic metadata at the beginning. The header includes the used cipher, the encrypted master-key itself and parameters required for its derivation for decryption. The latter parameters in turn result from options used during initial encryption of the master-key (e.g. {{ic|--iter-time}}, {{ic|--use-random}}). <br />
<br />
For the dis-/advantages of the different techniques, please refer back to [[#Comparison table]] or browse the specific pages. <br />
<br />
See also:<br />
* [[Wikipedia:Passphrase]]<br />
* [[Wikipedia:Key (cryptography)]]<br />
* [[Wikipedia:Key management]]<br />
* [[Wikipedia:Key derivation function]]<br />
<br />
===Ciphers and modes of operation===<br />
<br />
The actual algorithm used for translating between pieces of unencrypted and encrypted data (so-called "plaintext" and "ciphertext") which correspond to each other with respect to a given encryption key, is called a "'''cipher'''".<br />
<br />
Disk encryption employs "block ciphers", which operate on fixed-length blocks of data, e.g. 16 bytes (128 bits). At the time of this writing, the predominantly used ones are:<br />
{| class="wikitable" style="margin:0 5em 1.5em 5em;"<br />
! scope="col" style="text-align:left" | <br />
! scope="col" style="text-align:left" | block&nbsp;size<br />
! scope="col" style="text-align:left" | key&nbsp;size<br />
! scope="col" style="text-align:left" | comment<br />
|-<br />
! scope="row" style="text-align:right" | [[Wikipedia:Advanced_Encryption_Standard|AES]]<br />
| 128 bits<br />
| 128, 192 or 256 bits<br />
| approved by the NSA for protecting "SECRET" and "TOP SECRET" classified US-government information (when used with a key size of 192 or 256 bits)<br />
|-<br />
! scope="row" style="text-align:right" | [[wikipedia:Blowfish (cipher)|Blowfish]]<br />
| 64 bits<br />
| 32–448 bits<br />
| one of the first patent-free secure ciphers that became publicly available, hence very well established on Linux<br />
|-<br />
! scope="row" style="text-align:right" | [[Wikipedia:Twofish|Twofish]]<br />
| 128 bits<br />
| 128, 192 or 256 bits<br />
| developed as successor of Blowfish, but has not attained as much widespread usage<br />
|-<br />
! scope="row" style="text-align:right" | [[wikipedia:Serpent (cipher)|Serpent]]<br />
| 128 bits<br />
| 128, 192 or 256 bits<br />
| Considered the most secure of the five AES-competition finalists[http://csrc.nist.gov/archive/aes/round2/r2report.pdf][https://www.cl.cam.ac.uk/~rja14/Papers/serpentcase.pdf][https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf].<br />
|}<br />
<br />
Encrypting/decrypting a sector ([[#Basic principle|see above]]) is achieved by dividing it into small blocks matching the cipher's block-size, and following a certain rule-set (a so-called "'''mode of operation'''") for how to consecutively apply the cipher to the individual blocks.<br />
<br />
Simply applying it to each block separately without modification (dubbed the "''electronic codebook (ECB)''" mode) would not be secure, because if the same 16 bytes of plaintext always produce the same 16 bytes of ciphertext, an attacker could easily recognize patterns in the ciphertext that is stored on disk.<br />
<br />
The most basic (and common) mode of operation used in practice is "''cipher-block chaining (CBC)''". When encrypting a sector with this mode, each block of plaintext data is combined in a mathematical way with the ciphertext of the previous block, before encrypting it using the cipher. For the first block, since it has no previous ciphertext to use, a special pre-generated data block stored with the sector's cryptographic metadata and called an "'''initialization vector (IV)'''" is used:<br />
<br />
{{Text art|<nowiki><br />
╭──────────────╮<br />
│initialization│<br />
│vector │<br />
╰────────┬─────╯<br />
╭ ╠══════════╣ ╭─key │ ┣┉┉┉┉┉┉┉┉┉┉┫ <br />
│ ║ ║ ▼ ▼ ┋ ┋ . START<br />
┴ ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"Hello, W"┋ block ╱╰────┐<br />
sector n ║ ║ ┋ ┋ 1 ╲╭────┘<br />
of file or ║ ║──────────────────╮ ┋ ┋ ' <br />
blockdevice ╟──────────╢ ╭─key │ ┠┈┈┈┈┈┈┈┈┈┈┨<br />
┬ ║ ║ ▼ ▼ ┋ ┋<br />
│ ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"orld !!!"┋ block<br />
│ ║ ║ ┋ ┋ 2<br />
│ ║ ║──────────────────╮ ┋ ┋<br />
│ ╟──────────╢ │ ┠┈┈┈┈┈┈┈┈┈┈┨<br />
│ ║ ║ ▼ ┋ ┋<br />
: : ... : ... ... : ... : ...<br />
<br />
ciphertext plaintext<br />
on disk in RAM<br />
</nowiki>}}<br />
<br />
When decrypting, the procedure is reversed analogously.<br />
<br />
One thing worth noting is the generation of the unique initialization vector for each sector. The simplest choice is to calculate it in a predictable fashion from a readily available value such as the sector number. However, this might allow an attacker with repeated access to the system to perform a so-called [[wikipedia:Watermarking_attack|watermarking attack]]. To prevent that, a method called "Encrypted salt-sector initialization vector ('''ESSIV''')" can be used to generate the initialization vectors in a way that makes them look completely random to a potential attacker.<br />
<br />
There are also a number of other, more complicated modes of operation available for disk encryption, which already provide built-in security against such attacks (and hence do not require ESSIV).<br />
Some can also additionally guarantee authenticity of the encrypted data (i.e. confirm that it has not been modified/corrupted by someone who does not have access to the key).<br />
<br />
See also:<br />
* [[Wikipedia:Disk encryption theory]]<br />
* [[Wikipedia:Block cipher]]<br />
* [[Wikipedia:Block cipher modes of operation]]<br />
<br />
===Plausible deniability===<br />
<br />
See [[Wikipedia:Plausible deniability]].</div>Ivankhttps://wiki.archlinux.org/index.php?title=Gocryptfs&diff=574515Gocryptfs2019-06-04T08:09:01Z<p>Ivank: Category:Disk encryption matching encfs/ecryptfs</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Disk encryption]]<br />
[[Category:FUSE]]<br />
[[ja:Gocryptfs]]<br />
{{Related articles start}}<br />
{{Related|Disk encryption}}<br />
{{Related|Encfs}}<br />
{{Related articles end}}<br />
From [https://nuetzlich.net/gocryptfs/ gocryptfs]:<br />
<br />
:gocryptfs uses file-based encryption that is implemented as a mountable FUSE filesystem. Each file in gocryptfs is stored one corresponding encrypted file on the hard disk. <br />
:The highlights are: Scrypt password hashing, GCM encryption for all file contents, EME wide-block encryption for file names with a per-directory IV.<br />
<br />
See the [https://nuetzlich.net/gocryptfs/ gocryptfs] project home for further introduction of its features, benchmarks, etc. See [[Disk encryption#Comparison table]] for an overview of alternative methods and [[EncFS]] for the direct alternative.<br />
<br />
== Installation == <br />
<br />
[[Install]] {{Pkg|gocryptfs}} or {{Aur|gocryptfs-git}}. <br />
<br />
As a FUSE filesystem, gocryptfs is fully configurable by the user and stores its configuration files in the user's directory paths.<br />
<br />
== Usage ==<br />
<br />
See {{man|1|gocryptfs}} and its examples first.<br />
<br />
{{Warning|<br />
* To achieve its design goal of [[w:Authenticated encryption|authenticated encryption]], gocryptfs implements a AES-EME encryption mode (for filenames, not the content). While this mode is not widely used/audited yet, it offers integrity protection for the data, a feature not available for direct alternative encryption methods.<br />
* See the project's tracking [https://github.com/rfjakob/gocryptfs/issues/90 bug report] regarding findings of the first security audit for more information.}}<br />
<br />
{{Tip|Execute {{ic|gocryptfs -speed}} to test throughput for available encryption methods. Note the slowest {{ic|AES-SIV-512-Go}} mode is required (and automatically selected) for reverse mode.}}<br />
<br />
=== Example using reverse mode ===<br />
<br />
A major application for file-based encryption methods are encrypted backups. FUSE-based filesystems are flexible for this, since they allow a wide array of backup destinations using standard tools. For example, a gocryptfs-encrypted FUSE mount point can be easily created directly on a [[Samba]]/[[NFS]] share or [[Dropbox]] location, synchronized to a remote host with [[rsync]], or just be manually copied to a remote backup storage.<br />
<br />
The [https://nuetzlich.net/gocryptfs/reverse_mode/ reverse mode] of gocryptfs is particularly useful for creating encrypted backups, since it requires virtually no extra storage capacity on the machine to back up.<br />
<br />
The following shows an example of user ''archie'' creating a backup of {{ic|/home/archie}}:<br />
<br />
First, ''archie'' initializes the configuration for the home directory:<br />
{{hc|$ gocryptfs -init -reverse /home/archie|<br />
Choose a password for protecting your files.<br />
Password:<br />
...}}<br />
<br />
Second, an empty directory for the encrypted view of the home directory is created and mounted:<br />
<br />
{{bc|$ mkdir /tmp/''crypt''<br />
$ gocryptfs -reverse /home/''archie'' /tmp/''crypt''<br />
Password:<br />
Decrypting master key<br />
<br />
Your master key is:<br />
...<br />
Filesystem mounted and ready.<br />
$}}<br />
<br />
{{Tip|The {{ic|-exclude ''folder''}} option is available during the mount. Note that with software like ''rsync'' errors or warnings may occur if exclusions are done later only.[https://github.com/rfjakob/gocryptfs/issues/235#issuecomment-410506242]}}<br />
<br />
Third, ''archie'' creates a backup of the encrypted directory, a simple local copy for this example:<br />
<br />
$ cp -a /tmp/''crypt'' /tmp/''backup''<br />
<br />
and done. <br />
<br />
The encrypted directory can stay mounted for the user session, or be unmounted manually: <br />
$ fusermount -u /tmp/''crypt''<br />
$ rmdir /tmp/''crypt''<br />
<br />
To restore from the encrypted backup, a plain-text view is mounted using gocryptfs's normal mode: <br />
{{bc|$ mkdir /tmp/''restore''<br />
$ gocryptfs /tmp/''backup''/ /tmp/''restore''<br />
Password: <br />
Decrypting master key<br />
...<br />
Filesystem mounted and ready.<br />
$}}<br />
<br />
Now the required files can be restored.<br />
<br />
== See also == <br />
* [https://defuse.ca/audits/gocryptfs.htm A first security audit] of gocryptfs<br />
* [https://tools.ietf.org/html/rfc5297 RFC5297] Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)</div>Ivankhttps://wiki.archlinux.org/index.php?title=HiDPI&diff=571911HiDPI2019-04-23T22:01:34Z<p>Ivank: /* GNOME */ xsettings overrides also needs to be set if doing it manually (https://wiki.gnome.org/HowDoI/HiDpi)</p>
<hr />
<div>[[Category:Graphics]]<br />
[[ja:HiDPI]]<br />
[[zh-hans:HiDPI]]<br />
{{Related articles start}}<br />
{{Related|Font configuration}}<br />
{{Related articles end}}<br />
HiDPI (High Dots Per Inch) displays, also known by Apple's "[[wikipedia:Retina Display|Retina Display]]" marketing name, are screens with a high resolution in a relatively small format. They are mostly found in high-end laptops and monitors.<br />
<br />
Not all software behaves well in high-resolution mode yet. Here are listed most common tweaks which make work on a HiDPI screen more pleasant.<br />
<br />
== Desktop environments ==<br />
<br />
=== GNOME ===<br />
To enable HiDPI, ''Settings > Devices > Displays'',or use gsettings:<br />
<br />
$ gsettings set org.gnome.settings-daemon.plugins.xsettings overrides "[{'Gdk/WindowScalingFactor', <2>}]"<br />
$ gsettings set org.gnome.desktop.interface scaling-factor 2<br />
<br />
{{Note|1=GNOME only allows integer scaling numbers to be set. 1 = 100%, 2 = 200%, etc.}}<br />
<br />
==== Fractional Scaling ====<br />
<br />
A setting of {{ic|2, 3, etc}}, which is all you can do with {{ic|scaling-factor}}, may not be ideal for certain HiDPI displays and smaller screens (e.g. small tablets). <br />
<br />
* Wayland<br />
<br />
Enable fractional Scaling experimental-feature:<br />
<br />
$ gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"<br />
<br />
then open ''Settings > Devices > Displays'' (the new options may only appear after a restart)<br />
<br />
* Xorg<br />
<br />
You can achieve any non-integer scale factor by using a combination of GNOME's {{ic|scaling-factor}} and [[xrandr]]. This combination keeps the TTF fonts properly scaled so that they do not become blurry if using {{ic|xrandr}} alone. You specify zoom-in factor with {{ic|gsettings}} and zoom-out factor with [[xrandr]].<br />
<br />
First scale GNOME up to the minimum size which is too big. Usually "2" is already too big, otherwise try "3" etc. Then start scaling down by setting zoom-out factor with [[xrandr]]. First get the relevant output name, the examples below use {{ic|eDP1}}. Start e.g. with zoom-out 1.25 times. If the UI is still too big, increase the scale factor; if it is too small decrease the scale factor.<br />
<br />
$ xrandr --output eDP1 --scale 1.25x1.25<br />
<br />
{{Note|To allow the mouse to reach the whole screen, you may need to use the {{ic|--panning}} option as explained in [[#Side display]].}}<br />
<br />
{{Accuracy|The following was initially added under [[#X Resources]]. Clarify how it integrates with the info there or that above for GNOME.|section=GNOME ignores X settings}}<br />
<br />
GNOME ignores X settings due to its xsettings Plugin in Gnome Settings Daemon, where DPI setting is hard coded.<br />
There is blog entry for [http://blog.drtebi.com/2012/12/changing-dpi-setting-on-gnome-34.html recompiling Gnome Settings Daemon].<br />
In the source documentation there is another way mentioned to set X settings DPI:<br />
<br />
You can use the dconf Editor and navigate to key <br />
<br />
/org/gnome/settings-daemon/plugins/xsettings/overrides<br />
<br />
and complement the entry with the value<br />
<br />
'Xft/DPI': <153600><br />
<br />
From README.xsettings<br />
<br />
Noting that variants must be specified in the usual way (wrapped in <>).<br />
<br />
Note also that DPI in the above example is expressed in 1024ths of an inch.<br />
<br />
==== Text Scaling ====<br />
<br />
Alternatively or additionally to above solution, you can scale only text by factor not limited by whole numbers, for example:<br />
<br />
$ gsettings set org.gnome.desktop.interface text-scaling-factor 1.5<br />
<br />
=== KDE ===<br />
<br />
You can use KDE's settings to fine tune font, icon, and widget scaling. This solution affects both Qt and Gtk+ applications.<br />
<br />
To adjust font, widget, and icon scaling together:<br />
<br />
# ''System Settings > Display and Monitor > Display Configuration > Scale Display''<br />
# Drag the slider to the desired size<br />
# Restart for the settings to take effect<br />
<br />
To adjust only font scaling:<br />
<br />
# ''System Settings > Fonts''<br />
# Check "Force fonts DPI" and adjust the DPI level to the desired value. This setting should take effect immediately for newly started applications. You will have to logout and login for it to take effect on Plasma desktop.<br />
<br />
To adjust only icon scaling:<br />
<br />
# ''System Settings > Icons > Advanced''<br />
# Choose the desired icon size for each category listed. This should take effect immediately.<br />
<br />
'''Display Scale not integer bug :'''<br />
<br />
When you use not integer values for Display Scale it causes font render issue in some QT application ( ex. Okular ).<br />
<br />
A workaround for this is to:<br />
<br />
# Set the scale value to {{ic|1}}<br />
# Adjust your font and icons and use the "Force fonts DPI" ( this affects all apps, also GTK but not create issue with the fonts )<br />
# Restart KDE<br />
# If required tune the GTK apps using the variables {{ic|GDK_SCALE}}/{{ic|GDK_DPI_SCALE}} (as described above)<br />
<br />
==== Tray icons with fixed size ====<br />
<br />
The tray icons are not scaled with the rest of the desktop, since Plasma ignores the Qt scaling settings by default. To make Plasma respect the Qt settings, set {{ic|PLASMA_USE_QT_SCALING}} to {{ic|1}}.<br />
<br />
=== Xfce ===<br />
<br />
Xfce uses the DPI given by the X server. There is an option to override Font DPI (''Settings Manager > Appearance > Fonts > DPI > Custom DPI setting'') but it's better to adjust X server DPI instead. See [[Xorg#Display size and DPI]] for how to fix it.<br />
<br />
To enlarge icons in system tray, ''right-click on it (aim for empty space / top pixels / bottom pixels, so that you will not activate icons themselves) > Properties'', set “Maximum icon size” to 32, 48 or 64.<br />
<br />
Xfwm comes with two hidpi themes: Default-hdpi and Default-xhdpi. You can set them under ''Settings Manager > Window Manager > Style > Theme''.<br />
<br />
You can set the default icon sizes of gtk2 menus, buttons and so on under ''Settings Manager > Settings Editor > xsettings > Gtk > IconSizes'', with a line like this: {{ic|1=gtk-large-toolbar=96,96:gtk-small-toolbar=64,64:gtk-menu=64,64:gtk-dialog=96,96:gtk-button=64,64:gtk-dnd=64,64}}. "gtk-dnd" is for the icons during drag'n'drop, the others are quite self-explanatory. You can use any value your icon theme supports.<br />
<br />
=== Cinnamon ===<br />
<br />
Has good support out of the box.<br />
<br />
=== Enlightenment ===<br />
<br />
For E18, go to the E Setting panel. In ''Look > Scaling'', you can control the UI scaling ratios. A ratio of 1.2 seems to work well for the native resolution of the MBPr 15" screen.<br />
<br />
== X Server ==<br />
<br />
Some programs use the DPI given by the X server. Examples are i3 ([https://github.com/i3/i3/blob/next/libi3/dpi.c source]) and Chromium ([https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/widget/desktop_aura/desktop_screen_x11.cc source]).<br />
<br />
To verify that the X Server has properly detected the physical dimensions of your monitor, use the ''xdpyinfo'' utility from the {{Pkg|xorg-xdpyinfo}} package:<br />
<br />
{{hc|$ xdpyinfo {{!}} grep -B 2 resolution|<br />
screen #0:<br />
dimensions: 3200x1800 pixels (423x238 millimeters)<br />
resolution: 192x192 dots per inch<br />
}}<br />
<br />
This example uses inaccurate dimensions (423mm x 328mm, even though the Dell XPS 9530 has 346mm x 194mm) to have a clean multiple of 96 dpi, in this case 192 dpi. This tends to work better than using the correct DPI — Pango renders fonts crisper in i3 for example.<br />
<br />
If the DPI displayed by xdpyinfo is not correct, see [[Xorg#Display size and DPI]] for how to fix it.<br />
<br />
== X Resources ==<br />
<br />
If you are not using a desktop environment such as KDE, Xfce, or other that manipulates the X settings for you, you can set the desired DPI setting manually via the {{ic|Xft.dpi}} variable in [[Xresources]]:<br />
<br />
{{hc|~/.Xresources|2=<br />
Xft.dpi: 180<br />
Xft.autohint: 0<br />
Xft.lcdfilter: lcddefault<br />
Xft.hintstyle: hintfull<br />
Xft.hinting: 1<br />
Xft.antialias: 1<br />
Xft.rgba: rgb<br />
}}<br />
<br />
Make sure the settings are loaded properly when X starts, for instance in your {{ic|~/.xinitrc}} with {{ic|xrdb -merge ~/.Xresources}} (see [[Xresources]] for more information).<br />
<br />
This will make the font render properly in most toolkits and applications, it will however not affect things such as icon size!<br />
Setting {{ic|Xft.dpi}} at the same time as toolkit scale (e.g. {{ic|GDK_SCALE}}) may cause interface elements to be much larger than intended in some programs like firefox.<br />
<br />
== GUI toolkits ==<br />
<br />
=== Qt 5 ===<br />
<br />
Since Qt 5.6, Qt 5 applications can be instructed to honor screen DPI by setting the {{ic|QT_AUTO_SCREEN_SCALE_FACTOR}} environment variable:<br />
<br />
export QT_AUTO_SCREEN_SCALE_FACTOR=1<br />
<br />
If automatic detection of DPI does not produce the desired effect, scaling can be set manually per-screen ({{ic|QT_SCREEN_SCALE_FACTORS}}) or globally ({{ic|QT_SCALE_FACTOR}}). For more details see the [https://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/ Qt blog post].<br />
<br />
{{Note|<br />
* If you manually set the screen factor, it is important to set {{ic|1=QT_AUTO_SCREEN_SCALE_FACTOR=0}} otherwise some applications which explicitly force high DPI enabling get scaled twice.<br />
* {{ic|QT_SCALE_FACTOR}} scales fonts, but {{ic|QT_SCREEN_SCALE_FACTORS}} does not scale fonts.<br />
* If you also set the font DPI manually in ''xrdb'' to support other toolkits, {{ic|QT_SCALE_FACTORS}} will give you huge fonts.<br />
* If you have multiple screens of differing DPI ie: [[#Side display]] you may need to do {{ic|1=QT_SCREEN_SCALE_FACTORS="2;2"}}<br />
}}<br />
<br />
An [https://bugreports.qt.io/browse/QTBUG-53022 alternative] is e.g.:<br />
<br />
QT_FONT_DPI=96 vym<br />
<br />
=== GDK 3 (GTK+ 3) ===<br />
<br />
If you are using a window manager other than Gnome and have scaled the fonts using Xft.dpi, you must tell GDK to scale the UI as well. This will result in a further increase of the font-size for GDK apps, so you must undo the scaling of the text only.<br />
<br />
To scale UI elements by a factor of two:<br />
<br />
export GDK_SCALE=2<br />
<br />
To undo scaling of text:<br />
<br />
export GDK_DPI_SCALE=0.5<br />
<br />
=== GTK+ 2 ===<br />
<br />
Scaling of UI elements is not supported by the toolkit itself, however it's possible to generate a theme with elements pre-scaled for HiDPI display using {{AUR|oomox-git}}.<br />
<br />
=== Elementary (EFL) ===<br />
<br />
To scale UI elements by a factor of 1.5:<br />
<br />
export ELM_SCALE=1.5<br />
<br />
For more details see https://phab.enlightenment.org/w/elementary/<br />
<br />
== Boot managers ==<br />
<br />
=== GRUB ===<br />
<br />
==== Lower the framebuffer resolution ====<br />
<br />
Set a lower resolution for the framebuffer as explained in [[GRUB/Tips and tricks#Setting the framebuffer resolution]].<br />
<br />
==== Change GRUB font size ====<br />
<br />
Find a ttf font that you like in {{ic|/usr/share/fonts/}}.<br />
<br />
Convert the font to a format that GRUB can utilize:<br />
<br />
# grub-mkfont -s 30 -o /boot/grubfont.pf2 /usr/share/fonts/FontFamily/FontName.ttf<br />
<br />
{{Note|Change the {{ic|-s 30}} parameter to modify the font size}}<br />
<br />
Edit {{ic|/etc/default/grub}} to set the new font as shown in [[GRUB/Tips and tricks#Background image and bitmap fonts]]:<br />
<br />
GRUB_FONT="/boot/grubfont.pf2"<br />
<br />
Update GRUB configuration by running {{ic|grub-mkconfig -o /boot/grub/grub.cfg}}<br />
<br />
== Applications ==<br />
<br />
{{Accuracy|{{ic|--force-device-scale-factor}} only works on Chromium based (including Electron) applications.}}<br />
<br />
As a general rule, applications can be launched with a custom scaling value, e.g. {{ic|1=$ atom --force-device-scale-factor=2}}. A more permanent solution is to add this scaling factor as a flag to the relevant .conf or .desktop file (normally located at {{ic|/usr/share/applications/}}). In the latter instance, the flag should be added to the line beginning with "Exec=", e.g. {{ic|1=Exec=/usr/bin/atom --force-device-scale-factor=2 %F}}. The next section provides more details on implementing this for specific applications.<br />
<br />
=== Atom ===<br />
<br />
Add {{ic|1=--force-device-scale-factor=2}} as a flag to the atom.desktop file:<br />
<br />
{{hc|/usr/share/applications/atom.desktop|2=<br />
Exec=/usr/bin/atom --force-device-scale-factor=2 %F<br />
}}<br />
<br />
=== Browsers ===<br />
<br />
==== Firefox ====<br />
<br />
Firefox should use the [[#GDK 3 (GTK+ 3)]] settings. However, the suggested {{ic|GDK_SCALE}} suggestion does not consistently scale the entirety of Firefox, and does not work for fractional values (e.g., a factor of 158DPI/96DPI = 1.65 for a 1080p 14" laptop). You may want to use {{ic|GDK_DPI_SCALE}} instead. Another option, which will avoid Firefox-specific settings in many setups is to use the settings in [[#X Resources]] as Firefox should respect the {{ic|Xft.dpi}} value defined there.<br />
<br />
To override those, open Firefox advanced preferences page ({{ic|about:config}}) and set parameter {{ic|layout.css.devPixelsPerPx}} to {{ic|2}} (or find the one that suits you better; {{ic|2}} is a good choice for Retina screens), but it also does not consistently scale the entirety of Firefox. If Firefox is not scaling fonts, you may want to create {{ic|userChrome.css}} and add appropriate styles to it. More information about {{ic|userChrome.css}} at [http://kb.mozillazine.org/index.php?title=UserChrome.css mozillaZine].<br />
<br />
{{hc|~/.mozilla/firefox/<em><profile></em>/chrome/userChrome.css|<br />
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");<br />
<br />
/* #tabbrowser-tabs, #navigator-toolbox, menuitem, menu, ... */<br />
* {<br />
font-size: 15px !important;<br />
}<br />
<br />
/* exception for badge on adblocker */<br />
.toolbarbutton-badge {<br />
font-size: 8px !important;<br />
}<br />
}}<br />
<br />
{{Warning|The following extension is not compatible with Firefox Quantum (version 57 and above).}}<br />
<br />
If you use a HiDPI monitor such as Retina display together with another monitor, you can use [https://addons.mozilla.org/en-US/firefox/addon/autohidpi/ AutoHiDPI] add-on in order to automatically adjust {{ic|layout.css.devPixelsPerPx}} setting for the active screen. Also, since Firefox version 49, it auto-scales based on your screen resolution, making it easier to deal with 2 or more screens.<br />
<br />
If you use Wayland, you can also use the Wayland-enabled packages of Firefox from the AUR: {{AUR|firefox-wayland}} (compiles from source) or {{AUR|fedora-firefox-wayland-bin}} (binary from Fedora). You might experience some minor visual glitches with these packages.<br />
<br />
==== Chromium / Google Chrome ====<br />
<br />
Chromium should use the [[#GDK 3 (GTK+ 3)]] settings.<br />
<br />
To override those, use the {{ic|1=--force-device-scale-factor}} flag with a scaling value. This will scale all content and ui, including tab and font size. For example {{ic|1=chromium --force-device-scale-factor=2}}.<br />
<br />
Using this option, a scaling factor of 1 would be normal scaling. Floating point values can be used. To make the change permanent, for Chromium, you can add it to {{ic|~/.config/chromium-flags.conf}}:<br />
<br />
{{hc|~/.config/chromium-flags.conf|2=<br />
--force-device-scale-factor=2<br />
}}<br />
<br />
To make this work for Chrome, add the same option to {{ic|~/.config/chrome-flags.conf}} instead.<br />
<br />
If you use a HiDPI monitor such as Retina display together with another monitor, you can use the [https://chrome.google.com/webstore/detail/resolution-zoom/enjjhajnmggdgofagbokhmifgnaophmh reszoom] extension in order to automatically adjust the zoom level for the active screen.<br />
<br />
==== Opera ====<br />
<br />
Opera should use the [[#GDK 3 (GTK+ 3)]] settings.<br />
<br />
To override those, use the {{ic|1=--alt-high-dpi-setting=X}} command line option, where X is the desired DPI. For example, with {{ic|1=--alt-high-dpi-setting=144}} Opera will assume that DPI is 144. Newer versions of opera will auto detect the DPI using the font DPI setting (in KDE: the force font DPI setting.)<br />
<br />
=== Gimp 2.8 ===<br />
<br />
Use a high DPI theme, or adjust {{ic|1=gtkrc}} of an existing theme. (Change all occurrences of the size {{ic|1=button}} to {{ic|1=dialog}}, for example {{ic|1=GimpToolPalette::tool-icon-size}}.)<br />
<br />
There is also the [https://github.com/jedireza/gimp-hidpi gimp-hidpi].<br />
<br />
=== IntelliJ IDEA ===<br />
<br />
IntelliJ IDEA 15 and above should include HiDPI support.[http://blog.jetbrains.com/idea/2015/07/intellij-idea-15-eap-comes-with-true-hidpi-support-for-windows-and-linux/] If it does not work, the most convenient way to fix the problem in this case seems to be changing the Override Default Fonts setting:<br />
<br />
:''File > Settings > Behaviour & Appearance > Appearance''<br />
<br />
The addition of {{ic|1=-Dhidpi=true}} to the vmoptions file in either {{ic|$HOME/.IdeaC14/}} or {{ic|/usr/share/intelligj-idea-ultimate-edition/bin/}} of [https://youtrack.jetbrains.com/issue/IDEA-114944 release 14] should not be required anymore.<br />
<br />
=== Java applications ===<br />
<br />
Java applications using the AWT/Swing framework can be scaled by defining the sun.java2d.uiScale variable when invoking java. For example,<br />
<br />
java -Dsun.java2d.uiScale=2 -jar some_application.jar<br />
<br />
Since Java 9 the GDK_SCALE environment variable is used to scale Swing applications accordingly.<br />
<br />
=== MATLAB ===<br />
<br />
Recent versions (R2017b) of [[MATLAB]] allow to set the scale factor[https://www.mathworks.com/matlabcentral/answers/406956-does-matlab-support-high-dpi-screens-on-linux]:<br />
<br />
>> s = settings;s.matlab.desktop.DisplayScaleFactor<br />
>> s.matlab.desktop.DisplayScaleFactor.PersonalValue = 2<br />
<br />
The settings take effect after MATLAB is restarted.<br />
<br />
=== Mono applications ===<br />
<br />
According to [https://bugzilla.xamarin.com/show_bug.cgi?id=35870], Mono applications should be scalable like [[#GDK 3 (GTK+ 3)|GTK3]] applications.<br />
<br />
=== NetBeans ===<br />
<br />
NetBeans allows the font size of its interface to be controlled using the {{ic|1=--fontsize}} parameter during startup. To make this change permanent edit the {{ic|1=/usr/share/netbeans/etc/netbeans.conf}} file and append the {{ic|1=--fontsize}} parameter to the {{ic|1=netbeans_default_options}} property.[http://wiki.netbeans.org/FaqFontSize]<br />
<br />
The editor fontsize can be controlled from ''Tools > Option > Fonts & Colors''.<br />
<br />
The output window fontsize can be controlled from ''Tools > Options > Miscelaneous > Output''<br />
<br />
=== Skype ===<br />
<br />
Skype for Linux ({{AUR|skypeforlinux-stable-bin}} package) uses [[#GDK 3 (GTK+ 3)]].<br />
<br />
=== Slack ===<br />
<br />
Slack ({{AUR|slack-desktop}}), like all [https://electronjs.org/ Electron] apps, can be configured to use a custom scaling value by adding a {{ic|1=--force-device-scale-factor}} flag to the .desktop file. This is normally located at {{ic|/usr/share/applications/}}. The flag should be added to the line beginning with "Exec=". For example:<br />
<br />
{{hc|/usr/share/applications/slack.desktop|2=<br />
Exec=env LD_PRELOAD=/usr/lib/libcurl.so.3 /usr/bin/slack --force-device-scale-factor=1.5 %U<br />
}}<br />
<br />
=== Spotify ===<br />
<br />
You can change scale factor by simple {{ic|Ctrl++}} for zoom in, {{ic|Ctrl+-}} for zoom out and {{ic|Ctrl+0}} for default scale. Scaling setting will be saved in {{ic|~/.config/spotify/Users/YOUR-SPOTIFY-USER-NAME/prefs}}:<br />
<br />
{{hc|~/.config/spotify/Users/YOUR-SPOTIFY-USER-NAME/prefs|2=<br />
app.browser.zoom-level=100<br />
}}<br />
<br />
Also Spotify can be launched with a custom scaling factor which will be multiplied with setting specified in {{ic|~/.config/spotify/Users/YOUR-SPOTIFY-USER-NAME/prefs}}, for example<br />
<br />
$ spotify --force-device-scale-factor=1.5<br />
<br />
=== Steam ===<br />
<br />
==== Official HiDPI support ====<br />
<br />
* Starting on 25 of January 2018 in the beta program there is actual support for HiDPI and it should be automatically detected.<br />
* ''Steam > Settings > Interface'', check "Enlarge text and icons based on monitor size" (restart required)<br />
* If it not automatically detected use {{ic|1=GDK_SCALE=2}} to set the desired scale factor.<br />
<br />
==== Unofficial ====<br />
<br />
The [https://github.com/MoriTanosuke/HiDPI-Steam-Skin HiDPI-Steam-Skin] can be installed to increase the font size of the interface. While not perfect, it does improve usability. <br />
<br />
{{Note|The README for the HiDPI skin lists several possible locations for where to place the skin. The correct folder out of these can be identified by the presence of a file named {{ic|1=skins_readme.txt}}.}}<br />
<br />
[http://steamcommunity.com/groups/metroskin/discussions/0/517142253861033946/ MetroSkin Unofficial Patch] also helps with HiDPI on Steam with Linux.<br />
<br />
=== Sublime Text 3 ===<br />
<br />
Sublime Text 3 has full support for display scaling. Go to ''Preferences > Settings > User Settings'' and add {{ic|"ui_scale": 2.0}} to your settings.<br />
<br />
=== Thunderbird ===<br />
<br />
See [[#Firefox]]. To access {{ic|about:config}}, go to ''Edit > Preferences > Advanced >Config editor''.<br />
<br />
=== VirtualBox ===<br />
<br />
{{Note|This only applies to KDE with scaling enabled.}}<br />
<br />
VirtualBox also applies the system-wide scaling to the virtual monitor, which reduces the maximum resolution inside VMs by your scaling factor (see [https://www.virtualbox.org/ticket/16604]).<br />
<br />
This can be worked around by calculating the inverse of your scaling factor and manually setting this new scaling factor for the VirtualBox execution, e.g.<br />
<br />
$ QT_SCALE_FACTOR=0.5 VirtualBox --startvm vm-name<br />
<br />
=== Wine applications ===<br />
<br />
Run<br />
<br />
$ winecfg<br />
<br />
and change the "dpi" setting found in the "Graphics" tab. This only affects the font size.<br />
<br />
=== Zathura document viewer ===<br />
<br />
No modifications required for document viewing.<br />
<br />
UI text scaling is specified via [https://pwmt.org/projects/zathura/documentation/ configuration file] (note that "font" is a [https://pwmt.org/projects/girara/options/ girara option]):<br />
<br />
set font "monospace normal 20"<br />
<br />
=== Zoom ===<br />
<br />
Zoom can be started with a proper scaling by overriding the {{ic|1=QT_SCALE_FACTOR}} environment variable.<br />
<br />
$ QT_SCALE_FACTOR=2 zoom<br />
<br />
=== Unsupported applications ===<br />
<br />
{{AUR|run_scaled-git}} can be used to scale applications (which uses {{Pkg|xpra}} internally).<br />
<br />
Another approach is to run the application full screen and without decoration in its own VNC desktop. Then scale the viewer. With Vncdesk ({{AUR|vncdesk-git}} from the [[AUR]]) you can set up a desktop per application, then start server and client with a simple command such as {{ic|vncdesk 2}}.<br />
<br />
[[x11vnc]] has an experimental option {{ic|-appshare}}, which opens one viewer per application window. Perhaps something could be hacked up with that.<br />
<br />
== Multiple displays ==<br />
<br />
The HiDPI setting applies to the whole desktop, so non-HiDPI external displays show everything too large. However, note that setting different scaling factors for different monitors is already supported in [[Wayland]].<br />
<br />
=== Side display ===<br />
<br />
One workaround is to use [[xrandr]]'s scale option. To have a non-HiDPI monitor (on DP1) right of an internal HiDPI display (eDP1), one could run:<br />
<br />
$ xrandr --output eDP-1 --auto --output DP-1 --auto --scale 2x2 --right-of eDP-1<br />
<br />
When extending above the internal display, you may see part of the internal display on the external monitor. In that case, specify the position manually.<br />
<br />
You may adjust the "sharpness" parameter on your monitor settings to adjust the blur level introduced with scaling.<br />
<br />
{{Note|1=Above solution with {{ic|--scale 2x2}} does not work on some Nvidia cards. No solution is currently available. [https://bbs.archlinux.org/viewtopic.php?pid=1670840] A potential workaround exists with configuring {{ic|1=ForceFullCompositionPipeline=On}} on the {{ic|CurrentMetaMode}} via {{ic|nvidia-settings}}. For more info see [https://askubuntu.com/a/979551/763549].}}<br />
<br />
{{Note|If you are using the {{ic|modesetting}} driver you will get mouse flickering. This can be solved by scaling your non-scaled screen by 0.9999x0.9999.}}<br />
<br />
=== Multiple external monitors ===<br />
<br />
There might be some problems in scaling more than one external monitors which have lower dpi than the built-in HiDPI display. In that case, you may want to try downscaling the HiDPI display instead, with e.g.<br />
<br />
$ xrandr --output eDP1 --scale 0.5x0.5 --output DP2 --right-of eDP1 --output HDMI1 --right-of DP2<br />
<br />
In addition, when you downscale the HiDPI display, the font on the HiDPI display will be slightly blurry, but it's a different kind of bluriness compared with the one introduced by upscaling the external displays. You may compare and see which kind of bluriness is less problematic for you.<br />
<br />
=== Mirroring ===<br />
<br />
If all you want is to mirror ("unify") displays, this is easy as well:<br />
<br />
With AxB your native HiDPI resolution (for ex 3200x1800) and CxD your external screen resolution (e.g. 1920x1200)<br />
<br />
$ xrandr --output HDMI --scale [A/C]x[B/D]<br />
<br />
In this example which is QHD (3200/1920 = 1.66 and 1800/1200 = 1.5)<br />
<br />
$ xrandr --output HDMI --scale 1.66x1.5<br />
<br />
For UHD to 1080p (3840/1920=2 2160/1080=2)<br />
<br />
$ xrandr --output HDMI --scale 2x2<br />
<br />
You may adjust the "sharpness" parameter on your monitor settings to adjust the blur level introduced with scaling.<br />
<br />
=== Tools ===<br />
<br />
There are several tools which automate the commands described above.<br />
<br />
* [https://gist.github.com/wvengen/178642bbc8236c1bdb67 This script] extend a non-HiDPI external display above a HiDPI internal display.<br />
* [https://github.com/ashwinvis/xrandr-extend xrandr-extend].<br />
* {{AUR|xlayoutdisplay}} is a CLI front end for xrandr which detects and sets correct DPI: [https://github.com/alex-courtis/xlayoutdisplay README]<br />
<br />
== Linux console ==<br />
<br />
The default [[w:Linux console|Linux console]] font will be very small on hidpi displays, the largest font present in the {{Pkg|kbd}} package is {{ic|latarcyrheb-sun32}} and other packages like {{Pkg|terminus-font}} contain further alternatives, such as {{ic|ter-132n}}(normal) and {{ic|ter-132b}}(bold). See [[Linux console#Fonts]] for configuration details.<br />
<br />
After changing the font, it is often garbled and unreadable when changing to other virtual consoles ({{ic|tty2-6}}). To fix this you can [[Kernel_mode_setting#Forcing_modes_and_EDID|force specific mode]] for KMS, such as {{ic|1=video=2560x1600@60}} (substitute in the native resolution of your HiDPI display), and reboot.<br />
<br />
== See also ==<br />
<br />
* [http://www.phoronix.com/scan.php?page=article&item=linux_uhd4k_gpus Ultra HD 4K Linux Graphics Card Testing] (Nov 2013)<br />
* [http://www.eizo.com/library/basics/pixel_density_4k/ Understanding pixel density]<br />
* [http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ Mixed DPI and the X Window System]</div>Ivankhttps://wiki.archlinux.org/index.php?title=OpenSSH&diff=571152OpenSSH2019-04-14T14:49:40Z<p>Ivank: /* Speeding up SSH */ mention faster ciphers, some formatting and move cipher/compression settings to the top as most impactful</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[Category:Servers]]<br />
[[Category:OpenBSD]]<br />
[[de:SSH]]<br />
[[es:OpenSSH]]<br />
[[fa:SSH]]<br />
[[fr:ssh]]<br />
[[ja:Secure Shell]]<br />
[[ru:Secure Shell]]<br />
[[zh-hans:Secure Shell]]<br />
{{Related articles start}}<br />
{{Related|SSH keys}}<br />
{{Related|Pam abl}}<br />
{{Related|fail2ban}}<br />
{{Related|sshguard}}<br />
{{Related|Sshfs}}<br />
{{Related|Syslog-ng}}<br />
{{Related|SFTP chroot}}<br />
{{Related|SCP and SFTP}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:OpenSSH|OpenSSH]] (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the [[Secure Shell]] (SSH) protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openssh}} package.<br />
<br />
== Client usage ==<br />
<br />
To connect to a server, run:<br />
<br />
$ ssh -p ''port'' ''user''@''server-address''<br />
<br />
If the server only allows public-key authentication, follow [[SSH keys]].<br />
<br />
=== Configuration ===<br />
<br />
The client can be configured to store common options and hosts. All options can be declared globally or restricted to specific hosts. For example:<br />
<br />
{{hc|~/.ssh/config|# global options<br />
User ''user''<br />
<br />
# host-specific options<br />
Host ''myserver''<br />
HostName ''server-address''<br />
Port ''port''<br />
}}<br />
<br />
With such a configuration, the following commands are equivalent<br />
<br />
$ ssh -p ''port'' ''user''@''server-address''<br />
$ ssh ''myserver''<br />
<br />
See {{man|5|ssh_config}} for more information.<br />
<br />
Some options do not have command line switch equivalents, but you can specify config options on the command line with {{ic|-o}}. For example {{ic|1=-oKexAlgorithms=+diffie-hellman-group1-sha1}}.<br />
<br />
== Server usage ==<br />
<br />
=== Configuration ===<br />
<br />
The SSH daemon configuration file can be found and edited in {{ic|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
To allow access only for some users add this line:<br />
<br />
AllowUsers ''user1 user2''<br />
<br />
To allow access only for some groups:<br />
<br />
AllowGroups ''group1 group2''<br />
<br />
To add a nice welcome message (e.g. from the {{ic|/etc/issue}} file), configure the {{ic|Banner}} option:<br />
<br />
Banner /etc/issue<br />
<br />
Public and private host keys are automatically generated in {{ic|/etc/ssh}} by the ''sshd'' [[#Daemon management|service files]] on the first run after installation. Four key pairs are provided based on the algorithms [[SSH keys#Choosing the authentication key type|dsa, rsa, ecdsa and ed25519]]. To have sshd use a particular key, specify the following option:<br />
<br />
HostKey /etc/ssh/ssh_host_rsa_key<br />
<br />
If the server is to be exposed to the WAN, it is recommended to change the default port from 22 to a random higher one like this:<br />
Port 39901<br />
<br />
{{Tip|<br />
* To help select an alternative port that is not already assigned to a common service, review the [[Wikipedia:List of TCP and UDP port numbers|list of TCP and UDP port numbers]]. You can also find port information locally in {{ic|/etc/services}}. A port change from default port 22 will reduce the number of log entries caused by automated authentication attempts but will not eliminate them. See [[Port knocking]] for related information.<br />
* It is recommended to disable password logins entirely. This will greatly increase security, see [[#Force public key authentication]] for more information. See [[#Protection]] for more recommend security methods.<br />
* OpenSSH can listen to multiple ports simply by having multiple {{ic|Port ''port_number''}} lines in the config file.<br />
}}<br />
<br />
=== Daemon management ===<br />
<br />
{{Pkg|openssh}} comes with two kinds of [[systemd]] service files:<br />
<br />
# {{ic|sshd.service}}, which will keep the SSH daemon permanently active and fork for each incoming connection.[https://projects.archlinux.org/svntogit/packages.git/tree/trunk/sshd.service?h=packages/openssh#n16] It is especially suitable for systems with a large amount of SSH traffic.[https://projects.archlinux.org/svntogit/packages.git/tree/trunk/sshd.service?h=packages/openssh&id=4cadf5dff444e4b7265f8918652f4e6dff733812#n15] <br />
# {{ic|sshd.socket}} + {{ic|sshd@.service}}, which spawn on-demand instances of the SSH daemon per connection. Using it implies that ''systemd'' listens on the SSH socket and will only start the daemon process for an incoming connection. It is the recommended way to run {{ic|sshd}} in almost all cases.[https://projects.archlinux.org/svntogit/packages.git/tree/trunk/sshd.service?h=packages/openssh&id=4cadf5dff444e4b7265f8918652f4e6dff733812#n18][http://lists.freedesktop.org/archives/systemd-devel/2011-January/001107.html][http://0pointer.de/blog/projects/inetd.html]<br />
<br />
You can [[start]] and [[enable]] either {{ic|sshd.service}} '''or''' {{ic|sshd.socket}} to begin using the daemon.<br />
<br />
If using the socket service, you will need to [[edit]] the unit file if you want it to listen on a port other than the default 22:<br />
<br />
{{hc|# systemctl edit sshd.socket|<nowiki><br />
[Socket]<br />
ListenStream=<br />
ListenStream=12345<br />
</nowiki>}}<br />
<br />
{{Warning|Using {{ic|sshd.socket}} negates the {{ic|ListenAddress}} setting, so it will allow connections over any address. To achieve the effect of setting {{ic|ListenAddress}}, you must specify the port ''and'' IP for {{ic|ListenStream}} (e.g. {{ic|1=ListenStream=192.168.1.100:22}}). You must also add {{ic|1=FreeBind=true}} under {{ic|[Socket]}} or else setting the IP address will have the same drawback as setting {{ic|ListenAddress}}: the socket will fail to start if the network is not up in time.}}<br />
<br />
{{Tip|When using socket activation a transient instance of {{ic|sshd@.service}} will be started for each connection (with different instance names). Therefore, neither {{ic|sshd.socket}} nor the daemon's regular {{ic|sshd.service}} allow to monitor connection attempts in the log. The logs of socket-activated instances of SSH can be seen with {{ic|journalctl -u "sshd@*"}} or with {{ic|journalctl /usr/bin/sshd}}.}}<br />
<br />
{{Note|Even the {{ic|sshd.socket}} unit may fail (e.g. due to out-of-memory situation) and {{ic|1=Restart=always}} cannot be specified on socket units. [https://github.com/systemd/systemd/issues/11553]}}<br />
<br />
=== Protection ===<br />
<br />
Allowing remote log-on through SSH is good for administrative purposes, but can pose a threat to your server's security. Often the target of brute force attacks, SSH access needs to be limited properly to prevent third parties gaining access to your server.<br />
<br />
Several other good guides and tools are available on the topic, for example:<br />
<br />
* [[MozillaWiki:Security/Guidelines/OpenSSH|Article by Mozilla Infosec Team]]<br />
* [https://github.com/mozilla/ssh_scan Mozilla ssh_scan]<br />
* [https://stribika.github.io/2015/01/04/secure-secure-shell.html Secure sshd]<br />
<br />
==== Force public key authentication ====<br />
<br />
If a client cannot authenticate through a public key, by default the SSH server falls back to password authentication, thus allowing a malicious user to attempt to gain access by [[#Protecting against brute force attacks|brute-forcing]] the password. One of the most effective ways to protect against this attack is to disable password logins entirely, and force the use of [[SSH keys]]. This can be accomplished by disabling the following options in the daemon configuration file:<br />
<br />
{{hc|/etc/ssh/sshd_config|PasswordAuthentication no}}<br />
<br />
{{Warning|Before adding this to your configuration, make sure that all accounts which require SSH access have public-key authentication set up in the corresponding {{ic|authorized_keys}} files. See [[SSH keys#Copying the public key to the remote server]] for more information.}}<br />
<br />
==== Two-factor authentication and public keys ====<br />
<br />
SSH can be set up to require multiple ways of authentication, you can tell which authentication methods are required using the {{ic|AuthenticationMethods}} option. This enables you to use public keys as well as a two-factor authorization.<br />
<br />
See [[Google Authenticator]] to set up Google Authenticator.<br />
<br />
To use [[PAM]] with OpenSSH, edit the following files:<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
ChallengeResponseAuthentication yes<br />
AuthenticationMethods publickey keyboard-interactive:pam<br />
}}<br />
<br />
Then you can log in with either a publickey '''or''' the user authentication as required by your PAM setup.<br />
<br />
If, on the other hand, you want to authenticate the user on both a publickey '''and''' the user authentication as required by your PAM setup, use a comma instead of a space to separate the AuthenticationMethods:<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
ChallengeResponseAuthentication yes<br />
AuthenticationMethods publickey''','''keyboard-interactive:pam<br />
}}<br />
<br />
With required pubkey '''and''' pam authentication you may wish to disable the password requirement:<br />
<br />
{{hc|/etc/pam.d/sshd|<br />
auth required pam_securetty.so #disable remote root<br />
#Require google authenticator<br />
auth required pam_google_authenticator.so<br />
#But not password<br />
#auth include system-remote-login<br />
account include system-remote-login<br />
password include system-remote-login<br />
session include system-remote-login<br />
}}<br />
<br />
==== Protecting against brute force attacks ====<br />
<br />
Brute forcing is a simple concept: One continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations.<br />
<br />
===== Using ufw =====<br />
<br />
See [[ufw#Rate limiting with ufw]].<br />
<br />
===== Using iptables =====<br />
<br />
{{Merge|Simple stateful firewall#Bruteforce attacks|Out of scope, same technique as already described in the SSF.}}<br />
<br />
If you are already using iptables you can easily protect SSH against brute force attacks by using the following rules. <br />
<br />
{{note|In this example the SSH port was changed to port 42660 TCP.}}<br />
<br />
Before the following rules can be used we create a new rule chain to log and drop too many connection attempts:<br />
<br />
# iptables -N LOG_AND_DROP<br />
<br />
The first rule will be applied to packets that signal the start of new connections headed for TCP port 42660<br />
<br />
# iptables -A INPUT -p tcp -m tcp --dport 42660 -m state --state NEW -m recent --set --name DEFAULT --rsource<br />
<br />
The next rule tells iptables to look for packets that match the previous rule's parameters, and which also come from hosts already added to the watch list.<br />
<br />
# iptables -A INPUT -p tcp -m tcp --dport 42660 -m state --state NEW -m recent --update --seconds 90 --hitcount 4 --name DEFAULT --rsource -j LOG_AND_DROP<br />
<br />
Now iptables decides what to do with TCP traffic to port 42660 which does not match the previous rule.<br />
<br />
# iptables -A INPUT -p tcp -m tcp --dport 42660 -j ACCEPT<br />
<br />
We are appending this rule to the LOG_AND_DROP table, and we use the -j (jump) operator to pass the packet's information to the logging facility<br />
<br />
# iptables -A LOG_AND_DROP -j LOG --log-prefix "iptables deny: " --log-level 7<br />
<br />
After they are logged by the first rule, all packets are then dropped<br />
<br />
# iptables -A LOG_AND_DROP -j DROP<br />
<br />
===== Anti-brute-force tools =====<br />
<br />
You can protect yourself from brute force attacks by using an automated script that blocks anybody trying to brute force their way in, for example [[fail2ban]] or [[sshguard]].<br />
<br />
* Only allow incoming SSH connections from trusted locations<br />
* Use [[fail2ban]] or [[sshguard]] to automatically block IP addresses that fail password authentication too many times.<br />
* Use [https://github.com/jtniehof/pam_shield pam_shield] to block IP addresses that perform too many login attempts within a certain period of time. In contrast to [[fail2ban]] or [[sshguard]], this program does not take login success or failure into account.<br />
<br />
==== Limit root login ====<br />
<br />
{{Out of date|Root login has been disabled by default upstream in the current version. Unclear to me what parts of this section and subsections are redundant.}}<br />
<br />
It is generally considered bad practice to allow the root user to log in without restraint over SSH. There are two methods by which SSH root access can be restricted for increased security.<br />
<br />
===== Deny =====<br />
<br />
Sudo selectively provides root rights for actions requiring these without requiring authenticating against the root account. This allows locking the root account against access via SSH and potentially functions as a security measure against brute force attacks, since now an attacker must guess the account name in addition to the password.<br />
<br />
SSH can be configured to deny remote logins with the root user by editing the "Authentication" section in the daemon configuration file. Simply set {{ic|PermitRootLogin}} to {{ic|no}}:<br />
<br />
{{hc|/etc/ssh/sshd_config|PermitRootLogin no}}<br />
<br />
Next, [[restart]] the SSH daemon.<br />
<br />
You will now be unable to log in through SSH under root, but will still be able to log in with your normal user and use [[su]] or [[sudo]] to do system administration.<br />
<br />
===== Restrict =====<br />
<br />
Some automated tasks such as remote, full-system backup require full root access. To allow these in a secure way, instead of disabling root login via SSH, it is possible to only allow root logins for selected commands. This can be achieved by editing {{ic|~root/.ssh/authorized_keys}}, by prefixing the desired key, e.g. as follows:<br />
<br />
command="/usr/lib/rsync/rrsync -ro /" ssh-rsa …<br />
<br />
This will allow any login with this specific key only to execute the command specified between the quotes.<br />
<br />
The increased attack surface created by exposing the root user name at login can be compensated by adding the following to {{ic|sshd_config}}:<br />
<br />
PermitRootLogin forced-commands-only<br />
<br />
This setting will not only restrict the commands which root may execute via SSH, but it will also disable the use of passwords, forcing use of public key authentication for the root account.<br />
<br />
A slightly less restrictive alternative will allow any command for root, but makes brute force attacks infeasible by enforcing public key authentication. For this option, set:<br />
<br />
PermitRootLogin prohibit-password<br />
<br />
==== Securing the authorized_keys file ====<br />
<br />
For additional protection, you can prevent users from adding new public keys and connecting from them.<br />
<br />
In the server, make the {{ic|authorized_keys}} file read-only for the user and deny all other permissions:<br />
<br />
$ chmod 400 ~/.ssh/authorized_keys<br />
<br />
To keep the user from simply changing the permissions back, [[File permissions and attributes#chattr and lsattr|set the immutable bit]] on the {{ic|authorized_keys}} file. After that the user could rename the {{ic|~/.ssh}} directory to something else and create a new {{ic|~/.ssh}} directory and {{ic|authorized_keys}} file. To prevent this, set the immutable bit on the {{ic|~/.ssh}} directory too.<br />
<br />
{{Note|If you find yourself needing to add a new key, you will first have to remove the immutable bit from {{ic|authorized_keys}} and make it writable. Follow the steps above to secure it again.}}<br />
<br />
== Tips and tricks ==<br />
<br />
{{Accuracy|According to the current layout, this section seems rather generic, but in fact most of the offered tips work only in ''openssh''. For example ''dropbear'' (listed in [[#Other SSH clients and servers]]) does not support SOCKS proxy.[https://en.wikipedia.org/wiki/Comparison_of_SSH_clients#Technical]}}<br />
<br />
=== Encrypted SOCKS tunnel ===<br />
<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you do not have to remember your IP-address.<br />
<br />
==== Step 1: start the connection ====<br />
<br />
You only have to execute this single command to start the connection:<br />
<br />
$ ssh -TND 4711 ''user''@''host''<br />
<br />
where {{Ic|''user''}} is your username at the SSH server running at the {{Ic|''host''}}. It will ask for your password, and then you are connected. The {{Ic|N}} flag disables the interactive prompt, and the {{Ic|D}} flag specifies the local port on which to listen on (you can choose any port number if you want). The {{Ic|T}} flag disables pseudo-tty allocation.<br />
<br />
It is nice to add the verbose ({{Ic|-v}}) flag, because then you can verify that it is actually connected from that output.<br />
<br />
==== Step 2: configure your browser (or other programs) ====<br />
<br />
The above step is useful only in combination with a web browser or another program that uses this newly created SOCKS tunnel. Since SSH currently supports both SOCKS4 and SOCKS5, you can use either of them.<br />
<br />
* For Firefox: ''Preferences > General > Network Proxy > Manual proxy'', and enter {{ic|localhost}} in the ''SOCKS host'' text field, and the port number in the next text field ({{ic|4711}} in the example above).<br />
<br />
Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by the following steps:<br />
<br />
# Type {{ic|about:config}} into the Firefox location bar<br />
# Set {{ic|network.proxy.socks_remote_dns}} to {{ic|true}}<br />
# Restart Firefox<br />
<br />
* For Chromium: You can set the SOCKS settings as environment variables or as command line options. I recommend to add one of the following functions to your {{ic|.bashrc}}:<br />
<br />
function secure_chromium {<br />
port=4711<br />
export SOCKS_SERVER=localhost:$port<br />
export SOCKS_VERSION=5<br />
chromium &<br />
exit<br />
}<br />
<br />
OR<br />
<br />
function secure_chromium {<br />
port=4711<br />
chromium --proxy-server="socks://localhost:$port" &<br />
exit<br />
}<br />
<br />
Now open a terminal and just do:<br />
<br />
$ secure_chromium<br />
<br />
Enjoy your secure tunnel!<br />
<br />
=== X11 forwarding ===<br />
<br />
X11 forwarding is a mechanism that allows graphical interfaces of X11 programs running on a remote system to be displayed on a local client machine. For X11 forwarding the remote host does not need to have a full X11 system installed, however it needs at least to have ''xauth'' installed. ''xauth'' is a utility that maintains {{ic|Xauthority}} configurations used by server and client for authentication of X11 session ([http://xmodulo.com/2012/11/how-to-enable-x11-forwarding-using-ssh.html source]).<br />
<br />
{{Warning|X11 forwarding has important security implications which should be at least acknowledged by reading relevant sections of {{man|1|ssh}}, {{man|5|sshd_config}}, and {{man|5|ssh_config}} manual pages. See also [https://security.stackexchange.com/questions/14815/security-concerns-with-x11-forwarding this StackExchange question.]}}<br />
<br />
==== Setup ====<br />
<br />
===== Remote =====<br />
<br />
* [[install]] the {{Pkg|xorg-xauth}} and {{Pkg|xorg-xhost}} packages<br />
* in {{ic|/etc/ssh/ssh'''d'''_config}}:<br />
** set {{ic|X11Forwarding}} to ''yes''<br />
** verify that {{ic|AllowTcpForwarding}} and {{ic|X11UseLocalhost}} options are set to ''yes'', and that {{ic|X11DisplayOffset}} is set to ''10'' (those are the default values if nothing has been changed, see {{man|5|sshd_config}})<br />
* then [[restart]] the [[#Daemon management|''sshd'' daemon]].<br />
<br />
===== Client =====<br />
<br />
* [[install]] the {{Pkg|xorg-xauth}} package<br />
* enable the {{ic|ForwardX11}} option by either specifying the {{ic|-X}} switch on the command line for opportunistic connections, or by setting {{ic|ForwardX11}} to ''yes'' in the [[#Configuration|client's configuration]].<br />
<br />
{{Tip|You can enable the {{ic|ForwardX11Trusted}} option ({{ic|-Y}} switch on the command line) if GUI is drawing badly or you receive errors; this will prevent X11 forwardings from being subjected to the [http://www.x.org/wiki/Development/Documentation/Security/ X11 SECURITY extension] controls. Be sure you have read [[#X11 forwarding|the warning]] at the beginning of this section if you do so.}}<br />
<br />
==== Usage ====<br />
<br />
{{Accuracy|{{ic|xhost}} is [http://unix.stackexchange.com/questions/12755/how-to-forward-x-over-ssh-from-ubuntu-machine#comment17148_12772 generally not needed]|section=X11 forwarding}}<br />
<br />
Log on to the remote machine normally, specifying the {{ic|-X}} switch if ''ForwardX11'' was not enabled in the client's configuration file:<br />
<br />
$ ssh -X ''user@host''<br />
<br />
If you receive errors trying to run graphical applications, try ''ForwardX11Trusted'' instead:<br />
<br />
$ ssh -Y ''user@host''<br />
<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
<br />
$ xclock<br />
<br />
If you get "Cannot open display" errors try the following command as the non root user:<br />
<br />
$ xhost +<br />
<br />
The above command will allow anybody to forward X11 applications. To restrict forwarding to a particular host type:<br />
<br />
$ xhost +hostname<br />
<br />
where hostname is the name of the particular host you want to forward to. See {{man|1|xhost}} for more details.<br />
<br />
Be careful with some applications as they check for a running instance on the local machine. [[Firefox]] is an example: either close the running Firefox instance or use the following start parameter to start a remote instance on the local machine:<br />
<br />
$ firefox --no-remote<br />
<br />
If you get "X11 forwarding request failed on channel 0" when you connect (and the server {{ic|/var/log/errors.log}} shows "Failed to allocate internet-domain X11 display socket"), make sure package {{Pkg|xorg-xauth}} is installed. If its installation is not working, try to either:<br />
<br />
* enable the {{ic|AddressFamily any}} option in {{ic|ssh'''d'''_config}} on the ''server'', or<br />
* set the {{ic|AddressFamily}} option in {{ic|ssh'''d'''_config}} on the ''server'' to inet.<br />
Setting it to inet may fix problems with Ubuntu clients on IPv4.<br />
<br />
For running X applications as other user on the SSH server you need to {{Ic|xauth add}} the authentication line taken from {{Ic|xauth list}} of the SSH logged in user.<br />
<br />
{{Tip|[http://unix.stackexchange.com/a/12772/29867 Here] are [http://unix.stackexchange.com/a/46748/29867 some] useful [http://superuser.com/a/805060/185665 links] for troubleshooting {{ic|X11 Forwarding}} issues.}}<br />
<br />
=== Forwarding other ports ===<br />
<br />
In addition to SSH's built-in support for X11, it can also be used to securely tunnel any TCP connection, by use of local forwarding or remote forwarding.<br />
<br />
Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the {{Ic|-L}} switch and it is accompanying forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -L 1000:mail.google.com:25 192.168.0.100<br />
<br />
will use SSH to login to and open a shell on {{ic|192.168.0.100}}, and will also create a tunnel from the local machine's TCP port 1000 to mail.google.com on port 25. Once established, connections to {{ic|localhost:1000}} will connect to the Gmail SMTP port. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from {{ic|192.168.0.100}}, and such data will be secure between the local machine and 192.168.0.100, but not between {{ic|192.168.0.100}} and Google, unless other measures are taken.<br />
<br />
Similarly:<br />
<br />
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100<br />
<br />
will allow connections to {{ic|localhost:2000}} which will be transparently sent to the remote host on port 6001. The preceding example is useful for VNC connections using the vncserver utility--part of the tightvnc package--which, though very useful, is explicit about its lack of security.<br />
<br />
Remote forwarding allows the remote host to connect to an arbitrary host via the SSH tunnel and the local machine, providing a functional reversal of local forwarding, and is useful for situations where, e.g., the remote host has limited connectivity due to firewalling. It is enabled with the {{Ic|-R}} switch and a forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200<br />
<br />
will bring up a shell on {{ic|192.168.0.200}}, and connections from {{ic|192.168.0.200}} to itself on port 3000 (the remote host's {{ic|localhost:3000}}) will be sent over the tunnel to the local machine and then on to irc.freenode.net on port 6667, thus, in this example, allowing the use of IRC programs on the remote host to be used, even if port 6667 would normally be blocked to it.<br />
<br />
Both local and remote forwarding can be used to provide a secure "gateway", allowing other computers to take advantage of an SSH tunnel, without actually running SSH or the SSH daemon by providing a bind-address for the start of the tunnel as part of the forwarding specification, e.g. {{Ic|<tunnel address>:<tunnel port>:<destination address>:<destination port>}}. The {{Ic|<tunnel address>}} can be any address on the machine at the start of the tunnel. The address {{Ic|localhost}} allows connections via the {{ic|localhost}} or loopback interface, and an empty address or {{Ic|*}} allow connections via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the {{Ic|<tunnel address>}} is set to {{Ic|localhost}}. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the {{Ic|GatewayPorts}} option in {{man|5|sshd_config}} and {{ic|-L address}} option in {{man|1|ssh}} for more information about remote forwarding and local forwarding, respectively.<br />
<br />
=== Jump hosts ===<br />
<br />
In certain scenarios, there might not be a direct connection to your target SSH daemon, and the use of a jump server (or bastion server) is required. Thus, we attempt to connect together two or more SSH tunnels, and assuming your local keys are authorized against each server in the chain. This is possible using SSH agent forwarding ({{ic|-A}}) and pseudo-terminal allocation ({{ic|-t}}) which forwards your local key with the following syntax:<br />
<br />
$ ssh -A -t -l user1 bastion1 \<br />
ssh -A -t -l user2 intermediate2 \<br />
ssh -A -t -l user3 target<br />
<br />
An easier way to do this is using the {{ic|-J}} flag:<br />
<br />
$ ssh -J user1@bastion1,user2@intermediate2 user3@target<br />
<br />
Multiple hosts in the {{ic|-J}} directive can be separted with a comma, they will be connected to in the order listed. The {{ic|user...@}} part is not required, but can be used. The host specifications for {{ic|-J}} use the ssh configuration file, so specific per-host options can be set there, if needed.<br />
<br />
=== Reverse SSH through a relay ===<br />
<br />
{{Style|The idea of SSH tunneling is classic, so some references for detailed explanation would be nice. E.g. [https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work/118650#118650] which includes other scenarios.}}<br />
<br />
The idea is that client connects to the server via another relay, while the server is connected to the same relay using a reverse SSH tunnel. This is for example useful when the server is behind a NAT and relay is a publicly accessible SSH server used as a proxy to which the user has access. So the prerequisite is that client's keys are authorized against both the relay and the server and server's need to be authorized against the relay as well for the reverse SSH connection.<br />
<br />
The following configuration example assumes that user1 is the user account used on client, user2 on relay and user3 on server. First the server needs to establish the reverse tunnel with:<br />
<br />
ssh -R 2222:localhost:22 -N user2@relay<br />
<br />
Which can also be automated with a startup script, systemd service or {{Pkg|autossh}}.<br />
<br />
{{Expansion|Explain why {{ic|ssh user3@relay -p 2222}} is not sufficient.}}<br />
<br />
At the client side the connection is established with:<br />
<br />
ssh user2@relay ssh user3@localhost -p 2222<br />
<br />
The remote command to establish the connection to reverse tunnel can also be defined in relay's {{ic|~/.ssh/authorized_keys}} by including the {{ic|command}} field as follows:<br />
<br />
command="ssh user3@localhost -p 2222" ssh-rsa KEY2 user1@client<br />
<br />
In this case the connection is established with:<br />
<br />
ssh user2@relay<br />
<br />
Note that SCP's autocomplete function in client's terminal is not working and even the SCP transfers themselves are not working under some configurations.<br />
<br />
=== Multiplexing ===<br />
<br />
The SSH daemon usually listens on port 22. However, it is common practice for many public internet hotspots to block all traffic that is not on the regular HTTP/S ports (80 and 443, respectively), thus effectively blocking SSH connections. The immediate solution for this is to have {{ic|sshd}} listen additionally on one of the whitelisted ports:<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
Port 22<br />
Port 443<br />
}}<br />
<br />
However, it is likely that port 443 is already in use by a web server serving HTTPS content, in which case it is possible to use a multiplexer, such as {{Pkg|sslh}}, which listens on the multiplexed port and can intelligently forward packets to many services.<br />
<br />
=== Speeding up SSH ===<br />
<br />
There are several [[#Configuration|client configuration]] options which can speed up connections either globally or for specific hosts. See {{man|5|ssh_config}} for full descriptions of these options.<br />
<br />
* ''Use a faster cipher'': on modern CPUs with AESNI instructions, {{ic|aes128-gcm@openssh.com}} and {{ic|aes256-gcm@openssh.com}} should offer significantly better performance over openssh's default preferred cipher, usually {{ic|chacha20-poly1305@openssh.com}}. Cipher can be selected {{ic|-c}} flag. For a permanent effect, put {{ic|Ciphers}} option in your ~/.ssh/config with ciphers in new preferred order, e.g.:<br />
*: {{bc|Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr}}<br />
<br />
* ''Enable or disable compression'': compression can increase speed on slow connections, it is enabled with the {{ic|Compression yes}} option or the {{ic|-C}} flag. However the compression algorithm used is the relatively slow {{man|1|gzip}} which becomes the bottleneck on fast networks. In order to speed up the connection one should use the {{ic|Compression no}} option on local or fast networks.<br />
<br />
* ''Connection sharing'': you can make all sessions to the same host share a single connection using these options:<br />
*: {{bc|<nowiki><br />
ControlMaster auto<br />
ControlPersist yes<br />
ControlPath ~/.ssh/sockets/socket-%r@%h:%p<br />
</nowiki>}}<br />
: where {{ic|~/.ssh/sockets}} can be any directory not writable by other users.<br />
<br />
* {{ic|ControlPersist}} specifies how long the master should wait in the background for new clients after the initial client connection has been closed. Possible values are either: <br />
** {{ic|no}} to close the connection immediately after the last client disconnects, <br />
** a time in seconds,<br />
** {{ic|yes}} to wait forever, the connection will never be closed automatically.<br />
<br />
* Login time can be shortened by bypassing IPv6 lookup using the {{ic|AddressFamily inet}} option or {{ic|-4}} flag.<br />
<br />
* Last, if you intend to use SSH for SFTP or SCP, [https://www.psc.edu/index.php/hpn-ssh High Performance SSH/SCP] can significantly increase throughput by raising dynamically the SSH buffer sizes. Install the package {{AUR|openssh-hpn-git}} to use a patched version of OpenSSH with this enhancement.<br />
<br />
=== Mounting a remote filesystem with SSHFS ===<br />
<br />
Please refer to the [[SSHFS]] article to mount a SSH-accessible remote system to a local folder, so you will be able to do any operation on the mounted files with any tool (copy, rename, edit with vim, etc.). ''sshfs'' is generally preferred over ''shfs'', the latter has not been updated since 2004.<br />
{{Tip|There is a package {{AUR|autosshfs-git}}{{Broken package link|package not found}} that can be used to run autosshfs automatically at login.}}<br />
<br />
=== Keep alive ===<br />
<br />
By default, the SSH session automatically logs out if it has been idle for a certain time. To keep the session up, the client can send a keep-alive signal to the server if no data has been received for some time, or symmetrically the server can send messages at regular intervals if it has not heard from the client.<br />
<br />
* On the '''server''' side, {{ic|ClientAliveInterval}} sets the timeout in seconds after which if no data has been received from the client, ''sshd'' will send a request for response. The default is 0, no message is sent. For example to request a response every 60 seconds from the client, set the {{ic|ClientAliveInterval 60}} option in your [[#Configuration_2|server configuration]]. See also the {{ic|ClientAliveCountMax}} and {{ic|TCPKeepAlive}} options.<br />
* On the '''client''' side, {{ic|ServerAliveInterval}} controls the interval between the requests for response sent from the client to the server. For example to request a response every 120 seconds from the server, add the {{ic|ServerAliveInterval 120}} option to your [[#Configuration|client configuration]]. See also the {{ic|ServerAliveCountMax}} and {{ic|TCPKeepAlive}} options.<br />
<br />
{{Note| To ensure a session is kept alive, only one of either the client or the server needs to send keep alive requests. If ones control both the servers and the clients, a reasonable choice is to only configure the clients that require a persistent session with a positive {{ic|ServerAliveInterval}} and leave other clients and servers in their default configuration.}}<br />
<br />
=== Automatically restart SSH tunnels with systemd ===<br />
<br />
[[systemd]] can automatically start SSH connections on boot/login ''and'' restart them when they fail. This makes it a useful tool for maintaining SSH tunnels.<br />
<br />
The following service can start an SSH tunnel on login using the connection settings in your [[#Configuration|ssh configuration]]. If the connection closes for any reason, it waits 10 seconds before restarting it:<br />
<br />
{{hc|~/.config/systemd/user/tunnel.service|<nowiki><br />
[Unit]<br />
Description=SSH tunnel to myserver<br />
<br />
[Service]<br />
Type=simple<br />
Restart=always<br />
RestartSec=10<br />
ExecStart=/usr/bin/ssh -F %h/.ssh/config -N myserver<br />
</nowiki>}}<br />
<br />
Then [[enable]] and [[start]] the user service. See [[#Keep alive]] for how to prevent the tunnel from timing out. If you wish to start the tunnel on boot, you will need to rewrite the unit as a system service.<br />
<br />
=== Autossh - automatically restarts SSH sessions and tunnels ===<br />
<br />
When a session or tunnel cannot be kept alive, for example due to bad network conditions causing client disconnections, you can use {{Pkg|autossh}} to automatically restart them.<br />
<br />
Usage examples:<br />
<br />
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com<br />
<br />
Combined with [[SSHFS]]:<br />
<br />
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example <br />
<br />
Connecting through a SOCKS-proxy set by [[Proxy settings]]:<br />
<br />
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com <br />
<br />
With the {{ic|-f}} option autossh can be made to run as a background process. Running it this way however means the passphrase cannot be entered interactively.<br />
<br />
The session will end once you type {{ic|exit}} in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.<br />
<br />
==== Run autossh automatically at boot via systemd ====<br />
<br />
If you want to automatically start autossh, you can create a systemd unit file:<br />
<br />
{{hc|/etc/systemd/system/autossh.service|2=<br />
[Unit]<br />
Description=AutoSSH service for port 2222<br />
After=network.target<br />
<br />
[Service]<br />
Environment="AUTOSSH_GATETIME=0"<br />
ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Here {{ic|1=AUTOSSH_GATETIME=0}} is an environment variable specifying how long ssh must be up before autossh considers it a successful connection, setting it to 0 autossh also ignores the first run failure of ssh. This may be useful when running autossh at boot. Other environment variables are available on the manpage. Of course, you can make this unit more complex if necessary (see the systemd documentation for details), and obviously you can use your own options for autossh, but note that the {{ic|-f}} implying {{ic|1=AUTOSSH_GATETIME=0}} does not work with systemd. <br />
<br />
Remember to [[start]] and/or [[enable]] the service afterwards.<br />
<br />
You may also need to disable ControlMaster e.g.<br />
<br />
ExecStart=/usr/bin/autossh -M 0 -o ControlMaster=no -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com<br />
<br />
{{Tip|It is also easy to maintain several autossh processes, to keep several tunnels alive. Just create multiple service files with different names.}}<br />
<br />
=== Alternative service should SSH daemon fail ===<br />
<br />
For remote or headless servers which rely exclusively on SSH, a failure to start the SSH daemon (e.g., after a system upgrade) may prevent administration access. [[systemd]] offers a simple solution via {{ic|OnFailure}} option.<br />
<br />
Let us suppose the server runs {{ic|sshd}} and [[telnet]] is the fail-safe alternative of choice. Create a file as follows. Do '''not''' [[enable]] telnet.socket!<br />
<br />
{{hc|/etc/systemd/system/sshd.service.d/override.conf|2=<br />
[Unit]<br />
OnFailure=telnet.socket<br />
}}<br />
<br />
That's it. Telnet is not available when {{ic|sshd}} is running. Should {{ic|sshd}} fail to start, a telnet session can be opened for recovery.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Checklist ===<br />
<br />
Check these simple issues before you look any further.<br />
<br />
# The config directory {{ic|~/.ssh}}, its contents should be accessible only by the user (check this on both the client and the server), and the user's home folder should only be writable by the user: {{bc|<nowiki><br />
$ chmod go-w ~<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/*<br />
$ chown -R $USER ~/.ssh<br />
</nowiki>}}<br />
# Check that the client's public key (e.g. {{ic|id_rsa.pub}}) is in {{ic|~/.ssh/authorized_keys}} on the server.<br />
# Check that you did not limit SSH access with {{ic|AllowUsers}} or {{ic|AllowGroups}} in the [[#Configuration_2|server config]].<br />
# Check if the user has set a password. Sometimes new users who have not yet logged in to the server do not have a password.<br />
# [[Append]] {{ic|LogLevel DEBUG}} to {{ic|/etc/ssh/sshd_config}}.<br />
# Use {{ic|journalctl -xe}} for possible (error) messages.<br />
# [[Restart]] {{ic|sshd}} and logout/login on both client and server.<br />
<br />
=== Connection refused or timeout problem ===<br />
<br />
==== Port forwarding ====<br />
<br />
If you are behind a NAT mode/router (which is likely unless you are on a VPS or publicly addressed host), make sure that your router is forwarding incoming ssh connections to your machine. Find the server's internal IP address with {{ic|$ ip addr}} and set up your router to forward TCP on your SSH port to that IP. [http://portforward.com portforward.com] can help with that.<br />
<br />
==== Is SSH running and listening? ====<br />
<br />
The [[ss]] utility shows all the processes listening to a TCP port with the following command line:<br />
<br />
$ ss --tcp --listening<br />
<br />
If the above command do not show the system is listening to the port {{ic|ssh}}, then SSH is NOT running: check {{ic|/var/log/messages}} for errors etc.<br />
<br />
==== Are there firewall rules blocking the connection? ====<br />
<br />
[[Iptables]] may be blocking connections on port {{ic|22}}. Check this with:<br />
{{bc|# iptables -nvL}}<br />
and look for rules that might be dropping packets on the {{ic|INPUT}} chain. Then, if necessary, unblock the port with a command like: <br />
{{bc|<br />
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT<br />
}}<br />
For more help configuring firewalls, see [[firewalls]].<br />
<br />
==== Is the traffic even getting to your computer? ====<br />
<br />
Start a traffic dump on the computer you are having problems with:<br />
<br />
# tcpdump -lnn -i any port ssh and tcp-syn<br />
<br />
This should show some basic information, then wait for any matching traffic to happen before displaying it. Try your connection now. If you do not see any output when you attempt to connect, then something outside of your computer is blocking the traffic (e. g., hardware firewall, NAT router etc.).<br />
<br />
==== Your ISP or a third party blocking default port? ====<br />
<br />
{{Note|Try this step if you '''know''' you are not running any firewalls and you know you have configured the router for DMZ or have forwarded the port to your computer and it still does not work. Here you will find diagnostic steps and a possible solution.}}<br />
<br />
In some cases, your ISP might block the default port (SSH port 22) so whatever you try (opening ports, hardening the stack, defending against flood attacks, et al) ends up useless. To confirm this, create a server on all interfaces (0.0.0.0) and connect remotely. <br />
<br />
If you get an error message comparable to this:<br />
<br />
ssh: connect to host www.inet.hr port 22: Connection refused<br />
<br />
That means the port is '''not''' being blocked by the ISP, but the server does not run SSH on that port (See [[wikipedia:Security through obscurity|security through obscurity]]).<br />
<br />
However, if you get an error message comparable to this:<br />
<br />
ssh: connect to host 111.222.333.444 port 22: Operation timed out <br />
<br />
That means that something is rejecting your TCP traffic on port 22. Basically that port is stealth, either by your firewall or 3rd party intervention (like an ISP blocking and/or rejecting incoming traffic on port 22). If you know you are not running any firewall on your computer, and you know that Gremlins are not growing in your routers and switches, then your ISP is blocking the traffic.<br />
<br />
To double check, you can run Wireshark on your server and listen to traffic on port 22. Since Wireshark is a Layer 2 Packet Sniffing utility, and TCP/UDP are Layer 3 and above (see [[wikipedia:Internet protocol suite|IP Network stack]]), if you do not receive anything while connecting remotely, a third party is most likely to be blocking the traffic on that port to your server.<br />
<br />
===== Diagnosis =====<br />
<br />
[[Install]] either {{Pkg|tcpdump}} or Wireshark with the {{Pkg|wireshark-cli}} package.<br />
<br />
For tcpdump:<br />
<br />
# tcpdump -ni ''interface'' "port 22"<br />
<br />
For Wireshark:<br />
<br />
$ tshark -f "tcp port 22" -i ''interface''<br />
<br />
where {{ic|''interface''}} is the network interface for a WAN connection (see {{ic|ip a}} to check). If you are not receiving any packets while trying to connect remotely, you can be very sure that your ISP is blocking the incoming traffic on port 22.<br />
<br />
===== Possible solution =====<br />
<br />
The solution is just to use some other port that the ISP is not blocking. Open the {{ic|/etc/ssh/sshd_config}} and configure the file to use different ports. For example, add:<br />
<br />
Port 22<br />
Port 1234<br />
<br />
Also make sure that other "Port" configuration lines in the file are commented out. Just commenting "Port 22" and putting "Port 1234" will not solve the issue because then sshd will only listen on port 1234. Use both lines to run the SSH server on both ports. <br />
<br />
[[Restart]] the server {{ic|sshd.service}} and you are almost done. You still have to configure your client(s) to use the other port instead of the default port. There are numerous solutions to that problem, but let us cover two of them here.<br />
<br />
==== Read from socket failed: connection reset by peer ====<br />
<br />
Recent versions of openssh sometimes fail with the above error message when connecting to older ssh servers. This can be worked around by setting various [[#Configuration|client options]] for that host. See {{man|5|ssh_config}} for more information about the following options.<br />
<br />
The problem could be the {{ic|ecdsa-sha2-nistp*-cert-v01@openssh}} elliptical host key algorithms. These can be disabled by setting {{ic|HostKeyAlgorithms}} to a list excluding those algorithms.<br />
<br />
If that does not work, it could be that the list of ciphers is too long. Set the {{ic|Ciphers}} option to a shorter list (fewer than 80 characters should be enough). Similarly, you can also try shortening the list of {{ic|MACs}}.<br />
<br />
See also the [http://www.gossamer-threads.com/lists/openssh/dev/51339 discussion] on the openssh bug forum.<br />
<br />
=== "[your shell]: No such file or directory" / ssh_exchange_identification problem ===<br />
<br />
One possible cause for this is the need of certain SSH clients to find an absolute path (one returned by {{Ic|whereis -b [your shell]}}, for instance) in {{Ic|$SHELL}}, even if the shell's binary is located in one of the {{Ic|$PATH}} entries.<br />
<br />
==="Terminal unknown" or "Error opening terminal" error message===<br />
<br />
If you receive the above errors upon logging in, this means the server does not recognize your terminal. Ncurses applications like nano may fail with the message "Error opening terminal".<br />
<br />
The correct solution is to install the client terminal's terminfo file on the server. This tells console programs on the server how to correctly interact with your terminal. You can get info about current terminfo using {{ic|$ infocmp}} and then find out [[pacman#Querying package databases|which package owns it]].<br />
<br />
If you cannot [[install]] it normally, you can copy your terminfo to your home directory on the server:<br />
<br />
$ ssh myserver mkdir -p ~/.terminfo/${TERM:0:1}<br />
$ scp /usr/share/terminfo/${TERM:0:1}/$TERM myserver:~/.terminfo/${TERM:0:1}/<br />
<br />
After logging in and out from the server the problem should be fixed.<br />
<br />
==== TERM hack ====<br />
<br />
{{Note|This should only be used as a last resort.}}<br />
<br />
Alternatively, you can simply set {{ic|1=TERM=xterm}} in your environment on the server (e.g. in {{ic|.bash_profile}}). This will silence the error and allow ncurses applications to run again, but you may experience strange behavior and graphical glitches unless your terminal's control sequences exactly match xterm's.<br />
<br />
=== Connection closed by x.x.x.x [preauth] ===<br />
<br />
If you are seeing this error in your sshd logs, make sure you have set a valid HostKey<br />
<br />
HostKey /etc/ssh/ssh_host_rsa_key<br />
<br />
=== id_dsa refused by OpenSSH 7.0 ===<br />
<br />
OpenSSH 7.0 deprecated DSA public keys for security reasons. If you absolutely must enable them, set the [[#Configuration|config]] option {{ic|PubkeyAcceptedKeyTypes +ssh-dss}} (http://www.openssh.com/legacy.html does not mention this).<br />
<br />
=== No matching key exchange method found by OpenSSH 7.0 ===<br />
<br />
OpenSSH 7.0 deprecated the diffie-hellman-group1-sha1 key algorithm because it is weak and within theoretical range of the so-called Logjam attack (see http://www.openssh.com/legacy.html). If the key algorithm is needed for a particular host, ssh will produce an error message like this:<br />
<br />
Unable to negotiate with 127.0.0.1: no matching key exchange method found.<br />
Their offer: diffie-hellman-group1-sha1<br />
<br />
The best resolution for these failures is to upgrade/configure the server to not use deprecated algorithms. If that is not possible, you can force the client to reenable the algorithm with the [[#Configuration|client option]] {{ic|KexAlgorithms +diffie-hellman-group1-sha1}}.<br />
<br />
=== tmux/screen session killed when disconnecting from SSH ===<br />
<br />
If your processes get killed at the end of the session, it is possible that you are using socket activation and it gets killed by {{Pkg|systemd}} when it notices that the SSH session process exited. In that case there are two solutions. One is to avoid using socket activation by using {{ic|ssh.service}} instead of {{ic|ssh.socket}}. The other is to set {{ic|1=KillMode=process}} in the Service section of {{ic|ssh@.service}}.<br />
<br />
The {{ic|1=KillMode=process}} setting may also be useful with the classic {{ic|ssh.service}}, as it avoids killing the SSH session process or the {{Pkg|screen}} or {{Pkg|tmux}} processes when the server gets stopped or restarted.<br />
<br />
=== SSH session stops responding ===<br />
<br />
SSH responds to [[Wikipedia:Software flow control|flow control commands]] {{ic|XON}} and {{ic|XOFF}}. It will freeze/hang/stop responding when you hit {{ic|Ctrl+s}}. Use {{ic|Ctrl+q}} to resume your session.<br />
<br />
=== Broken pipe ===<br />
<br />
If you attempt to create a connection which results in a {{ic|Broken pipe}} response for {{ic|packet_write_wait}}, you should reattempt the connection in debug mode and see if the output ends in error:<br />
{{bc|debug3: send packet: type 1<br />
packet_write_wait: Connection to A.B.C.D port 22: Broken pipe}}<br />
The {{ic|send packet}} line above indicates that the reply packet was never received. So, it follows that this is a ''QoS'' issue. To decrease the likely-hood of a packet being dropped, set {{ic|IPQoS}}:<br />
{{hc|/etc/ssh/ssh_config|Host *<br />
IPQoS reliability}}<br />
The {{ic|reliability}} ({{ic|0x04}}) type-of-service should resolve the issue, as well as {{ic|0x00}} and {{ic|throughput}} ({{ic|0x08}}).<br />
<br />
=== Slow daemon startup after reboot ===<br />
<br />
If you are experiencing excessively long daemon startup times after reboots (e.g. several minutes before the daemon starts accepting connections), especially on headless or virtualized servers, it may be due to a lack of entropy.[https://bbs.archlinux.org/viewtopic.php?id=241954] This can be remedied by installing either [[Rng-tools]] or [[Haveged]], as appropriate for your system. However, take note of the associated security implications discussed in each package's respective wiki page.<br />
<br />
== See also ==<br />
<br />
* [http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]<br />
* [http://www.ibm.com/developerworks/library/l-keyc/index.html OpenSSH key management, Part 1] and [http://www.ibm.com/developerworks/library/l-keyc2 Part 2] on IBM developerWorks<br />
* [https://stribika.github.io/2015/01/04/secure-secure-shell.html Secure Secure Shell]</div>Ivankhttps://wiki.archlinux.org/index.php?title=QEMU&diff=570777QEMU2019-04-09T01:54:23Z<p>Ivank: /* qxl */ add a note to increase vga_memmb for high resolutions</p>
<hr />
<div>[[Category:Emulation]]<br />
[[Category:Hypervisors]]<br />
[[de:Qemu]]<br />
[[es:QEMU]]<br />
[[fr:Qemu]]<br />
[[ja:QEMU]]<br />
[[ru:QEMU]]<br />
[[zh-hans:QEMU]]<br />
[[zh-hant:QEMU]]<br />
{{Related articles start}}<br />
{{Related|:Category:Hypervisors}}<br />
{{Related|Libvirt}}<br />
{{Related|QEMU/Guest graphics acceleration}}<br />
{{Related|PCI passthrough via OVMF}}<br />
{{Related articles end}}<br />
<br />
According to the [http://wiki.qemu.org/Main_Page QEMU about page], "QEMU is a generic and open source machine emulator and virtualizer."<br />
<br />
When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your x86 PC). By using dynamic translation, it achieves very good performance.<br />
<br />
QEMU can use other hypervisors like [[Xen]] or [[KVM]] to use CPU extensions ([[Wikipedia:Hardware-assisted virtualization|HVM]]) for virtualization. When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|qemu}} package (or {{Pkg|qemu-headless}} for the version without GUI) and below optional packages for your needs:<br />
<br />
* {{Pkg|qemu-arch-extra}} - extra architectures support<br />
* {{Pkg|qemu-block-gluster}} - [[Glusterfs]] block support<br />
* {{Pkg|qemu-block-iscsi}} - [[iSCSI]] block support<br />
* {{Pkg|qemu-block-rbd}} - RBD block support <br />
* {{Pkg|samba}} - [[Samba|SMB/CIFS]] server support<br />
<br />
== Graphical front-ends for QEMU ==<br />
<br />
Unlike other virtualization programs such as [[VirtualBox]] and [[VMware]], QEMU does not provide a GUI to manage virtual machines (other than the window that appears when running a virtual machine), nor does it provide a way to create persistent virtual machines with saved settings. All parameters to run a virtual machine must be specified on the command line at every launch, unless you have created a custom script to start your virtual machine(s).<br />
<br />
[[Libvirt]] provides a convenient way to manage QEMU virtual machines. See [[Libvirt#Client|list of libvirt clients]] for available front-ends.<br />
<br />
Other GUI front-ends for QEMU:<br />
<br />
* {{App|AQEMU|QEMU GUI written in Qt5.|https://github.com/tobimensch/aqemu|{{AUR|aqemu}}}}<br />
* {{App|QtEmu|Graphical user interface for QEMU written in Qt4.|https://qtemu.org/|{{AUR|qtemu}}}}<br />
<br />
== Creating new virtualized system ==<br />
<br />
=== Creating a hard disk image ===<br />
{{Accuracy|If I get the man page right the raw format only allocates the full size if the filesystem does not support "holes" or it is <br />
explicitly told to preallocate. See man qemu-img in section Notes.}} <br />
{{Tip|See the [https://en.wikibooks.org/wiki/QEMU/Images QEMU Wikibook] for more information on QEMU images.}}<br />
<br />
To run QEMU you will need a hard disk image, unless you are booting a live system from CD-ROM or the network (and not doing so to install an operating system to a hard disk image). A hard disk image is a file which stores the contents of the emulated hard disk.<br />
<br />
A hard disk image can be ''raw'', so that it is literally byte-by-byte the same as what the guest sees, and will always use the full capacity of the guest hard drive on the host. This method provides the least I/O overhead, but can waste a lot of space, as not-used space on the guest cannot be used on the host.<br />
<br />
Alternatively, the hard disk image can be in a format such as ''qcow2'' which only allocates space to the image file when the guest operating system actually writes to those sectors on its virtual hard disk. The image appears as the full size to the guest operating system, even though it may take up only a very small amount of space on the host system. This image format also supports QEMU snapshotting functionality (see [[#Creating and managing snapshots via the monitor console]] for details). However, using this format instead of ''raw'' will likely affect performance.<br />
<br />
QEMU provides the {{ic|qemu-img}} command to create hard disk images. For example to create a 4 GB image in the ''raw'' format:<br />
<br />
$ qemu-img create -f raw ''image_file'' 4G<br />
<br />
You may use {{ic|-f qcow2}} to create a ''qcow2'' disk instead.<br />
<br />
{{Note|You can also simply create a ''raw'' image by creating a file of the needed size using {{ic|dd}} or {{ic|fallocate}}.}}<br />
<br />
{{Warning|If you store the hard disk images on a [[Btrfs]] file system, you should consider disabling [[Btrfs#Copy-on-Write (CoW)|Copy-on-Write]] for the directory before creating any images.}}<br />
<br />
==== Overlay storage images ====<br />
<br />
You can create a storage image once (the 'backing' image) and have QEMU keep mutations to this image in an overlay image. This allows you to revert to a previous state of this storage image. You could revert by creating a new overlay image at the time you wish to revert, based on the original backing image.<br />
<br />
To create an overlay image, issue a command like:<br />
<br />
$ qemu-img create -o backing_file=''img1.raw'',backing_fmt=''raw'' -f ''qcow2'' ''img1.cow''<br />
<br />
After that you can run your QEMU VM as usual (see [[#Running virtualized system]]):<br />
<br />
$ qemu-system-x86_64 ''img1.cow''<br />
<br />
The backing image will then be left intact and mutations to this storage will be recorded in the overlay image file.<br />
<br />
When the path to the backing image changes, repair is required.<br />
<br />
{{Warning|The backing image's absolute filesystem path is stored in the (binary) overlay image file. Changing the backing image's path requires some effort.}}<br />
<br />
Make sure that the original backing image's path still leads to this image. If necessary, make a symbolic link at the original path to the new path. Then issue a command like:<br />
<br />
$ qemu-img rebase -b ''/new/img1.raw'' ''/new/img1.cow''<br />
<br />
At your discretion, you may alternatively perform an 'unsafe' rebase where the old path to the backing image is not checked:<br />
<br />
$ qemu-img rebase -u -b ''/new/img1.raw'' ''/new/img1.cow''<br />
<br />
==== Resizing an image ====<br />
<br />
{{Warning|Resizing an image containing an NTFS boot file system could make the operating system installed on it unbootable. It is recommended to create a backup first.}}<br />
<br />
The {{ic|qemu-img}} executable has the {{ic|resize}} option, which enables easy resizing of a hard drive image. It works for both ''raw'' and ''qcow2''. For example, to increase image space by 10 GB, run:<br />
<br />
$ qemu-img resize ''disk_image'' +10G<br />
<br />
After enlarging the disk image, you must use file system and partitioning tools inside the virtual machine to actually begin using the new space. When shrinking a disk image, you must '''first reduce the allocated file systems and partition sizes''' using the file system and partitioning tools inside the virtual machine and then shrink the disk image accordingly, otherwise shrinking the disk image will result in data loss! For a Windows guest, open the "create and format hard disk partitions" control panel.<br />
<br />
==== Converting an image ====<br />
<br />
You can convert an image to other formats using {{ic|qemu-img convert}}. This example shows how to convert a ''raw'' image to ''qcow2'':<br />
<br />
$ qemu-img convert -f raw -O qcow2 ''input''.img ''output''.qcow2<br />
<br />
This will not remove the original input file.<br />
<br />
=== Preparing the installation media ===<br />
<br />
To install an operating system into your disk image, you need the installation medium (e.g. optical disk, USB-drive, or ISO image) for the operating system. The installation medium should not be mounted because QEMU accesses the media directly.<br />
<br />
{{Tip|If using an optical disk, it is a good idea to first dump the media to a file because this both improves performance and does not require you to have direct access to the devices (that is, you can run QEMU as a regular user without having to change access permissions on the media's device file). For example, if the CD-ROM device node is named {{ic|/dev/cdrom}}, you can dump it to a file with the command: {{bc|1=$ dd if=/dev/cdrom of=''cd_image.iso'' bs=4k}}}}<br />
<br />
=== Installing the operating system===<br />
<br />
This is the first time you will need to start the emulator. To install the operating system on the disk image, you must attach both the disk image and the installation media to the virtual machine, and have it boot from the installation media.<br />
<br />
For example on i386 guests, to install from a bootable ISO file as CD-ROM and a raw disk image:<br />
<br />
$ qemu-system-x86_64 -cdrom ''iso_image'' -boot order=d -drive file=''disk_image'',format=raw<br />
<br />
See {{man|1|qemu}} for more information about loading other media types (such as floppy, disk images or physical drives) and [[#Running virtualized system]] for other useful options.<br />
<br />
After the operating system has finished installing, the QEMU image can be booted directly (see [[#Running virtualized system]]).<br />
<br />
{{Note|By default only 128 MB of memory is assigned to the machine. The amount of memory can be adjusted with the {{ic|-m}} switch, for example {{ic|-m 512M}} or {{ic|-m 2G}}.}}<br />
<br />
{{Tip|<br />
* Instead of specifying {{ic|1=-boot order=x}}, some users may feel more comfortable using a boot menu: {{ic|1=-boot menu=on}}, at least during configuration and experimentation.<br />
* If you need to replace floppies or CDs as part of the installation process, you can use the QEMU machine monitor (press {{ic|Ctrl+Alt+2}} in the virtual machine's window) to remove and attach storage devices to a virtual machine. Type {{ic|info block}} to see the block devices, and use the {{ic|change}} command to swap out a device. Press {{ic|Ctrl+Alt+1}} to go back to the virtual machine.}}<br />
<br />
== Running virtualized system ==<br />
<br />
{{ic|qemu-system-*}} binaries (for example {{ic|qemu-system-i386}} or {{ic|qemu-system-x86_64}}, depending on guest's architecture) are used to run the virtualized guest. The usage is:<br />
<br />
$ qemu-system-x86_64 ''options'' ''disk_image''<br />
<br />
Options are the same for all {{ic|qemu-system-*}} binaries, see {{man|1|qemu}} for documentation of all options.<br />
<br />
By default, QEMU will show the virtual machine's video output in a window. One thing to keep in mind: when you click inside the QEMU window, the mouse pointer is grabbed. To release it, press {{ic|Ctrl+Alt+g}}.<br />
<br />
{{Warning|QEMU should never be run as root. If you must launch it in a script as root, you should use the {{ic|-runas}} option to make QEMU drop root privileges.}}<br />
<br />
=== Enabling KVM ===<br />
<br />
KVM must be supported by your processor and kernel, and necessary [[kernel modules]] must be loaded. See [[KVM]] for more information.<br />
<br />
To start QEMU in KVM mode, append {{ic|-enable-kvm}} to the additional start options. To check if KVM is enabled for a running VM, enter the [[#QEMU monitor]] using {{ic|Ctrl+Alt+Shift+2}}, and type {{ic|info kvm}}.<br />
<br />
{{Note|<br />
* The argument {{ic|1=accel=kvm}} of the {{ic|-machine}} option is equivalent to the {{ic|-enable-kvm}} option.<br />
* If you start your VM with a GUI tool and experience very bad performance, you should check for proper KVM support, as QEMU may be falling back to software emulation.<br />
* KVM needs to be enabled in order to start Windows 7 and Windows 8 properly without a ''blue screen''.<br />
}}<br />
<br />
=== Enabling IOMMU (Intel VT-d/AMD-Vi) support ===<br />
<br />
First enable IOMMU, see [[PCI passthrough via OVMF#Setting up IOMMU]].<br />
<br />
Add {{ic|-device intel-iommu}} to create the IOMMU device:<br />
<br />
$ qemu-system-x86_64 '''-enable-kvm -machine q35,accel=kvm -device intel-iommu''' -cpu host ..<br />
<br />
{{Note|<br />
On Intel CPU based systems creating an IOMMU device in a QEMU guest with {{ic|-device intel-iommu}} will disable PCI passthrough with an error like: {{bc|Device at bus pcie.0 addr 09.0 requires iommu notifier which is currently not supported by intel-iommu emulation}} While adding the kernel parameter {{ic|1=intel_iommu=on}} is still needed for remapping IO (e.g. [[PCI passthrough via OVMF#Isolating the GPU|PCI passthrough with vfio-pci]]), {{ic|-device intel-iommu}} should not be set if PCI PCI passthrough is required.<br />
}}<br />
<br />
== Moving data between host and guest OS ==<br />
<br />
=== Network ===<br />
<br />
Data can be shared between the host and guest OS using any network protocol that can transfer files, such as [[NFS]], [[SMB]], [[Wikipedia:Network Block Device|NBD]], HTTP, [[Very Secure FTP Daemon|FTP]], or [[SSH]], provided that you have set up the network appropriately and enabled the appropriate services.<br />
<br />
The default user-mode networking allows the guest to access the host OS at the IP address 10.0.2.2. Any servers that you are running on your host OS, such as a SSH server or SMB server, will be accessible at this IP address. So on the guests, you can mount directories exported on the host via [[SMB]] or [[NFS]], or you can access the host's HTTP server, etc.<br />
It will not be possible for the host OS to access servers running on the guest OS, but this can be done with other network configurations (see [[#Tap networking with QEMU]]).<br />
<br />
=== QEMU's port forwarding ===<br />
<br />
QEMU can forward ports from the host to the guest to enable e.g. connecting from the host to a SSH-server running on the guest.<br />
<br />
For example, to bind port 10022 on the host with port 22 (SSH) on the guest, start QEMU with a command like:<br />
<br />
$ qemu-system-x86_64 ''disk_image'' -net nic -net user,hostfwd=''tcp::10022-:22''<br />
<br />
Make sure the sshd is running on the guest and connect with:<br />
<br />
$ ssh ''guest-user''@localhost -p10022<br />
<br />
=== QEMU's built-in SMB server ===<br />
<br />
QEMU's documentation says it has a "built-in" SMB server, but actually it just starts up [[Samba]] with an automatically generated {{ic|smb.conf}} file located at {{ic|/tmp/qemu-smb.''pid''-0/smb.conf}} and makes it accessible to the guest at a different IP address (10.0.2.4 by default). This only works for user networking, and this is not necessarily very useful since the guest can also access the normal [[Samba]] service on the host if you have set up shares on it.<br />
<br />
To enable this feature, start QEMU with a command like:<br />
<br />
$ qemu-system-x86_64 ''disk_image'' -net nic -net user,smb=''shared_dir_path''<br />
<br />
where {{ic|''shared_dir_path''}} is a directory that you want to share between the guest and host.<br />
<br />
Then, in the guest, you will be able to access the shared directory on the host 10.0.2.4 with the share name "qemu". For example, in Windows Explorer you would go to {{ic|\\10.0.2.4\qemu}}.<br />
<br />
{{Note|<br />
* If you are using sharing options multiple times like {{ic|1=-net user,smb=''shared_dir_path1'' -net user,smb=''shared_dir_path2''}} or {{ic|1=-net user,smb=''shared_dir_path1'',smb=''shared_dir_path2''}} then it will share only the last defined one.<br />
* If you cannot access the shared folder and the guest system is Windows, check that the [http://ecross.mvps.org/howto/enable-netbios-over-tcp-ip-with-windows.htm NetBIOS protocol is enabled] and that a firewall does not block [http://technet.microsoft.com/en-us/library/cc940063.aspx ports] used by the NetBIOS protocol.<br />
* If you cannot access the shared folder and the guest system is Windows 10 Enterprise or Education or Windows Server 2016, [https://support.microsoft.com/en-us/help/4046019 enable guest access].<br />
}}<br />
<br />
=== Mounting a partition inside a raw disk image ===<br />
<br />
When the virtual machine is not running, it is possible to mount partitions that are inside a raw disk image file by setting them up as loopback devices. This does not work with disk images in special formats, such as qcow2, although those can be mounted using {{ic|qemu-nbd}}.<br />
<br />
{{Warning|You must make sure to unmount the partitions before running the virtual machine again. Otherwise, data corruption is very likely to occur.}}<br />
<br />
==== With manually specifying byte offset ====<br />
<br />
One way to mount a disk image partition is to mount the disk image at a certain offset using a command like the following:<br />
<br />
# mount -o loop,offset=32256 ''disk_image'' ''mountpoint''<br />
<br />
The {{ic|1=offset=32256}} option is actually passed to the {{ic|losetup}} program to set up a loopback device that starts at byte offset 32256 of the file and continues to the end. This loopback device is then mounted. You may also use the {{ic|sizelimit}} option to specify the exact size of the partition, but this is usually unnecessary.<br />
<br />
Depending on your disk image, the needed partition may not start at offset 32256. Run {{ic|fdisk -l ''disk_image''}} to see the partitions in the image. fdisk gives the start and end offsets in 512-byte sectors, so multiply by 512 to get the correct offset to pass to {{ic|mount}}.<br />
<br />
==== With loop module autodetecting partitions ====<br />
<br />
The Linux loop driver actually supports partitions in loopback devices, but it is disabled by default. To enable it, do the following:<br />
<br />
* Get rid of all your loopback devices (unmount all mounted images, etc.).<br />
* [[Kernel_modules#Manual_module_handling|Unload]] the {{ic|loop}} kernel module, and load it with the {{ic|1=max_part=15}} parameter set. Additionally, the maximum number of loop devices can be controlled with the {{ic|max_loop}} parameter.<br />
<br />
{{Tip|You can put an entry in {{ic|/etc/modprobe.d}} to load the loop module with {{ic|1=max_part=15}} every time, or you can put {{ic|1=loop.max_part=15}} on the kernel command-line, depending on whether you have the {{ic|loop.ko}} module built into your kernel or not.}}<br />
<br />
Set up your image as a loopback device:<br />
<br />
# losetup -f -P ''disk_image''<br />
<br />
Then, if the device created was {{ic|/dev/loop0}}, additional devices {{ic|/dev/loop0pX}} will have been automatically created, where X is the number of the partition. These partition loopback devices can be mounted directly. For example:<br />
<br />
# mount /dev/loop0p1 ''mountpoint''<br />
<br />
To mount the disk image with ''udisksctl'', see [[Udisks#Mount loop devices]].<br />
<br />
==== With kpartx ====<br />
<br />
'''kpartx''' from the {{Pkg|multipath-tools}} package can read a partition table on a device and create a new device for each partition. For example:<br />
# kpartx -a ''disk_image''<br />
<br />
This will setup the loopback device and create the necessary partition(s) device(s) in {{ic|/dev/mapper/}}.<br />
<br />
=== Mounting a partition inside a qcow2 image ===<br />
<br />
You may mount a partition inside a qcow2 image using {{ic|qemu-nbd}}. See [http://en.wikibooks.org/wiki/QEMU/Images#Mounting_an_image_on_the_host Wikibooks].<br />
<br />
=== Using any real partition as the single primary partition of a hard disk image ===<br />
<br />
Sometimes, you may wish to use one of your system partitions from within QEMU. Using a raw partition for a virtual machine will improve performance, as the read and write operations do not go through the file system layer on the physical host. Such a partition also provides a way to share data between the host and guest.<br />
<br />
In Arch Linux, device files for raw partitions are, by default, owned by ''root'' and the ''disk'' group. If you would like to have a non-root user be able to read and write to a raw partition, you need to change the owner of the partition's device file to that user.<br />
<br />
{{Warning|<br />
* Although it is possible, it is not recommended to allow virtual machines to alter critical data on the host system, such as the root partition.<br />
* You must not mount a file system on a partition read-write on both the host and the guest at the same time. Otherwise, data corruption will result.<br />
}}<br />
<br />
After doing so, you can attach the partition to a QEMU virtual machine as a virtual disk.<br />
<br />
However, things are a little more complicated if you want to have the ''entire'' virtual machine contained in a partition. In that case, there would be no disk image file to actually boot the virtual machine since you cannot install a bootloader to a partition that is itself formatted as a file system and not as a partitioned device with a MBR. Such a virtual machine can be booted either by specifying the [[kernel]] and [[initrd]] manually, or by simulating a disk with a MBR by using linear [[RAID]].<br />
<br />
==== By specifying kernel and initrd manually ====<br />
<br />
QEMU supports loading [[Kernels|Linux kernels]] and [[initramfs|init ramdisks]] directly, thereby circumventing bootloaders such as [[GRUB]]. It then can be launched with the physical partition containing the root file system as the virtual disk, which will not appear to be partitioned. This is done by issuing a command similar to the following:<br />
<br />
{{Note|In this example, it is the '''host's''' images that are being used, not the guest's. If you wish to use the guest's images, either mount {{ic|/dev/sda3}} read-only (to protect the file system from the host) and specify the {{ic|/full/path/to/images}} or use some kexec hackery in the guest to reload the guest's kernel (extends boot time). }}<br />
<br />
$ qemu-system-x86_64 -kernel /boot/vmlinuz-linux -initrd /boot/initramfs-linux.img -append root=/dev/sda /dev/sda3<br />
<br />
In the above example, the physical partition being used for the guest's root file system is {{ic|/dev/sda3}} on the host, but it shows up as {{ic|/dev/sda}} on the guest.<br />
<br />
You may, of course, specify any kernel and initrd that you want, and not just the ones that come with Arch Linux.<br />
<br />
When there are multiple [[kernel parameters]] to be passed to the {{ic|-append}} option, they need to be quoted using single or double quotes. For example:<br />
<br />
... -append 'root=/dev/sda1 console=ttyS0'<br />
<br />
==== Simulate virtual disk with MBR using linear RAID ====<br />
<br />
A more complicated way to have a virtual machine use a physical partition, while keeping that partition formatted as a file system and not just having the guest partition the partition as if it were a disk, is to simulate a MBR for it so that it can boot using a bootloader such as GRUB.<br />
<br />
You can do this using software [[RAID]] in linear mode (you need the {{ic|linear.ko}} kernel driver) and a loopback device: the trick is to dynamically prepend a master boot record (MBR) to the real partition you wish to embed in a QEMU raw disk image.<br />
<br />
Suppose you have a plain, unmounted {{ic|/dev/hdaN}} partition with some file system on it you wish to make part of a QEMU disk image. First, you create some small file to hold the MBR:<br />
<br />
$ dd if=/dev/zero of=''/path/to/mbr'' count=32<br />
<br />
Here, a 16 KB (32 * 512 bytes) file is created. It is important not to make it too small (even if the MBR only needs a single 512 bytes block), since the smaller it will be, the smaller the chunk size of the software RAID device will have to be, which could have an impact on performance. Then, you setup a loopback device to the MBR file:<br />
<br />
# losetup -f ''/path/to/mbr''<br />
<br />
Let us assume the resulting device is {{ic|/dev/loop0}}, because we would not already have been using other loopbacks. Next step is to create the "merged" MBR + {{ic|/dev/hdaN}} disk image using software RAID:<br />
<br />
# modprobe linear<br />
# mdadm --build --verbose /dev/md0 --chunk=16 --level=linear --raid-devices=2 /dev/loop0 /dev/hda''N''<br />
<br />
The resulting {{ic|/dev/md0}} is what you will use as a QEMU raw disk image (do not forget to set the permissions so that the emulator can access it). The last (and somewhat tricky) step is to set the disk configuration (disk geometry and partitions table) so that the primary partition start point in the MBR matches the one of {{ic|/dev/hda''N''}} inside {{ic|/dev/md0}} (an offset of exactly 16 * 512 = 16384 bytes in this example). Do this using {{ic|fdisk}} on the host machine, not in the emulator: the default raw disc detection routine from QEMU often results in non-kilobyte-roundable offsets (such as 31.5 KB, as in the previous section) that cannot be managed by the software RAID code. Hence, from the the host:<br />
<br />
# fdisk /dev/md0<br />
<br />
Press {{ic|X}} to enter the expert menu. Set number of 's'ectors per track so that the size of one cylinder matches the size of your MBR file. For two heads and a sector size of 512, the number of sectors per track should be 16, so we get cylinders of size 2x16x512=16k.<br />
<br />
Now, press {{ic|R}} to return to the main menu.<br />
<br />
Press {{ic|P}} and check that the cylinder size is now 16k.<br />
<br />
Now, create a single primary partition corresponding to {{ic|/dev/hda''N''}}. It should start at cylinder 2 and end at the end of the disk (note that the number of cylinders now differs from what it was when you entered fdisk.<br />
<br />
Finally, 'w'rite the result to the file: you are done. You now have a partition you can mount directly from your host, as well as part of a QEMU disk image:<br />
<br />
$ qemu-system-x86_64 -hdc /dev/md0 ''[...]''<br />
<br />
You can, of course, safely set any bootloader on this disk image using QEMU, provided the original {{ic|/dev/hda''N''}} partition contains the necessary tools.<br />
<br />
===== Alternative: use nbd-server =====<br />
Instead of linear RAID, you may use {{ic|nbd-server}} (from the {{pkg|nbd}} package) to create an MBR wrapper for QEMU.<br />
<br />
Assuming you have already set up your MBR wrapper file like above, rename it to {{ic|wrapper.img.0}}. Then create a symbolic link named {{ic|wrapper.img.1}} in the same directory, pointing to your partition. Then put the following script in the same directory:<br />
<br />
#!/bin/sh<br />
dir="$(realpath "$(dirname "$0")")"<br />
cat >wrapper.conf <<EOF<br />
[generic]<br />
allowlist = true<br />
listenaddr = 127.713705<br />
port = 10809<br />
<br />
[wrap]<br />
exportname = $dir/wrapper.img<br />
multifile = true<br />
EOF<br />
<br />
nbd-server \<br />
-C wrapper.conf \<br />
-p wrapper.pid \<br />
"$@"<br />
<br />
The {{ic|.0}} and {{ic|.1}} suffixes are essential; the rest can be changed. After running the above script (which you may need to do as root to make sure nbd-server is able to access the partition), you can launch QEMU with:<br />
<br />
qemu-system-x86_64 -drive file=nbd:127.713705:10809:exportname=wrap ''[...]''<br />
<br />
== Networking ==<br />
<br />
{{Style|Network topologies (sections [[#Host-only networking]], [[#Internal networking]] and info spread out across other sections) should not be described alongside the various virtual interfaces implementations, such as [[#User-mode networking]], [[#Tap networking with QEMU]], [[#Networking with VDE2]].}}<br />
<br />
The performance of virtual networking should be better with tap devices and bridges than with user-mode networking or vde because tap devices and bridges are implemented in-kernel.<br />
<br />
In addition, networking performance can be improved by assigning virtual machines a [http://wiki.libvirt.org/page/Virtio virtio] network device rather than the default emulation of an e1000 NIC. See [[#Installing virtio drivers]] for more information.<br />
<br />
=== Link-level address caveat ===<br />
<br />
By giving the {{ic|-net nic}} argument to QEMU, it will, by default, assign a virtual machine a network interface with the link-level address {{ic|52:54:00:12:34:56}}. However, when using bridged networking with multiple virtual machines, it is essential that each virtual machine has a unique link-level (MAC) address on the virtual machine side of the tap device. Otherwise, the bridge will not work correctly, because it will receive packets from multiple sources that have the same link-level address. This problem occurs even if the tap devices themselves have unique link-level addresses because the source link-level address is not rewritten as packets pass through the tap device.<br />
<br />
Make sure that each virtual machine has a unique link-level address, but it should always start with {{ic|52:54:}}. Use the following option, replace ''X'' with arbitrary hexadecimal digit:<br />
<br />
$ qemu-system-x86_64 -net nic,macaddr=52:54:''XX:XX:XX:XX'' -net vde ''disk_image''<br />
<br />
Generating unique link-level addresses can be done in several ways:<br />
<br />
<ol><br />
<li>Manually specify unique link-level address for each NIC. The benefit is that the DHCP server will assign the same IP address each time the virtual machine is run, but it is unusable for large number of virtual machines.<br />
</li><br />
<li>Generate random link-level address each time the virtual machine is run. Practically zero probability of collisions, but the downside is that the DHCP server will assign a different IP address each time. You can use the following command in a script to generate random link-level address in a {{ic|macaddr}} variable:<br />
<br />
{{bc|1=<br />
printf -v macaddr "52:54:%02x:%02x:%02x:%02x" $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff )) $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff ))<br />
qemu-system-x86_64 -net nic,macaddr="$macaddr" -net vde ''disk_image''<br />
}}<br />
<br />
</li><br />
<li>Use the following script {{ic|qemu-mac-hasher.py}} to generate the link-level address from the virtual machine name using a hashing function. Given that the names of virtual machines are unique, this method combines the benefits of the aforementioned methods: it generates the same link-level address each time the script is run, yet it preserves the practically zero probability of collisions.<br />
<br />
{{hc|qemu-mac-hasher.py|<nowiki><br />
#!/usr/bin/env python<br />
<br />
import sys<br />
import zlib<br />
<br />
if len(sys.argv) != 2:<br />
print("usage: %s <VM Name>" % sys.argv[0])<br />
sys.exit(1)<br />
<br />
crc = zlib.crc32(sys.argv[1].encode("utf-8")) & 0xffffffff<br />
crc = str(hex(crc))[2:]<br />
print("52:54:%s%s:%s%s:%s%s:%s%s" % tuple(crc))<br />
</nowiki>}}<br />
<br />
In a script, you can use for example:<br />
<br />
vm_name="''VM Name''"<br />
qemu-system-x86_64 -name "$vm_name" -net nic,macaddr=$(qemu-mac-hasher.py "$vm_name") -net vde ''disk_image''<br />
</li><br />
</ol><br />
<br />
=== User-mode networking ===<br />
<br />
By default, without any {{ic|-netdev}} arguments, QEMU will use user-mode networking with a built-in DHCP server. Your virtual machines will be assigned an IP address when they run their DHCP client, and they will be able to access the physical host's network through IP masquerading done by QEMU.<br />
<br />
{{warning|This only works with the TCP and UDP protocols, so ICMP, including {{ic|ping}}, will not work. Do not use {{ic|ping}} to test network connectivity.}}<br />
<br />
This default configuration allows your virtual machines to easily access the Internet, provided that the host is connected to it, but the virtual machines will not be directly visible on the external network, nor will virtual machines be able to talk to each other if you start up more than one concurrently.<br />
<br />
QEMU's user-mode networking can offer more capabilities such as built-in TFTP or SMB servers, redirecting host ports to the guest (for example to allow SSH connections to the guest) or attaching guests to VLANs so that they can talk to each other. See the QEMU documentation on the {{ic|-net user}} flag for more details.<br />
<br />
However, user-mode networking has limitations in both utility and performance. More advanced network configurations require the use of tap devices or other methods.<br />
<br />
{{Note|If the host system uses [[systemd-networkd]], make sure to symlink the {{ic|/etc/resolv.conf}} file as described in [[systemd-networkd#Required services and setup]], otherwise the DNS lookup in the guest system will not work.}}<br />
<br />
=== Tap networking with QEMU ===<br />
<br />
[[wikipedia:TUN/TAP|Tap devices]] are a Linux kernel feature that allows you to create virtual network interfaces that appear as real network interfaces. Packets sent to a tap interface are delivered to a userspace program, such as QEMU, that has bound itself to the interface.<br />
<br />
QEMU can use tap networking for a virtual machine so that packets sent to the tap interface will be sent to the virtual machine and appear as coming from a network interface (usually an Ethernet interface) in the virtual machine. Conversely, everything that the virtual machine sends through its network interface will appear on the tap interface.<br />
<br />
Tap devices are supported by the Linux bridge drivers, so it is possible to bridge together tap devices with each other and possibly with other host interfaces such as {{ic|eth0}}. This is desirable if you want your virtual machines to be able to talk to each other, or if you want other machines on your LAN to be able to talk to the virtual machines.<br />
<br />
{{Warning|If you bridge together tap device and some host interface, such as {{ic|eth0}}, your virtual machines will appear directly on the external network, which will expose them to possible attack. Depending on what resources your virtual machines have access to, you may need to take all the [[Firewalls|precautions]] you normally would take in securing a computer to secure your virtual machines. If the risk is too great, virtual machines have little resources or you set up multiple virtual machines, a better solution might be to use [[#Host-only networking|host-only networking]] and set up NAT. In this case you only need one firewall on the host instead of multiple firewalls for each guest.}}<br />
<br />
As indicated in the user-mode networking section, tap devices offer higher networking performance than user-mode. If the guest OS supports virtio network driver, then the networking performance will be increased considerably as well. Supposing the use of the tap0 device, that the virtio driver is used on the guest, and that no scripts are used to help start/stop networking, next is part of the qemu command one should see:<br />
<br />
-device virtio-net,netdev=network0 -netdev tap,id=network0,ifname=tap0,script=no,downscript=no<br />
<br />
But if already using a tap device with virtio networking driver, one can even boost the networking performance by enabling vhost, like:<br />
<br />
-device virtio-net,netdev=network0 -netdev tap,id=network0,ifname=tap0,script=no,downscript=no,vhost=on<br />
<br />
See http://www.linux-kvm.com/content/how-maximize-virtio-net-performance-vhost-net for more information.<br />
<br />
==== Host-only networking ====<br />
<br />
If the bridge is given an IP address and traffic destined for it is allowed, but no real interface (e.g. {{ic|eth0}}) is connected to the bridge, then the virtual machines will be able to talk to each other and the host system. However, they will not be able to talk to anything on the external network, provided that you do not set up IP masquerading on the physical host. This configuration is called ''host-only networking'' by other virtualization software such as [[VirtualBox]].<br />
<br />
{{Tip|<br />
* If you want to set up IP masquerading, e.g. NAT for virtual machines, see the [[Internet sharing#Enable NAT]] page.<br />
* See [[Network bridge]] for information on creating bridge.<br />
* You may want to have a DHCP server running on the bridge interface to service the virtual network. For example, to use the {{ic|172.20.0.1/16}} subnet with [[dnsmasq]] as the DHCP server:<br />
# ip addr add 172.20.0.1/16 dev br0<br />
# ip link set br0 up<br />
# dnsmasq --interface&#61;br0 --bind-interfaces --dhcp-range&#61;172.20.0.2,172.20.255.254<br />
}}<br />
<br />
==== Internal networking ====<br />
<br />
If you do not give the bridge an IP address and add an [[iptables]] rule to drop all traffic to the bridge in the INPUT chain, then the virtual machines will be able to talk to each other, but not to the physical host or to the outside network. This configuration is called ''internal networking'' by other virtualization software such as [[VirtualBox]]. You will need to either assign static IP addresses to the virtual machines or run a DHCP server on one of them.<br />
<br />
By default iptables would drop packets in the bridge network. You may need to use such iptables rule to allow packets in a bridged network:<br />
<br />
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT<br />
<br />
==== Bridged networking using qemu-bridge-helper ====<br />
<br />
{{Note|This method is available since QEMU 1.1, see http://wiki.qemu.org/Features/HelperNetworking.}}<br />
<br />
This method does not require a start-up script and readily accommodates multiple taps and multiple bridges. It uses {{ic|/usr/lib/qemu/qemu-bridge-helper}} binary, which allows creating tap devices on an existing bridge.<br />
<br />
{{Tip|See [[Network bridge]] for information on creating bridge.}}<br />
<br />
First, create a configuration file containing the names of all bridges to be used by QEMU:<br />
<br />
{{hc|/etc/qemu/bridge.conf|<br />
allow ''bridge0''<br />
allow ''bridge1''<br />
...}}<br />
<br />
Now start the VM. The most basic usage would be:<br />
<br />
$ qemu-system-x86_64 -net nic -net bridge,br=''bridge0'' ''[...]''<br />
<br />
With multiple taps, the most basic usage requires specifying the VLAN for all additional NICs:<br />
<br />
$ qemu-system-x86_64 -net nic -net bridge,br=''bridge0'' -net nic,vlan=1 -net bridge,vlan=1,br=''bridge1'' ''[...]''<br />
<br />
==== Creating bridge manually ====<br />
<br />
{{Style|This section needs serious cleanup and may contain out-of-date information.}}<br />
<br />
{{Tip|Since QEMU 1.1, the [http://wiki.qemu.org/Features/HelperNetworking network bridge helper] can set tun/tap up for you without the need for additional scripting. See [[#Bridged networking using qemu-bridge-helper]].}}<br />
<br />
The following describes how to bridge a virtual machine to a host interface such as {{ic|eth0}}, which is probably the most common configuration. This configuration makes it appear that the virtual machine is located directly on the external network, on the same Ethernet segment as the physical host machine.<br />
<br />
We will replace the normal Ethernet adapter with a bridge adapter and bind the normal Ethernet adapter to it.<br />
<br />
* Install {{Pkg|bridge-utils}}, which provides {{ic|brctl}} to manipulate bridges.<br />
<br />
* Enable IPv4 forwarding:<br />
# sysctl net.ipv4.ip_forward=1<br />
<br />
To make the change permanent, change {{ic|1=net.ipv4.ip_forward = 0}} to {{ic|1=net.ipv4.ip_forward = 1}} in {{ic|/etc/sysctl.d/99-sysctl.conf}}.<br />
<br />
* Load the {{ic|tun}} module and configure it to be loaded on boot. See [[Kernel modules]] for details.<br />
<br />
* Now create the bridge. See [[Bridge with netctl]] for details. Remember to name your bridge as {{ic|br0}}, or change the scripts below to your bridge's name.<br />
<br />
* Create the script that QEMU uses to bring up the tap adapter with {{ic|root:kvm}} 750 permissions:<br />
{{hc|/etc/qemu-ifup|<nowiki><br />
#!/bin/sh<br />
<br />
echo "Executing /etc/qemu-ifup"<br />
echo "Bringing up $1 for bridged mode..."<br />
sudo /usr/bin/ip link set $1 up promisc on<br />
echo "Adding $1 to br0..."<br />
sudo /usr/bin/brctl addif br0 $1<br />
sleep 2<br />
</nowiki>}}<br />
<br />
* Create the script that QEMU uses to bring down the tap adapter in {{ic|/etc/qemu-ifdown}} with {{ic|root:kvm}} 750 permissions:<br />
{{hc|/etc/qemu-ifdown|<nowiki><br />
#!/bin/sh<br />
<br />
echo "Executing /etc/qemu-ifdown"<br />
sudo /usr/bin/ip link set $1 down<br />
sudo /usr/bin/brctl delif br0 $1<br />
sudo /usr/bin/ip link delete dev $1<br />
</nowiki>}}<br />
<br />
* Use {{ic|visudo}} to add the following to your {{ic|sudoers}} file:<br />
{{bc|<nowiki><br />
Cmnd_Alias QEMU=/usr/bin/ip,/usr/bin/modprobe,/usr/bin/brctl<br />
%kvm ALL=NOPASSWD: QEMU<br />
</nowiki>}}<br />
<br />
* You launch QEMU using the following {{ic|run-qemu}} script:<br />
{{hc|run-qemu|<nowiki><br />
#!/bin/bash<br />
USERID=$(whoami)<br />
<br />
# Get name of newly created TAP device; see https://bbs.archlinux.org/viewtopic.php?pid=1285079#p1285079<br />
precreationg=$(/usr/bin/ip tuntap list | /usr/bin/cut -d: -f1 | /usr/bin/sort)<br />
sudo /usr/bin/ip tuntap add user $USERID mode tap<br />
postcreation=$(/usr/bin/ip tuntap list | /usr/bin/cut -d: -f1 | /usr/bin/sort)<br />
IFACE=$(comm -13 <(echo "$precreationg") <(echo "$postcreation"))<br />
<br />
# This line creates a random MAC address. The downside is the DHCP server will assign a different IP address each time<br />
printf -v macaddr "52:54:%02x:%02x:%02x:%02x" $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff )) $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff ))<br />
# Instead, uncomment and edit this line to set a static MAC address. The benefit is that the DHCP server will assign the same IP address.<br />
# macaddr='52:54:be:36:42:a9'<br />
<br />
qemu-system-x86_64 -net nic,macaddr=$macaddr -net tap,ifname="$IFACE" $*<br />
<br />
sudo ip link set dev $IFACE down &> /dev/null<br />
sudo ip tuntap del $IFACE mode tap &> /dev/null<br />
</nowiki>}}<br />
<br />
Then to launch a VM, do something like this<br />
$ run-qemu -hda ''myvm.img'' -m 512<br />
<br />
* It is recommended for performance and security reasons to disable the [http://ebtables.netfilter.org/documentation/bridge-nf.html firewall on the bridge]:<br />
{{hc|/etc/sysctl.d/10-disable-firewall-on-bridge.conf|<nowiki><br />
net.bridge.bridge-nf-call-ip6tables = 0<br />
net.bridge.bridge-nf-call-iptables = 0<br />
net.bridge.bridge-nf-call-arptables = 0<br />
</nowiki>}}<br />
Run {{ic|sysctl -p /etc/sysctl.d/10-disable-firewall-on-bridge.conf}} to apply the changes immediately.<br />
<br />
See the [http://wiki.libvirt.org/page/Networking#Creating_network_initscripts libvirt wiki] and [https://bugzilla.redhat.com/show_bug.cgi?id=512206 Fedora bug 512206]. If you get errors by sysctl during boot about non-existing files, make the {{ic|bridge}} module load at boot. See [[Kernel modules#Automatic module loading with systemd]].<br />
<br />
Alternatively, you can configure [[iptables]] to allow all traffic to be forwarded across the bridge by adding a rule like this:<br />
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT<br />
<br />
==== Network sharing between physical device and a Tap device through iptables ====<br />
<br />
{{Merge|Internet_sharing|Duplication, not specific to QEMU.}}<br />
<br />
Bridged networking works fine between a wired interface (Eg. eth0), and it is easy to setup. However if the host gets connected to the network through a wireless device, then bridging is not possible.<br />
<br />
See [[Network bridge#Wireless interface on a bridge]] as a reference.<br />
<br />
One way to overcome that is to setup a tap device with a static IP, making linux automatically handle the routing for it, and then forward traffic between the tap interface and the device connected to the network through iptables rules.<br />
<br />
See [[Internet sharing]] as a reference.<br />
<br />
There you can find what is needed to share the network between devices, included tap and tun ones. The following just hints further on some of the host configurations required. As indicated in the reference above, the client needs to be configured for a static IP, using the IP assigned to the tap interface as the gateway. The caveat is that the DNS servers on the client might need to be manually edited if they change when changing from one host device connected to the network to another.<br />
<br />
To allow IP forwarding on every boot, one need to add the following lines to sysctl configuration file inside {{ic|/etc/sysctl.d}}:<br />
<br />
net.ipv4.ip_forward = 1<br />
net.ipv6.conf.default.forwarding = 1<br />
net.ipv6.conf.all.forwarding = 1<br />
<br />
The iptables rules can look like:<br />
<br />
# Forwarding from/to outside<br />
iptables -A FORWARD -i ${INT} -o ${EXT_0} -j ACCEPT<br />
iptables -A FORWARD -i ${INT} -o ${EXT_1} -j ACCEPT<br />
iptables -A FORWARD -i ${INT} -o ${EXT_2} -j ACCEPT<br />
iptables -A FORWARD -i ${EXT_0} -o ${INT} -j ACCEPT<br />
iptables -A FORWARD -i ${EXT_1} -o ${INT} -j ACCEPT<br />
iptables -A FORWARD -i ${EXT_2} -o ${INT} -j ACCEPT<br />
# NAT/Masquerade (network address translation)<br />
iptables -t nat -A POSTROUTING -o ${EXT_0} -j MASQUERADE<br />
iptables -t nat -A POSTROUTING -o ${EXT_1} -j MASQUERADE<br />
iptables -t nat -A POSTROUTING -o ${EXT_2} -j MASQUERADE<br />
<br />
The prior supposes there are 3 devices connected to the network sharing traffic with one internal device, where for example:<br />
<br />
INT=tap0<br />
EXT_0=eth0<br />
EXT_1=wlan0<br />
EXT_2=tun0<br />
<br />
The prior shows a forwarding that would allow sharing wired and wireless connections with the tap device.<br />
<br />
The forwarding rules shown are stateless, and for pure forwarding. One could think of restricting specific traffic, putting a firewall in place to protect the guest and others. However those would decrease the networking performance, while a simple bridge does not include any of that.<br />
<br />
Bonus: Whether the connection is wired or wireless, if one gets connected through VPN to a remote site with a tun device, supposing the tun device opened for that connection is tun0, and the prior iptables rules are applied, then the remote connection gets also shared with the guest. This avoids the need for the guest to also open a VPN connection. Again, as the guest networking needs to be static, then if connecting the host remotely this way, one most probably will need to edit the DNS servers on the guest.<br />
<br />
=== Networking with VDE2 ===<br />
<br />
{{Style|This section needs serious cleanup and may contain out-of-date information.}}<br />
<br />
==== What is VDE? ====<br />
<br />
VDE stands for Virtual Distributed Ethernet. It started as an enhancement of [[User-mode Linux|uml]]_switch. It is a toolbox to manage virtual networks.<br />
<br />
The idea is to create virtual switches, which are basically sockets, and to "plug" both physical and virtual machines in them. The configuration we show here is quite simple; However, VDE is much more powerful than this, it can plug virtual switches together, run them on different hosts and monitor the traffic in the switches. You are invited to read [http://wiki.virtualsquare.org/wiki/index.php/Main_Page the documentation of the project].<br />
<br />
The advantage of this method is you do not have to add sudo privileges to your users. Regular users should not be allowed to run modprobe.<br />
<br />
==== Basics ====<br />
<br />
VDE support can be [[pacman|installed]] via the {{Pkg|vde2}} package.<br />
<br />
In our config, we use tun/tap to create a virtual interface on my host. Load the {{ic|tun}} module (see [[Kernel modules]] for details):<br />
<br />
# modprobe tun<br />
<br />
Now create the virtual switch:<br />
<br />
# vde_switch -tap tap0 -daemon -mod 660 -group users<br />
<br />
This line creates the switch, creates {{ic|tap0}}, "plugs" it, and allows the users of the group {{ic|users}} to use it.<br />
<br />
The interface is plugged in but not configured yet. To configure it, run this command:<br />
<br />
# ip addr add 192.168.100.254/24 dev tap0<br />
<br />
Now, you just have to run KVM with these {{ic|-net}} options as a normal user:<br />
<br />
$ qemu-system-x86_64 -net nic -net vde -hda ''[...]''<br />
<br />
Configure networking for your guest as you would do in a physical network.<br />
<br />
{{Tip|You might want to set up NAT on tap device to access the internet from the virtual machine. See [[Internet sharing#Enable NAT]] for more information.}}<br />
<br />
==== Startup scripts ====<br />
<br />
Example of main script starting VDE:<br />
<br />
{{hc|/etc/systemd/scripts/qemu-network-env|<nowiki><br />
#!/bin/sh<br />
# QEMU/VDE network environment preparation script<br />
<br />
# The IP configuration for the tap device that will be used for<br />
# the virtual machine network:<br />
<br />
TAP_DEV=tap0<br />
TAP_IP=192.168.100.254<br />
TAP_MASK=24<br />
TAP_NETWORK=192.168.100.0<br />
<br />
# Host interface<br />
NIC=eth0<br />
<br />
case "$1" in<br />
start)<br />
echo -n "Starting VDE network for QEMU: "<br />
<br />
# If you want tun kernel module to be loaded by script uncomment here<br />
#modprobe tun 2>/dev/null<br />
## Wait for the module to be loaded<br />
#while ! lsmod | grep -q "^tun"; do echo "Waiting for tun device"; sleep 1; done<br />
<br />
# Start tap switch<br />
vde_switch -tap "$TAP_DEV" -daemon -mod 660 -group users<br />
<br />
# Bring tap interface up<br />
ip address add "$TAP_IP"/"$TAP_MASK" dev "$TAP_DEV"<br />
ip link set "$TAP_DEV" up<br />
<br />
# Start IP Forwarding<br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
iptables -t nat -A POSTROUTING -s "$TAP_NETWORK"/"$TAP_MASK" -o "$NIC" -j MASQUERADE<br />
;;<br />
stop)<br />
echo -n "Stopping VDE network for QEMU: "<br />
# Delete the NAT rules<br />
iptables -t nat -D POSTROUTING -s "$TAP_NETWORK"/"$TAP_MASK" -o "$NIC" -j MASQUERADE<br />
<br />
# Bring tap interface down<br />
ip link set "$TAP_DEV" down<br />
<br />
# Kill VDE switch<br />
pgrep vde_switch | xargs kill -TERM<br />
;;<br />
restart|reload)<br />
$0 stop<br />
sleep 1<br />
$0 start<br />
;;<br />
*)<br />
echo "Usage: $0 {start|stop|restart|reload}"<br />
exit 1<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Example of systemd service using the above script:<br />
<br />
{{hc|/etc/systemd/system/qemu-network-env.service|<nowiki><br />
[Unit]<br />
Description=Manage VDE Switch<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/etc/systemd/scripts/qemu-network-env start<br />
ExecStop=/etc/systemd/scripts/qemu-network-env stop<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Change permissions for {{ic|qemu-network-env}} to be executable<br />
<br />
# chmod u+x /etc/systemd/scripts/qemu-network-env<br />
<br />
You can [[start]] {{ic|qemu-network-env.service}} as usual.<br />
<br />
====Alternative method====<br />
<br />
If the above method does not work or you do not want to mess with kernel configs, TUN, dnsmasq, and iptables you can do the following for the same result.<br />
<br />
# vde_switch -daemon -mod 660 -group users<br />
# slirpvde --dhcp --daemon<br />
<br />
Then, to start the VM with a connection to the network of the host:<br />
<br />
$ qemu-system-x86_64 -net nic,macaddr=52:54:00:00:EE:03 -net vde ''disk_image''<br />
<br />
=== VDE2 Bridge ===<br />
<br />
Based on [http://selamatpagicikgu.wordpress.com/2011/06/08/quickhowto-qemu-networking-using-vde-tuntap-and-bridge/ quickhowto: qemu networking using vde, tun/tap, and bridge] graphic. Any virtual machine connected to vde is externally exposed. For example, each virtual machine can receive DHCP configuration directly from your ADSL router.<br />
<br />
==== Basics ====<br />
<br />
Remember that you need {{ic|tun}} module and {{Pkg|bridge-utils}} package.<br />
<br />
Create the vde2/tap device:<br />
<br />
# vde_switch -tap tap0 -daemon -mod 660 -group users<br />
# ip link set tap0 up<br />
<br />
Create bridge:<br />
<br />
# brctl addbr br0<br />
<br />
Add devices:<br />
<br />
# brctl addif br0 eth0<br />
# brctl addif br0 tap0<br />
<br />
And configure bridge interface:<br />
<br />
# dhcpcd br0<br />
<br />
==== Startup scripts ====<br />
<br />
All devices must be set up. And only the bridge needs an IP address. For physical devices on the bridge (e.g. {{ic|eth0}}), this can be done with [[netctl]] using a custom Ethernet profile with:<br />
<br />
{{hc|/etc/netctl/ethernet-noip|<nowiki><br />
Description='A more versatile static Ethernet connection'<br />
Interface=eth0<br />
Connection=ethernet<br />
IP=no<br />
</nowiki>}}<br />
<br />
The following custom systemd service can be used to create and activate a VDE2 tap interface for use in the {{ic|users}} user group.<br />
<br />
{{hc|/etc/systemd/system/vde2@.service|<nowiki><br />
[Unit]<br />
Description=Network Connectivity for %i<br />
Wants=network.target<br />
Before=network.target<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=/usr/bin/vde_switch -tap %i -daemon -mod 660 -group users<br />
ExecStart=/usr/bin/ip link set dev %i up<br />
ExecStop=/usr/bin/ip addr flush dev %i<br />
ExecStop=/usr/bin/ip link set dev %i down<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
And finally, you can create the [[Bridge with netctl|bridge interface with netctl]].<br />
<br />
=== Shorthand configuration ===<br />
<br />
If you're using QEMU with various networking options a lot, you probably have created a lot of {{ic|-netdev}} and {{ic|-device}} argument pairs, which gets quite repetitive. You can instead use the {{ic|-nic}} argument to combine {{ic|-netdev}} and {{ic|-device}} together, so that, for example, these arguments:<br />
<br />
-netdev tap,id=network0,ifname=tap0,script=no,downscript=no,vhost=on -device virtio-net,netdev=network0<br />
<br />
...become:<br />
<br />
-nic tap,ifname=tap0,script=no,downscript=no,vhost=on,model=virtio-net<br />
<br />
Notice the lack of network IDs, and that the device was created with {{ic|<nowiki>model=...</nowiki>}}. The first half of the {{ic|-nic}} parameters are {{ic|-netdev}} parameters, whereas the second half (after {{ic|<nowiki>model=...</nowiki>}}) are related with the device. The same parameters (for example, {{ic|<nowiki>smb=...</nowiki>}}) are used. There's also a special parameter for {{ic|-nic}} which completely disables the default (user-mode) networking:<br />
<br />
-nic none<br />
<br />
See [https://qemu.weilnetz.de/doc/qemu-doc.html#Network-options QEMU networking documentation] for more information on parameters you can use.<br />
<br />
== Graphic card ==<br />
<br />
QEMU can emulate several types of VGA card. The card type is passed in the {{ic|-vga ''type''}} command line option and can be {{ic|std}}, {{ic|qxl}}, {{ic|vmware}}, {{ic|virtio}}, {{ic|cirrus}} or {{ic|none}}.<br />
<br />
=== std ===<br />
<br />
With {{ic|-vga std}} you can get a resolution of up to 2560 x 1600 pixels without requiring guest drivers. This is the default since QEMU 2.2.<br />
<br />
=== qxl ===<br />
<br />
QXL is a paravirtual graphics driver with 2D support. To use it, pass the {{ic|-vga qxl}} option and install drivers in the guest. You may want to use [[#SPICE]] for improved graphical performance when using QXL.<br />
<br />
On Linux guests, the {{ic|qxl}} and {{ic|bochs_drm}} kernel modules must be loaded in order to gain a decent performance.<br />
<br />
Default VGA memory size for QXL devices is 16M which is sufficient to drive resolutions approximately up to QHD (2560x1440). To enable higher resolutions, [[#Multi-monitor_support|increase vga_memmb]].<br />
<br />
=== vmware ===<br />
<br />
Although it is a bit buggy, it performs better than std and cirrus. Install the VMware drivers {{Pkg|xf86-video-vmware}} and {{Pkg|xf86-input-vmmouse}} for Arch Linux guests.<br />
<br />
=== virtio ===<br />
<br />
{{ic|virtio-vga}} / {{ic|virtio-gpu}} is a paravirtual 3D graphics driver based on [https://virgil3d.github.io/ virgl]. Currently a work in progress, supporting only very recent (>= 4.4) Linux guests with {{Pkg|mesa}} (>=11.2) compiled with the option {{ic|1=gallium-drivers=virgl}}.<br />
<br />
To enable 3D acceleration on the guest system select this vga with {{ic|-vga virtio}} and enable the opengl context in the display device with {{ic|1=-display sdl,gl=on}} or {{ic|1=-display gtk,gl=on}} for the sdl and gtk display output respectively. Successful configuration can be confirmed looking at the kernel log in the guest:<br />
<br />
{{hc|$ dmesg {{!}} grep drm |<br />
[drm] pci: virtio-vga detected<br />
[drm] virgl 3d acceleration enabled<br />
}}<br />
<br />
=== cirrus ===<br />
<br />
The cirrus graphical adapter was the default [http://wiki.qemu.org/ChangeLog/2.2#VGA before 2.2]. It [https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/ should not] be used on modern systems.<br />
<br />
=== none ===<br />
<br />
This is like a PC that has no VGA card at all. You would not even be able to access it with the {{ic|-vnc}} option. Also, this is different from the {{ic|-nographic}} option which lets QEMU emulate a VGA card, but disables the SDL display.<br />
<br />
== SPICE ==<br />
The [http://spice-space.org/ SPICE project] aims to provide a complete open source solution for remote access to virtual machines in a seamless way. SPICE can only be used when using [[#qxl]] as the graphical output.<br />
=== Enabling SPICE via the command line ===<br />
The following is example of booting with SPICE as the remote desktop protocol, including the support for copy and paste from host:<br />
<br />
$ qemu-system-x86_64 -vga qxl -device virtio-serial-pci -spice port=5930,disable-ticketing -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent<br />
<br />
The parameters have the following meaning:<br />
# {{ic|-device virtio-serial-pci}} adds a virtio-serial device<br />
# {{ic|1=-device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0}} opens a port for spice vdagent in the virtio-serial device,<br />
# {{ic|1=-chardev spicevmc,id=spicechannel0,name=vdagent}} adds a spicevmc chardev for that port. It is important that the {{ic|1=chardev=}} option of the {{ic|virtserialport}} device matches the {{ic|1=id=}} option given to the {{ic|chardev}} option ({{ic|spicechannel0}} in this example). It is also important that the port name is {{ic|com.redhat.spice.0}}, because that is the namespace where vdagent is looking for in the guest. And finally, specify {{ic|1=name=vdagent}} so that spice knows what this channel is for.''<br />
{{Tip|<br />
* Since QEMU in SPICE mode acts similarly to a remote desktop server, it may be more convenient to run QEMU in daemon mode with the {{ic|-daemonize}} parameter.<br />
* Using [[wikipedia:Unix_socket|Unix sockets]] instead of TCP ports does not involve using network stack on the host system, so it is [https://unix.stackexchange.com/questions/91774/performance-of-unix-sockets-vs-tcp-ports reportedly] better for performance. Example:<br />
{{bc|1=$ qemu-system-x86_64 -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -spice unix,addr=/tmp/vm_spice.socket,disable-ticketing}}<br />
Then connect with {{ic|$ remote-viewer spice+unix:///tmp/vm_spice.socket}} or with {{ic|1=$ spicy --uri="spice+unix:///tmp/vm_spice.socket"}}.<br />
}}<br />
<br />
=== Connect to the guest with a SPICE client ===<br />
A SPICE client is necessary to connect to the guest. In Arch, the following clients are available:<br />
<br />
{{App|virt-viewer|is the recommended SPICE client by the protocol developers|run it with {{ic|$ remote-viewer spice://127.0.0.1:5930}}|{{Pkg|virt-viewer}}}}<br />
<br />
{{App|spice-gtk|is a GTK+ client which can also be used|run it with {{ic|$ spicy -h 127.0.0.1 -p 5930}}|{{Pkg|spice-gtk}}}}<br />
<br />
{{Tip|To connect to the guest through SSH tunelling, the following type of command can be used: {{bc|$ ssh -fL 5999:localhost:5930 ''my.domain.org'' sleep 10; spicy -h 127.0.0.1 -p 5999}}<br />
This example connects ''spicy'' to the local port {{ic|5999}} which is forwarded through SSH to the guest's SPICE server located at the address ''my.domain.org'', port {{ic|5930}}.<br />
Note the {{ic|-f}} option that requests ssh to execute the command {{ic|sleep 10}} in the background. This way, the ssh session runs while the client is active and auto-closes once the client ends.<br />
}}<br />
<br />
For clients that run on smartphone or on other platforms, refer to the ''Other clients'' section in [http://www.spice-space.org/download.html spice-space download].<br />
<br />
=== SPICE support on the guest ===<br />
For '''Arch Linux guests''', for improved support for multiple monitors or clipboard sharing, the following packages should be installed:<br />
* {{Pkg|spice-vdagent}}: Spice agent xorg client that enables copy and paste between client and X-session and more. [[Enable]] {{ic|spice-vdagentd.service}} after installation.<br />
* {{Pkg|xf86-video-qxl}}: Xorg X11 qxl video driver<br />
For guests under '''other operating systems''', refer to the ''Guest'' section in [http://www.spice-space.org/download.html spice-space download].<br />
<br />
=== Password authentication with SPICE ===<br />
If you want to enable password authentication with SPICE you need to remove {{ic|disable-ticketing}} from the {{ic|-spice}} argument and instead add {{ic|1=password=''yourpassword''}}. For example:<br />
<br />
$ qemu-system-x86_64 -vga qxl -spice port=5900,password=''yourpassword'' -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent<br />
<br />
Your SPICE client should now ask for the password to be able to connect to the SPICE server.<br />
<br />
=== TLS encrypted communication with SPICE ===<br />
<br />
You can also configure TLS encryption for communicating with the SPICE server. First, you need to have a directory which contains the following files (the names must be exactly as indicated):<br />
* {{ic|ca-cert.pem}}: the CA master certificate.<br />
* {{ic|server-cert.pem}}: the server certificate signed with {{ic|ca-cert.pem}}.<br />
* {{ic|server-key.pem}}: the server private key.<br />
<br />
An example of generation of self-signed certificates with your own generated CA for your server is shown in the [https://www.spice-space.org/spice-user-manual.html#_generating_self_signed_certificates Spice User Manual].<br />
<br />
Afterwards, you can run QEMU with SPICE as explained above but using the following {{ic|-spice}} argument: {{ic|1=-spice tls-port=5901,password=''yourpassword'',x509-dir=''/path/to/pki_certs''}}, where {{ic|''/path/to/pki_certs''}} is the directory path that contains the three needed files shown earlier.<br />
<br />
It is now possible to connect to the server using {{pkg|virt-viewer}}:<br />
<br />
$ remote-viewer spice://''hostname''?tls-port=5901 --spice-ca-file=''/path/to/ca-cert.pem'' --spice-host-subject="C=''XX'',L=''city'',O=''organization'',CN=''hostname''" --spice-secure-channels=all<br />
<br />
Keep in mind that the {{ic|--spice-host-subject}} parameter needs to be set according to your {{ic|server-cert.pem}} subject. You also need to copy {{ic|ca-cert.pem}} to every client to verify the server certificate.<br />
<br />
{{Tip|You can get the subject line of the server certificate in the correct format for {{ic|--spice-host-subject}} (with entries separated by commas) using the following command: {{bc|<nowiki>$ openssl x509 -noout -subject -in server-cert.pem | cut -d' ' -f2- | sed 's/\///' | sed 's/\//,/g'</nowiki>}}<br />
}}<br />
<br />
The equivalent {{Pkg|spice-gtk}} command is:<br />
<br />
$ spicy -h ''hostname'' -s 5901 --spice-ca-file=ca-cert.pem --spice-host-subject="C=''XX'',L=''city'',O=''organization'',CN=''hostname''" --spice-secure-channels=all<br />
<br />
== VNC ==<br />
<br />
One can add the {{ic|-vnc :''X''}} option to have QEMU redirect the VGA display to the VNC session. Substitute {{ic|''X''}} for the number of the display (0 will then listen on 5900, 1 on 5901...).<br />
<br />
$ qemu-system-x86_64 -vnc :0<br />
<br />
An example is also provided in the [[#Starting QEMU virtual machines on boot]] section.<br />
{{Warning|The default VNC server setup does not use any form of authentication. Any user can connect from any host.}}<br />
<br />
=== Basic password authentication ===<br />
<br />
An access password can be setup easily by using the {{ic|password}} option. The password must be indicated in the QEMU monitor and connection is only possible once the password is provided.<br />
<br />
$ qemu-system-x86_64 -vnc :0,password -monitor stdio<br />
<br />
In the QEMU monitor, password is set using the command {{ic|change vnc password}} and then indicating the password.<br />
<br />
Alternatively if one create the following file:<br />
<br />
{{hc|vncpassword.txt|change vnc password<br />
''mykvmvncpassword''}}<br />
<br />
The following command line directly runs vnc with a password:<br />
<br />
$ cat vncpassword.txt | qemu-system-x86_64 -vnc :0,password -monitor stdio<br />
<br />
{{Note|The password is limited to 8 characters and can be guessed through brute force attack. More elaborated protection is strongly recommended for public network.}}<br />
<br />
== Audio ==<br />
<br />
=== Host ===<br />
<br />
The audio driver used by QEMU is set with the {{ic|QEMU_AUDIO_DRV}} environment variable:<br />
<br />
$ export QEMU_AUDIO_DRV=pa<br />
<br />
Run the following command to get QEMU's configuration options related to PulseAudio:<br />
<br />
$ qemu-system-x86_64 -audio-help | awk '/Name: pa/' RS=<br />
<br />
The listed options can be exported as environment variables, for example:<br />
<br />
{{bc|1=<br />
$ export QEMU_PA_SINK=alsa_output.pci-0000_04_01.0.analog-stereo.monitor<br />
$ export QEMU_PA_SOURCE=input<br />
}}<br />
<br />
=== Guest ===<br />
To get list of the supported emulation audio drivers:<br />
$ qemu-system-x86_64 -soundhw help<br />
<br />
To use e.g. {{ic|hda}} driver for the guest use the {{ic|-soundhw hda}} command with QEMU.<br />
<br />
{{Note|Video graphic card emulated drivers for the guest machine may also cause a problem with the sound quality. Test one by one to make it work. You can list possible options with {{ic|<nowiki>qemu-system-x86_64 -h | grep vga</nowiki>}}.}}<br />
<br />
== Installing virtio drivers ==<br />
<br />
QEMU offers guests the ability to use paravirtualized block and network devices using the [http://wiki.libvirt.org/page/Virtio virtio] drivers, which provide better performance and lower overhead.<br />
<br />
* A virtio block device requires the option {{Ic|-drive}} for passing a disk image, with parameter {{Ic|1=if=virtio}}:<br />
$ qemu-system-x86_64 -boot order=c -drive file=''disk_image'',if=virtio<br />
<br />
* Almost the same goes for the network:<br />
$ qemu-system-x86_64 -net nic,model=virtio<br />
<br />
{{Note|This will only work if the guest machine has drivers for virtio devices. Linux does, and the required drivers are included in Arch Linux, but there is no guarantee that virtio devices will work with other operating systems.}}<br />
<br />
=== Preparing an (Arch) Linux guest ===<br />
<br />
To use virtio devices after an Arch Linux guest has been installed, the following modules must be loaded in the guest: {{Ic|virtio}}, {{Ic|virtio_pci}}, {{Ic|virtio_blk}}, {{Ic|virtio_net}}, and {{Ic|virtio_ring}}. For 32-bit guests, the specific "virtio" module is not necessary.<br />
<br />
If you want to boot from a virtio disk, the initial ramdisk must contain the necessary modules. By default, this is handled by [[mkinitcpio]]'s {{ic|autodetect}} hook. Otherwise use the {{ic|MODULES}} array in {{ic|/etc/mkinitcpio.conf}} to include the necessary modules and rebuild the initial ramdisk.<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=(virtio virtio_blk virtio_pci virtio_net)}}<br />
<br />
Virtio disks are recognized with the prefix {{ic|'''v'''}} (e.g. {{ic|'''v'''da}}, {{ic|'''v'''db}}, etc.); therefore, changes must be made in at least {{ic|/etc/fstab}} and {{ic|/boot/grub/grub.cfg}} when booting from a virtio disk.<br />
<br />
{{Tip|When referencing disks by [[UUID]] in both {{ic|/etc/fstab}} and bootloader, nothing has to be done.}}<br />
<br />
Further information on paravirtualization with KVM can be found [http://www.linux-kvm.org/page/Boot_from_virtio_block_device here].<br />
<br />
You might also want to install {{Pkg|qemu-guest-agent}} to implement support for QMP commands that will enhance the hypervisor management capabilities. After installing the package you can enable and start the {{ic|qemu-ga.service}}.<br />
<br />
=== Preparing a Windows guest ===<br />
<br />
{{Note|1=The only (reliable) way to upgrade a Windows 8.1 guest to Windows 10 seems to be to temporarily choose cpu core2duo,nx for the install [http://ubuntuforums.org/showthread.php?t=2289210]. After the install, you may revert to other cpu settings (8/8/2015).}}<br />
<br />
==== Block device drivers ====<br />
<br />
===== New Install of Windows =====<br />
<br />
Windows does not come with the virtio drivers. Therefore, you will need to load them during installation. There are basically two ways to do this: via Floppy Disk or via ISO files. Both images can be downloaded from the [https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso Fedora repository].<br />
<br />
The floppy disk option is difficult because you will need to press F6 (Shift-F6 on newer Windows) at the very beginning of powering on the QEMU. This is difficult since you need time to connect your VNC console window. You can attempt to add a delay to the boot sequence. See {{man|1|qemu}} for more details about applying a delay at boot.<br />
<br />
The ISO option to load drivers is the preferred way, but it is available only on Windows Vista and Windows Server 2008 and later. The procedure is to load the image with virtio drivers in an additional cdrom device along with the primary disk device and Windows installer:<br />
<br />
$ qemu-system-x86_64 ... \<br />
-drive file=''/path/to/primary/disk.img'',index=0,media=disk,if=virtio \<br />
-drive file=''/path/to/installer.iso'',index=2,media=cdrom \<br />
-drive file=''/path/to/virtio.iso'',index=3,media=cdrom \<br />
...<br />
<br />
During the installation, the Windows installer will ask you for your Product key and perform some additional checks. When it gets to the "Where do you want to install Windows?" screen, it will give a warning that no disks are found. Follow the example instructions below (based on Windows Server 2012 R2 with Update).<br />
<br />
* Select the option {{ic|Load Drivers}}.<br />
* Uncheck the box for "Hide drivers that aren't compatible with this computer's hardware".<br />
* Click the Browse button and open the CDROM for the virtio iso, usually named "virtio-win-XX".<br />
* Now browse to {{ic|E:\viostor\[your-os]\amd64}}, select it, and press OK.<br />
* Click Next<br />
<br />
You should now see your virtio disk(s) listed here, ready to be selected, formatted and installed to.<br />
<br />
===== Change Existing Windows VM to use virtio =====<br />
Modifying an existing Windows guest for booting from virtio disk is a bit tricky.<br />
<br />
You can download the virtio disk driver from the [https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso Fedora repository].<br />
<br />
Now you need to create a new disk image, which will force Windows to search for the driver. For example:<br />
<br />
$ qemu-img create -f qcow2 ''fake.qcow2'' 1G<br />
<br />
Run the original Windows guest (with the boot disk still in IDE mode) with the fake disk (in virtio mode) and a CD-ROM with the driver.<br />
<br />
$ qemu-system-x86_64 -m 512 -drive file=''windows_disk_image'',if=ide -drive file=''fake.qcow2'',if=virtio -cdrom virtio-win-0.1-81.iso<br />
<br />
Windows will detect the fake disk and try to find a driver for it. If it fails, go to the ''Device Manager'', locate the SCSI drive with an exclamation mark icon (should be open), click ''Update driver'' and select the virtual CD-ROM. Do not navigate to the driver folder within the CD-ROM, simply select the CD-ROM drive and Windows will find the appropriate driver automatically (tested for Windows 7 SP1). Do not forget to select the checkbox which says to search for directories recursively.<br />
<br />
When the installation is successful, you can turn off the virtual machine and launch it again, now with the boot disk attached in virtio mode:<br />
<br />
$ qemu-system-x86_64 -m 512 -drive file=''windows_disk_image'',if=virtio<br />
<br />
{{Note|If you encounter the Blue Screen of Death, make sure you did not forget the {{ic|-m}} parameter, and that you do not boot with virtio instead of ide for the system drive before drivers are installed.}}<br />
<br />
==== Network drivers ====<br />
<br />
Installing virtio network drivers is a bit easier, simply add the {{ic|-net}} argument as explained above.<br />
<br />
$ qemu-system-x86_64 -m 512 -drive file=''windows_disk_image'',if=virtio -net nic,model=virtio -cdrom virtio-win-0.1-74.iso<br />
<br />
Windows will detect the network adapter and try to find a driver for it. If it fails, go to the ''Device Manager'', locate the network adapter with an exclamation mark icon (should be open), click ''Update driver'' and select the virtual CD-ROM. Do not forget to select the checkbox which says to search for directories recursively.<br />
<br />
==== Balloon driver ====<br />
<br />
If you want to track you guest memory state (for example via {{ic|virsh}} command {{ic|dommemstat}}) or change guest's memory size in runtime (you still won't be able to change memory size, but can limit memory usage via inflating balloon driver) you will need to install guest balloon driver.<br />
<br />
For this you will need to go to ''Device Manager'', locate ''PCI standard RAM Controller'' in ''System devices'' (or unrecognized PCI controller from ''Other devices'') and choose ''Update driver''. In opened window you will need to choose ''Browse my computer...'' and select the CD-ROM (and don't forget the ''Include subdirectories'' checkbox). Reboot after installation. This will install the driver and you will be able to inflate the balloon (for example via hmp command {{ic|balloon ''memory_size''}}, which will cause balloon to take as much memory as possible in order to shrink the guest's available memory size to ''memory_size''). However, you still won't be able to track guest memory state. In order to do this you will need to install ''Balloon'' service properly. For that open command line as administrator, go to the CD-ROM, ''Balloon'' directory and deeper, depending on your system and architecture. Once you are in ''amd64'' (''x86'') directory, run {{ic|blnsrv.exe -i}} which will do the installation. After that {{ic|virsh}} command {{ic|dommemstat}} should be outputting all supported values.<br />
<br />
=== Preparing a FreeBSD guest ===<br />
<br />
Install the {{ic|emulators/virtio-kmod}} port if you are using FreeBSD 8.3 or later up until 10.0-CURRENT where they are included into the kernel. After installation, add the following to your {{ic|/boot/loader.conf}} file:<br />
<br />
{{bc|<nowiki><br />
virtio_load="YES"<br />
virtio_pci_load="YES"<br />
virtio_blk_load="YES"<br />
if_vtnet_load="YES"<br />
virtio_balloon_load="YES"<br />
</nowiki>}}<br />
<br />
Then modify your {{ic|/etc/fstab}} by doing the following:<br />
<br />
{{bc|<nowiki><br />
sed -i bak "s/ada/vtbd/g" /etc/fstab<br />
</nowiki>}}<br />
<br />
And verify that {{ic|/etc/fstab}} is consistent. If anything goes wrong, just boot into a rescue CD and copy {{ic|/etc/fstab.bak}} back to {{ic|/etc/fstab}}.<br />
<br />
== QEMU monitor ==<br />
<br />
While QEMU is running, a monitor console is provided in order to provide several ways to interact with the virtual machine running. The QEMU monitor offers interesting capabilities such as obtaining information about the current virtual machine, hotplugging devices, creating snapshots of the current state of the virtual machine, etc. To see the list of all commands, run {{ic|help}} or {{ic|?}} in the QEMU monitor console or review the relevant section of the [https://qemu.weilnetz.de/doc/qemu-doc.html#pcsys_005fmonitor official QEMU documentation].<br />
<br />
=== Accessing the monitor console ===<br />
<br />
When using the {{ic|std}} default graphics option, one can access the QEMU monitor by pressing {{ic|Ctrl+Alt+2}} or by clicking ''View > compatmonitor0'' in the QEMU window. To return to the virtual machine graphical view either press {{ic|Ctrl+Alt+1}} or click ''View > VGA''.<br />
<br />
However, the standard method of accessing the monitor is not always convenient and does not work in all graphic outputs QEMU supports. Alternative options of accessing the monitor are described below:<br />
<br />
* [[telnet]]: Run QEMU with the {{ic|-monitor telnet:127.0.0.1:''port'',server,nowait}} parameter. When the virtual machine is started you will be able to access the monitor via telnet:<br />
$ telnet 127.0.0.1 ''port''<br />
{{Note|If {{ic|127.0.0.1}} is specified as the IP to listen it will be only possible to connect to the monitor from the same host QEMU is running on. If connecting from remote hosts is desired, QEMU must be told to listen {{ic|0.0.0.0}} as follows: {{ic|-monitor telnet:0.0.0.0:''port'',server,nowait}}. Keep in mind that it is recommended to have a [[firewall]] configured in this case or make sure your local network is completely trustworthy since this connection is completely unauthenticated and unencrypted.}}<br />
<br />
* UNIX socket: Run QEMU with the {{ic|-monitor unix:''socketfile'',server,nowait}} parameter. Then you can connect with either {{pkg|socat}} or {{pkg|openbsd-netcat}}.<br />
<br />
For example, if QEMU is run via:<br />
<br />
$ qemu-system-x86_64 ''[...]'' -monitor unix:/tmp/monitor.sock,server,nowait ''[...]''<br />
<br />
It is possible to connect to the monitor with:<br />
<br />
$ socat - UNIX-CONNECT:/tmp/monitor.sock<br />
<br />
Or with:<br />
<br />
$ nc -U /tmp/monitor.sock<br />
<br />
* TCP: You can expose the monitor over TCP with the argument {{ic|-monitor tcp:127.0.0.1:''port'',server,nowait}}. Then connect with netcat, either {{pkg|openbsd-netcat}} or {{pkg|gnu-netcat}} by running:<br />
<br />
$ nc 127.0.0.1 ''port''<br />
<br />
{{Note|In order to be able to connect to the tcp socket from other devices other than the same host QEMU is being run on you need to listen to {{ic|0.0.0.0}} like explained in the telnet case. The same security warnings apply in this case as well.}}<br />
<br />
* Standard I/O: It is possible to access the monitor automatically from the same terminal QEMU is being run by running it with the argument {{ic|-monitor stdio}}.<br />
<br />
=== Sending keyboard presses to the virtual machine using the monitor console ===<br />
<br />
Some combinations of keys may be difficult to perform on virtual machines due to the host intercepting them instead in some configurations (a notable example is the {{ic|Ctrl+Alt+F*}} key combinations, which change the active tty). To avoid this problem, the problematic combination of keys may be sent via the monitor console instead. Switch to the monitor and use the {{ic|sendkey}} command to forward the necessary keypresses to the virtual machine. For example:<br />
<br />
(qemu) sendkey ctrl-alt-f2<br />
<br />
=== Creating and managing snapshots via the monitor console ===<br />
<br />
{{Note|This feature will '''only''' work when the virtual machine disk image is in ''qcow2'' format. It will not work with ''raw'' images.}}<br />
<br />
It is sometimes desirable to save the current state of a virtual machine and having the possibility of reverting the state of the virtual machine to that of a previously saved snapshot at any time. The QEMU monitor console provides the user with the necessary utilities to create snapshots, manage them, and revert the machine state to a saved snapshot.<br />
<br />
* Use {{ic|savevm ''name''}} in order to create a snapshot with the tag ''name''.<br />
* Use {{ic|loadvm ''name''}} to revert the virtual machine to the state of the snapshot ''name''.<br />
* Use {{ic|delvm ''name''}} to delete the snapshot tagged as ''name''.<br />
* Use {{ic|info snapshots}} to see a list of saved snapshots. Snapshots are identified by both an auto-incremented ID number and a text tag (set by the user on snapshot creation).<br />
<br />
=== Running the virtual machine in immutable mode ===<br />
<br />
It is possible to run a virtual machine in a frozen state so that all changes will be discarded when the virtual machine is powered off just by running QEMU with the {{ic|-snapshot}} parameter. When the disk image is written by the guest, changes will be saved in a temporary file in {{ic|/tmp}} and will be discarded when QEMU halts.<br />
<br />
However, if a machine is running in frozen mode it is still possible to save the changes to the disk image if it is afterwards desired by using the monitor console and running the following command:<br />
<br />
(qemu) commit all<br />
<br />
If snapshots are created when running in frozen mode they will be discarded as soon as QEMU is exited unless changes are explicitly commited to disk, as well.<br />
<br />
=== Pause and power options via the monitor console ===<br />
<br />
Some operations of a physical machine can be emulated by QEMU using some monitor commands:<br />
<br />
* {{ic|system_powerdown}} will send an ACPI shutdown request to the virtual machine. This effect is similar to the power button in a physical machine.<br />
* {{ic|system_reset}} will reset the virtual machine similarly to a reset button in a physical machine. This operation can cause data loss and file system corruption since the virtual machine is not cleanly restarted.<br />
* {{ic|stop}} will pause the virtual machine.<br />
* {{ic|cont}} will resume a virtual machine previously paused.<br />
<br />
=== Taking screenshots of the virtual machine ===<br />
<br />
Screenshots of the virtual machine graphic display can be obtained in the PPM format by running the following command in the monitor console:<br />
<br />
(qemu) screendump ''file.ppm''<br />
<br />
== QEMU machine protocol ==<br />
<br />
The QEMU machine protocol (QMP) is a JSON-based protocol which allows applications to control a QEMU instance. Similarly to the [[#QEMU monitor]] it offers ways to interact with a running machine and the JSON protocol allows to do it programmatically. The description of all the QMP commands can be found in [https://raw.githubusercontent.com/coreos/qemu/master/qmp-commands.hx qmp-commands].<br />
<br />
=== Start QMP ===<br />
<br />
The usual way to control the guest using the QMP protocol, is to open a TCP socket when launching the machine using the {{ic|-qmp}} option. Here it is using for example the TCP port 4444:<br />
<br />
$ qemu-system-x86_64 ''[...]'' -qmp tcp:localhost:4444,server,nowait<br />
<br />
Then one way to communicate with the QMP agent is to use [[netcat]]:<br />
<br />
{{hc|nc localhost 4444|{"QMP": {"version": {"qemu": {"micro": 0, "minor": 1, "major": 3}, "package": ""}, "capabilities": []} } }}<br />
<br />
At this stage, the only command that can be recognized is {{ic|qmp_capabilities}}, so that QMP enters into command mode. Type:<br />
<br />
{"execute": "qmp_capabilities"}<br />
<br />
Now, QMP is ready to receive commands, to retrieve the list of recognized commands, use:<br />
<br />
{"execute": "query-commands"}<br />
<br />
=== Live merging of child image into parent image ===<br />
<br />
It is possible to merge a running snapshot into its parent by issuing a {{ic|block-commit}} command. In its simplest form the following line will commit the child into its parent:<br />
{"execute": "block-commit", "arguments": {"device": "''devicename''"}}<br />
<br />
Upon reception of this command, the handler looks for the base image and converts it from read only to read write mode and then runs the commit job.<br />
<br />
Once the ''block-commit'' operation has completed, the event {{ic|BLOCK_JOB_READY}} will be emitted, signalling that the synchronization has finished. The job can then be gracefully completed by issuing the command {{ic|block-job-complete}}:<br />
<br />
{"execute": "block-job-complete", "arguments": {"device": "''devicename''"}}<br />
<br />
Until such a command is issued, the ''commit'' operation remains active.<br />
After successful completion, the base image remains in read write mode and becomes the new active layer. On the other hand, the child image becomes invalid and it is the responsibility of the user to clean it up.<br />
<br />
{{Tip|The list of device and their names can be retrieved by executing the command {{ic|query-block}} and parsing the results. The device name is in the {{ic|device}} field, for example {{ic|ide0-hd0}} for the hard disk in this example: {{hc|{"execute": "query-block"}|{"return": [{"io-status": "ok", "device": "'''ide0-hd0'''", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 27074281472, "filename": "parent.qcow2", ... } }} }}<br />
<br />
=== Live creation of a new snapshot ===<br />
To create a new snapshot out of a running image, run the command:<br />
{"execute": "blockdev-snapshot-sync", "arguments": {"device": "''devicename''","snapshot-file": "''new_snapshot_name''.qcow2"}}<br />
<br />
This creates an overlay file named {{ic|''new_snapshot_name''.qcow2}} which then becomes the new active layer.<br />
<br />
== Tips and tricks ==<br />
=== Improve virtual machine performance ===<br />
<br />
There are a number of techniques that you can use to improve the performance of the virtual machine. For example:<br />
<br />
* Use the {{ic|-cpu host}} option to make QEMU emulate the host's exact CPU. If you do not do this, it may be trying to emulate a more generic CPU.<br />
* Especially for Windows guests, enable [http://blog.wikichoon.com/2014/07/enabling-hyper-v-enlightenments-with-kvm.html Hyper-V enlightenments]: {{ic|1=-cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time}}.<br />
* If the host machine has multiple cores, assign the guest more cores using the {{ic|-smp}} option.<br />
* Make sure you have assigned the virtual machine enough memory. By default, QEMU only assigns 128 MiB of memory to each virtual machine. Use the {{ic|-m}} option to assign more memory. For example, {{ic|-m 1024}} runs a virtual machine with 1024 MiB of memory.<br />
* Use KVM if possible: add {{ic|1=-machine type=pc,accel=kvm}} to the QEMU start command you use.<br />
* If supported by drivers in the guest operating system, use [http://wiki.libvirt.org/page/Virtio virtio] for network and/or block devices. For example:<br />
$ qemu-system-x86_64 -net nic,model=virtio -net tap,if=tap0,script=no -drive file=''disk_image'',media=disk,if=virtio<br />
* Use TAP devices instead of user-mode networking. See [[#Tap networking with QEMU]].<br />
* If the guest OS is doing heavy writing to its disk, you may benefit from certain mount options on the host's file system. For example, you can mount an [[Ext4|ext4 file system]] with the option {{ic|1=barrier=0}}. You should read the documentation for any options that you change because sometimes performance-enhancing options for file systems come at the cost of data integrity.<br />
* If you have a raw disk image, you may want to disable the cache:<br />
$ qemu-system-x86_64 -drive file=''disk_image'',if=virtio,'''cache=none'''<br />
* Use the native Linux AIO:<br />
$ qemu-system-x86_64 -drive file=''disk_image'',if=virtio''',aio=native,cache.direct=on'''<br />
* If you use a qcow2 disk image, I/O performance can be improved considerably by ensuring that the L2 cache is of sufficient size. The [https://blogs.igalia.com/berto/2015/12/17/improving-disk-io-performance-in-qemu-2-5-with-the-qcow2-l2-cache/ formula] to calculate L2 cache is: l2_cache_size = disk_size * 8 / cluster_size. Assuming the qcow2 image was created with the default cluster size of 64K, this means that for every 8 GB in size of the qcow2 image, 1 MB of L2 cache is best for performance. Only 1 MB is used by QEMU by default; specifying a larger cache is done on the QEMU command line. For instance, to specify 4 MB of cache (suitable for a 32 GB disk with a cluster size of 64K):<br />
$ qemu-system-x86_64 -drive file=''disk_image'',format=qcow2,l2-cache-size=4M<br />
* If you are running multiple virtual machines concurrently that all have the same operating system installed, you can save memory by enabling [[wikipedia:Kernel_SamePage_Merging_(KSM)|kernel same-page merging]]. See [[#Enabling KSM]].<br />
* In some cases, memory can be reclaimed from running virtual machines by running a memory ballooning driver in the guest operating system and launching QEMU using {{ic|-device virtio-balloon}}.<br />
* It is possible to use a emulation layer for an ICH-9 AHCI controller (although it may be unstable). The AHCI emulation supports [[Wikipedia:Native_Command_Queuing|NCQ]], so multiple read or write requests can be outstanding at the same time:<br />
$ qemu-system-x86_64 -drive id=disk,file=''disk_image'',if=none -device ich9-ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0<br />
<br />
See http://www.linux-kvm.org/page/Tuning_KVM for more information.<br />
<br />
=== Starting QEMU virtual machines on boot ===<br />
<br />
==== With libvirt ====<br />
<br />
If a virtual machine is set up with [[libvirt]], it can be configured with {{ic|virsh autostart}} or through the ''virt-manager'' GUI to start at host boot by going to the Boot Options for the virtual machine and selecting "Start virtual machine on host boot up".<br />
<br />
==== With systemd service ====<br />
<br />
To run QEMU VMs on boot, you can use following systemd unit and config.<br />
<br />
{{hc|/etc/systemd/system/qemu@.service|2=<br />
[Unit]<br />
Description=QEMU virtual machine<br />
<br />
[Service]<br />
Environment="type=system-x86_64" "haltcmd=kill -INT $MAINPID"<br />
EnvironmentFile=/etc/conf.d/qemu.d/%i<br />
ExecStart=/usr/bin/qemu-${type} -name %i -nographic $args<br />
ExecStop=/bin/sh -c ${haltcmd}<br />
TimeoutStopSec=30<br />
KillMode=none<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
{{Note|According to {{man|5|systemd.service}} and {{ic|5|systemd.kill}} man pages it is necessary to use the {{ic|1=KillMode=none}} option. Otherwise the main qemu process will be killed immediately after the {{ic|ExecStop}} command quits (it simply echoes one string) and your quest system will not be able to shutdown correctly.<br />
}}<br />
<br />
Then create per-VM configuration files, named {{ic|/etc/conf.d/qemu.d/''vm_name''}}, with the variables {{ic|type}}, {{ic|args}} and {{ic|altcmd}} set. Example configs:<br />
<br />
{{hc|/etc/conf.d/qemu.d/one|<nowiki><br />
type="system-x86_64"<br />
<br />
args="-enable-kvm -m 512 -hda /dev/vg0/vm1 -net nic,macaddr=DE:AD:BE:EF:E0:00 \<br />
-net tap,ifname=tap0 -serial telnet:localhost:7000,server,nowait,nodelay \<br />
-monitor telnet:localhost:7100,server,nowait,nodelay -vnc :0"<br />
<br />
haltcmd="echo 'system_powerdown' | nc localhost 7100" # or netcat/ncat<br />
<br />
# You can use other ways to shut down your VM correctly<br />
#haltcmd="ssh powermanager@vm1 sudo poweroff"<br />
</nowiki>}}<br />
<br />
{{hc|/etc/conf.d/qemu.d/two|<nowiki><br />
args="-enable-kvm -m 512 -hda /srv/kvm/vm2.img -net nic,macaddr=DE:AD:BE:EF:E0:01 \<br />
-net tap,ifname=tap1 -serial telnet:localhost:7001,server,nowait,nodelay \<br />
-monitor telnet:localhost:7101,server,nowait,nodelay -vnc :1"<br />
<br />
haltcmd="echo 'system_powerdown' | nc localhost 7101"<br />
</nowiki>}}<br />
<br />
The description of the variables is the following:<br />
* {{ic|type}} - QEMU binary to call. If specified, will be prepended with {{ic|/usr/bin/qemu-}} and that binary will be used to start the VM.<br />
* {{ic|args}} - QEMU command line to start with. Will always be prepended with {{ic|-name ${vm} -nographic}}.<br />
* {{ic|haltcmd}} - Command to shut down a VM safely. In this example, the QEMU monitor is exposed via telnet using {{ic|-monitor telnet:..}} and the VMs are powered off via ACPI by sending {{ic|system_powerdown}} to monitor with the {{ic|nc}} command. You can use SSH or some other ways as well.<br />
<br />
To set which virtual machines will start on boot-up, [[enable]] the {{ic|qemu@''vm_name''.service}} systemd unit.<br />
<br />
=== Mouse integration ===<br />
<br />
To prevent the mouse from being grabbed when clicking on the guest operating system's window, add the options {{ic|-usb -device usb-tablet}}. This means QEMU is able to report the mouse position without having to grab the mouse. This also overrides PS/2 mouse emulation when activated. For example:<br />
<br />
$ qemu-system-x86_64 -hda ''disk_image'' -m 512 -usb -device usb-tablet<br />
<br />
If that does not work, try using {{ic|-vga qxl}} parameter, also look at the instructions [[#Mouse cursor is jittery or erratic]].<br />
<br />
=== Pass-through host USB device ===<br />
<br />
To access physical USB device connected to host from VM, you can use the option: {{ic|-usbdevice host:''vendor_id'':''product_id''}}.<br />
<br />
You can find {{ic|vendor_id}} and {{ic|product_id}} of your device with {{ic|lsusb}} command.<br />
<br />
Since the default I440FX chipset emulated by qemu feature a single UHCI controller (USB 1), the {{ic|-usbdevice}} option will try to attach your physical device to it. In some cases this may cause issues with newer devices. A possible solution is to emulate the [http://wiki.qemu.org/Features/Q35 ICH9] chipset, which offer an EHCI controller supporting up to 12 devices, using the option {{ic|1=-machine type=q35}}.<br />
<br />
A less invasive solution is to emulate an EHCI (USB 2) or XHCI (USB 3) controller with the option {{ic|1=-device usb-ehci,id=ehci}} or {{ic|1=-device nec-usb-xhci,id=xhci}} respectively and then attach your physical device to it with the option {{ic|1=-device usb-host,..}} as follows:<br />
<br />
-device usb-host,bus='''controller_id'''.0,vendorid=0x'''vendor_id''',productid=0x'''product_id'''<br />
<br />
You can also add the {{ic|1=...,port=''<n>''}} setting to the previous option to specify in which physical port of the virtual controller you want to attach your device, useful in the case you want to add multiple usb devices to the VM.<br />
<br />
{{Note|If you encounter permission errors when running QEMU, see [[udev#About udev rules]] for information on how to set permissions of the device.}}<br />
<br />
=== USB redirection with SPICE ===<br />
<br />
When using [[#SPICE]] it is possible to redirect USB devices from the client to the virtual machine without needing to specify them in the QEMU command. It is possible to configure the number of USB slots available for redirected devices (the number of slots will determine the maximum number of devices which can be redirected simultaneously). The main advantages of using SPICE for redirection compared to the previously-mentioned {{ic|-usbdevice}} method is the possibility of hot-swapping USB devices after the virtual machine has started, without needing to halt it in order to remove USB devices from the redirection or adding new ones. This method of USB redirection also allows us to redirect USB devices over the network, from the client to the server. In summary, it is the most flexible method of using USB devices in a QEMU virtual machine.<br />
<br />
We need to add one EHCI/UHCI controller per available USB redirection slot desired as well as one SPICE redirection channel per slot. For example, adding the following arguments to the QEMU command you use for starting the virtual machine in SPICE mode will start the virtual machine with three available USB slots for redirection:<br />
<br />
{{bc|<nowiki>-device ich9-usb-ehci1,id=usb \<br />
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,multifunction=on \<br />
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2 \<br />
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4 \<br />
-chardev spicevmc,name=usbredir,id=usbredirchardev1 \<br />
-device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 \<br />
-chardev spicevmc,name=usbredir,id=usbredirchardev2 \<br />
-device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 \<br />
-chardev spicevmc,name=usbredir,id=usbredirchardev3 \<br />
-device usb-redir,chardev=usbredirchardev3,id=usbredirdev3</nowiki>}}<br />
<br />
Both {{ic|spicy}} from {{Pkg|spice-gtk}} (''Input > Select USB Devices for redirection'') and {{ic|remote-viewer}} from {{pkg|virt-viewer}} (''File > USB device selection'') support this feature. Please make sure that you have installed the necessary SPICE Guest Tools on the virtual machine for this functionality to work as expected (see the [[#SPICE]] section for more information).<br />
<br />
{{Warning|Keep in mind that when a USB device is redirected from the client, it will not be usable from the client operating system itself until the redirection is stopped. It is specially important to never redirect the input devices (namely mouse and keyboard), since it will be then difficult to access the SPICE client menus to revert the situation, because the client will not respond to the input devices after being redirected to the virtual machine.}}<br />
<br />
=== Enabling KSM ===<br />
<br />
Kernel Samepage Merging (KSM) is a feature of the Linux kernel that allows for an application to register with the kernel to have its pages merged with other processes that also register to have their pages merged. The KSM mechanism allows for guest virtual machines to share pages with each other. In an environment where many of the guest operating systems are similar, this can result in significant memory savings.<br />
<br />
{{Note|Although KSM may reduce memory usage, it may increase CPU usage. Also note some security issues may occur, see [[Wikipedia:Kernel same-page merging]].}}<br />
<br />
To enable KSM:<br />
<br />
# echo 1 > /sys/kernel/mm/ksm/run<br />
<br />
To make it permanent, use [[systemd#Temporary files|systemd's temporary files]]:<br />
<br />
{{hc|/etc/tmpfiles.d/ksm.conf|<br />
w /sys/kernel/mm/ksm/run - - - - 1<br />
}}<br />
<br />
If KSM is running, and there are pages to be merged (i.e. at least two similar VMs are running), then {{ic|/sys/kernel/mm/ksm/pages_shared}} should be non-zero. See https://www.kernel.org/doc/Documentation/vm/ksm.txt for more information.<br />
<br />
{{Tip|An easy way to see how well KSM is performing is to simply print the contents of all the files in that directory: {{bc|$ grep . /sys/kernel/mm/ksm/*}}}}<br />
<br />
=== Multi-monitor support ===<br />
The Linux QXL driver supports four heads (virtual screens) by default. This can be changed via the {{ic|1=qxl.heads=N}} kernel parameter.<br />
<br />
The default VGA memory size for QXL devices is 16M (VRAM size is 64M). This is not sufficient if you would like to enable two 1920x1200 monitors since that requires 2 × 1920 × 4 (color depth) × 1200 = 17.6 MiB VGA memory. This can be changed by replacing {{ic|-vga qxl}} by {{ic|<nowiki>-vga none -device qxl-vga,vgamem_mb=32</nowiki>}}. If you ever increase vgamem_mb beyond 64M, then you also have to increase the {{ic|vram_size_mb}} option.<br />
<br />
=== Copy and paste ===<br />
<br />
One way to share the clipboard between the host and the guest is to enable the SPICE remote desktop protocol and access the client with a SPICE client.<br />
One needs to follow the steps described in [[#SPICE]]. A guest run this way will support copy paste with the host.<br />
<br />
=== Windows-specific notes ===<br />
<br />
QEMU can run any version of Windows from Windows 95 through Windows 10.<br />
<br />
It is possible to run [[Windows PE]] in QEMU.<br />
<br />
==== Fast startup ====<br />
{{Note|An administrator account is required to change power settings.}}<br />
For Windows 8 (or later) guests it is better to disable "Turn on fast startup (recommended)" from the Power Options of the Control Panel as explained in the following [https://www.tenforums.com/tutorials/4189-turn-off-fast-startup-windows-10-a.html forum page], as it causes the guest to hang during every other boot.<br />
<br />
Fast Startup may also need to be disabled for changes to the {{ic|-smp}} option to be properly applied.<br />
<br />
==== Remote Desktop Protocol ====<br />
<br />
If you use a MS Windows guest, you might want to use RDP to connect to your guest VM. If you are using a VLAN or are not in the same network as the guest, use:<br />
<br />
$ qemu-system-x86_64 -nographic -net user,hostfwd=tcp::5555-:3389<br />
<br />
Then connect with either {{Pkg|rdesktop}} or {{Pkg|freerdp}} to the guest. For example:<br />
<br />
$ xfreerdp -g 2048x1152 localhost:5555 -z -x lan<br />
<br />
=== Clone Linux system installed on physical equipment ===<br />
<br />
Linux system installed on physical equipment can be cloned for running on QEMU vm. See [https://coffeebirthday.wordpress.com/2018/09/14/clone-linux-system-for-qemu-virtual-machine/ Clone Linux system from hardware for QEMU virtual machine]<br />
<br />
== Troubleshooting ==<br />
<br />
=== Mouse cursor is jittery or erratic ===<br />
<br />
If the cursor jumps around the screen uncontrollably, entering this on the terminal before starting QEMU might help:<br />
<br />
$ export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
If this helps, you can add this to your {{ic|~/.bashrc}} file.<br />
<br />
=== No visible Cursor ===<br />
<br />
Add {{ic|-show-cursor}} to QEMU's options to see a mouse cursor.<br />
<br />
If that still does not work, make sure you have set your display device appropriately, for example: {{ic|-vga qxl}}.<br />
<br />
=== Two different mouse cursors are visible ===<br />
<br />
Apply the tip [[#Mouse integration]].<br />
<br />
=== Keyboard issues when using VNC ===<br />
When using VNC, you might experience keyboard problems described (in gory details) [https://www.berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ here]. The solution is ''not'' to use the {{ic|-k}} option on QEMU, and to use {{ic|gvncviewer}} from {{Pkg|gtk-vnc}}. See also [http://www.mail-archive.com/libvir-list@redhat.com/msg13340.html this] message posted on libvirt's mailing list.<br />
<br />
=== Keyboard seems broken or the arrow keys do not work ===<br />
<br />
Should you find that some of your keys do not work or "press" the wrong key (in particular, the arrow keys), you likely need to specify your keyboard layout as an option. The keyboard layouts can be found in {{ic|/usr/share/qemu/keymaps}}.<br />
<br />
$ qemu-system-x86_64 -k ''keymap'' ''disk_image''<br />
<br />
=== Guest display stretches on window resize ===<br />
<br />
To restore default window size, press {{ic|Ctrl+Alt+u}}.<br />
<br />
=== ioctl(KVM_CREATE_VM) failed: 16 Device or resource busy ===<br />
<br />
If an error message like this is printed when starting QEMU with {{ic|-enable-kvm}} option:<br />
<br />
ioctl(KVM_CREATE_VM) failed: 16 Device or resource busy<br />
failed to initialize KVM: Device or resource busy<br />
<br />
that means another [[hypervisor]] is currently running. It is not recommended or possible to run several hypervisors in parallel.<br />
<br />
=== libgfapi error message ===<br />
<br />
The error message displayed at startup:<br />
<br />
Failed to open module: libgfapi.so.0: cannot open shared object file: No such file or directory<br />
<br />
[[Install]] {{pkg|glusterfs}} or ignore the error message as GlusterFS is a optional dependency.<br />
<br />
=== Kernel panic on LIVE-environments===<br />
<br />
If you start a live-environment (or better: booting a system) you may encounter this:<br />
<br />
[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown block(0,0)<br />
<br />
or some other boot hindering process (e.g. cannot unpack initramfs, cant start service foo).<br />
Try starting the VM with the {{ic|-m VALUE}} switch and an appropriate amount of RAM, if the ram is to low you will probably encounter similar issues as above/without the memory-switch.<br />
<br />
=== Windows 7 guest suffers low-quality sound ===<br />
<br />
Using the {{ic|hda}} audio driver for Windows 7 guest may result in low-quality sound. Changing the audio driver to {{ic|ac97}} by passing the {{ic|-soundhw ac97}} arguments to QEMU and installing the AC97 driver from [https://www.realtek.com/en/component/zoo/category/pc-audio-codecs-ac-97-audio-codecs-software Realtek AC'97 Audio Codecs] in the guest may solve the problem. See [https://bugzilla.redhat.com/show_bug.cgi?id=1176761#c16 Red Hat Bugzilla – Bug 1176761] for more information.<br />
<br />
=== Could not access KVM kernel module: Permission denied ===<br />
<br />
If you encounter the following error:<br />
<br />
libvirtError: internal error: process exited while connecting to monitor: Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied<br />
<br />
Systemd 234 assign it a dynamic id to group kvm (see [https://bugs.archlinux.org/task/54943 bug]). A workground for avoid this error, you need edit the file {{ic|/etc/libvirt/qemu.conf}} and change the line:<br />
<br />
group = "78"<br />
<br />
to<br />
<br />
group = "kvm"<br />
<br />
=== "System Thread Exception Not Handled" when booting a Windows VM ===<br />
<br />
Windows 8 or Windows 10 guests may raise a generic compatibility exception at boot, namely "System Thread Exception Not Handled", which tends to be caused by legacy drivers acting strangely on real machines. On KVM machines this issue can generally be solved by setting the CPU model to {{ic|core2duo}}.<br />
<br />
=== Certain Windows games/applications crashing/causing a bluescreen ===<br />
<br />
Occasionally, applications running in the VM may crash unexpectedly, whereas they'd run normally on a physical machine. If, while running {{ic|dmesg -wH}}, you encounter an error mentioning {{ic|MSR}}, the reason for those crashes is that KVM injects a [[wikipedia:General protection fault|General protection fault]] (GPF) when the guest tries to access unsupported [[wikipedia:Model-specific register|Model-specific registers]] (MSRs) - this often results in guest applications/OS crashing. A number of those issues can be solved by passing the {{ic|1=ignore_msrs=1}} option to the KVM module, which will ignore unimplemented MSRs.<br />
<br />
{{hc|/etc/modprobe.d/kvm.conf|2=<br />
...<br />
options kvm ignore_msrs=1<br />
...<br />
}}<br />
<br />
Cases where adding this option might help:<br />
<br />
* GeForce Experience complaining about an unsupported CPU being present.<br />
* StarCraft 2 and L.A. Noire reliably blue-screening Windows 10 with {{ic|KMODE_EXCEPTION_NOT_HANDLED}}. The blue screen information does not identify a driver file in these cases.<br />
<br />
{{Warning|While this is normally safe and some applications might not work without this, silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<br />
<br />
=== Applications in the VM experience long delays or take a long time to start ===<br />
<br />
This may be caused by insufficient available entropy in the VM. Consider allowing the guest to access the hosts's entropy pool by adding a [https://wiki.qemu.org/Features/VirtIORNG VirtIO RNG device] to the VM, or by installing an entropy generating daemon such as [[Haveged]].<br />
<br />
Anecdotally, OpenSSH takes a while to start accepting connections under insufficient entropy, without the logs revealing why.<br />
<br />
== See also ==<br />
<br />
* [http://qemu.org Official QEMU website]<br />
* [http://www.linux-kvm.org Official KVM website]<br />
* [http://qemu.weilnetz.de/qemu-doc.html QEMU Emulator User Documentation]<br />
* [https://en.wikibooks.org/wiki/QEMU QEMU Wikibook]<br />
* [http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu Hardware virtualization with QEMU] by AlienBOB (last updated in 2008)<br />
* [http://blog.falconindy.com/articles/build-a-virtual-army.html Building a Virtual Army] by Falconindy<br />
* [http://git.qemu.org/?p=qemu.git;a=tree;f=docs Lastest docs]<br />
* [http://qemu.weilnetz.de/ QEMU on Windows]<br />
* [[wikipedia:Qemu|Wikipedia]]<br />
* [[debian:QEMU|Debian Wiki - QEMU]]<br />
* [https://people.gnome.org/~markmc/qemu-networking.html QEMU Networking on gnome.org]<br />
* [http://bsdwiki.reedmedia.net/wiki/networking_qemu_virtual_bsd_systems.html Networking QEMU Virtual BSD Systems]<br />
* [https://www.gnu.org/software/hurd/hurd/running/qemu.html QEMU on gnu.org]<br />
* [https://wiki.freebsd.org/qemu QEMU on FreeBSD as host]<br />
* [https://wiki.mikejung.biz/KVM_/_Xen KVM/QEMU Virtio Tuning and SSD VM Optimization Guide]<br />
* [https://doc.opensuse.org/documentation/leap/virtualization/html/book.virt/part.virt.qemu.html Managing Virtual Machines with QEMU - OpenSUSE documentation]<br />
* [https://www.ibm.com/support/knowledgecenter/en/linuxonibm/liaat/liaatkvm.htm KVM on IBM Knowledge Center]</div>Ivankhttps://wiki.archlinux.org/index.php?title=Firefox/Privacy&diff=570776Firefox/Privacy2019-04-09T01:28:18Z<p>Ivank: mention ghacks and add a section for all user.js template sites</p>
<hr />
<div>[[Category:Web browser]]<br />
[[ja:Firefox プライバシー]]<br />
{{Related articles start}}<br />
{{Related|Firefox}}<br />
{{Related|Tor}}<br />
{{Related|Browser extensions}}<br />
{{Related|Browser Plugins}}<br />
{{Related|Firefox/Tweaks}}<br />
{{Related|Firefox/Profile on RAM}}<br />
{{Related articles end}}<br />
<br />
This article overviews how to configure Firefox to enhance security and privacy.<br />
<br />
== Configuration ==<br />
<br />
The following are privacy-focused configuration tweaks to prevent [https://panopticlick.eff.org/ browser fingerprinting] and tracking.<br />
<br />
=== Anti-fingerprinting ===<br />
<br />
Mozilla has started an [[MozillaWiki:Security/Fingerprinting|anti-fingerprinting project in Firefox]], as part of a project to upstream features from [[Tor Browser]]. Many of these anti-fingerprinting features are enabled by setting {{ic|about:config}}:<br />
<br />
* {{ic|privacy.resistFingerprinting}} {{ic|true}}<br />
<br />
There is no user-facing documentation about this flag, and Mozilla does not recommend users enable it, since it will break a few websites (it exists mostly to make life easier for the Tor Browser developers). But it does automatically enable many of the features listed below (such as changing your reported timezone and user agent), as well as protection against other, lesser-known fingerprinting techniques. See the [https://bugzilla.mozilla.org/show_bug.cgi?id=1333933 tracking bug] that lists many of these features.<br />
<br />
=== Tracking protection ===<br />
<br />
Firefox gained an option for [https://support.mozilla.org/en-US/kb/tracking-protection-firefox tracking protection]. It can be enabled by setting {{ic|about:config}}:<br />
<br />
* {{ic|privacy.trackingprotection.enabled}} {{ic|true}}<br />
<br />
Apart from privacy benefits, enabling [http://venturebeat.com/2015/05/24/firefoxs-optional-tracking-protection-reduces-load-time-for-top-news-sites-by-44/ tracking protection] may also reduce load time by 44%.<br />
<br />
Note that this is not a replacement for ad blocking extensions such as [[Browser extensions#Content blockers|uBlock Origin]] and it may or may not work with [[List of applications/Internet#Firefox_spin-offs|Firefox forks]]. If you are already running such an ad blocker with the correct lists, tracking protection might be redundant.<br />
<br />
=== Change browser time zone ===<br />
<br />
The time zone of your system can be used in browser fingerprinting. To set Firefox's time zone to UTC launch it as:<br />
<br />
$ TZ=UTC firefox<br />
<br />
Or, set a script to launch the above (for example, at {{ic|/usr/local/bin/firefox}}).<br />
<br />
=== Change user agent and platform ===<br />
<br />
You can override Firefox's user agent with the {{ic|general.useragent.override}} preference in {{ic|about:config}}.<br />
<br />
The value for the key is your browser's user agent. Select a known common one.<br />
<br />
{{Tip|<br />
* The value {{ic|Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0}} is used as the user agent for the Tor browser, thus being very common.<br />
* The [[#Anti-fingerprinting]] option also enables the Tor browser user agent and changes your browser platform automatically.<br />
}}<br />
<br />
{{Warning|Changing the user agent without changing to a corresponding platform will make your browser nearly unique.}}<br />
<br />
To change the platform for firefox, add the following {{ic|string}} key in {{ic|about:config}}:<br />
<br />
general.platform.override<br />
<br />
Select a known common platform that corresponds with your user agent.<br />
<br />
{{Tip|The value {{ic|Win32}} is used as the platform for the Tor browser, corresponding with the user agent provided above.}}<br />
<br />
=== WebRTC exposes LAN IP address ===<br />
<br />
To prevent websites from getting your local IP address via [[wikipedia:WebRTC|WebRTC]]'s peer-to-peer (and JavaScript), open {{ic|about:config}} and set:<br />
<br />
* {{ic|media.peerconnection.ice.default_address_only}} to {{ic|true}}<br />
* {{ic|media.peerconnection.enabled}} to {{ic|false}}. (only if you want to completely disable WebRTC)<br />
<br />
You can use this [http://net.ipcalf.com/ WebRTC test page] and [https://ipleak.net/ WebRTC IP Leak VPN / Tor IP Test] to confirm that your internal/external IP address is no longer leaked.<br />
<br />
=== Disable telemetry ===<br />
<br />
Set {{ic|toolkit.telemetry.enabled}} to {{ic|false}} and/or disable it under ''Preferences > Privacy & Security > Firefox Data Collection and Use''.<br />
<br />
=== Enable Do Not Track Header (DNT) ===<br />
<br />
{{Note|The remote server may choose to not honour the Do Not Track request.}}<br />
<br />
{{Warning|The Do Not Track header may be used to fingerprint your browser, since most users leave the option disabled.}}<br />
<br />
Set {{ic|privacy.donottrackheader.enabled}} to {{ic|true}} or toggle it in ''Preferences > Privacy & Security > Tracking Protection''<br />
<br />
=== Disable/Enforce Trusted Recursive Resolver ===<br />
<br />
Firefox 60 introduced a feature called [[mozillawiki:Trusted Recursive Resolver|Trusted Recursive Resolver]] (TRR). It circumvents DNS servers configured in your system, instead sending all DNS requests over HTTPS to Cloudflare servers. While this is significantly more secure (as "classic" DNS requests are sent in plain text over the network, and everyone along the way can snoop on these), this also makes all your DNS requests readable by Cloudflare, providing TRR servers.<br />
<br />
* If you trust DNS servers you've configured yourself more than Cloudflare's, you can disable TRR in {{ic|about:config}} by setting {{ic|network.trr.mode}} (integer, create it it it doesn't exist) to {{ic|5}}. (A value of 0 means disabled by default, and might be overridden by future updates - a value of 5 is disabled by choice and will not be overridden.)<br />
* If you trust Cloudflare DNS servers and would prefer extra privacy (thanks to encrypted DNS requests), you can enforce TRR by setting {{ic|network.trr.mode}} to {{ic|3}} (which completely disables classic DNS requests) or {{ic|2}} (uses TRR by default, falls back to classic DNS requests if that fails). Keep in mind that if you're using any intranet websites or trying to access computers in your local networks by their hostnames, enabling TRR may break name resolving in such cases.<br />
* If you want to encrypt your DNS requests but not use Cloudflare servers, you can point to a new DNS over HTTPS server by setting {{ic|network.trr.uri}} to your resolver URL. A list of currently available resolvers can be found in the [https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers curl wiki], along with other configuration options for TRR.<br />
<br />
=== Disable geolocation ===<br />
<br />
Set {{ic|geo.enabled}} to {{ic|false}} in {{ic|about:config}}.<br />
<br />
=== Disable Safe Browsing service ===<br />
<br />
Safe Browsing offers phishing protection and malware checks, however it may send user information (e.g. URL, file hashes, etc.) to third parties like Google.<br />
<br />
To disable the Safe Browsing service, in {{ic|about:config}} set: <br />
<br />
* {{ic|browser.safebrowsing.malware.enabled}} to {{ic|false}}<br />
* {{ic|browser.safebrowsing.phishing.enabled}} to {{ic|false}}<br />
<br />
In addition disable download checking, by setting {{ic|browser.safebrowsing.downloads.enabled}} to {{ic|false}}.<br />
<br />
=== Disable WebGL ===<br />
<br />
WebGL is a potential security risk.[http://security.stackexchange.com/questions/13799/is-webgl-a-security-concern] Set {{ic|webgl.disabled}} to {{ic|true}} in {{ic|about:config}} if you want to disable it.<br />
<br />
== Extensions ==<br />
<br />
See [[Browser extensions#Privacy]].<br />
<br />
== Remove system-wide hidden extensions ==<br />
<br />
Several extensions, hidden to the user, are installed by default in {{ic|/usr/lib/firefox/browser/features}}. Many can be safely removed via {{ic|rm ''extension-name''.xpi}} in order to completely remove unwanted features. Many of these extensions are not enabled by default and have a menu option for enabling or disabling. Note that any files removed will return upon update of the {{pkg|firefox}} package. To keep these extensions removed, consider adding the directories to {{ic|1=NoExtract=}} in {{ic|pacman.conf}}, see [[Pacman#Skip files from being installed to system]]. Below are a few examples of these extensions and their features.<br />
<br />
* {{ic|activity-stream@mozilla.org.xpi}} - "Activity Stream" which replaces the new tab page. See [https://github.com/mozilla/activity-stream]<br />
<br />
* {{ic|firefox@getpocket.com.xpi}} - [https://getpocket.com/firefox/ Pocket]<br />
<br />
* {{ic|followonsearch@mozilla.com.xpi}} - Search telemetry. See also [[#Disable telemetry]].<br />
<br />
* {{ic|shield-recipe-client@mozilla.org.xpi}} [https://support.mozilla.org/en-US/kb/shield SHIELD studies]<br />
<br />
See also [https://dxr.mozilla.org/mozilla-release/source/browser/extensions/] for a full list of system extensions including README files describing their functions.<br />
<br />
== Hardened user.js templates ==<br />
<br />
Several active projects maintain comprehensive hardened Firefox configurations in the form of a {{ic|user.js}} config that can be dropped to Firefox profile directory:<br />
<br />
* [https://github.com/pyllyukko/user.js pyllyukko/user.js]<br />
* [https://github.com/ghacksuserjs/ghacks-user.js ghacksuserjs/ghacks-user.js]<br />
* [https://ffprofile.com/ ffprofile.com] ([https://github.com/allo-/firefox-profilemaker github]) - online user.js generator. You select which features you want to enable and disable and in the end you get a download link for a zip-file with your profile template. You can for example disable some functions, which send data to Mozilla and Google, or disable several annoying Firefox functions like Mozilla Hello or the Pocket integration. <br />
<br />
== See also ==<br />
<br />
* [https://www.privacytools.io/#addons privacytools.io Firefox Privacy Add-ons]<br />
* [https://prism-break.org/en/categories/gnu-linux/#web-browser-addons prism-break.org Web Browser Addons]<br />
* [[MozillaWiki:Privacy/Privacy Task Force/firefox about config privacy tweeks]] - a wiki page maintained by Mozilla with descriptions of privacy specific settings.<br />
* [https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections How to stop Firefox from making automatic connections] - Is an annotated list of corresponding Firefox functionality and settings to disable it case-by-case.</div>Ivankhttps://wiki.archlinux.org/index.php?title=Uniform_look_for_Qt_and_GTK_applications&diff=570773Uniform look for Qt and GTK applications2019-04-09T00:57:53Z<p>Ivank: /* Styles for both Qt and GTK+ */ mention kvantum</p>
<hr />
<div>[[Category:Widget toolkits]]<br />
[[Category:Eye candy]]<br />
[[es:Uniform look for Qt and GTK applications]]<br />
[[it:Uniform look for Qt and GTK applications]]<br />
[[ja:Qt と GTK アプリケーションの外観の統合]]<br />
[[ru:Uniform look for Qt and GTK applications]]<br />
[[zh-hans:Uniform look for Qt and GTK applications]]<br />
{{Related articles start}}<br />
{{Related|GTK+}}<br />
{{Related|Qt}}<br />
{{Related articles end}}<br />
[[Qt]] and [[GTK+]] based programs both use a different widget toolkit to render the graphical user interface. Each come with different themes, styles and icon sets by default, among other things, so the "look and feel" differ significantly. This article will help you make your Qt and GTK+ applications look similar for a more streamlined and integrated desktop experience.<br />
<br />
== Overview ==<br />
<br />
To get a similar look between the toolkits, you will most likely have to modify the following:<br />
* '''Theme''': The custom appearance of an application, widget set, etc. It usually consists of a style, an icon theme and a color theme.<br />
* '''Style''': The graphical layout and look of the widget set.<br />
* '''Icon Theme''': A set of global icons.<br />
* '''Color Theme''': A set of global colors that are used in conjunction with the style.<br />
<br />
You can choose various approaches:<br />
* Modify [[#Styles for both Qt and GTK+|GTK+ and Qt styles]] separately with the tools listed below for each toolkit and aim for choosing similarly looking themes (style, colors, icons, cursors, fonts).<br />
* Use a special [[#Theme engines|theme engine]], which intermediates the modification of the other graphical toolkit to match your main toolkit.<br />
<br />
== Styles for both Qt and GTK+ ==<br />
There are widget style sets available for the purpose of integration, where builds are written and provided for both Qt and GTK+, all major versions included. With these, you can have one look for all applications regardless of the toolkit they had been written with.<br />
<br />
{{Tip|You may want to apply user defined styles to root applications, see [[GTK#Theme not applied to root applications]] and [[Qt#Theme not applied to root applications]].}}<br />
{{Note|1=Since version 3.16, GTK+ 3 [https://bbs.archlinux.org/viewtopic.php?pid=1518404#p1518404 does not support] non-CSS themes, hence previous solutions such as Oxygen-Gtk are [https://bugs.kde.org/show_bug.cgi?id=340288 no longer viable] options.}}<br />
<br />
=== Breeze ===<br />
<br />
Breeze is the default Qt style of KDE Plasma. It can be installed with the {{Pkg|breeze}} package for Qt5, the {{Pkg|breeze-kde4}}{{Broken package link|{{aur-mirror|breeze-kde4}}}} package for Qt4, and the {{Pkg|breeze-gtk}} package for GTK+ 2 and GTK+ 3.<br />
<br />
Once installed, you can use one of the many [[GTK+#Configuration tools|GTK+ configuration tools]] to change the GTK+ theme. <br />
<br />
If running KDE Plasma, install {{pkg|kde-gtk-config}} and either run it from the command line, or go to ''System Settings > Application Style > GNOME Application Style (GTK)''. Fonts, icon themes, cursors, and widget styles set in System Settings outside of the GTK configuration module will affect Qt only; GTK settings should be set manually using the previously mentioned module.<br />
<br />
=== Adwaita ===<br />
<br />
Adwaita is the default GNOME theme. The GTK+ 3 version is included in the {{Pkg|gtk3}} package, while the GTK+ 2 version is in {{Pkg|gnome-themes-extra}}. [https://github.com/MartinBriza/adwaita-qt adwaita-qt] is a Qt port of the Adwaita theme. Unlike [[#QGtkStyle]], which mimics the GTK+ 2 theme, it provides a native Qt style made to look like the GTK+ 3 Adwaita. It can be [[install|installed]] with the {{AUR|adwaita-qt4}} and {{AUR|adwaita-qt5}} packages for the Qt 4 and 5 versions, respectively.<br />
<br />
To set the Qt style as default:<br />
<br />
* For Qt4, it can be enabled with ''Qt Configuration'' ({{ic|qtconfig-qt4}}), choose ''adwaita'' under ''Appearance > GUI Style''. Alternatively, edit the {{ic|/etc/xdg/Trolltech.conf}} (system-wide) or {{ic|~/.config/Trolltech.conf}} (user-specific) file:<br />
<br />
{{hc|~/.config/Trolltech.conf|2=<br />
...<br />
[Qt]<br />
style=adwaita<br />
...<br />
}}<br />
<br />
* For Qt 5, it can be enabled by setting the following [[Environment variables#Graphical applications|environment variable]]: {{ic|1=QT_STYLE_OVERRIDE=adwaita}}. Alternatively, use {{Pkg|qt5ct}} package. For more detailed instructions, see [[Qt#Configuration of Qt5 apps under environments other than KDE Plasma]].<br />
<br />
=== Kvantum ===<br />
<br />
Kvantum ({{Pkg|kvantum-qt5}}) is customizable SVG-based theme engine for Qt5 that comes with a variety of built-in styles, including versions of some of popular GTK+ themes such as Adapta, Arc, Ambiance, Materia.<br />
<br />
== Theme engines ==<br />
<br />
A ''theme engine'' can be thought of as a thin layer API which translates themes (excluding icons) between one or more toolkits. These engines add some extra code in the process and it is arguable that this kind of a solution is not as elegant and optimal as using native styles.<br />
<br />
=== QGtkStyle ===<br />
<br />
{{Note|QGtkStyle has been removed from {{Pkg|qt5-base}} 5.7.0 [https://github.com/qtproject/qtbase/commit/899a815414e95da8d9429a4a4f4d7094e49cfc55] and added to {{Pkg|qt5-styleplugins}} [https://github.com/qtproject/qtstyleplugins/commit/102da7d50231fc5723dba6e72340bef3d29471aa]}}<br />
<br />
{{Warning|Depending on GTK+ 2 theme, this style may cause rendering issues such as transparent fonts or inconsistent widgets.}}<br />
<br />
This Qt style uses GTK+ 2 to render all components to blend in with [[GNOME]] and similar GTK+ based environments. Beginning with Qt 4.5, this style is included in Qt. It requires {{Pkg|gtk2}} to be installed and configured.<br />
<br />
This is the default Qt4 style in Cinnamon, GNOME and Xfce, and the default Qt5 style in Cinnamon, GNOME, MATE, LXDE and Xfce. In other environments:<br />
<br />
* For Qt4, it can be enabled with ''Qt Configuration'' ({{ic|qtconfig-qt4}}), choose ''GTK+'' under ''Appearance > GUI Style''. Alternatively, edit the {{ic|/etc/xdg/Trolltech.conf}} (system-wide) or {{ic|~/.config/Trolltech.conf}} (user-specific) file:<br />
<br />
{{hc|~/.config/Trolltech.conf|2=<br />
...<br />
[Qt]<br />
style=GTK+<br />
...<br />
}}<br />
<br />
* For Qt 5, it can be enabled by installing {{Pkg|qt5-styleplugins}} and setting the following [[Environment variables#Graphical applications|environment variable]]: {{ic|1=QT_QPA_PLATFORMTHEME=gtk2}}<br />
<br />
For full uniformity, make sure that the configured [[GTK+#Themes|GTK+ theme]] supports both GTK+ 2 and GTK+ 3. If your preferred theme has inconsistent rendering after configuring Qt to use GTK+2, install {{Pkg|gtk-theme-switch2}} and choose a theme.<br />
<br />
=== QGnomePlatform ===<br />
<br />
This Qt 5 platform theme applies the appearance settings of GNOME for Qt applications. It can be installed with the {{AUR|qgnomeplatform}} package or the {{AUR|qgnomeplatform-git}} package for the development version. It does not provide a Qt style itself, instead it requires a [[#Styles for both Qt and GTK+|style that support both Qt and GTK+]].<br />
<br />
This platform theme is enabled automatically in GNOME since version 3.20. For other systems, it can be enabled by setting the following [[Environment variables#Graphical applications|environment variable]]: {{ic|1=QT_QPA_PLATFORMTHEME=qgnomeplatform}}.<br />
<br />
== Tips and tricks ==<br />
=== KDE file dialogs for GTK+ applications ===<br />
<br />
'''Chromium'''<br />
<br />
At least for chromium installing {{ic|kdialog}} makes chromium used kde file dialog ( so `KGtk-wrapper` is not required )<br />
<br />
{{Out of date|KGtk-wrapper has not been updated for years, and can't be used anymore - several dependencies are missing.}}<br />
<br />
{{Warning|Some GTK+ applications may not be compatible with KGtk-wrapper (e.g. [[Chromium]]), sometimes the wrapper makes the application crash ([[Firefox]] or [[Thunderbird]]).}}<br />
<br />
{{AUR|kgtk}} from the [[AUR]] is a wrapper script which uses {{ic|LD_PRELOAD}} to force KDE file dialogs in GTK+ 2.x apps. Once installed you can run GTK+ 2.x applications with {{ic|kgtk-wrapper}} in two ways (using [[GIMP]] in the examples):<br />
<br />
* Calling {{ic|kgtk-wrapper}} directly and using the GTK+ 2.x binary as an argument:<br />
:{{bc|$ /usr/bin/kgtk-wrapper gimp}}<br />
* Modifying the KDE .desktop shortcuts files you can find at {{ic|/usr/share/applications/}} to prefix the {{ic|Exec}} statement with kgtk-wrapper.<br />
:e.g. with [[GIMP]], edit the {{ic|/usr/share/applications/gimp.desktop}} shortcut file and replace {{ic|1=Exec=gimp-2.8 %U}} by {{ic|1=Exec=kgtk-wrapper gimp-2.8 %U}}.<br />
<br />
'''Firefox'''<br />
<br />
Firefox can use kde file dialogs natively. See [[Firefox#KDE/GNOME integration]]<br />
<br />
=== Using a GTK+ icon theme in Qt apps ===<br />
<br />
{{Style|Duplicates [[environment variables]]}}<br />
<br />
If you are running Plasma, install {{Pkg|kde-gtk-config}} and select the icon-theme under ''System Settings > Application Style > GTK''.<br />
<br />
If you are using [[GNOME]], first check if {{Pkg|dconf-editor}} is installed.<br />
<br />
Then, run {{ic|dconf-editor}} and look under ''org > gnome > desktop > interface'' for {{ic|icon-theme}} key and change it to your preferred icon theme. <br />
<br />
If you are not using [[GNOME]], for example if you are running a minimal system with {{Pkg|i3-wm}}, first install {{Pkg|dconf-editor}}. <br />
<br />
Then, run {{ic|dconf-editor}} and look under ''org > gnome > desktop > interface'' for {{ic|icon-theme}} key and change it to your preferred icon theme. <br />
<br />
Since, you are not using [[GNOME]], you might have to set the value of {{ic|DESKTOP_SESSION}} in your profile. To do that execute the below code in a terminal and restart your system.<br />
<br />
$ echo 'export DESKTOP_SESSION=gnome' >> /etc/profile<br />
<br />
'''OR'''<br />
<br />
Set {{ic|1=export DESKTOP_SESSION=gnome}} somewhere in your {{ic|~/.xinitrc}} or, if you are using a [[Display manager]] in [[Xprofile]].<br />
<br />
{{Note| If the icon theme was not applied, you might want to check if the name that you entered of your preferred theme, was in the correct format. For example, if you want to apply the currently active icon theme to your QT applications, you can find the correct format of it's name with the command:<br />
<br />
{{bc|1=$ cat ~/.gtkrc-2.0 {{!}} grep icon-theme {{!}} cut -d= -f2}}<br />
<br />
}}<br />
<br />
=== Add Title bar and frame to GTK3 applications under KDE Plasma ===<br />
<br />
To have Gnome/GTK applications display with a KDE/Plasma title bar and frame, install {{AUR|gtk3-nocsd-git}} and restart your window manager to load the updated library path.<br />
<br />
You can also run Gtk application with the wrapper:<br />
$ gtk3-nocsd gedit<br />
<br />
=== Improve subpixel rendering of GTK apps under KDE Plasma ===<br />
<br />
See [[Font configuration#LCD filter]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Qt applications do not use QGtkStyle ===<br />
<br />
{{Out of date|GTK+-Qt Engine has been unmaintained for a while.|section=For removal or needs rewrite}}<br />
<br />
Qt will not apply QGtkStyle correctly if GTK+ is using the [[#GTK+-Qt Engine|GTK+-Qt Engine]]{{Broken section link}}. Qt determines whether the GTK+-Qt Engine is in use by reading the GTK+ configuration files listed in the environmental variable {{ic|GTK2_RC_FILES}}. If the environmental variable is not set properly, Qt assumes you are using the engine, sets QGtkStyle to use the style GTK+ style ''Clearlooks'', and outputs an error message:<br />
<br />
QGtkStyle cannot be used together with the GTK_Qt engine.<br />
<br />
Another error you may get after launching {{ic|qtconfig-qt4}} from a shell and selecting the GTK+ style is:<br />
<br />
QGtkStyle was unable to detect the current GTK+ theme.<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id&#61;99175&p&#61;1 this thread], you may simply have to install {{AUR|libgnomeui}} to solve this issue. This has the added benefit that you do not need to edit a file every time you change your theme via a graphical tool, like the one provided by xfce.<br />
<br />
Users of [[Openbox]] and other non-GNOME environments may encounter this problem. To solve this, first add the following to your {{ic|.xinitrc}} file:<br />
<br />
{{hc|.xinitrc|<nowiki><br />
...<br />
export GTK2_RC_FILES="$HOME/.gtkrc-2.0"<br />
...<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Make sure to add this line before invoking the window manager.<br />
* You can add multiple paths by separating them with colons.<br />
* Make sure to use {{ic|$HOME}} instead of {{ic|~}} as it will not properly expand to the user's home directory.<br />
}}<br />
<br />
Then specify the theme you want in the {{ic|~/.gtkrc-2.0}} file using a [[GTK+#Configuration_tools|dedicated application]] or manually, by adding:<br />
<br />
{{hc|.gtkrc-2.0|<nowiki><br />
...<br />
gtk-theme-name="[name of theme]"<br />
...<br />
</nowiki>}}<br />
<br />
Some tools only insert the following include directive in {{ic|~/.gtkrc-2.0}}:<br />
<br />
{{hc|.gtkrc-2.0|<br />
...<br />
include "/usr/share/themes/SomeTheme/gtk-2.0/gtkrc"<br />
...<br />
}}<br />
<br />
which apparently is not recognized by all versions of QGtkStyle. You can hotfix this problem by inserting the {{ic|gtk-theme-name}} manually in your {{ic|~/.gtkrc-2.0}} file like above.<br />
<br />
{{Note|Style-changing applications will most probably rewrite the {{ic|~/.gtkrc-2.0}} file the next time you change themes.}}<br />
<br />
If these steps do not work, install {{Pkg|gconf}} and run this command:<br />
<br />
gconftool-2 --set --type string /desktop/gnome/interface/gtk_theme [name of theme]<br />
<br />
If you further want to set the same icon and cursor theme, then you have to specify them, too.<br />
<br />
gconftool-2 --set --type string /desktop/gnome/interface/icon_theme Faenza-Dark<br />
<br />
This sets the icon theme to Faenza-Dark located in {{ic|/usr/share/icons/Faenza-Dark}}. For the cursor theme you first have to set the gconf value.<br />
<br />
gconftool-2 --set --type string /desktop/gnome/peripherals/mouse/cursor_theme Adwaita<br />
<br />
Then you will have to create the file {{ic|/usr/share/icons/default/index.theme}} with the following lines:<br />
<br />
[Icon Theme]<br />
Inherits=Adwaita<br />
<br />
=== Themes not working in GTK+ apps ===<br />
<br />
If the style or theme engine you set up is not showing in your GTK applications then it is likely your GTK+ settings files are not being loaded for some reason. You can check where your system expects to find these files by doing the following..<br />
$ export | grep gtk<br />
<br />
Usually the expected files should be {{ic|~/.gtkrc}} for GTK1 and {{ic|~/.gtkrc2.0}} or {{ic|~/.gtkrc2.0-kde}} for GTK+ 2.x.<br />
<br />
=== GTK+ apps don't use svg (breeze) icons after system upgrade ===<br />
<br />
Try to run this to fix this issue:<br />
# gdk-pixbuf-query-loaders --update-cache</div>Ivankhttps://wiki.archlinux.org/index.php?title=Qt&diff=570772Qt2019-04-09T00:36:34Z<p>Ivank: /* Qt5 */ mention kvantum</p>
<hr />
<div>[[Category:Widget toolkits]]<br />
[[ja:Qt]]<br />
[[ru:Qt]]<br />
[[zh-hans:Qt]]<br />
{{Related articles start}}<br />
{{Related|KDE}}<br />
{{Related|Uniform Look for Qt and GTK Applications}}<br />
{{Related|GTK+}}<br />
{{Related articles end}}<br />
[http://qt-project.org/ Qt] is a cross-platform application and widget toolkit that uses standard C++ but makes extensive use of a special code generator (called the [http://qt-project.org/doc/qt-4.8/moc.html Meta Object Compiler], or ''moc'') together with several macros to enrich the language. Some of its more important features include:<br />
<br />
* Running on the major desktop platforms and some of the mobile platforms.<br />
* Extensive internationalization support.<br />
* A complete library that provides SQL database access, XML parsing, thread management, network support, and a unified cross-platform application programming interface (API) for file handling.<br />
<br />
The Qt framework is the basis of the [[KDE]] software community, as well as other important open source and proprietary applications such as [[VLC]], [[VirtualBox]], [[Mathematica]] and many others.<br />
<br />
== Installation ==<br />
<br />
Two versions of Qt are currently available in the [[official repositories]]. They can be [[Pacman|installed]] with the following packages:<br />
<br />
* '''Qt 5.x''' is available in the {{Pkg|qt5-base}} package, with documentation in the {{Pkg|qt5-doc}} package.<br />
* '''Qt 4.x''' is available in the {{Pkg|qt4}} package, with documentation on AUR in the {{AUR|qt4-doc}} package.<br />
* '''Qt 3.x''' is available from the AUR in the {{AUR|qt3}} package, with documentation on AUR in the {{AUR|qt3-doc}} package.<br />
<br />
== Default Qt toolkit ==<br />
<br />
Qt packages do not provide the usual bins (e.g. ''qmake'') in {{ic|/usr/bin}} anymore. Instead {{ic|-qt5}}, {{ic|-qt4}} and {{ic|-qt3}} symlinks are provided (e.g. {{ic|qmake-qt5}}, {{ic|qmake-qt4}}, {{ic|qmake-qt3}}). This may cause compilation failures in Qt3/4 applications. <br />
<br />
By installing {{AUR|qtchooser}} you can restore the usual bins (e.g. ''qmake'') in {{ic|/usr/bin}} and setup the Qt toolkit to use. By default Qt5 is used.<br />
<br />
{{Warning|{{AUR|qtchooser}} is now in conflict with {{Pkg|qt5-base}}. You can install it in /usr/local if you really need it, but it's not officially supported. See {{Bug|51308}}.}}<br />
<br />
=== Using environment variables ===<br />
<br />
To define the default Qt toolkit, you can create {{ic|QT_SELECT}} [[environment variable]]. For example, to use Qt4, set {{ic|1=QT_SELECT=4}}.<br />
<br />
=== Using configuration files ===<br />
<br />
You can set the default Qt toolkit by creating a symlink {{ic|~/.config/qtchooser/default.conf}} to one of ''.conf'' files in {{ic|/etc/xdg/qtchooser/}} directory. For example, to set Qt4 symlink {{ic|/etc/xdg/qtchooser/4.conf}} to {{ic|~/.config/qtchooser/default.conf}}:<br />
<br />
$ ln -s {{ic|/etc/xdg/qtchooser/4.conf}} {{ic|~/.config/qtchooser/default.conf}}<br />
<br />
== Appearance ==<br />
<br />
=== Qt5 ===<br />
<br />
Qt5 decides the style to use based on what desktop environment is used:<br />
<br />
* In KDE Plasma, it uses the actually selected Qt style. It can be configured using ''KDE System Settings'' (''systemsettings5''), the settings can be found in ''Appearance > Application Style > Widget Style''.<br />
* In Cinnamon, GNOME, MATE, LXDE, Xfce, it uses GTK+ ([[Uniform look for Qt and GTK applications#QGtkStyle|QGtkStyle]]).<br />
* In other desktop environments, it uses Fusion.<br />
<br />
To force a specific style, you can set the {{ic|1=QT_STYLE_OVERRIDE}} [[environment variable]]. Specifically, set it to {{ic|gtk2}} if you want to use the [[GTK+]] theme (Note: you will need to install the Qt style plugins mention below to get the GTK+ style). Qt5 applications also support the {{ic|-style}} flag, which you can use to launch a Qt5 application with a specific style.<br />
<br />
The following styles are included in Qt5: ''Fusion'', ''Windows''. Others can be installed from the official repositories:<br />
<br />
* {{App|Breeze|Artwork, styles and assets for the Breeze visual style for the Plasma Desktop.|https://cgit.kde.org/breeze.git|{{Pkg|breeze}}}}<br />
* {{App|Oxygen|KDE Oxygen style.|https://cgit.kde.org/oxygen.git|{{Pkg|oxygen}}}}<br />
* {{App|QtCurve|A configurable set of widget styles for KDE and Gtk.|https://cgit.kde.org/qtcurve.git|{{Pkg|qtcurve-qt5}}}}<br />
* {{App|Adwaita-Qt|A style to bend Qt applications to look like they belong into GNOME Shell.|https://github.com/MartinBriza/adwaita-qt|{{AUR|adwaita-qt5}}}}<br />
* {{App|Qt style plugins|Additional style plugins for Qt5, including ''GTK+'', ''Cleanlooks'', ''Motif'', ''Plastique''.|http://code.qt.io/cgit/qt/qtstyleplugins.git|{{Pkg|qt5-styleplugins}}}}<br />
* {{App|Kvantum|customizable SVG-based theme engine with a variety of built-in styles, including imitations of some popular GTK+ themes such as ''Adapta'', ''Arc'', ''Ambiance''|https://github.com/tsujan/Kvantum/tree/master/Kvantum|{{Pkg|kvantum-qt5}}}}<br />
<br />
=== Qt4 ===<br />
<br />
Qt4 application will try to mimic the behavior of the desktop environment they are running on, unless they run into some problems or hard-coded settings.<br />
<br />
* In KDE Plasma, it uses the actually selected Qt style. It can be configured using ''KDE System Settings'' (''systemsettings5''), the settings can be found in ''Appearance > Application Style > Widget Style''.<br />
* In Cinnamon, GNOME, Xfce, it uses GTK+ ([[Uniform look for Qt and GTK applications#QGtkStyle|QGtkStyle]]).<br />
* In other desktop environments, it uses Windows.<br />
<br />
For those who want to change the look and feel of Qt4 applications, the ''Qt Configuration'' (''qtconfig-qt4'') GUI tool is provided by the {{Pkg|qt4}} package. It offers a simple interface to configure the appearance of Qt4 applications including style, colors, fonts and some further options.<br />
<br />
{{Note|If you use ''GTK+'' style, then color and font settings will be ignored, and inherited from GTK+ 2.}}<br />
<br />
Qt keeps all its configuration information in {{ic|/etc/xdg/Trolltech.conf}} (system-wide) or {{ic|~/.config/Trolltech.conf}} (user-specific). The file is rather difficult to navigate because it contains a lot of information not related to appearance, but for any changes you can just add to the end of the file and overwrite any previous values (make sure to add your modification under the [Qt] header).<br />
<br />
For example, to change the theme to QtCurve, add:<br />
<br />
{{hc|~/.config/Trolltech.conf|<nowiki><br />
...<br />
[Qt]<br />
style=QtCurve<br />
</nowiki>}}<br />
<br />
The following styles are included in Qt4: ''CDE'', ''Cleanlooks'', ''GTK+'', ''Motif'', ''Plastique'', ''Windows''. Others can be installed from the official repositories or the [[AUR]] (most are written for KDE Plasma Desktop):<br />
<br />
* {{App|Breeze|Artwork, styles and assets for the Breeze visual style for the Plasma Desktop.|https://cgit.kde.org/breeze.git|{{Pkg|breeze-kde4}}{{Broken package link|{{aur-mirror|breeze-kde4}}}}}}<br />
* {{App|[[Wikipedia:Oxygen Project|Oxygen]]|KDE Oxygen style.|https://cgit.kde.org/oxygen.git|{{Pkg|oxygen-kde4}}{{Broken package link|{{aur-mirror|oxygen-kde4}}}}}}<br />
* {{App|QtCurve|A configurable set of widget styles for KDE and Gtk.|https://cgit.kde.org/qtcurve.git|{{Pkg|qtcurve-qt4}}}}<br />
* {{App|Adwaita-Qt| A style to bend Qt applications to look like they belong into GNOME Shell.|https://github.com/MartinBriza/adwaita-qt|{{AUR|adwaita-qt4}}}}<br />
<br />
=== Qt Style Sheets ===<br />
<br />
An interesting way of customizing the look and feel of a Qt application is using Style Sheets, which are just simple CSS files. Using Style Sheets, one can modify the appearance of every widget in the application.<br />
<br />
To run an application with a different style just execute:<br />
<br />
$ qt_application -stylesheet ''style.qss''<br />
<br />
For more information on Qt Style Sheets see the [http://doc.qt.io/qt-5/stylesheet-reference.html official documentation] or other [http://thesmithfam.org/blog/2009/09/10/qt-stylesheets-tutorial/ tutorials]. As an example Style Sheet see this [http://kde-apps.org/content/show.php/roxydoxy?content&#61;125979 Dolphin modification].<br />
<br />
=== GTK+ and Qt ===<br />
<br />
If you have GTK+ and Qt applications, their looks might not exactly blend in very well. If you wish to make your GTK+ styles match your Qt styles please read [[Uniform look for Qt and GTK applications]].<br />
<br />
=== Configuration of Qt5 apps under environments other than KDE Plasma ===<br />
<br />
Unlike Qt4, Qt5 does not ship a qtconfig utility to configure fonts, icons or styles. Instead, it will try to use the settings from the running desktop environment. In KDE Plasma or GNOME this works well, but in other less popular desktop environments or window managers it can lead to missing icons in Qt5 applications. One way to solve this is to fake the running desktop environment by setting {{ic|1=XDG_CURRENT_DESKTOP=KDE}} or {{ic|GNOME}}, and then using the corresponding configuration application to set the desired icon set.<br />
<br />
Another solution is provided by the {{pkg|qt5ct}} package, which provides a Qt5 QPA independent of the desktop environment and a configuration utility. After installing the package, run {{ic|qt5ct}} to set an icon theme, and set the [[environment variable]] {{ic|1=QT_QPA_PLATFORMTHEME="qt5ct"}} so that the settings are picked up by Qt applications. Alternatively, use {{ic|--platformtheme qt5ct}} as argument to the Qt5 application.<br />
<br />
If the below errors are received, and some icons still do not appear in some of the apps, install {{pkg|oxygen}} and {{pkg|oxygen-icons}}:<br />
<br />
Icon theme "oxygen" not found.<br />
Icon theme "oxygen" not found.<br />
Error: standard icon theme "oxygen" not found!<br />
<br />
== Development ==<br />
<br />
=== Supported platforms ===<br />
<br />
Qt supports most platforms that are available today, even some of the more obscure ones, with more ports appearing every once in a while. For a more complete list see the [[Wikipedia:Qt_(framework)#Platforms|Qt Wikipedia article]].<br />
<br />
==== Android ====<br />
<br />
First of all, you need an [[Android|Android SDK]] and NDK.<br />
Install SDK {{AUR|android-sdk}} (some tools have been removed) or {{AUR|android-sdk-25.2.5}} and NDK {{AUR|android-ndk-10e}} from [[AUR]] or using [[Android Studio]].<br />
It is highly recommended to install NDK version [https://developer.android.com/ndk/downloads/older_releases.html#ndk-10c-downloads 10e] because of some [https://wiki.qt.io/Qt_for_Android_known_issues known issues].<br />
Next you are going to need Qt 5 for Android. You can install it from [[AUR]] as described below or build it yourself, you can find build instructions on Qt [http://wiki.qt.io/Android wiki] page.<br />
<br />
* {{AUR|android-qt5-arm64-v8a}}{{Broken package link|package not found}} - arm64-v8a [https://developer.android.com/ndk/guides/abis.html ABI]<br />
* {{AUR|android-qt5-armeabi}}{{Broken package link|package not found}} - armeabi<br />
* {{AUR|android-armv7a-eabi-qt5}} - armeabi-v7a<br />
* {{AUR|android-qt5-mips}}{{Broken package link|package not found}} - mips<br />
* {{AUR|android-x86-qt5}} - x86<br />
* {{AUR|android-x86-64-qt5}} - x86_64<br />
<br />
Or you can use a [https://download.qt.io/official_releases/qt/5.11/5.11.1/qt-opensource-linux-x64-5.11.1.run Qt Installer], for a full list see [https://download.qt.io/official_releases/qt/ Official Qt installers].<br />
<br />
=== Tools ===<br />
<br />
The following are official Qt tools:<br />
<br />
* {{App|[[Wikipedia:Qt Creator|Qt Creator]]|A cross-platform IDE tailored for Qt that supports all of its features.|http://doc.qt.io/qtcreator/|{{Pkg|qtcreator}}}}<br />
* {{App|Qt Linguist|A set of tools that speed the translation and internationalization of Qt applications.|http://doc.qt.io/qt-5/qtlinguist-index.html|Qt 5: {{Pkg|qt5-tools}}, Qt 4: {{Pkg|qt4}}}}<br />
* {{App|Qt Assistant|A configurable and redistributable documentation reader for Qt ''qch'' files.|http://doc.qt.io/qt-5/qtassistant-index.html|Qt 5: {{Pkg|qt5-tools}}, Qt 4: {{Pkg|qt4}}}}<br />
* {{App|Qt Designer|A powerful cross-platform GUI layout and forms builder for Qt widgets.|http://doc.qt.io/qt-5/qtdesigner-manual.html|Qt 5: {{Pkg|qt5-tools}}, Qt 4: {{Pkg|qt4}}}}<br />
* {{App|Qt Quick Designer|A visual editor for QML files which supports WYSIWYG. It allows you to rapidly design and build Qt Quick applications and components from scratch.|http://doc.qt.io/qtcreator/creator-using-qt-quick-designer.html|{{Pkg|qtcreator}}}}<br />
* {{App|qmlscene|A tool for loading QML documents that makes it easy to quickly develop and debug QML applications.|http://doc.qt.io/qt-5/qtquick-qmlscene.html|Qt 5: {{Pkg|qt5-declarative}}, Qt 4 QML Viewer: {{Pkg|qt4}}}}<br />
* {{App|[[Wikipedia:Qmake|qmake]]|A tool that helps simplify the build process for development project across different platforms, similar to [[Wikipedia:CMake|cmake]], but with fewer options and tailored for Qt applications.|http://doc.qt.io/qt-5/qmake-manual.html|Qt 5: {{Pkg|qt5-base}}, Qt 4: {{Pkg|qt4}}}}<br />
* {{App|uic|A tool that reads ''*.ui'' XML files and generates the corresponding C++ files.|http://doc.qt.io/qt-5/uic.html|Qt 5: {{Pkg|qt5-base}}, Qt 4: {{Pkg|qt4}}}}<br />
* {{App|rcc|A tool that is used to embed resources (such as pictures) into a Qt application during the build process. It works by generating a C++ source file containing data specified in a Qt resource (.qrc) file.|http://doc.qt.io/qt-5/rcc.html|Qt 5: {{Pkg|qt5-base}}, Qt 4: {{Pkg|qt4}}}}<br />
* {{App|moc|A tool that handles Qt's C++ extensions (the signals and slots mechanism, the run-time type information, and the dynamic property system, etc.).|http://doc.qt.io/qt-5/moc.html|Qt 5: {{Pkg|qt5-base}}, Qt 4: {{Pkg|qt4}}}}<br />
<br />
=== Bindings ===<br />
<br />
Qt has bindings for all of the more popular languages, for a full list see [[Wikipedia:Qt (framework)#Programming language bindings|this list]].<br />
<br />
The following examples display a small 'Hello world!' message in a window.<br />
<br />
==== C++ ====<br />
<br />
* Package: <br />
** {{Pkg|qt4}} - Version 4.x of the Qt toolkit.<br />
** {{Pkg|qt5-base}} - Version 5.x of the Qt toolkit.<br />
* Website: http://qt-project.org/<br />
* Build: <br />
** The Qt4 version: {{ic|g++ $(pkg-config --cflags --libs QtGui) -o hello hello.cpp}}<br />
** The Qt5 version: {{ic|g++ $(pkg-config --cflags --libs Qt5Widgets) -fPIC -o hello hello.cpp}}<br />
* Run with: {{ic|./hello}}<br />
<br />
{{hc|hello.cpp|<br />
#include <QApplication><br />
#include <QLabel><br />
<br />
int main(int argc, char **argv)<br />
{<br />
QApplication app(argc, argv);<br />
QLabel hello("Hello world!");<br />
<br />
hello.show();<br />
return app.exec();<br />
}<br />
}}<br />
<br />
==== QML ====<br />
<br />
* Package: {{Pkg|qt4}} or {{Pkg|qt5-declarative}}.<br />
* Website: http://qt-project.org/<br />
* Run with: {{ic|qmlviewer-qt4 hello.qml}} or {{ic|qmlscene-qt5 hello.qml}}<br />
<br />
{{hc|hello.qml|<br />
import QtQuick 1.0<br />
<br />
Rectangle {<br />
id: page<br />
width: 400; height: 100<br />
color: "lightgray"<br />
<br />
Text {<br />
id: helloText<br />
text: "Hello world!"<br />
anchors.horizontalCenter: page.horizontalCenter<br />
anchors.verticalCenter: page.verticalCenter<br />
font.pointSize: 24; font.bold: true<br />
}<br />
}<br />
}}<br />
<br />
{{Note|For version 5.x of the Qt toolkit, we need to import QtQuick 2.y.}}<br />
<br />
==== Python (PyQt) ====<br />
<br />
* Package:<br />
** {{AUR|python-pyqt4}} - Python 3.x bindings for Qt 4<br />
** {{AUR|python2-pyqt4}} - Python 2.x bindings for Qt 4<br />
** {{Pkg|python-pyqt5}} - Python 3.x bindings for Qt 5<br />
** {{Pkg|python2-pyqt5}} - Python 2.x bindings for Qt 5<br />
<br />
* Website: http://www.riverbankcomputing.co.uk/software/pyqt/intro<br />
* Run with: {{ic|python hello-pyqt.py}} or {{ic|python2 hello-pyqt.py}}.<br />
<br />
{{hc|hello-pyqt.py|<nowiki><br />
import sys<br />
from PyQt4 import QtGui<br />
<br />
app = QtGui.QApplication(sys.argv)<br />
label = QtGui.QLabel("Hello world!")<br />
<br />
label.show()<br />
sys.exit(app.exec_())<br />
</nowiki>}}<br />
<br />
The Qt 5.x version is slighly different:<br />
{{hc|hello-pyqt.py|<nowiki><br />
import sys<br />
from PyQt5 import QtWidgets<br />
<br />
app = QtWidgets.QApplication(sys.argv)<br />
label = QtWidgets.QLabel("Hello world!")<br />
<br />
label.show()<br />
sys.exit(app.exec_())<br />
</nowiki>}}<br />
<br />
==== Python (PySide) ====<br />
<br />
* Package:<br />
** {{AUR|python-pyside}} - Python 3.x bindings<br />
** {{AUR|python2-pyside}} - Python 2.x bindings<br />
* Website: http://www.pyside.org/<br />
* Run with: {{ic|python hello-pyside.py}} or {{ic|python2 hello-pyside.py}}<br />
<br />
{{hc|hello-pyside.py|<nowiki><br />
import sys<br />
from PySide.QtCore import *<br />
from PySide.QtGui import *<br />
<br />
app = QApplication(sys.argv)<br />
label = QLabel("Hello world!")<br />
<br />
label.show()<br />
sys.exit(app.exec_())<br />
</nowiki>}}<br />
<br />
==== C# ====<br />
<br />
See [https://gitlab.com/ddobrev/QtSharp QtSharp].<br />
<br />
==== Ruby ====<br />
<br />
* Package: {{AUR|kdebindings-qtruby}}{{Broken package link|{{aur-mirror|kdebindings-qtruby}}}}<br />
* Website: http://rubyforge.org/projects/korundum/<br />
* Run with: {{ic|ruby hello.rb}}<br />
<br />
{{hc|hello.rb|<nowiki><br />
require 'Qt4'<br />
<br />
app = Qt::Application.new(ARGV)<br />
hello = Qt::Label.new('Hello World!')<br />
<br />
hello.show<br />
app.exec<br />
</nowiki>}}<br />
<br />
==== Perl ====<br />
<br />
* Package: {{AUR|kdebindings-perlqt}}{{Broken package link|{{aur-mirror|kdebindings-perlqt}}}}<br />
* Website: http://code.google.com/p/perlqt4/<br />
* Run with: {{ic|perl hello.pl}}<br />
<br />
{{hc|hello.pl|<nowiki><br />
use QtGui4;<br />
<br />
my $a = Qt::Application(\@ARGV);<br />
my $hello = Qt::Label("Hello World!", undef);<br />
<br />
$hello->show;<br />
exit $a->exec;<br />
</nowiki>}}<br />
<br />
==== Lua ====<br />
<br />
* Package: {{AUR|libqtlua}}{{Broken package link|{{aur-mirror|libqtlua}}}}<br />
* Website: http://www.nongnu.org/libqtlua/<br />
* Run with: {{ic|qtlua hello.lua}}<br />
<br />
{{hc|hello.lua|<nowiki><br />
label = qt.new_widget("QLabel")<br />
<br />
label:setText("Hello World!")<br />
label:show()<br />
</nowiki>}}<br />
<br />
{{Note|QtLua is not designed to develop an application in pure Lua but rather to extend a Qt C++ application using Lua as scripting language.}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Disable/Change Qt journal logging behaviour ===<br />
<br />
When using [[KDE]] and/or any other Qt [[desktop environment]] debug info may be frequently be logged in the [[systemd journal]].<br />
<br />
Set {{ic|QT_LOGGING_RULES}} as [[environment variable]] to change this behaviour, e.g. to completely disable logging:<br />
<br />
{{hc|/etc/environment|2=<br />
QT_LOGGING_RULES='*=false'<br />
}}<br />
<br />
To allow only debug logging, use {{ic|1=QT_LOGGING_RULES="*.debug=false"}}.<br />
<br />
=== Icon theme is not applied ===<br />
<br />
Since Qt 5.1 SVG support has moved into a module. Since {{Pkg|qt5-base}} does not depend on {{Pkg|qt5-svg}} it may happen that the {{Pkg|qt5-base}} is installed but not {{Pkg|qt5-svg}}. This results in deceptive icon theme behaviour. Since SVG is not supported the icons are silently skipped and the icon theme may seem to be unused. Installing {{Pkg|qt5-svg}} explicitly solves the problem.<br />
<br />
=== Theme not applied to root applications ===<br />
<br />
As the user theme file ({{ic|$XDG_CONFIG_HOME/Trolltech.conf}}), are not read by other accounts, the selected theme will not apply to [[Running_X_apps_as_root|X applications run as root]]. Possible solutions include:<br />
<br />
* Create symlinks, e.g {{bc|# ln -s /home/[username]/.config/Trolltech.conf /etc/xdg/Trolltech.conf}}<br />
* Configure system-wide theme file: {{ic|/etc/xdg/Trolltech.conf}}<br />
* Adjust the theme as root<br />
<br />
=== Qt4 style not respected ===<br />
<br />
If pure Qt4 (non-KDE) applications do not stick with your selected Qt4 style, then you will probably need to tell Qt4 how to find KDE's styles (Oxygen, Phase etc.). You just need to set the [[environment variable]] {{ic|QT_PLUGIN_PATH}}. E.g.:<br />
<br />
QT_PLUGIN_PATH=$HOME/.kde4/lib/kde4/plugins/:/usr/lib/kde4/plugins/<br />
<br />
{{ic|qtconfig-qt4}} should then be able to find your kde styles and everything should look nice again!<br />
<br />
Alternatively, you can symlink the Qt4 styles directory to the KDE4 styles one:<br />
<br />
# ln -s /usr/lib/{kde,qt}4/plugins/styles/''theme_name''<br />
<br />
=== All Qt5-based applications fail to run after Qt5 update ===<br />
<br />
If you get an error similar to<br />
<br />
Qt FATAL: Cannot mix incompatible Qt library (version 0x50900) with this library (version 0x50901)<br />
<br />
then you are most likely using a Qt5 platform theme or style plugin which has not been recompiled against the latest version of Qt5. These usually use Qt private headers which means they depend on an exact version of Qt and not just a matching soname. Figure out which theme/style you are using by checking the {{ic|QT_STYLE_OVERRIDE}} and {{ic|QT_QPA_PLATFORMTHEME}} environment variables, and rebuild the AUR package that provides it.<br />
<br />
== See also ==<br />
<br />
* [http://qt.io/ Official Website]<br />
* [http://doc.qt.io/ Qt Documentation]<br />
* [http://planet.qt.io/ Planet Qt]<br />
* [http://qt-apps.org/ Qt Applications]</div>Ivank