| 2021-01-27 11:22:44 |
Christian Ehrhardt |
bug |
|
|
added bug |
| 2021-01-27 11:22:55 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Groovy |
|
| 2021-01-27 11:22:55 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Groovy) |
|
| 2021-01-27 11:22:55 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Focal |
|
| 2021-01-27 11:22:55 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Focal) |
|
| 2021-01-27 11:22:55 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-01-27 11:22:55 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Bionic) |
|
| 2021-01-27 11:23:27 |
Launchpad Janitor |
qemu (Ubuntu): status |
New |
Confirmed |
|
| 2021-01-27 11:23:27 |
Launchpad Janitor |
qemu (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2021-01-27 11:23:27 |
Launchpad Janitor |
qemu (Ubuntu Focal): status |
New |
Confirmed |
|
| 2021-01-27 11:23:27 |
Launchpad Janitor |
qemu (Ubuntu Groovy): status |
New |
Confirmed |
|
| 2021-01-27 12:14:54 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2021-01-27 12:49:58 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/397008 |
|
| 2021-01-27 12:50:40 |
Christian Ehrhardt |
qemu (Ubuntu): status |
Confirmed |
In Progress |
|
| 2021-01-27 12:50:50 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2021-01-27 12:50:54 |
Christian Ehrhardt |
tags |
|
server-next |
|
| 2021-01-27 12:57:45 |
Victor Tapia |
bug |
|
|
added subscriber Victor Tapia |
| 2021-02-11 13:33:21 |
Dan Streetman |
merge proposal linked |
|
https://code.launchpad.net/~ddstreet/ubuntu/+source/qemu/+git/qemu/+merge/397904 |
|
| 2021-07-15 13:04:34 |
Launchpad Janitor |
qemu (Ubuntu): status |
In Progress |
Fix Released |
|
| 2021-07-15 13:04:34 |
Launchpad Janitor |
cve linked |
|
2020-17380 |
|
| 2021-07-15 13:04:34 |
Launchpad Janitor |
cve linked |
|
2020-25085 |
|
| 2021-07-15 13:04:34 |
Launchpad Janitor |
cve linked |
|
2021-3392 |
|
| 2021-07-15 13:04:34 |
Launchpad Janitor |
cve linked |
|
2021-3409 |
|
| 2021-07-15 14:02:31 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Hirsute |
|
| 2021-07-15 14:02:31 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Hirsute) |
|
| 2021-07-15 14:13:08 |
Christian Ehrhardt |
qemu (Ubuntu Hirsute): status |
New |
Triaged |
|
| 2021-07-15 14:13:10 |
Christian Ehrhardt |
qemu (Ubuntu Groovy): status |
Confirmed |
Triaged |
|
| 2021-07-15 14:13:12 |
Christian Ehrhardt |
qemu (Ubuntu Focal): status |
Confirmed |
Triaged |
|
| 2021-07-15 14:13:13 |
Christian Ehrhardt |
qemu (Ubuntu Bionic): status |
Confirmed |
Triaged |
|
| 2021-07-28 23:16:59 |
Brian Murray |
qemu (Ubuntu Groovy): status |
Triaged |
Won't Fix |
|
| 2021-08-24 12:40:45 |
Christian Ehrhardt |
description |
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* TBD this particular change
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from cdrom-curl.xml
error: internal error: unable to execute QEMU command 'device_add': Property 'virtio-blk-device.drive' can't find value 'drive-virtio-disk2'
In the log we can see:
Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
One can also check files mapped into a process and we should see the /var/run/.. path being used now.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
TBD
[Other Info]
TBD
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-08-24 13:08:55 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* TBD this particular change
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from cdrom-curl.xml
error: internal error: unable to execute QEMU command 'device_add': Property 'virtio-blk-device.drive' can't find value 'drive-virtio-disk2'
In the log we can see:
Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
One can also check files mapped into a process and we should see the /var/run/.. path being used now.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
TBD
[Other Info]
TBD
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* TBD this particular change
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
TBD
[Other Info]
TBD
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-08-27 06:46:48 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* TBD this particular change
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
TBD
[Other Info]
TBD
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* TBD this particular change
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
TBD
[Other Info]
TBD
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-08-27 06:49:17 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/407764 |
|
| 2021-08-27 06:49:38 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/407765 |
|
| 2021-08-27 06:49:59 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/407766 |
|
| 2021-08-27 06:52:29 |
Christian Ehrhardt |
qemu (Ubuntu Bionic): status |
Triaged |
In Progress |
|
| 2021-08-27 06:52:31 |
Christian Ehrhardt |
qemu (Ubuntu Focal): status |
Triaged |
In Progress |
|
| 2021-08-27 06:52:33 |
Christian Ehrhardt |
qemu (Ubuntu Hirsute): status |
Triaged |
In Progress |
|
| 2021-09-09 00:36:54 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2021-09-09 09:57:42 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* TBD this particular change
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
TBD
[Other Info]
TBD
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* TBD this particular change
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-09-14 13:20:20 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* TBD this particular change
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-09-22 15:02:27 |
Christian Ehrhardt |
qemu (Ubuntu Bionic): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2021-09-23 12:46:01 |
Christian Ehrhardt |
qemu (Ubuntu Focal): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2021-09-23 12:46:03 |
Christian Ehrhardt |
qemu (Ubuntu Hirsute): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2021-09-24 06:46:47 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ apt install --reinstall qemu-*
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-09-24 06:48:09 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory and maybe also which mount point (and options) are backing it.
$ find /var/run/qemu/
$ findmnt /var/run/qemu/
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-09-24 06:49:24 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory and maybe also which mount point (and options) are backing it.
$ find /var/run/qemu/
$ findmnt /var/run/qemu/
# And then rm/mv the original .so files of qemu-block-extra
$ sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /usr/lib/x86_64-linux-gnu/qemu/block-curl.so.nothere
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory and maybe also which mount point (and options) are backing it.
$ find /var/run/qemu/
$ findmnt /var/run/qemu/
# And then rm/mv the original .so files of qemu-block-extra
sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /root/block-curl.so.notherightplace
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-09-27 08:39:57 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory and maybe also which mount point (and options) are backing it.
$ find /var/run/qemu/
$ findmnt /var/run/qemu/
# And then rm/mv the original .so files of qemu-block-extra
sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /root/block-curl.so.notherightplace
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a
try is also the use of an environment var for an extra path:
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory and maybe also which mount point (and options) are backing it.
$ find /var/run/qemu/
$ findmnt /var/run/qemu/
# And then rm/mv the original .so files of qemu-block-extra
sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /root/block-curl.so.notherightplace
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a try
This sub-test is only in Focal and Hirsute, was not present in Bionic.
This should have preference over the other dirs (usual load as well as fallback path), therefore we do NOT remove the usual paths and check if it works, we keep them but check the loaded binary.
TL;DR Copy the .so to another place and load it from there:
$ sudo cp /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /tmp/
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -nographic -cdrom https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/impish-live-server-amd64.is
# Then in other console check if it loaded that
$ $ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl | grep r-xp
7f3ef7dc1000-7f3ef7e23000 r-xp 0000c000 fc:01 5481 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0
7f3efa729000-7f3efa72c000 r-xp 00002000 fc:01 1086 /tmp/block-curl.so
We see the qemu block lib from the wanted path and other libs from the system as usual.
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-09-27 08:42:20 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory and maybe also which mount point (and options) are backing it.
$ find /var/run/qemu/
$ findmnt /var/run/qemu/
# And then rm/mv the original .so files of qemu-block-extra
sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /root/block-curl.so.notherightplace
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a try
This sub-test is only in Focal and Hirsute, was not present in Bionic.
This should have preference over the other dirs (usual load as well as fallback path), therefore we do NOT remove the usual paths and check if it works, we keep them but check the loaded binary.
TL;DR Copy the .so to another place and load it from there:
$ sudo cp /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /tmp/
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -nographic -cdrom https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/impish-live-server-amd64.is
# Then in other console check if it loaded that
$ $ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl | grep r-xp
7f3ef7dc1000-7f3ef7e23000 r-xp 0000c000 fc:01 5481 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0
7f3efa729000-7f3efa72c000 r-xp 00002000 fc:01 1086 /tmp/block-curl.so
We see the qemu block lib from the wanted path and other libs from the system as usual.
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory and maybe also which mount point (and options) are backing it.
$ find /var/run/qemu/
$ findmnt /var/run/qemu/
# And then rm/mv the original .so files of qemu-block-extra
sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /root/block-curl.so.notherightplace
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a try
This sub-test is only in Focal and Hirsute, was not present in Bionic.
This should have preference over the other dirs (usual load as well as fallback path), therefore we do NOT remove the usual paths and check if it works, we keep them but check the loaded binary.
TL;DR Copy the .so to another place and load it from there:
$ sudo cp /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /tmp/
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -nographic -cdrom https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/impish-live-server-amd64.iso
# Then in other console check if it loaded that
$ $ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl | grep r-xp
7f3ef7dc1000-7f3ef7e23000 r-xp 0000c000 fc:01 5481 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0
7f3efa729000-7f3efa72c000 r-xp 00002000 fc:01 1086 /tmp/block-curl.so
We see the qemu block lib from the wanted path and other libs from the system as usual.
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-09-28 08:46:46 |
Brett Milford |
bug |
|
|
added subscriber Brett Milford |
| 2021-09-30 10:35:28 |
Robie Basak |
qemu (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
| 2021-09-30 10:35:30 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-09-30 10:35:32 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2021-09-30 10:35:37 |
Robie Basak |
tags |
server-next |
server-next verification-needed verification-needed-hirsute |
|
| 2021-09-30 10:36:01 |
Robie Basak |
qemu (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2021-09-30 10:36:08 |
Robie Basak |
tags |
server-next verification-needed verification-needed-hirsute |
server-next verification-needed verification-needed-focal verification-needed-hirsute |
|
| 2021-09-30 10:36:31 |
Robie Basak |
qemu (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2021-09-30 10:36:38 |
Robie Basak |
tags |
server-next verification-needed verification-needed-focal verification-needed-hirsute |
server-next verification-needed verification-needed-bionic verification-needed-focal verification-needed-hirsute |
|
| 2021-09-30 10:41:08 |
Christian Ehrhardt |
description |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory and maybe also which mount point (and options) are backing it.
$ find /var/run/qemu/
$ findmnt /var/run/qemu/
# And then rm/mv the original .so files of qemu-block-extra
sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /root/block-curl.so.notherightplace
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a try
This sub-test is only in Focal and Hirsute, was not present in Bionic.
This should have preference over the other dirs (usual load as well as fallback path), therefore we do NOT remove the usual paths and check if it works, we keep them but check the loaded binary.
TL;DR Copy the .so to another place and load it from there:
$ sudo cp /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /tmp/
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -nographic -cdrom https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/impish-live-server-amd64.iso
# Then in other console check if it loaded that
$ $ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl | grep r-xp
7f3ef7dc1000-7f3ef7e23000 r-xp 0000c000 fc:01 5481 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0
7f3efa729000-7f3efa72c000 r-xp 00002000 fc:01 1086 /tmp/block-curl.so
We see the qemu block lib from the wanted path and other libs from the system as usual.
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
[Impact]
* An infrequent but annoying issue is QEMUs problem to not be able to
hot-add capabilities IF since starting the instance qemu has been
upgraded. This is due to qemu modules only working with exactly the
same build.
* The problem is that the path everyone (upstream+security) agreed
to put the files in is mounted noexec by default in Ubuntu preventing
to load the .so from there.
* In new versions this is solved via a .mount unit which is great for
transparency and control e.g. opt in/out of this. But for the SRU
after backporting the mount unit at first it was decided that a rather
simple "check and tmp-mount if needed" is more resilient, less complex
(mount unit handling by systemd/dh* is vastly different across
releases) and would have less regression risk for scenarios
were the admin has already made the path non noexec.
[Test Case]
I:
* $ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily
cat > curldisk.xml << EOF
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso">
<host name="archive.ubuntu.com" port="80"/>
</source>
<target dev='vdc' bus='virtio'/>
<readonly/>
</disk>
EOF
# Here up or downgrade the installed packages, even a minor
# version or a rebuild of the same version
# Instead if you prefer (easier) you can run
$ sudo apt install --reinstall qemu-block-extra
Next check if they appeared (action of the maintainer scripts)
in the /var/run/qemu/<version> directory and maybe also which mount point (and options) are backing it.
$ find /var/run/qemu/
$ findmnt /var/run/qemu/
# And then rm/mv the original .so files of qemu-block-extra
sudo mv /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /root/block-curl.so.notherightplace
# Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id
Without the fix this will now fail some way, e.g. on Focal with:
$ virsh attach-device lateload curldisk.xml
Reported issue happens on attach:
root@b:~# virsh attach-device lateload cdrom-curl.xml
error: Failed to attach device from curldisk.xml
error: internal error: unable to execute QEMU command 'blockdev-add': Unknown driver 'http'
That attach should work on >Focal and also one can also check files mapped into a process and we should see the /var/run/.. path being used now.
$ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl
The original file path:
7f619941b000-7f619941c000 rw-p 00005000 fc:01 258107 /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
But since we moved that way before being loaded it should point to /run/qemu/... this time.
II:
* As it had issues in the first iteration of the fix worth a try
This sub-test is only in Focal and Hirsute, was not present in Bionic.
This should have preference over the other dirs (usual load as well as fallback path), therefore we do NOT remove the usual paths and check if it works, we keep them but check the loaded binary.
TL;DR Copy the .so to another place and load it from there:
$ sudo cp /usr/lib/x86_64-linux-gnu/qemu/block-curl.so /tmp/
$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -nographic -cdrom https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/impish-live-server-amd64.iso
# Then in other console check if it loaded that
$ $ sudo cat /proc/$(pidof qemu-system-x86_64)/maps | grep curl | grep r-xp
7f3ef7dc1000-7f3ef7e23000 r-xp 0000c000 fc:01 5481 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0
7f3efa729000-7f3efa72c000 r-xp 00002000 fc:01 1086 /tmp/block-curl.so
We see the qemu block lib from the wanted path and other libs from the system as usual.
III:
remount /run with exec, we want to see that it does NOT create a new mountpoint in this case:
$ sudo mount -o remount,exec /run
$ findmnt -T /var/run
TARGET SOURCE FSTYPE OPTIONS
/run tmpfs tmpfs rw,nosuid,nodev,relatime,size=202588k,mode=755,inode64
Then upgrade and recheck
$ find /var/run/qemu/; findmnt -T /var/run/qemu
/var/run/qemu/
/var/run/qemu/Debian_1_5.2+dfsg-9ubuntu3.2~hirsuteppa7
/var/run/qemu/Debian_1_5.2+dfsg-9ubuntu3.2~hirsuteppa7/block-ssh.so
/var/run/qemu/Debian_1_5.2+dfsg-9ubuntu3.2~hirsuteppa7/block-rbd.so
/var/run/qemu/Debian_1_5.2+dfsg-9ubuntu3.2~hirsuteppa7/block-iscsi.so
/var/run/qemu/Debian_1_5.2+dfsg-9ubuntu3.2~hirsuteppa7/block-curl.so
/var/run/qemu/README
/var/run/qemu/exec
TARGET SOURCE FSTYPE OPTIONS
/run tmpfs tmpfs rw,nosuid,nodev,relatime,size=202588k,mode=755,inode64
Important is that in this case it is still /run and not /run/qemu
[Regression Potential]
Via extensive discussion we tried to find the least regression-risk way
but still the most likely regression would be where administrators have
taken means to modify/prepare /run/qemu themselves which might now collide.
[Other Info]
In Focal there were a few more (effectively no-op) mistakes which are cleaned up by this as well. It did save gui modules (not present in bionic, not wrong in hirsute) that can not be late loaded, so there is no point in saving them. Furthermore it had (bad patch match) enabled the feature on the qemu-system-x86-xen builds which have no use-case for this.
---
This is a continuation of bug 1847361.
Since that is in Ubuntu and Debian we are:
- correctly saving the modules to those paths in /var/run/qemu.
- qemu tries to load from that path as fallback
- that works fine in containers running qemu/kvm
But there is an issue on non-container systems as /run usually is like this:
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path.
The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options.
In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set.
This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. |
|
| 2021-10-04 09:26:30 |
Christian Ehrhardt |
tags |
server-next verification-needed verification-needed-bionic verification-needed-focal verification-needed-hirsute |
server-next verification-done verification-done-bionic verification-done-focal verification-done-hirsute |
|
| 2021-10-11 16:39:07 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-10-11 16:39:04 |
Launchpad Janitor |
qemu (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2021-10-11 16:39:49 |
Launchpad Janitor |
qemu (Ubuntu Hirsute): status |
Fix Committed |
Fix Released |
|
| 2021-10-11 17:55:02 |
Launchpad Janitor |
qemu (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
