Ubuntu
libvirt package

Apparmor deny when trying to use hugetlbfs

Bug #646468 reported by mik
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Fix Released
Low
Serge Hallyn

Bug Description

When starting a VM with hugepages support, I get an apparmor deny message and the VM starts with normal pages.

dmesg shows:
[ 449.428584] type=1400 audit(1285282448.505:47): apparmor="DENIED" operation="mknod" parent=1 profile="libvirt-e2420e79-06d6-f8d0-0523-7c52b3650191" name="/dev/hugepages/libvirt/qemu/kvm.2DUKKZ" pid=3325 comm="kvm" requested_mask="c" denied_mask="c" fsuid=103 ouid=103

# lsb_release -rd
Description: Ubuntu maverick (development branch)
Release: 10.10

To reproduce, I did this:

echo "hugetlbfs /dev/hugepages hugetlbfs defaults 0 0" >> /etc/fstab
echo "vm.nr_hugepages = 1024" >> /etc/sysctl.conf

WARNING: this will use 2G of RAM. Don't try to apply sysctl settings on a running system...

Added to my domain xml (somewhere under the domain tag):
<memoryBacking><hugepages/></memoryBacking>

Then rebooted and tried to start the domain.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Can you add this to /etc/apparmor.d/abstractions/libvirt-qemu:
  owner /dev/hugepages/libvirt/qemu/* w,

and try again?

Changed in libvirt (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
status: New → Incomplete
Jamie Strandboge (jdstrand)
tags: added: apparmor
Revision history for this message
mik (therealmik) wrote :

Ok, that was closer, but this time I get the message:

[84836.383289] type=1400 audit(1285366835.469:59): apparmor="DENIED" operation="open" parent=1 profile="libvirt-e2420e79-06d6-f8d0-0523-7c52b3650191" name="/dev/hugepages/libvirt/qemu/kvm.3Ag3N7" pid=1149 comm="kvm" requested_mask="r" denied_mask="r" fsuid=103 ouid=103

When I changed it to "rw" it worked... But does that mean that guests can read each others' memory (if compromised)?

Revision history for this message
mik (therealmik) wrote :

Just a follow-up...

This actually does work, and since qemu seems to unlink() right after the mkstemp() there's only a small race condition there, and after that the only way to steal another VMs memory is via procfs.

Is it worth writing a small doc (or debconf option?) to help people setup hugetlbfs with libvirt?

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I read about how it unlinks after creation, so I think in general have just a commented line like this in /etc/apparmor.d/abstractions/libvirt-qemu is ok:
  # Uncomment the following line to enable huge pages in your guests.
  # owner /dev/hugepages/libvirt/qemu/* rw,

It would be better if libvirt could do this dynamically like it does with disks, etc (the SELinux driver may already do this). This should be investigated.

Changed in libvirt (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Low
assignee: Jamie Strandboge (jdstrand) → nobody
Revision history for this message
nutznboltz (nutznboltz-deactivatedaccount) wrote :

Look at this PPA
https://launchpad.net/~jcollins/+archive/jaminppa

Revision history for this message
mik (therealmik) wrote :

A better way to do it would be to modify libvirt to create a directory on the hugetlbfs for the vm (not just for itself), then pass that as the mem-path to kvm and tell the sVirt driver about it somehow.

Serge Hallyn (serge-hallyn)
Changed in libvirt (Ubuntu):
assignee: nobody → Serge Hallyn (serge-hallyn)
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libvirt - 1.0.0-0ubuntu4

---------------
libvirt (1.0.0-0ubuntu4) raring; urgency=low

  * debian/patches/apparmor-allow-hugepages: update apparmor policies to
    allow use of hugepages. (LP: #646468)
  * debian/patches/vnc-socket.patch: If a vnc socket is in use, add it's
    path to the apparmor policy. (LP: #1069534)
 -- Serge Hallyn <email address hidden> Wed, 05 Dec 2012 16:43:04 -0600

Changed in libvirt (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.