Bug#1058905: QEMU: why not use package opensbi as dependency?
18.12.2023 10:59, Heinrich Schuchardt: On 12/18/23 07:41, Michael Tokarev wrote: Yes, we can do that. I don't see much benefit here though. For one, I dislike dangling symlinks in package, and don't want to add yet another directory to firmware search directories. OpenSBI is security critical as it runs in the highest privilege mode at Linux runtime. There have been potentially security relevant code errors detected in the past like buffer overruns. Sure. I am concerned that security errors fixed in the OpenSBI package might not be fixed in qemu-system-data at the same time. For the security team it would be much more evident what to fix if there were only one package building OpenSBI. I dunno where we have more chances to have a fix faster - in qemu than in opensbi. Maybe Vagrant can answer this one. If we're to go this route, will ask opensbi maintainer(s) to create symlinks to opensbi firmware in /usr/share/qemu/ directory. This will involve Break/Replace of the old qemu-system-data package. /mjt
Bug#1058905: QEMU: why not use package opensbi as dependency?
On 12/18/23 07:41, Michael Tokarev wrote: Yes, we can do that. I don't see much benefit here though. For one, I dislike dangling symlinks in package, and don't want to add yet another directory to firmware search directories. OpenSBI is security critical as it runs in the highest privilege mode at Linux runtime. There have been potentially security relevant code errors detected in the past like buffer overruns. I am concerned that security errors fixed in the OpenSBI package might not be fixed in qemu-system-data at the same time. For the security team it would be much more evident what to fix if there were only one package building OpenSBI. Best regards Heinrich
Bug#1058905: QEMU: why not use package opensbi as dependency?
18.12.2023 09:33, Heinrich Schuchardt wrote: Package: qemu-system-data Version: 1:8.2.0~rc2+ds-1 Severity: wishlist Hello Michael, Debian provides package opensbi. I didn't know about opensbi up until this your email. In the qemu package's debian/rules we build another OpenSBI. Wouldn't it be preferable to reuse the existing opensbi package? This would imply that if we update OpenSBI also QEMU will use that new version. Well, this is a two-folded knife, as usual. This also means that if there's an update of opensbi in qemu, we'll have to update separate opensbi package in debian. So far (in recent years) we only had seabios-hppa update like that (and there's no seabios-hppa package in debian anyway). Before, we had to keep some pieces closer to qemu, - eg, seabios were updated much more frequently in qemu (with qemu-specific changes too) than upstream releases were released. This is in the past now though. These are the duplicate files: opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.elf qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.elf opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.bin qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin Yes, we can do that. I don't see much benefit here though. For one, I dislike dangling symlinks in package, and don't want to add yet another directory to firmware search directories. /mjt
Bug#1058905: QEMU: why not use package opensbi as dependency?
Package: qemu-system-data Version: 1:8.2.0~rc2+ds-1 Severity: wishlist Hello Michael, Debian provides package opensbi. In the qemu package's debian/rules we build another OpenSBI. Wouldn't it be preferable to reuse the existing opensbi package? This would imply that if we update OpenSBI also QEMU will use that new version. These are the duplicate files: opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.elf qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.elf opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.bin qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin Best regards Heinrich
