** Description changed: [ Impact ] QEMU processes spawned by Libvirt can't read /proc/sys/vm/max_map_count. This matters because as of QEMU v9.0.0 (commit 86a637e4), QEMU reads that file to limit the coroutine pool size. Without this change, QEMU processes spawned by Libvirt will read an incorrect value of vm.max_map_count, which has the effect of increasing the limit of pooled coroutines and thus can increase allocated VMAs. See the related LP: #2168803 for more info. This SRU blocks 2168803. The upstream fix adds the relevant path to the template AppArmor - profile. It has been merged since tag v10.7.0-rc1. + profile. It has been merged since tag v10.7.0-rc1, so only Noble is + affected. [ Test plan ] # Create a trivial domain in order to create a test AppArmor profile. 1. wget https://launchpadlibrarian.net/880886930/trivial.xml 2. virsh create trivial.xml --autodestroy # Test the trivial domain's AppArmor profile 3. ls /etc/apparmor.d/libvirt/ # find any profile here, ex: libvirt-4fcb5a29-1f28-43b0-96e6-029659a49394 4. aa-exec --profile libvirt-4fcb5a29-1f28-43b0-96e6-029659a49394 -- cat /proc/sys/vm/max_map_count # Fail output (before patch) - 5a. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-6e18aeb6-2af2-476b-b3f1-dc27578aea8b -- cat /proc/sys/vm/max_map_count + 5a. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-6e18aeb6-2af2-476b-b3f1-dc27578aea8b -- cat /proc/sys/vm/max_map_count cat: /proc/sys/vm/max_map_count: Permission denied # Success output (after patch) - 5b. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-38b3b5c2-3c08-4ac6-bf12-8992f4abed4f -- cat /proc/sys/vm/max_map_count + 5b. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-38b3b5c2-3c08-4ac6-bf12-8992f4abed4f -- cat /proc/sys/vm/max_map_count 1048576 # Cleanup 6. virsh destroy trivial.xml 7. sudo rm /etc/apparmor.d/libvirt/libvirt-[uuids used for testing] [ Regression risk ] The regression risk with adding a single entry to the Libvirt AppArmor template is such that every guest's emulator process spawned by Libvirt will have access to the aforementioned file listed in the profile by default. Technically speaking, if a guest-to-host escape is performed, then that means one more file will be allowed by AppArmor. However, this patch - only allows 'read' access, so this additon would only serve as an + only allows 'read' access, so this addition would only serve as an information source. QEMU necessarily needs to read the value of vm.max_map_count to calculate a sane limit for pooled coroutines. Every QEMU process that spawns after commit 86a637e4 will need to read this file, so it makes sense to make the change in the template. + `/proc/sys/vm/overcommit_memory` is already in the template, so this is + an established method for granting access to reading tunable values. [ Other info ] LP bug tracking QEMU SRU (LP: #2168803): https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2168803 Upstream Libvirt patch: https://gitlab.com/libvirt/libvirt/-/commit/85e07fb1ceee Upstream QEMU patch necesitating this change: https://gitlab.com/qemu-project/qemu/-/commit/86a637e4
** Description changed: [ Impact ] QEMU processes spawned by Libvirt can't read /proc/sys/vm/max_map_count. This matters because as of QEMU v9.0.0 (commit 86a637e4), QEMU reads that file to limit the coroutine pool size. Without this change, QEMU processes spawned by Libvirt will read an incorrect value of vm.max_map_count, which has the effect of increasing the limit of pooled coroutines and thus can increase allocated VMAs. See the related LP: #2168803 for more info. This SRU blocks 2168803. The upstream fix adds the relevant path to the template AppArmor profile. It has been merged since tag v10.7.0-rc1, so only Noble is - affected. + affected. Older releases like Jammy are not affected because QEMU + doesn't read the file there. [ Test plan ] # Create a trivial domain in order to create a test AppArmor profile. 1. wget https://launchpadlibrarian.net/880886930/trivial.xml 2. virsh create trivial.xml --autodestroy # Test the trivial domain's AppArmor profile 3. ls /etc/apparmor.d/libvirt/ # find any profile here, ex: libvirt-4fcb5a29-1f28-43b0-96e6-029659a49394 4. aa-exec --profile libvirt-4fcb5a29-1f28-43b0-96e6-029659a49394 -- cat /proc/sys/vm/max_map_count # Fail output (before patch) 5a. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-6e18aeb6-2af2-476b-b3f1-dc27578aea8b -- cat /proc/sys/vm/max_map_count cat: /proc/sys/vm/max_map_count: Permission denied # Success output (after patch) 5b. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-38b3b5c2-3c08-4ac6-bf12-8992f4abed4f -- cat /proc/sys/vm/max_map_count 1048576 # Cleanup 6. virsh destroy trivial.xml 7. sudo rm /etc/apparmor.d/libvirt/libvirt-[uuids used for testing] [ Regression risk ] The regression risk with adding a single entry to the Libvirt AppArmor template is such that every guest's emulator process spawned by Libvirt will have access to the aforementioned file listed in the profile by default. Technically speaking, if a guest-to-host escape is performed, then that means one more file will be allowed by AppArmor. However, this patch only allows 'read' access, so this addition would only serve as an information source. QEMU necessarily needs to read the value of vm.max_map_count to calculate a sane limit for pooled coroutines. Every QEMU process that spawns after commit 86a637e4 will need to read this file, so it makes sense to make the change in the template. `/proc/sys/vm/overcommit_memory` is already in the template, so this is an established method for granting access to reading tunable values. [ Other info ] LP bug tracking QEMU SRU (LP: #2168803): https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2168803 Upstream Libvirt patch: https://gitlab.com/libvirt/libvirt/-/commit/85e07fb1ceee Upstream QEMU patch necesitating this change: https://gitlab.com/qemu-project/qemu/-/commit/86a637e4 ** Description changed: [ Impact ] QEMU processes spawned by Libvirt can't read /proc/sys/vm/max_map_count. This matters because as of QEMU v9.0.0 (commit 86a637e4), QEMU reads that file to limit the coroutine pool size. Without this change, QEMU processes spawned by Libvirt will read an incorrect value of vm.max_map_count, which has the effect of increasing the limit of pooled coroutines and thus can increase allocated VMAs. See the related LP: #2168803 for more info. This SRU blocks 2168803. The upstream fix adds the relevant path to the template AppArmor profile. It has been merged since tag v10.7.0-rc1, so only Noble is affected. Older releases like Jammy are not affected because QEMU doesn't read the file there. [ Test plan ] # Create a trivial domain in order to create a test AppArmor profile. 1. wget https://launchpadlibrarian.net/880886930/trivial.xml - 2. virsh create trivial.xml --autodestroy + 2. virsh create trivial.xml # Test the trivial domain's AppArmor profile 3. ls /etc/apparmor.d/libvirt/ # find any profile here, ex: libvirt-4fcb5a29-1f28-43b0-96e6-029659a49394 4. aa-exec --profile libvirt-4fcb5a29-1f28-43b0-96e6-029659a49394 -- cat /proc/sys/vm/max_map_count # Fail output (before patch) 5a. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-6e18aeb6-2af2-476b-b3f1-dc27578aea8b -- cat /proc/sys/vm/max_map_count cat: /proc/sys/vm/max_map_count: Permission denied # Success output (after patch) 5b. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-38b3b5c2-3c08-4ac6-bf12-8992f4abed4f -- cat /proc/sys/vm/max_map_count 1048576 # Cleanup 6. virsh destroy trivial.xml 7. sudo rm /etc/apparmor.d/libvirt/libvirt-[uuids used for testing] [ Regression risk ] The regression risk with adding a single entry to the Libvirt AppArmor template is such that every guest's emulator process spawned by Libvirt will have access to the aforementioned file listed in the profile by default. Technically speaking, if a guest-to-host escape is performed, then that means one more file will be allowed by AppArmor. However, this patch only allows 'read' access, so this addition would only serve as an information source. QEMU necessarily needs to read the value of vm.max_map_count to calculate a sane limit for pooled coroutines. Every QEMU process that spawns after commit 86a637e4 will need to read this file, so it makes sense to make the change in the template. `/proc/sys/vm/overcommit_memory` is already in the template, so this is an established method for granting access to reading tunable values. [ Other info ] LP bug tracking QEMU SRU (LP: #2168803): https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2168803 Upstream Libvirt patch: https://gitlab.com/libvirt/libvirt/-/commit/85e07fb1ceee Upstream QEMU patch necesitating this change: https://gitlab.com/qemu-project/qemu/-/commit/86a637e4 ** Description changed: [ Impact ] QEMU processes spawned by Libvirt can't read /proc/sys/vm/max_map_count. This matters because as of QEMU v9.0.0 (commit 86a637e4), QEMU reads that file to limit the coroutine pool size. Without this change, QEMU processes spawned by Libvirt will read an incorrect value of vm.max_map_count, which has the effect of increasing the limit of pooled coroutines and thus can increase allocated VMAs. See the related LP: #2168803 for more info. This SRU blocks 2168803. The upstream fix adds the relevant path to the template AppArmor profile. It has been merged since tag v10.7.0-rc1, so only Noble is affected. Older releases like Jammy are not affected because QEMU doesn't read the file there. [ Test plan ] # Create a trivial domain in order to create a test AppArmor profile. 1. wget https://launchpadlibrarian.net/880886930/trivial.xml 2. virsh create trivial.xml # Test the trivial domain's AppArmor profile - 3. ls /etc/apparmor.d/libvirt/ # find any profile here, ex: libvirt-4fcb5a29-1f28-43b0-96e6-029659a49394 + 3. ls /etc/apparmor.d/libvirt/ # find the new profile here, ex: libvirt-4fcb5a29-1f28-43b0-96e6-029659a49394 4. aa-exec --profile libvirt-4fcb5a29-1f28-43b0-96e6-029659a49394 -- cat /proc/sys/vm/max_map_count # Fail output (before patch) 5a. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-6e18aeb6-2af2-476b-b3f1-dc27578aea8b -- cat /proc/sys/vm/max_map_count cat: /proc/sys/vm/max_map_count: Permission denied # Success output (after patch) 5b. [email protected]@legitness:~/Work/vm/450187$ aa-exec --profile libvirt-38b3b5c2-3c08-4ac6-bf12-8992f4abed4f -- cat /proc/sys/vm/max_map_count 1048576 # Cleanup 6. virsh destroy trivial.xml 7. sudo rm /etc/apparmor.d/libvirt/libvirt-[uuids used for testing] [ Regression risk ] The regression risk with adding a single entry to the Libvirt AppArmor template is such that every guest's emulator process spawned by Libvirt will have access to the aforementioned file listed in the profile by default. Technically speaking, if a guest-to-host escape is performed, then that means one more file will be allowed by AppArmor. However, this patch only allows 'read' access, so this addition would only serve as an information source. QEMU necessarily needs to read the value of vm.max_map_count to calculate a sane limit for pooled coroutines. Every QEMU process that spawns after commit 86a637e4 will need to read this file, so it makes sense to make the change in the template. `/proc/sys/vm/overcommit_memory` is already in the template, so this is an established method for granting access to reading tunable values. [ Other info ] LP bug tracking QEMU SRU (LP: #2168803): https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2168803 Upstream Libvirt patch: https://gitlab.com/libvirt/libvirt/-/commit/85e07fb1ceee Upstream QEMU patch necesitating this change: https://gitlab.com/qemu-project/qemu/-/commit/86a637e4 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2170732 Title: AppArmor fix for LP2168803; reads from /proc/sys/vm/max_map_count denied To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/2170732/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
