| 2022-09-08 08:36:27 |
Paride Legovini |
bug |
|
|
added bug |
| 2022-09-08 08:36:42 |
Paride Legovini |
bug |
|
|
added subscriber J. S. Seldenthuis |
| 2022-09-08 08:36:48 |
Paride Legovini |
bug |
|
|
added subscriber Ubuntu Server |
| 2022-09-08 08:36:57 |
Paride Legovini |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-09-08 08:36:57 |
Paride Legovini |
bug task added |
|
libvirt (Ubuntu Jammy) |
|
| 2022-09-08 08:37:05 |
Paride Legovini |
libvirt (Ubuntu Jammy): status |
New |
Triaged |
|
| 2022-09-08 08:37:09 |
Paride Legovini |
libvirt (Ubuntu): status |
New |
Fix Released |
|
| 2022-09-08 08:37:14 |
Paride Legovini |
tags |
|
server-todo |
|
| 2022-09-08 08:37:35 |
Paride Legovini |
bug watch added |
|
https://gitlab.com/libvirt/libvirt/-/issues/312 |
|
| 2022-09-08 08:37:35 |
Paride Legovini |
bug task added |
|
libvirt |
|
| 2022-09-08 09:53:44 |
Bug Watch Updater |
libvirt: status |
Unknown |
Fix Released |
|
| 2022-09-08 10:04:05 |
Christian Ehrhardt |
libvirt (Ubuntu Jammy): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2022-09-08 10:04:19 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/429630 |
|
| 2022-09-08 10:12:08 |
Christian Ehrhardt |
description |
[Filing https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1709818/comments/8 as a separate bug report. Thanks J. S. Seldenthuis (jseldent) for reporting it.]
Qemu tries to lock the uefi firmware image during vm creation, but the libvirt-supplied apparmor profile prevents this for the AAVMF firmware, and qemu fails with:
qemu-system-arm: Failed to lock byte 100
The solution is adding the "k" flag to the relevant apparmor profile. This is fixed upstream by this commit:
https://gitlab.com/libvirt/libvirt/-/commit/2b98d5d91d95087d8a96d6450fa96414ed05ba5c
which is already included in the libvirt version in Kinetic. |
[ Impact ]
* Qemu on arm64 changed behavior now trying to ensure exclusivity on the
AAVM files used by OVMF. That is stopped by apparmor and needs to be
allowed to function again (as it used to prior to jammy before the
locking took place).
* The fix does not change the code, instead it changes the rule for
the specific path in the guest-associated apparmor rule and
adds "k" (=locking) to it.
[ Test Plan ]
* On arm64 you can try to spawn an OVMF using test system
(from the upstream report):
$ virt-install --name test --ram 1024 --vcpus 2 --disk size=16 --location https://ftp.debian.org/debian/dists/bullseye/main/installer-arm64/ --osinfo debian11 --graphics none --tpm none --boot uefi
Without the fix that will emit an apparmor denial like:
apparmor="DENIED" operation="file_lock" profile="libvirt-2c81aaf3-2e3d-44a3-9acb-0e1e3c9bd54c" name="/usr/share/AAVMF/AAVMF_CODE.fd" pid=323963 comm="qemu-system-aa>
With the fix that apparmor denial will not occur and it reaches further
stages of guest initialization.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* a return of bug 1709818 but for a different file type
---
[Filing https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1709818/comments/8 as a separate bug report. Thanks J. S. Seldenthuis (jseldent) for reporting it.]
Qemu tries to lock the uefi firmware image during vm creation, but the libvirt-supplied apparmor profile prevents this for the AAVMF firmware, and qemu fails with:
qemu-system-arm: Failed to lock byte 100
The solution is adding the "k" flag to the relevant apparmor profile. This is fixed upstream by this commit:
https://gitlab.com/libvirt/libvirt/-/commit/2b98d5d91d95087d8a96d6450fa96414ed05ba5c
which is already included in the libvirt version in Kinetic. |
|
| 2022-09-08 10:17:43 |
Christian Ehrhardt |
description |
[ Impact ]
* Qemu on arm64 changed behavior now trying to ensure exclusivity on the
AAVM files used by OVMF. That is stopped by apparmor and needs to be
allowed to function again (as it used to prior to jammy before the
locking took place).
* The fix does not change the code, instead it changes the rule for
the specific path in the guest-associated apparmor rule and
adds "k" (=locking) to it.
[ Test Plan ]
* On arm64 you can try to spawn an OVMF using test system
(from the upstream report):
$ virt-install --name test --ram 1024 --vcpus 2 --disk size=16 --location https://ftp.debian.org/debian/dists/bullseye/main/installer-arm64/ --osinfo debian11 --graphics none --tpm none --boot uefi
Without the fix that will emit an apparmor denial like:
apparmor="DENIED" operation="file_lock" profile="libvirt-2c81aaf3-2e3d-44a3-9acb-0e1e3c9bd54c" name="/usr/share/AAVMF/AAVMF_CODE.fd" pid=323963 comm="qemu-system-aa>
With the fix that apparmor denial will not occur and it reaches further
stages of guest initialization.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* a return of bug 1709818 but for a different file type
---
[Filing https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1709818/comments/8 as a separate bug report. Thanks J. S. Seldenthuis (jseldent) for reporting it.]
Qemu tries to lock the uefi firmware image during vm creation, but the libvirt-supplied apparmor profile prevents this for the AAVMF firmware, and qemu fails with:
qemu-system-arm: Failed to lock byte 100
The solution is adding the "k" flag to the relevant apparmor profile. This is fixed upstream by this commit:
https://gitlab.com/libvirt/libvirt/-/commit/2b98d5d91d95087d8a96d6450fa96414ed05ba5c
which is already included in the libvirt version in Kinetic. |
[ Impact ]
* Qemu on arm64 changed behavior now trying to ensure exclusivity on the
AAVM files used by OVMF. That is stopped by apparmor and needs to be
allowed to function again (as it used to prior to jammy before the
locking took place).
* The fix does not change the code, instead it changes the rule for
the specific path in the guest-associated apparmor rule and
adds "k" (=locking) to it.
[ Test Plan ]
* On arm64 you can try to spawn an OVMF using test system
(from the upstream report):
$ virt-install --name test --ram 1024 --vcpus 2 --disk size=16 --location https://ftp.debian.org/debian/dists/bullseye/main/installer-arm64/ --osinfo debian11 --graphics none --tpm none --boot uefi
Without the fix that will emit an apparmor denial like:
apparmor="DENIED" operation="file_lock" profile="libvirt-2c81aaf3-2e3d-44a3-9acb-0e1e3c9bd54c" name="/usr/share/AAVMF/AAVMF_CODE.fd" pid=323963 comm="qemu-system-aa>
With the fix that apparmor denial will not occur and it reaches further
stages of guest initialization.
[ Where problems could occur ]
* Since it "only" changes apparmor rules and in doing so only "widens"
what is allowed there should be not many problems, those I can think of
are
- Conffile churn: this changes a conffile and despit all documentation
pointers and hints to use a local override some people have changes.
So we might override some of those or at least trigger conffile
prompts.
- Usually restricting apparmor is more risky than opening it up. The
one pattern that could happen is that in some places something
"expected to fail will now work. But that is the purpose of the fix.
- gladly AAVMF is only used for arm, so other platforms should be
"even more unaffected"
[ Other Info ]
* a return of bug 1709818 but for a different file type
---
[Filing https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1709818/comments/8 as a separate bug report. Thanks J. S. Seldenthuis (jseldent) for reporting it.]
Qemu tries to lock the uefi firmware image during vm creation, but the libvirt-supplied apparmor profile prevents this for the AAVMF firmware, and qemu fails with:
qemu-system-arm: Failed to lock byte 100
The solution is adding the "k" flag to the relevant apparmor profile. This is fixed upstream by this commit:
https://gitlab.com/libvirt/libvirt/-/commit/2b98d5d91d95087d8a96d6450fa96414ed05ba5c
which is already included in the libvirt version in Kinetic. |
|
| 2022-09-12 06:38:52 |
Christian Ehrhardt |
libvirt (Ubuntu Jammy): status |
Triaged |
In Progress |
|
| 2022-10-04 22:56:52 |
Chris Halse Rogers |
libvirt (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2022-10-04 22:56:55 |
Chris Halse Rogers |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-10-04 22:56:57 |
Chris Halse Rogers |
bug |
|
|
added subscriber SRU Verification |
| 2022-10-04 22:57:02 |
Chris Halse Rogers |
tags |
server-todo |
server-todo verification-needed verification-needed-jammy |
|
| 2022-10-05 08:26:16 |
Christian Ehrhardt |
tags |
server-todo verification-needed verification-needed-jammy |
server-todo verification-done verification-done-jammy |
|
| 2022-10-17 13:30:35 |
Launchpad Janitor |
libvirt (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2022-10-17 13:30:43 |
Timo Aaltonen |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2022-10-19 13:59:56 |
Michał Małoszewski |
tags |
server-todo verification-done verification-done-jammy |
verification-done verification-done-jammy |
|
| 2023-01-09 07:10:35 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Focal |
|
| 2023-01-09 07:10:35 |
Christian Ehrhardt |
bug task added |
|
libvirt (Ubuntu Focal) |
|
| 2023-01-09 07:11:29 |
Christian Ehrhardt |
libvirt (Ubuntu Focal): status |
New |
Triaged |
|
| 2023-01-09 07:30:21 |
Christian Ehrhardt |
description |
[ Impact ]
* Qemu on arm64 changed behavior now trying to ensure exclusivity on the
AAVM files used by OVMF. That is stopped by apparmor and needs to be
allowed to function again (as it used to prior to jammy before the
locking took place).
* The fix does not change the code, instead it changes the rule for
the specific path in the guest-associated apparmor rule and
adds "k" (=locking) to it.
[ Test Plan ]
* On arm64 you can try to spawn an OVMF using test system
(from the upstream report):
$ virt-install --name test --ram 1024 --vcpus 2 --disk size=16 --location https://ftp.debian.org/debian/dists/bullseye/main/installer-arm64/ --osinfo debian11 --graphics none --tpm none --boot uefi
Without the fix that will emit an apparmor denial like:
apparmor="DENIED" operation="file_lock" profile="libvirt-2c81aaf3-2e3d-44a3-9acb-0e1e3c9bd54c" name="/usr/share/AAVMF/AAVMF_CODE.fd" pid=323963 comm="qemu-system-aa>
With the fix that apparmor denial will not occur and it reaches further
stages of guest initialization.
[ Where problems could occur ]
* Since it "only" changes apparmor rules and in doing so only "widens"
what is allowed there should be not many problems, those I can think of
are
- Conffile churn: this changes a conffile and despit all documentation
pointers and hints to use a local override some people have changes.
So we might override some of those or at least trigger conffile
prompts.
- Usually restricting apparmor is more risky than opening it up. The
one pattern that could happen is that in some places something
"expected to fail will now work. But that is the purpose of the fix.
- gladly AAVMF is only used for arm, so other platforms should be
"even more unaffected"
[ Other Info ]
* a return of bug 1709818 but for a different file type
---
[Filing https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1709818/comments/8 as a separate bug report. Thanks J. S. Seldenthuis (jseldent) for reporting it.]
Qemu tries to lock the uefi firmware image during vm creation, but the libvirt-supplied apparmor profile prevents this for the AAVMF firmware, and qemu fails with:
qemu-system-arm: Failed to lock byte 100
The solution is adding the "k" flag to the relevant apparmor profile. This is fixed upstream by this commit:
https://gitlab.com/libvirt/libvirt/-/commit/2b98d5d91d95087d8a96d6450fa96414ed05ba5c
which is already included in the libvirt version in Kinetic. |
[ Impact ]
* Qemu on arm64 changed behavior now trying to ensure exclusivity on the
AAVM files used by OVMF. That is stopped by apparmor and needs to be
allowed to function again (as it used to prior to jammy before the
locking took place).
* The fix does not change the code, instead it changes the rule for
the specific path in the guest-associated apparmor rule and
adds "k" (=locking) to it.
[ Test Plan ]
* On arm64 you can try to spawn an OVMF using test system
(from the upstream report):
$ virt-install --name test --ram 1024 --vcpus 2 --disk size=16 --location https://ftp.debian.org/debian/dists/bullseye/main/installer-arm64/ --osinfo debian11 --graphics none --tpm none --boot uefi
Without the fix that will emit an apparmor denial like:
apparmor="DENIED" operation="file_lock" profile="libvirt-2c81aaf3-2e3d-44a3-9acb-0e1e3c9bd54c" name="/usr/share/AAVMF/AAVMF_CODE.fd" pid=323963 comm="qemu-system-aa>
With the fix that apparmor denial will not occur and it reaches further
stages of guest initialization.
For tests on focal only a subset trigger with the qemu in focal, but any self-build or backport, like the one from https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports will use the extended locking that triggers the problem on ovmf/aavmf resources as well. So consider adding those (but not the libvirt from that PPA as it already has the fix) to reproduce.
[ Where problems could occur ]
* Since it "only" changes apparmor rules and in doing so only "widens"
what is allowed there should be not many problems, those I can think of
are
- Conffile churn: this changes a conffile and despit all documentation
pointers and hints to use a local override some people have changes.
So we might override some of those or at least trigger conffile
prompts.
- Usually restricting apparmor is more risky than opening it up. The
one pattern that could happen is that in some places something
"expected to fail will now work. But that is the purpose of the fix.
- gladly AAVMF is only used for arm, so other platforms should be
"even more unaffected"
[ Other Info ]
* a return of bug 1709818 but for a different file type
---
[Filing https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1709818/comments/8 as a separate bug report. Thanks J. S. Seldenthuis (jseldent) for reporting it.]
Qemu tries to lock the uefi firmware image during vm creation, but the libvirt-supplied apparmor profile prevents this for the AAVMF firmware, and qemu fails with:
qemu-system-arm: Failed to lock byte 100
The solution is adding the "k" flag to the relevant apparmor profile. This is fixed upstream by this commit:
https://gitlab.com/libvirt/libvirt/-/commit/2b98d5d91d95087d8a96d6450fa96414ed05ba5c
which is already included in the libvirt version in Kinetic. |
|
| 2023-01-09 07:49:58 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/435343 |
|
| 2023-01-09 07:51:31 |
Christian Ehrhardt |
tags |
verification-done verification-done-jammy |
server-todo verification-done verification-done-jammy |
|
| 2023-02-01 01:23:24 |
Chris Halse Rogers |
libvirt (Ubuntu Focal): status |
Triaged |
Fix Committed |
|
| 2023-02-01 01:23:26 |
Chris Halse Rogers |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-02-01 01:23:32 |
Chris Halse Rogers |
tags |
server-todo verification-done verification-done-jammy |
server-todo verification-done-jammy verification-needed verification-needed-focal |
|
| 2023-02-01 16:21:22 |
Robie Basak |
libvirt (Ubuntu Focal): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2023-02-02 11:05:50 |
Christian Ehrhardt |
tags |
server-todo verification-done-jammy verification-needed verification-needed-focal |
block-proposed block-proposed-focal server-todo verification-done verification-done-focal verification-done-jammy |
|
| 2023-03-29 15:09:47 |
Christian Ehrhardt |
tags |
block-proposed block-proposed-focal server-todo verification-done verification-done-focal verification-done-jammy |
block-proposed block-proposed-focal verification-done verification-done-focal verification-done-jammy |
|
| 2024-04-03 02:06:40 |
Chris Halse Rogers |
tags |
block-proposed block-proposed-focal verification-done verification-done-focal verification-done-jammy |
block-proposed block-proposed-focal verification-done-jammy verification-needed verification-needed-focal |
|
| 2024-04-03 02:09:52 |
Chris Halse Rogers |
tags |
block-proposed block-proposed-focal verification-done-jammy verification-needed verification-needed-focal |
verification-done verification-done-focal verification-done-jammy |
|
| 2024-04-18 17:28:36 |
Robie Basak |
tags |
verification-done verification-done-focal verification-done-jammy |
verification-done-jammy verification-needed verification-needed-focal |
|
| 2024-04-24 19:49:56 |
Mauricio Faria de Oliveira |
tags |
verification-done-jammy verification-needed verification-needed-focal |
verification-done verification-done-focal verification-done-jammy |
|
| 2024-04-25 13:40:23 |
Launchpad Janitor |
libvirt (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
