QEMU 2.10 may require AppArmor updates for pflash devices

[dann frazier]

From: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1710019/comments/5

I've been testing w/ local QEMU builds on ARM64 and I've found that, starting at commit:
  244a56681 file-posix: Add image locking to perm operations

My test case (attached to this bug) began to fail with:

error: Failed to start domain 7936-0
error: internal error: process exited while connecting to monitor:
2017-08-14T23:43:10.255604Z qemu-system-aarch64: -drive
file=/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd,if=pflash,format=raw,unit=0,readonly=on:
Failed to unlock byte 100
2017-08-14T23:43:10.255750Z qemu-system-aarch64: -drive
file=/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd,if=pflash,format=raw,unit=0,readonly=on:
Failed to unlock byte 100
2017-08-14T23:43:10.255936Z qemu-system-aarch64: -drive
file=/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd,if=pflash,format=raw,unit=0,readonly=on:
Failed to lock byte 100

[Christian Ehrhardt  (paelzer)]

Thanks for spawning off that bug from the former discussion Dann!
I'd really like to see the associated dmesg for the expected apparmor denial to be confirmed.

Given your XML was able to check what we get generated (stripped down to the interesting bits).
$ ./src/virt-aa-helper --create --dryrun --uuid 'libvirt-bead65d7-c9ed-4cdc-9a2c-953fbb59faf8' < ~/Downloads/5531-0.xml
  "/home/ubuntu/vm-start-stop/vms/5531-0.img" rwk,
  "/home/ubuntu/vm-start-stop/vms/5531-0_CODE.fd" r,
  # don't audit writes to readonly files
  deny "/home/ubuntu/vm-start-stop/vms/5531-0_CODE.fd" w,
  "/home/ubuntu/vm-start-stop/vms/5531-0_VARS.fd" rw,

So we have an explicit readonly and the new code is trying a lock.
The deny is to have writes not fill up logs and deny silently.
Very likely we need (mind the k there):
  "/home/ubuntu/vm-start-stop/vms/5531-0_CODE.fd" rk,

If you want you can try to tune "/etc/apparmor.d/libvirt/libvirt-<uuid>" before the include to the .files (or in /etc/apparmor.d/abstractions/libvirt-qemu for all guests) with rules to allow that if that unblocks you.

I'm not sure if locking requires write in the apparmor way of thinking.
In the worst case the explcit deny wil hide that - so consider removing it if you see nothing.

Looking forward to the dmesg to confirm

[dann frazier (dannf)]

dmesg from after failed start:

[145199.354628] audit: type=1400 audit(1502895136.129:117): apparmor="DENIED" operation="open" profile="virt-aa-helper" name="/proc/34702/auxv" pid=34702 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[145199.354634] audit: type=1400 audit(1502895136.129:118): apparmor="DENIED" operation="open" profile="virt-aa-helper" name="/proc/34702/auxv" pid=34702 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[145199.925267] audit: type=1400 audit(1502895136.700:119): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-261702e0-efa8-4263-a187-570844c1308f" pid=34704 comm="apparmor_parser"
[145200.108591] audit: type=1400 audit(1502895136.883:120): apparmor="DENIED" operation="file_lock" profile="libvirt-261702e0-efa8-4263-a187-570844c1308f" name="/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd" pid=34708 comm="qemu-system-aar" requested_mask="k" denied_mask="k" fsuid=64055 ouid=1000
[145200.108597] audit: type=1400 audit(1502895136.883:121): apparmor="DENIED" operation="file_lock" profile="libvirt-261702e0-efa8-4263-a187-570844c1308f" name="/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd" pid=34708 comm="qemu-system-aar" requested_mask="k" denied_mask="k" fsuid=64055 ouid=1000
[145200.108745] audit: type=1400 audit(1502895136.883:122): apparmor="DENIED" operation="file_lock" profile="libvirt-261702e0-efa8-4263-a187-570844c1308f" name="/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd" pid=34708 comm="qemu-system-aar" requested_mask="k" denied_mask="k" fsuid=64055 ouid=1000
[145200.869690] audit: type=1400 audit(1502895137.644:123): apparmor="STATUS" operation="profile_remove" profile="unconfined" name="libvirt-261702e0-efa8-4263-a187-570844c1308f" pid=34725 comm="apparmor_parser"

[dann frazier (dannf)]

