virtualizer: enforce maximum system resources a virtual machine may use

[phabricator-migrator]

Information

ID: 12
PHID: PHID-TASK-igsd5s4aupeexzb2hajg
Author: Patrick
Status at Migration Time: open
Priority at Migration Time: Normal

Description

An adversary could stress either/and CPU, HDD, RAM, network connection and other Whonix-Workstations and perhaps also the host would suffer. This is bad:

• attacks on anonymity when using multiple workstations (whether behind same gateway or not)
• host ddos

Virtual machines (VM) can use an unlimited amount of resources. I.e.

• CPU load
• network load
• I/O (hdd) load
• graphic calculation load
• (RAM load?)

This might happen because some application inside a VM has a bug and starts draining resources or because a VM has been compromised.

Ideally the virtualizer on the host would enforce maximum system resources the VM may use.

This ticket is a reminder to implement this protection for all virtualizers supported by Whonix some day.

If someone wants to implement this feature for a particular virtualizer, please create a sub task to keep things separated.

Related:
T530

Comments

---

HulaHoop

2015-05-25 01:16:14 UTC

For CPU, setting the Linux scheduler to the Nice level for a VM process can limit effect of CPU DoS. Using cgroups, virtual machines can also be restricted to CPU limits which supports the prevention of denial of service.

For memory, reducing or disabling swap puts limits on memory DoS.

Even without any changes to Host DoS can be effectively mitigated:
Limiting the number of logical CPUs for a VM in its settings limits the amount of Host cores it can use.
Linux’s OOM-killer will identify and kill the offending VM process if causing the host to run out of memory.

---

HulaHoop

2015-06-07 15:52:15 UTC

virsh can set disk activity limits per vm:

7.4. Block I/O Tuning Techniques Red Hat Enterprise Linux 7 | Red Hat Customer Portal

---

Patrick

2016-11-11 14:45:00 UTC

! In T567#10647, @HulaHoop wrote:
blkiotune and iotune can restrict io (KVM only)

libvirt: Domain XML format

---

HulaHoop

2016-11-11 23:20:08 UTC

There’s a problem with setting this. SSD vs HDD io throughput is very different. What is reasonable for one will be excessive or too low for the other.

---

Patrick

2016-11-12 02:22:12 UTC

HulaHoop (HulaHoop):

HulaHoop added a comment.

There’s a problem with setting this. SSD vs HDD io throughput is very different. What is reasonable for one will be excessive or too low for the other.

Set the limit to protect against excessive use of SSD then. SSD users
are better off then and HDD users not any worse. (HDD users would have
to manually adjust that value.) (Or auto detect somehow?)

---

HulaHoop

2016-11-19 04:39:21 UTC

Though I agree with anonym’s argument that resource exhaustion goes against the purpose of advanced malware that wants to hide - I still looked at io limits in case you still think its valuable to set.

Turns out blkiotune can partition resources using “weighting” aka percentage besides setting arbitrary limits.

I think by “host block device” they refer to the physical device /dev/sda rather than getting into partition numbers like sda2. The latter would have made this option very messy.

https://www.debian.org/releases/stable/i386/apcs04.html.en

libvirt: Domain XML format

---

Patrick

2016-11-19 17:51:30 UTC

HulaHoop (HulaHoop):

HulaHoop added a comment.

Though I agree with anonym’s argument that resource exhaustion goes
against the purpose of advanced malware that wants to hide

Maybe. However, I wouldn’t assume that no type of malware ever tries
resource exhaustion.

I still looked at io limits in case you still think its valuable to set.

Yes, very much worthwhile. Should have always been a standard feature of
any virtualizer. It’s what one can reasonably expect, that no VM (or
application) is capable to exhaust resources so everything else suffers.
Even if not malware, but just a bug, it still is a huge usability issue
to run into cases where one thing can look up the whole computer.

---

HulaHoop

2016-11-20 15:16:05 UTC

Should limits be enforced for GW too?

---

Patrick

2016-11-20 16:07:43 UTC

Yes.

---

HulaHoop

2016-11-27 23:18:37 UTC

Done. Added io limit commits to open pull requests. Each vm can only use a maximum of 25% of the host io resources.

---

Patrick

2019-12-22 08:26:44 UTC

cgroups were mentioned by @madaidan

Cgroups may be a better option for that. Systemd uses cgroups and user sessions are run under a systemd slice by default AFAIK so we can just edit that systemd.resource-control

---

madaidan

2019-12-23 19:54:30 UTC

We should be able to create a drop-in file at /lib/systemd/system/user-.slice.d/ and add something such as

[Slice]
MemoryAccounting=yes
MemoryMax=4G

which would prevent all users from using more than 4gb of memory.

There’s more documentation on user slices at user@.service