Comment 35 for bug 1594902

Thanks to tyhicks from the security Team here some guidance how to go for step 2 of comment #30.
If anybody is hitting this issue again, please help to verify this before applying any of the workarounds summarized by Hans in comment #20.

To do so follow this:

# There are several moving parts involved:
#
# 1. The human readable profile
# 2. The binary cache file
# 3. The policy loaded into the kernel

# Save off the binary cache file
$ sudo mv /etc/apparmor.d/cache/usr.sbin.libvirtd /tmp/usr.sbin.libvirtd.oldcache

# Create a new binary cache file from the human readable profile (but do not load it) and save it off
$ sudo apparmor_parser -TWQ /etc/apparmor.d/usr.sbin.libvirtd
$ sudo mv /etc/apparmor.d/cache/usr.sbin.libvirtd /tmp/usr.sbin.libvirtd.newcache

# Verify that the old and new binary cache file matches the policy in the kernel
#
# Note: The in kernel path has an integer is appended to the end of the profile
# name and I can't tell you what the integer will be ahead of time, so use wildcard
$ sudo sha1sum /sys/kernel/security/apparmor/policy/profiles/usr.sbin.libvirtd.*/raw_data /tmp/usr.sbin.libvirtd.*
bbdf01649dd59ab1bd3d3696788aa0be9f6f6b03 /sys/kernel/security/apparmor/policy/profiles/usr.sbin.libvirtd.18/raw_data
bbdf01649dd59ab1bd3d3696788aa0be9f6f6b03 /tmp/usr.sbin.libvirtd.newcache
bbdf01649dd59ab1bd3d3696788aa0be9f6f6b03 /tmp/usr.sbin.libvirtd.oldcache

# If all hashes match, then it means that the profile, binary cache, and
# in-kernel policy are all in sync

But if in the error case all hashes would match it would make no sense that reloading the profiles helps as reported multiple times. So lets hope we can confirm this once somebody hits it again.