I confirmed that adding these lines to the libvirt profile allows me to start the guest (I assume the first two are already covered by the other bug).

  "/home/ubuntu/vm-start-stop/vms/7936-0.img" rwk,
  "/home/ubuntu/vm-start-stop/zesty-server-cloudimg-arm64.img" rk,
  "/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd" rk,
  "/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd" rk,

[Christian Ehrhardt  (paelzer)]

On Wed, Aug 16, 2017 at 6:48 PM, dann frazier <email address hidden>
wrote:

> I confirmed that adding these lines to the libvirt profile allows me to
> start the guest (I assume the first two are already covered by the other
> bug).
>
> "/home/ubuntu/vm-start-stop/vms/7936-0.img" rwk,
> "/home/ubuntu/vm-start-stop/zesty-server-cloudimg-arm64.img" rk,
>

Those are the two already fixed in latest libvirt, thanks for checking.

> "/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd" rk,
> "/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd" rk,
>

Those two are the new ones - thanks.
With that I can dev a patch tmrw that fixes that.

One thing thou - you added the k to both.
But the Denies were only about the _CODE.
Would with only one getting the k permission the other one be the one
failing?

[dann frazier (dannf)]

On Wed, Aug 16, 2017 at 11:44 AM, ChristianEhrhardt
<email address hidden> wrote:
> On Wed, Aug 16, 2017 at 6:48 PM, dann frazier <email address hidden>
> wrote:
>
>> I confirmed that adding these lines to the libvirt profile allows me to
>> start the guest (I assume the first two are already covered by the other
>> bug).
>>
>> "/home/ubuntu/vm-start-stop/vms/7936-0.img" rwk,
>> "/home/ubuntu/vm-start-stop/zesty-server-cloudimg-arm64.img" rk,
>>
>
> Those are the two already fixed in latest libvirt, thanks for checking.
>
>
>> "/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd" rk,
>> "/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd" rk,
>>
>
> Those two are the new ones - thanks.
> With that I can dev a patch tmrw that fixes that.

Great!

> One thing thou - you added the k to both.
> But the Denies were only about the _CODE.
> Would with only one getting the k permission the other one be the one
> failing?

Correct. I tried adding 'k' only to _CODE, but subsequent start
attempts started reporting errors with _VARS:

ubuntu@grotrian:~$ sudo virsh start 7936-0
error: Failed to start domain 7936-0
error: internal error: process exited while connecting to monitor:
2017-08-16T16:44:36.708278Z qemu-system-aarch64: -drive
file=/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd,if=pflash,format=raw,unit=1:
Failed to unlock byte 100
2017-08-16T16:44:36.708431Z qemu-system-aarch64: -drive
file=/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd,if=pflash,format=raw,unit=1:
Failed to unlock byte 100
2017-08-16T16:44:36.708662Z qemu-system-aarch64: -drive
file=/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd,if=pflash,format=raw,unit=1:
Failed to lock byte 100

I gather QEMU only attempts to lock _VARS once it has successfully
acquired a lock on _CODE.

  -dann

[Christian Ehrhardt  (paelzer)]

Thanks Dannf, that confirmed all I needed.
Writing the upstream fix and adding it to next libvirt upload into artful.

While at it I looked around for other candidates which might qualify for a related issue.
External kernel/initrd came to my mind, but that was not affected.

[Christian Ehrhardt  (paelzer)]

Upstreaming at https://www.redhat.com/archives/libvir-list/2017-August/msg00483.html
Using that as a patch already and pushing to artful for you to verify (it worked for me, but better be sure).

The bug should get the usual auto-update once it migrated, then please retest.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 3.6.0-1ubuntu2

---------------
libvirt (3.6.0-1ubuntu2) artful; urgency=medium

  * d/p/ubuntu-aa/0036-virt-aa-helper-locking-loader-nvram-for-qemu-2.10.patch:
    for compatibility with the behavior of qemu 2.10 this adds locking
    permission to rules generated for loader/nvram (LP: #1710960)

 -- Christian Ehrhardt <email address hidden> Thu, 17 Aug 2017 10:00:19 +0200

[dann frazier (dannf)]

On Thu, Aug 17, 2017 at 4:19 AM, ChristianEhrhardt
<email address hidden> wrote:
> Upstreaming at https://www.redhat.com/archives/libvir-list/2017-August/msg00483.html
> Using that as a patch already and pushing to artful for you to verify (it worked for me, but better be sure).

Thanks, verified!

 -dann