Bug#1067586: Drop hard-coded dependency on libbpp-core4
Source: libbpp-seq
Version: 2.4.1-10.1
Severity: normal
Tags: patch
This dependency will be automatically generated by ${shlibs:Depends}
and avoids a co-dependency on both libbpp-core4 and libbpp-core4t64.
diff -Nru libbpp-seq-2.4.1/debian/control libbpp-seq-2.4.1/debian/control
--- libbpp-seq-2.4.1/debian/control 2024-02-29 03:13:25.0 -0700
+++ libbpp-seq-2.4.1/debian/control 2024-03-23 23:26:04.0 -0600
@@ -39,8 +40,7 @@
Multi-Arch: same
Section: libs
Depends: ${shlibs:Depends},
- ${misc:Depends},
- libbpp-core4
+ ${misc:Depends}
Pre-Depends: ${misc:Pre-Depends}
Description: Bio++ Sequence library
Bio++ is a set of C++ libraries for Bioinformatics, including sequence
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1067585: Drop hardcoded dependency on libgroonga0t64
Source: groonga-normalizer-mysql
Version: 1.2.3-2
Severity: normal
This dependency is already provided via ${shlibs:Depends}.
diff -Nru groonga-normalizer-mysql-1.2.3/debian/control
groonga-normalizer-mysql-1.2.3/debian/control
--- groonga-normalizer-mysql-1.2.3/debian/control 2024-03-03
07:06:57.0 -0700
+++ groonga-normalizer-mysql-1.2.3/debian/control 2024-03-23
23:14:20.0 -0600
@@ -17,7 +18,6 @@
Depends:
${misc:Depends},
${shlibs:Depends},
- libgroonga0t64
Multi-Arch: same
Description: MySQL derived normalizer for Groonga
Groonga is an open-source fulltext search engine and column store.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1067583: Drop hardcoded dependency on libgfal-srm-ifce1
Source: gfal2
Version: 2.22.1-1.1build2
Severity: normal
Tags: patch
The proper shlib dependency will automatically be added by ${shlib:deps}.
This avoids a co-dependency on libgfal-srm-ifce1 and libgfal-srm-ifce1t64.
diff -Nru gfal2-2.22.1/debian/control gfal2-2.22.1/debian/control
--- gfal2-2.22.1/debian/control 2024-03-11 16:40:20.0 -0600
+++ gfal2-2.22.1/debian/control 2024-03-23 22:20:55.0 -0600
@@ -131,7 +131,6 @@
Depends:
libgfal2-2t64 (= ${binary:Version}),
libgfal-transfer2t64 (= ${binary:Version}),
- libgfal-srm-ifce1 (>= 1.23.1),
${shlibs:Depends},
${misc:Depends}
Description: Provides srm support for gfal2
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1064920: FTBFS on 32-bit architectures
Source: rshim-user-space
Version: 2.0.12+debian-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
The switch to fuse3 appears to have introduced a build issue for 32-bit
architectures such as armhf:
From
https://buildd.debian.org/status/fetch.php?pkg=rshim-user-space=armhf=2.0.20%2Bdebian-1=1709056732=0
:
gcc -DHAVE_CONFIG_H -I. -I.. -Wall -DHAVE_RSHIM_NET -I/usr/include/libusb-1.0
-DHAVE_RSHIM_USB -I/usr/include/arm-linux-gnueabihf -DHAVE_RSHIM_PCIE
-I/usr/include/fuse3 -DHAVE_RSHIM_FUSE -Wdate-time -D_FORTIFY_SOURCE=2
-DFUSE_USE_VERSION=30 -DDEFAULT_RSHIM_CONFIG_FILE='"/etc/rshim.conf"' -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -c -o
rshim-rshim_fuse.o `test -f 'rshim_fuse.c' || echo './'`rshim_fuse.c
In file included from /usr/include/fuse3/fuse_lowlevel.h:25,
from /usr/include/fuse3/cuse_lowlevel.h:19,
from rshim_fuse.c:23:
/usr/include/fuse3/fuse_common.h:928:1: error: static assertion failed: "fuse:
off_t must be 64bit"
928 | _Static_assert(sizeof(off_t) == 8, "fuse: off_t must be 64bit");
| ^~
rshim_pcie.c: In function ‘rshim_pcie_mmap_vfio’:
rshim_pcie.c:52:37: warning: overflow in conversion from ‘long long unsigned
int’ to ‘__off_t’ {aka ‘long int’} changes value from ‘7696581394436’ to ‘4’
[-Woverflow]
52 | #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
| ^
rshim_pcie.c:634:18: note: in expansion of macro ‘VFIO_GET_REGION_ADDR’
634 | VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX) +
| ^~~~
rshim_pcie.c:52:37: warning: overflow in conversion from ‘long long unsigned
int’ to ‘__off_t’ {aka ‘long int’} changes value from ‘7696581394436’ to ‘4’
[-Woverflow]
52 | #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
| ^
rshim_pcie.c:643:19: note: in expansion of macro ‘VFIO_GET_REGION_ADDR’
643 | VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX) +
| ^~~~
rshim_fuse.c: In function ‘rshim_fuse_misc_read’:
rshim_fuse.c:713:36: warning: format ‘%ld’ expects argument of type ‘long int’,
but argument 5 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
713 | n = snprintf(p, len, "%-16s%ld(s)\n", "UP_TIME",
value/BF3_REF_CLK_IN_HZ);
| ~~^
||
|long int
| %lld
rshim_fuse.c: In function ‘rshim_fuse_misc_write’:
rshim_fuse.c:954:25: warning: format ‘%lx’ expects argument of type ‘long
unsigned int *’, but argument 3 has type ‘uint64_t *’ {aka ‘long long unsigned
int *’} [-Wformat=]
954 | if (sscanf(p, " 0x%lx", ) != 1)
| ~~^ ~~
| | |
| | uint64_t * {aka long long unsigned int *}
| long unsigned int *
| %llx
make[3]: *** [Makefile:524: rshim-rshim_fuse.o] Error 1
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1064914: build-depends on superseded package pkg-config
Source: rshim-user-space Version: 2.0.20+debian-1 Severity: minor X-Debbugs-Cc: Taihsiang Ho (tai271828) >From lintian: W: rshim-user-space source: build-depends-on-obsolete-package Build-Depends: pkg-config => pkgconf N: N: The package build-depends on a package that has been superseded. If the N: superseded package is part of an ORed group, it should not be the first N: package in the group. N: N: Visibility: warning N: Show-Always: no N: Check: fields/package-relations
Bug#1060398: code not installed
forwarded 1060398 https://gitlab.com/kraxel/virt-firmware/-/issues/10 tags 1060398 + upstream severity 1060398 minor thanks Thanks Michael. We don't currently install the impacted code, but I've gone ahead and reported this upstream.
Bug#1060042: qemu-efi-aarch64: Saving OVMF configuration changes fail
On Thu, Feb 15, 2024 at 10:06:35AM +, Simon John wrote: > I have the same problem when changing settings or even > starting an existing aarch64 VM in virt-manager, the error > I get is: > > Error starting domain: operation failed: Unable to find > 'efi' firmware that is compatible with the current > configuration > > Downgrading to qemu-efi-aarch64_2023.11-6_all.deb and > qemu-efi-arm_2023.11-6_all.deb fixes the issue, so the > breakage is in -7 Hi Simon, I see nothing in common between the issue you are describing and this bug. Please report a new issue. -dann
Bug#1061256: edk2: CVE-2023-45229 CVE-2023-45230 CVE-2023-45231 CVE-2023-45232 CVE-2023-45233 CVE-2023-45234 CVE-2023-45235 CVE-2023-45236 CVE-2023-45237
On Sun, Feb 11, 2024 at 08:46:32PM +0100, Salvatore Bonaccorso wrote: > Does this split look good to you? Yes, thank you! -dann
Bug#1061256: edk2: CVE-2023-45229 CVE-2023-45230 CVE-2023-45231 CVE-2023-45232 CVE-2023-45233 CVE-2023-45234 CVE-2023-45235 CVE-2023-45236 CVE-2023-45237
Thanks Salvatore. The first 7 are now fixed upstream, so I'm preparing an upload for those. Fixes for CVE-2023-45236 and CVE-2023-45237 are still in the works. Should we split those into separate bugs? -dann
Bug#967994: CVE-2019-14560 fixed, but rejected?
fixed 967994 2023.05-1 thanks Yes, there is a fix for this in upstream edk2-stable202305. However, the CVE is marked as rejected: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14560 But it seems to have been treated a valid issue. There is a note about requesting a new CVE: https://bugzilla.tianocore.org/show_bug.cgi?id=2167#c14 I asked for the status there. -dann
Bug#1014468: fixed
fixed 1014468 2022.11-1 thanks CVE-2021-38576 was fixed in 2021.11-1. CVE-2021-38577 was rejected. CVE-2021-38578 was fixed in 2022.11-1. -dann
Bug#1055987: ITP: virt-firmware -- Tools for manipulating edk2 (ovmf/qemu-efi) firmware images
On Sun, Dec 17, 2023 at 07:53:52PM +0100, Luca Boccassi wrote: > On Sun, 17 Dec 2023, 17:45 dann frazier, wrote: > > > On Thu, Dec 07, 2023 at 08:58:23PM +, Luca Boccassi wrote: > > > On Wed, 15 Nov 2023 05:54:23 -0700 dann frazier > > > wrote: > > > > Package: wnpp > > > > Severity: wishlist > > > > Owner: dann frazier > > > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > > > > > * Package name: virt-firmware > > > > Version : 23.10 > > > > Upstream Contact: Gerd Hoffmann > > > > * URL : https://gitlab.com/kraxel/virt-firmware > > > > * License : GPL-2+ > > > > Programming Lang: Python > > > > Description : Tools for manipulating edk2 (ovmf/qemu-efi) > > > firmware images > > > > > > > > This is a collection of tools for edk2 firmware images. They support > > > > decoding and printing the content of firmware volumes. Variable > > > stores > > > > (e.g. OVMF_VARS.fd) can be modified, for example to enroll secure > > > boot > > > > certificates. Tools included: > > > > > > > > virt-fw-dump - Decodes and prints the content of firmware volumes. > > > > > > > > virt-fw-vars - Print and edit variable store volumes. Currently > > > focused on > > > > enrolling certificates and enabling secure boot. > > > > > > > > virt-fw-sigdb - Print and edit EFI signature database files. > > > > > > > > host-efi-vars - Read efi variables from linux efivarfs and > > > decode/print them. > > > > > > > > kernel-bootcfg - Manage efi boot configuration for UKIs (unified > > > kernel > > > > images) when using direct boot (without boot loader > > > like > > > > grub or systemd-boot). > > > > > > > > pe-dumpinfo - Information dump for pe (the format used by EFI) > > > binaries. > > > > > > > > pe-listsigs - List signatures and certificate chain for pe binaries. > > > Can also > > > >extract certificates & signatures. > > > > > > > > > > > > My immediate motivation for packaging this is that, as the maintainer > > > of > > > > the edk2 package, I need to remove some deprecated image types - > > > specifically > > > > the OVMF 2M images. These utilities can help users migrate their VMs > > > to > > > > supported types by dumping/loading the variable stores. > > > > > > > > In the future, I expect edk2 packaging to evolve into using these > > > tools > > > > to modify images out-of-band, instead of launching QEMU instances to > > > > modify them in-band as part of the build. > > > > > > > > > > Hello Dann, > > > > > > I find myself in need of this package for some CI usage as well, are > > > you planning to work on this soon? Do you need any help? > > > > Hi Luca, > > > > Apologies for the delayed response. I believe I have completed the > > packaging and am prepared to upload: > > > > https://salsa.debian.org/dannf/virt-firmware > > > > Feel free to review and let me know if you have any feedback. > > > > -dann > > > > Looks good to me, thanks. Ship it! Shipped :) -dann
Bug#1055987: ITP: virt-firmware -- Tools for manipulating edk2 (ovmf/qemu-efi) firmware images
On Thu, Dec 07, 2023 at 08:58:23PM +, Luca Boccassi wrote: > On Wed, 15 Nov 2023 05:54:23 -0700 dann frazier > wrote: > > Package: wnpp > > Severity: wishlist > > Owner: dann frazier > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name : virt-firmware > > Version : 23.10 > > Upstream Contact: Gerd Hoffmann > > * URL : https://gitlab.com/kraxel/virt-firmware > > * License : GPL-2+ > > Programming Lang: Python > > Description : Tools for manipulating edk2 (ovmf/qemu-efi) > firmware images > > > > This is a collection of tools for edk2 firmware images. They support > > decoding and printing the content of firmware volumes. Variable > stores > > (e.g. OVMF_VARS.fd) can be modified, for example to enroll secure > boot > > certificates. Tools included: > > > > virt-fw-dump - Decodes and prints the content of firmware volumes. > > > > virt-fw-vars - Print and edit variable store volumes. Currently > focused on > > enrolling certificates and enabling secure boot. > > > > virt-fw-sigdb - Print and edit EFI signature database files. > > > > host-efi-vars - Read efi variables from linux efivarfs and > decode/print them. > > > > kernel-bootcfg - Manage efi boot configuration for UKIs (unified > kernel > > images) when using direct boot (without boot loader > like > > grub or systemd-boot). > > > > pe-dumpinfo - Information dump for pe (the format used by EFI) > binaries. > > > > pe-listsigs - List signatures and certificate chain for pe binaries. > Can also > > extract certificates & signatures. > > > > > > My immediate motivation for packaging this is that, as the maintainer > of > > the edk2 package, I need to remove some deprecated image types - > specifically > > the OVMF 2M images. These utilities can help users migrate their VMs > to > > supported types by dumping/loading the variable stores. > > > > In the future, I expect edk2 packaging to evolve into using these > tools > > to modify images out-of-band, instead of launching QEMU instances to > > modify them in-band as part of the build. > > > > Hello Dann, > > I find myself in need of this package for some CI usage as well, are > you planning to work on this soon? Do you need any help? Hi Luca, Apologies for the delayed response. I believe I have completed the packaging and am prepared to upload: https://salsa.debian.org/dannf/virt-firmware Feel free to review and let me know if you have any feedback. -dann
Bug#1052173: fixed upstream
tag 1052173 + patch tag 1052173 + fixed-upstream thanks I found that this problem does not occur with latest upstream, so I used bisection to identify the fix. The problem no longer occurs after applying this fix to the existing package: commit 124efd03f3cb9b1df819134eb7cb6683497be9b1 Author: Richard Hughes Date: Wed Apr 13 14:16:02 2022 +0100 Fix a double free spotted by Coverity
Bug#1055987: ITP: virt-firmware -- Tools for manipulating edk2 (ovmf/qemu-efi) firmware images
Package: wnpp Severity: wishlist Owner: dann frazier X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: virt-firmware Version : 23.10 Upstream Contact: Gerd Hoffmann * URL : https://gitlab.com/kraxel/virt-firmware * License : GPL-2+ Programming Lang: Python Description : Tools for manipulating edk2 (ovmf/qemu-efi) firmware images This is a collection of tools for edk2 firmware images. They support decoding and printing the content of firmware volumes. Variable stores (e.g. OVMF_VARS.fd) can be modified, for example to enroll secure boot certificates. Tools included: virt-fw-dump - Decodes and prints the content of firmware volumes. virt-fw-vars - Print and edit variable store volumes. Currently focused on enrolling certificates and enabling secure boot. virt-fw-sigdb - Print and edit EFI signature database files. host-efi-vars - Read efi variables from linux efivarfs and decode/print them. kernel-bootcfg - Manage efi boot configuration for UKIs (unified kernel images) when using direct boot (without boot loader like grub or systemd-boot). pe-dumpinfo - Information dump for pe (the format used by EFI) binaries. pe-listsigs - List signatures and certificate chain for pe binaries. Can also extract certificates & signatures. My immediate motivation for packaging this is that, as the maintainer of the edk2 package, I need to remove some deprecated image types - specifically the OVMF 2M images. These utilities can help users migrate their VMs to supported types by dumping/loading the variable stores. In the future, I expect edk2 packaging to evolve into using these tools to modify images out-of-band, instead of launching QEMU instances to modify them in-band as part of the build.
Bug#1049840: timeout
tag 1049840 + pending thanks Hi Lucas, This does not seem to be a problem with rebuilding per se. I can not reproduce it, and I don't see a way a "dirty tree" could cause this failure. The log shows a timeout in a pyexpect script, so I hypothesize that the 2nd build just ran slower than the first - and very slow in general. My plan for this is to remove the default timeouts during the build and just rely on buildd timeouts for any hangs. -dann
Bug#1042438: root caused to shim
On Sat, Sep 23, 2023 at 11:15:45AM +0100, Simon John wrote: > Thanks for looking into this! > > I was hoping we could revert the offending edk2 commit in debian rather than > getting every guest os vendor to update their shim - which would mean only > fresh installs would work. > > Red Hat seem to have merged the fix this year: > > https://github.com/rhboot/shim/commit/c7b305152802c8db688605654f75e1195def9fd6 > > But there's not be a new rhel/fedora rpm in well over a year, still 15.6 Yeah, shim updates are hard to do, so let's give distributions some time to update. I've reverted the change in edk2 for now, but I do plan to restore it by early 2024.
Bug#1042438: root caused to shim
OK, I finally found some time to debug this. I debugged it with an Ubuntu VM that used shim 15.7, but I suspect it is the same issue with Fedora 38 and AlmaLinux 9.2. shim 15.6 introduced the following commit: commit 226fee25ffcbd29988399ba080c7706eb1d52251 Author: Peter Jones Date: Thu Dec 2 18:29:50 2021 -0500 PE Loader: support and require NX This adds support in our PE loader for NX support utilizing the EFI_MEMORY_ATTRIBUTE protocol. Specifically, it changes the loader such that: - binaries without the EFI_IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag set in the Optional Header are rejected as EFI_UNSUPPORTED - binaries with non-discardable sections that have both the EFI_SCN_MEM_WRITE and EFI_SCN_MEM_EXECUTE flags set are rejected as EFI_UNSUPPORTED - if the EFI_MEMORY_ATTRIBUTE protocol is installed, then: - sections without the EFI_SCN_MEM_READ flag set will be marked with EFI_MEMORY_RP - sections without the EFI_SCN_MEM_WRITE flag set will be marked with EFI_MEMORY_RO - sections without the EFI_SCN_MEM_EXECUTE flag set will be marked with EFI_MEMORY_XP Signed-off-by: Peter Jones EDK2 didn't expose the EFI_MEMORY_ATTRIBUTE protocol for ARM until 2023.05-1, so at that point this shim code was activated. Unfortunately, this shim code had a bug that causes this problem. Luckily it has since been fixed in upstream git: From c7b305152802c8db688605654f75e1195def9fd6 Mon Sep 17 00:00:00 2001 From: Nicholas Bishop Date: Mon, 19 Dec 2022 18:56:13 -0500 Subject: [PATCH] pe: Align section size up to page size for mem attrs Setting memory attributes is generally done at page granularity, and this is enforced by checks in `get_mem_attrs` and `update_mem_attrs`. But unlike the section address, the section size isn't necessarily aligned to 4KiB. Round up the section size to fix this. Signed-off-by: Nicholas Bishop I've asked Ubuntu to pick this up (LP: #2036604). Please ask your favorite guest OS distributions to pick it up as well.
Bug#1052173: segfaults in libgobject-2.0.so.0.7800.0
Package: colord Version: 1.4.6-3 Severity: normal I noticed that this service has been stuck in a respawn/segfault loop on my system. [...] [ 4969.616799] colord[22761]: segfault at 55fd30d664d5 ip 7f47219ccc01 sp 7ffecd7fd3a8 error 4 in libgobject-2.0.so.0.7800.0[7f47219a1000+34000] likely on CPU 3 (core 1, socket 0) [ 4969.616819] Code: c5 57 02 00 48 8b 34 e8 e9 53 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 85 ff 74 47 48 8b 07 48 85 c0 74 3f <48> 8b 00 48 3d fc 03 00 00 77 2c 48 8d 15 8d 57 02 00 48 c1 e8 02 [ 4972.827228] colord[22778]: segfault at 55e578ec796c ip 7f56e6dc2c01 sp 7ffd52003138 error 4 in libgobject-2.0.so.0.7800.0[7f56e6d97000+34000] likely on CPU 3 (core 1, socket 0) [ 4972.827253] Code: c5 57 02 00 48 8b 34 e8 e9 53 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 85 ff 74 47 48 8b 07 48 85 c0 74 3f <48> 8b 00 48 3d fc 03 00 00 77 2c 48 8d 15 8d 57 02 00 48 c1 e8 02 [ 4976.595370] colord[22797]: segfault at 5573ed6cf512 ip 7f72d6785c01 sp 7fff98e380c8 error 4 in libgobject-2.0.so.0.7800.0[7f72d675a000+34000] likely on CPU 0 (core 0, socket 0) (gdb) thread apply all bt Thread 5 (Thread 0x7fef177fe6c0 (LWP 18507)): #0 0x7fef1dcfc9ff in __GI___poll (fds=0x7fef0c000b90, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7fef1e05c237 in g_main_context_poll_unlocked (priority=, n_fds=2, fds=0x7fef0c000b90, timeout=, context=0x7fef08005d00) at ../../../glib/gmain.c:4653 #2 g_main_context_iterate_unlocked (context=0x7fef08005d00, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4344 #3 0x7fef1e05cbdf in g_main_loop_run (loop=0x7fef08005e30) at ../../../glib/gmain.c:4551 #4 0x7fef1e2cbdfa in gdbus_shared_thread_func (user_data=0x7fef08005cd0) at ../../../gio/gdbusprivate.c:284 #5 0x7fef1e0899e1 in g_thread_proxy (data=0x560db24a50b0) at ../../../glib/gthread.c:831 #6 0x7fef1dc893ec in start_thread (arg=) at ./nptl/pthread_create.c:444 #7 0x7fef1dd09a2c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 4 (Thread 0x7fef17fff6c0 (LWP 18506)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x7fef1e0b7b70 in g_cond_wait_until (cond=cond@entry=0x560db24e0fe8, mutex=mutex@entry=0x560db24e0fe0, end_time=end_time@entry=3795687445) at ../../../glib/gthread-posix.c:1677 #2 0x7fef1e026133 in g_async_queue_pop_intern_unlocked (queue=0x560db24e0fe0, wait=1, end_time=3795687445) at ../../../glib/gasyncqueue.c:428 #3 0x7fef1e08a3ea in g_thread_pool_wait_for_new_task (pool=0x560db24b3f90) at ../../../glib/gthreadpool.c:274 #4 g_thread_pool_thread_proxy (data=) at ../../../glib/gthreadpool.c:339 #5 0x7fef1e0899e1 in g_thread_proxy (data=0x7fef18000b70) at ../../../glib/gthread.c:831 #6 0x7fef1dc893ec in start_thread (arg=) at ./nptl/pthread_create.c:444 #7 0x7fef1dd09a2c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 3 (Thread 0x7fef1c9fe6c0 (LWP 18505)): #0 0x7fef1dcfc9ff in __GI___poll (fds=0x560db24e75b0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7fef1e05c237 in g_main_context_poll_unlocked (priority=, n_fds=2, fds=0x560db24e75b0, timeout=, context=0x560db24e73f0) at ../../../glib/gmain.c:4653 #2 g_main_context_iterate_unlocked (context=context@entry=0x560db24e73f0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4344 #3 0x7fef1e05c8f0 in g_main_context_iteration (context=0x560db24e73f0, may_block=may_block@entry=1) at ../../../glib/gmain.c:4414 #4 0x7fef1e05c941 in glib_worker_main (data=) at ../../../glib/gmain.c:6574 #5 0x7fef1e0899e1 in g_thread_proxy (data=0x560db24d8690) at ../../../glib/gthread.c:831 #6 0x7fef1dc893ec in start_thread (arg=) at ./nptl/pthread_create.c:444 #7 0x7fef1dd09a2c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 2 (Thread 0x7fef1d1ff6c0 (LWP 18504)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x7fef1e0b79a4 in g_cond_wait (cond=cond@entry=0x560db24e2108, mutex=mutex@entry=0x560db24e2100) at ../../../glib/gthread-posix.c:1552 #2 0x7fef1e02615b in g_async_queue_pop_intern_unlocked (queue=0x560db24e2100, wait=1, end_time=-1) at ../../../glib/gasyncqueue.c:425 #3 0x7fef1e08a06a in g_thread_pool_spawn_thread (data=) at ../../../glib/gthreadpool.c:311 #4 0x7fef1e0899e1 in g_thread_proxy (data=0x560db24e0570) at ../../../glib/gthread.c:831 #5 0x7fef1dc893ec in start_thread (arg=) at ./nptl/pthread_create.c:444 #6 0x7fef1dd09a2c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 1 (Thread 0x7fef1d643900 (LWP 18503)): #0 g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x560db2516200, fundamental_type=fundamental_type@entry=0x50 [GObject]) at ../../../gobject/gtype.c:4184 #1 0x7fef1e16387d in
Bug#1043241: options
We've been discussing this with upstream at https://github.com/OP-TEE/optee_client/pull/355 , which is an attempt to make emulation a runtime option. An argument is being made that it should remain a build time switch, to avoid having to ship the emulation code in production environments. We'll see how that shakes out. If this remains a build-time switch, one option would be for Debian to consider building 2 different binary packages. Would the maintainer be open to that?
Bug#1043241: please support non-emulated RPMB
Source: optee-client Version: 3.21.0-1 Severity: wishlist tee-supplicant can be configured at build-time to either use a real RPMB or to emulate one. The default is to emulate one, and that appears to be what the Debian binary does today. Please provide support for using a real RPMB.
Bug#1042438: bisection results
# first bad commit: [1c4dfadb4611ef511816dfdfbdb37d7d100b5a4b] ArmPkg/CpuDxe: Implement EFI memory attributes protocol Reverting that from latest upstream seems to make the problem go away. But the reason is not clear to me. This commit registers a protocol, but it doesn't appear to use that protocol on its own. I wonder if the AlmaLinux bootloader stack is trying to use it?
Bug#1041495: binutils regression causes edk2 to FTBFS - cannot find entry symbol _ModuleEntryPoint / assertion failures
Package: binutils
Version: 2.40.90.20230714-2
Severity: normal
Tags: upstream
edk2 has begun to FTBFS after recent binutils updates. Log follows below[*],
as well as a log using gcc -v[**].
This is reproducible with upstream binutils. I bisected the failure to
upstream commit fb221fba1a5 ("Add --remap-inputs option to the BFD linker").
After applying a reversion of that commit to the Debian package, this failure
goes away.
[*]
dannf@xps13:/tmp/edk2-2023.05$ "gcc" -o
/tmp/edk2-2023.05/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/DEBUG/StatusCodeHandlerPei.dll
-nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x40
-Wl,--entry,_ModuleEntryPoint -u _ModuleEntryPoint
-Wl,-Map,/tmp/edk2-2023.05/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/DEBUG/StatusCodeHandlerPei.map,--whole-archive
-Wl,-melf_x86_64,--oformat=elf64-x86-64,-pie -flto -Os
-Wl,--start-group,@/tmp/edk2-2023.05/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/OUTPUT/static_library_files.lst,--end-group
-g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror
-Wno-array-bounds -include AutoGen.h -fno-common -ffunction-sections
-fdata-sections -fno-stack-protector
-DSTRING_ARRAY_NAME=StatusCodeHandlerPeiStrings -m64 -march=x86-64
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))"
-maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie
-fno-asynchronous-unwind-tables -Wno-address -fno-omit-frame-pointer -flto
-DUSING_LTO -Wno-unused-but-set-variable -Wno-unused-const-variable
-DMDEPKG_NDEBUG -mno-mmx -mno-sse -D DISABLE_NEW_DEPRECATED_INTERFACES -D
TDX_GUEST_SUPPORTED -D ENABLE_MD5_DEPRECATED_INTERFACES
-Wl,--defsym=PECOFF_HEADER_SIZE=0x228
-Wl,--script=/tmp/edk2-2023.05/BaseTools/Scripts/GccBase.lds -Wno-error
/usr/bin/ld: warning: IoFifoSev.obj: missing .note.GNU-stack section implies
executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future
version of the linker
/usr/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint; defaulting to
0240
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.40.90.20230714 assertion fail
../../bfd/elflink.c:10611
/usr/bin/ld: BFD (GNU Binutils for
Bug#1035760: ITP: rshim-user-space -- Userspace (fuse) host driver for Mellanox BlueField devices
Package: wnpp Severity: wishlist Owner: dann frazier X-Debbugs-Cc: debian-de...@lists.debian.org, Liming Sun , Taihsiang Ho * Package name: rshim-user-space Version : 2.0.7 Upstream Contact: Mellanox Technologies * URL : https://github.com/Mellanox/rshim-user-space * License : GPL Programming Lang: C Description : Userspace (fuse) host driver for Mellanox BlueField devices This is a userspace driver that provides host access to BlueField PCIe devices. It can be used to push boot streams (usually to flash a new OS image), access a virtual console, provide a virtual network interface connecting the BlueField device and its host, and a debug interface. I work with BlueField PCIe devices as part of my day job. These devices run a full Linux distribution, and this driver is required to manage them from the host OS. I plan to maintain it as part of a small (1-3) person team, where I will likely be the only member who is a DD. We plan to use salsa for hosting.
Bug#1030898: please enable rdma support
Source: libpcap Version: 1.10.3-1 Severity: wishlist Tags: patch This would enable the RDMA sniffer in tcpdump. --- libpcap-1.10.3/debian/controlorig 2023-02-08 14:31:21.136166108 -0700 +++ libpcap-1.10.3/debian/control 2023-02-08 14:22:13.560898916 -0700 @@ -7,6 +7,7 @@ Build-Depends: bison, flex, libbluetooth-dev [linux-any], libdbus-1-dev, + libibverbs-dev, linux-libc-dev [i386] Rules-Requires-Root: no Standards-Version: 4.6.2 -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1025656: synchronous exception when using qemu-efi-aarch64 2022.11
tag 1025656 + confirmed thanks Thank you for the bug report. Something does seem to be wrong with the qemu-efi-aarch64. I'll see if I can find the cause through bisection.
Bug#1016359: [edk2-devel] [Patch 1/2] OvmfPkg: Change default to disable MptScsi and PvScsi
On Wed, Dec 07, 2022 at 11:22:10AM -0500, James Bottomley wrote: > On Wed, 2022-12-07 at 17:04 +0100, Ard Biesheuvel wrote: > > On Wed, 7 Dec 2022 at 17:02, Gerd Hoffmann wrote: > > > > > > On Wed, Dec 07, 2022 at 09:14:39AM -0500, James Bottomley wrote: > > > > On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote: > > > > > So at some point, these drivers will be removed rather than > > > > > kept > > > > > alive by the core team unless someone steps up. > > > > > > > > How important is keeping them alive? > > > > > > Most common use case is probably bootimg images created on other > > > hypervisors on qemu. Otherwise there is little reason to use > > > something which is not virtio-scsi. > > > > > > > I can volunteer to "maintain" them which I anticipate won't be > > > > much effort (plus I'm used to looking after obsolete SCSI > > > > equipment). The hardware is obsolete, so the mechanics of their > > > > emulation isn't going to change, the only potential risk is > > > > changes in the guest to host transmission layer that breaks > > > > something. > > > > > > > Thanks James, that would be very helpful. > > > > > Yes, I don't expect it being much effort, but knowing oldish scsi > > > stuff certainly helps understanding the driver code if needed. If > > > you want step up sent a patch updating Maintainers.txt accordingly. > > > > > > > Having the informed opinion of a domain expert should allow us to > > diagnose issued related to these drivers with more confidence, and > > also give us insight in how obsolete those drivers actually are. > > > > I can send the patch if you prefer. > > Sure, who can resist someone else doing all the work. > > I note we do have a maintained LSI driver: OvmfPkg/LsiScsiDxe. It > seems to be based on the 53c896 which is really only a marginal subset > of the 1030 ... if I'm remembering correctly the 1030 did Low Voltage > Differential (so a faster SCSI Parallel bus), but since that's a SCSI > Bus protocol, it should have no real impact on the utility of the > emulation. Is the LsiScsiDxe usable by Debian? I tried it, but it doesn't seem to enumerate any blk devices. The driver loads and reports that it is managing a device: Shell> drivers T D D Y C I R P F A V VERSION E G G #D #C DRIVER NAME IMAGE NAME == = = = == == === == [...] 6E 0010 D - - 1 - LSI 53C895A SCSI Controller Driver LsiScsiDxe [...] But no blk devices. Using the same VM config and just swapping the controller from lsilogic to virtio-scsi, yields the expected blk devices. To be clear, I'm unaware of OVMF ever working with this device in Debian. -dann
Bug#1025701: ovmf: does not recognise virtio-scsi controller
On Wed, Dec 7, 2022 at 10:36 AM Vincent Danjean wrote: > > Package: ovmf > Version: 2022.11-1 > Severity: normal > > Hi, > > I was thinking my bug was #1016359, but with the additionnal > info, it is a different one. So, I'm opening this bug as asked. > > ovmf in sid does not allow one to boot over a virtio-scsi contrôleur. > My disques are not seen anymore (not even in the EFI menus). > Downgrading to 2020.11-2+deb11u1 fixes the issue. Thanks for opening this new issue! As I mentioned in #1016359, I had no problems booting a VM w/ virtio-scsi in sid, so this seems like it may be config-specific. Can you provide me with a way to reproduce this - e.g. your libvirt XML? -dann
Bug#1016359: more info
On Tue, Dec 06, 2022 at 09:21:21PM +, Thorsten Glaser wrote: > Hi dann, > > >OK, then I think there may be multiple conflated issues here. Let's > >focus on the original use case you described - a VM created with > >virt-manager using a SCSI controller doesn't work. You tried > > Nonono, not quite. > > The original use case: an *EFI* VM with a SCSI controller does not > work. This is what I reported. Sure, I thought that was implied since this is a UEFI firmware bug. To be clear, my testing was with UEFI boot enabled. > >I just tried this on latest sid, and was able to reproduce. "lsilogic" > >does indeed not work. > > Oh, interesting. That’s got to be a new/different bug. We were on > bullseye, not sid, in case that helps. Do you believe it is new/different because you assumed I was not using a UEFI VM, or some other reason(s)? Note that I tested both bullseye and sid - neither supports it, and there's no evidence we ever did. > >Thorsten - do you have reason that you prefer lsilogic to virtio-scsi? > > Yes: I mostly run operating systems with no or insufficient support > for virtio over the hypervisor interface. (There’s also virtio over > PCI, but my inquiries to the qemu developers how to even access this > led to them eventually agreeing it probably isn’t even implemented > fully yet.) OK, so it sounds like this bug is really a "please enable lsilogic support in OVMF" - as that is the only way to support the guests you mostly run w/ SCSI. Is that accurate? > In the specific case, it was a VM “appliance” imported from some > other virtualisation tools that had a preconfigured Windows, and > the other VM hosts all use lsilogic for that. I trimmed the content about virtio-scsi. Please report any virtio-scsi issues in a new bug since I'm not convinced they are related to the issue you are having with lsilogic-dependendent VMs. Even if you think they are, I'd much rather treat them as separate and merge them later if necessary then try to triage both in the same bug. -dann
Bug#1016359: more info
On Tue, Dec 06, 2022 at 07:25:27PM +, Thorsten Glaser wrote: > Hi dann, > > > Could you confirm the last version that worked for you - perhaps > > I have never booted an EFI system before; this VM was the first > time for me, so I do not have a “last version” either way. > > As I said, this does work with BIOS (or at least used to). OK, then I think there may be multiple conflated issues here. Let's focus on the original use case you described - a VM created with virt-manager using a SCSI controller doesn't work. You tried "lsilogic", but you assume based on a RH report that "virtio-scsi" also does not work. I just tried this on latest sid, and was able to reproduce. "lsilogic" does indeed not work. I also didn't find a way to tell virt-manager to use anything other that "lsilogic". But, when I edited the XML and changed "lsilogic" to "virtio-scsi" (and ran virsh define), the system booted fine. Thorsten - do you have reason that you prefer lsilogic to virtio-scsi? If not, I suggest just using virtio-scsi. I don't know why virt-manager defaults to that - even virt-install seems to default to virtio-scsi. I suggest someone take that up w/ the virt-manager maintainer(s). Now, Vincent me too'd this bug to say that virtio-scsi wasn't working for them, but the version in bullseye did work. Thorsten reported using the version of ovmf that *is* in bullseye and wasn't using virtio-scsi. So whatever Vincent is/was seeing seems like a separate issue. If you are still having a problem Vincent, please report a separate issue. -dann
Bug#1016359: more info
tag 1016359 + moreinfo thanks Hi Thorsten, Could you confirm the last version that worked for you - perhaps testing some builds from snapshot.debian.org if you're unsure? If you can provide the libvirt XML from your VM, that may be useful as well. -dann
Bug#1016359: [edk2-devel] [Patch 1/2] OvmfPkg: Change default to disable MptScsi and PvScsi
On Tue, Dec 06, 2022 at 06:56:49AM +0100, Gerd Hoffmann wrote: > On Mon, Dec 05, 2022 at 04:36:15PM -0700, dann frazier wrote: > > On Tue, Jul 26, 2022 at 12:46:39PM -0700, Michael D Kinney wrote: > > > The email addresses for the reviewers of the MptScsi and > > > PvScsi are no longer valid. Disable the MptScsi and PvScsi > > > drivers in all DSC files until new maintainers/reviewers can > > > be identified. > > > > Hi Michael, > > > > This seems likely to be the reason for the following regression > > report in Debian: > > > > https://bugs.debian.org/1016359 > > I'm not so sure about that. > > > > - DEFINE PVSCSI_ENABLE = TRUE > > > - DEFINE MPT_SCSI_ENABLE = TRUE > > > + DEFINE PVSCSI_ENABLE = FALSE > > > + DEFINE MPT_SCSI_ENABLE = FALSE > > >DEFINE LSI_SCSI_ENABLE = FALSE > > The bug report talks about lsilogic and virtio-scsi. > > lsilogic was already disabled by default before this patch. > > virtio-scsi support is included and there are no plans to change > that because it is a rather essential driver. It works just fine > upstream, and there isn't even a config switch to disable it. Thanks Gerd - I'll work with the users to clarify via the bug (thanks for responding there as well btw). -dann
Bug#1016359: ovmf: does not recognise SCSI controllers
On Tue, Nov 29, 2022 at 04:47:58PM +0100, Vincent Danjean wrote: > Hi, > > I can confirm that virtio-scsi does not work anymore > (and that this is indeed really annoying). It looks like upstream changed the default to disabled ahead of stable202208: commit 57783adfb579da32b1eeda77b2bec028a5e0b7b3 Author: Michael D Kinney Date: Tue Jul 26 12:40:00 2022 -0700 OvmfPkg: Change default to disable MptScsi and PvScsi I suppose we could override that and turn them back on - but that implies doing so without upstream support.
Bug#1022365: pdsh: diff for NMU version 2.34-0.2
Control: tags 1022365 + patch
Control: tags 1022365 + pending
diff -Nru pdsh-2.34/debian/changelog pdsh-2.34/debian/changelog
--- pdsh-2.34/debian/changelog 2022-10-11 08:24:01.0 -0600
+++ pdsh-2.34/debian/changelog 2022-11-27 15:07:39.0 -0700
@@ -1,3 +1,11 @@
+pdsh (2.34-0.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Workaround test failures by using modules symlinked into a temp dir.
+(Closes: #1022365).
+
+ -- dann frazier Sun, 27 Nov 2022 15:07:39 -0700
+
pdsh (2.34-0.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru pdsh-2.34/debian/rules pdsh-2.34/debian/rules
--- pdsh-2.34/debian/rules 2022-10-11 08:24:01.0 -0600
+++ pdsh-2.34/debian/rules 2022-11-27 14:56:56.0 -0700
@@ -34,6 +34,36 @@
--infodir=\$${prefix}/share/info \
$(CONFIG_FLAGS)
+MODULE_DIRS := src/modules/.libs tests/test-modules/.libs
+override_dh_auto_test:
+ # pdsh will refuse to load modules in subdirs not owned by either
+ # the building user or root, which causes many tests to fail on
+ # the builders (see #1022365). We workaround that by copying
+ # the module dirs to a temp directory and symlinking them into
+ # the build tree.
+
+ # dh_auto_test will do this, but we need to build them first
+ # so we can copy them to the tempdir
+ $(MAKE) -C tests/test-modules check
+
+ # Save a copy of the module dirs to restore later
+ tar -c $(MODULE_DIRS) > debian/module-dirs.tar
+
+ # Now replace module dirs with symlinks to tempdir counterparts
+ # and run the tests.
+ set -e; \
+ tmpdir=`mktemp -d`; \
+ (cd $$tmpdir && tar xv) < debian/module-dirs.tar; \
+ rm -rf $(MODULE_DIRS); \
+ for dir in $(MODULE_DIRS); do \
+ ln -s $$tmpdir/$$dir $$dir; \
+ done; \
+ dh_auto_test; \
+ rm -rf $$tmpdir
+
+ # Restore the module directories (replacing the symlinks)
+ tar xv < debian/module-dirs.tar
+
override_dh_auto_install:
dh_auto_install
# Clean up directory
@@ -50,3 +80,8 @@
rm -f $(CURDIR)/debian/pdsh/usr/bin/rpdcp
cp $(CURDIR)/debian/rpdcp.script $(CURDIR)/debian/pdsh/usr/bin/rpdcp
chmod 755 $(CURDIR)/debian/pdsh/usr/bin/rpdcp
+
+override_dh_auto_clean:
+ rm -f debian/module-dirs.tar
+ find . -name .libs -type l -exec rm {} \;
+ dh_auto_clean
Bug#1022365: reproduction
This seems to be the source of the problem: pdsh@ip-10-84-234-180: module path "/<>/src/modules/.libs" insecure. pdsh@ip-10-84-234-180: "/build": Owner not root, current uid, or pdsh executable owner pdsh@ip-10-84-234-180: Couldn't load any pdsh modules Indeed, I can reproduce by building in a directory that has an ancestor directory owned by a user that is neither root, nor myself. I've not been clever enough to workaround this. Two options would be to (1) disable the failing tests or (2) avoid the failures by linking the plugins statically. Neither seems ideal.
Bug#1022365: confirmed
Weird, tests pass for me locally. Will look into it.
Bug#589913: generic host argument support
Would you consider adding host argument support without providing a
[ppa] implementation? Users could then opt-in by adding a [ppa]
section to their /etc/dput.cf (or ~/.dput.cf). Here's just that piece
of the Ubuntu delta:
diff -urpN dput-1.1.2.orig/doc/man/dput.1 dput-1.1.2/doc/man/dput.1
--- dput-1.1.2.orig/doc/man/dput.1 2022-07-01 16:15:28.0 -0600
+++ dput-1.1.2/doc/man/dput.1 2022-09-20 15:28:47.064454572 -0600
@@ -15,7 +15,7 @@
.OP \-DPUVdflosu
.OP \-c CONFIGFILE
.OP \-e DAYS
-.RI [ HOSTNAME ]
+.RI [ HOSTNAME [:ARGUMENT] ]
.I CHANGESFILE
\f[R].\|.\|.\f[]
.YS
@@ -65,6 +65,10 @@ can perform on each package.
configuration. If not specified, \f[I]HOSTNAME\f[] defaults to the
value of the \f[B]default_host_main\f[] configuration parameter.
.
+You also can
+pass an argument to the host by appending the hostname with a colon followed
+by the argument.
+.
.P
The file transfer method is determined by the \f[B]method\f[]
configuration parameter for the specified host. See
diff -urpN dput-1.1.2.orig/doc/man/dput.cf.5 dput-1.1.2/doc/man/dput.cf.5
--- dput-1.1.2.orig/doc/man/dput.cf.5 2022-07-01 16:15:28.0 -0600
+++ dput-1.1.2/doc/man/dput.cf.52022-09-20 15:27:07.403817539 -0600
@@ -340,6 +340,14 @@ for packages that are allowed to be uplo
This variable is used when guessing the host to upload to.
.
.\" ==
+.SH HOST ARGUMENT
+.P
+If a user passes an argument to a host by appending the hostname with a colon,
+.B %(HOSTNAME)s
+will be replaced with the specified argument. Otherwise, it will be replaced
+with an empty string.
+.
+.\" ==
.SH FILES
.
.TP
diff -urpN dput-1.1.2.orig/dput/dput.py dput-1.1.2/dput/dput.py
--- dput-1.1.2.orig/dput/dput.py2022-07-01 16:15:28.0 -0600
+++ dput-1.1.2/dput/dput.py 2022-09-20 15:31:00.221305900 -0600
@@ -979,6 +979,19 @@ def main():
if len(args) == 1 and not options.check_only:
changes_file_paths = args[0:]
else:
+if ':' in args[0]:
+sys.stdout.write("D: Splitting host argument out of %s.\n" %
args[0])
+args[0], host_argument = args[0].split(":", 1)
+else:
+host_argument = ""
+
+if config.has_section(args[0]):
+sys.stdout.write("D: Setting host argument.\n")
+config.set(args[0], args[0], host_argument)
+else:
+# Let the code below handle this as it is sometimes okay (ie. -o)
+pass
+
if not options.check_only:
if options.debug:
sys.stdout.write(
Bug#1016966: pdsh: diff for NMU version 2.31-3.1
Package: pdsh
Version: 2.31-3
Severity: normal
Tags: patch pending
hey Brian
As discussed via e-mail, I've prepared an NMU for pdsh (versioned as
2.31-3.1) and uploaded it to DELAYED/1-day. Please feel free to tell
me if I should delay it longer.
-dann
diff -Nru pdsh-2.31/debian/changelog pdsh-2.31/debian/changelog
--- pdsh-2.31/debian/changelog 2014-10-26 20:37:56.0 -0600
+++ pdsh-2.31/debian/changelog 2022-08-10 11:35:52.0 -0600
@@ -1,3 +1,13 @@
+pdsh (2.31-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Enable readline support (closes: #754936).
+ * Updated Homepage URL (closes: #940539).
+ * Add Brazilian Portuguese debconf templates translation, thanks to
+Adriano Rafael Gomes (closes: #811540).
+
+ -- dann frazier Wed, 10 Aug 2022 11:35:52 -0600
+
pdsh (2.31-3) unstable; urgency=low
* Add Italian translation (closes: #764088)
diff -Nru pdsh-2.31/debian/control pdsh-2.31/debian/control
--- pdsh-2.31/debian/control 2014-10-26 20:37:32.0 -0600
+++ pdsh-2.31/debian/control 2022-08-10 11:35:52.0 -0600
@@ -3,14 +3,14 @@
Priority: extra
Maintainer: Brian Pellin
Uploaders: tony mancill
-Build-Depends: debhelper (>= 9), autotools-dev, libgenders0-dev (>= 1.3-4), libltdl-dev
+Build-Depends: debhelper (>= 9), autotools-dev, libgenders0-dev (>= 1.3-4), libltdl-dev, libreadline-dev
Standards-Version: 3.9.6
VCS-Git: git://git.debian.org/git/collab-maint/pdsh.git
Package: pdsh
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, perl, rsh-client, openssh-client | ssh (<< 1:3.8.1p1-9), genders ( >= 1.4-1-1 )
-Homepage: https://computing.llnl.gov/linux/pdsh.html
+Homepage: https://software.llnl.gov/repo/#/chaos/pdsh
Description: Efficient rsh-like utility, for using hosts in parallel
Pdsh is a high-performance, parallel remote shell utility, similar to dsh.
It has built-in, thread-safe clients for rsh. Pdsh uses a "sliding window"
diff -Nru pdsh-2.31/debian/po/pt_BR.po pdsh-2.31/debian/po/pt_BR.po
--- pdsh-2.31/debian/po/pt_BR.po 1969-12-31 17:00:00.0 -0700
+++ pdsh-2.31/debian/po/pt_BR.po 2022-08-10 11:33:15.0 -0600
@@ -0,0 +1,58 @@
+# Debconf translations for pdsh.
+# Copyright (C) 2016 THE pdsh'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the pdsh package.
+# Adriano Rafael Gomes , 2016.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: pdsh 2.31-3\n"
+"Report-Msgid-Bugs-To: bpel...@pellin.net\n"
+"POT-Creation-Date: 2006-11-06 21:50-0600\n"
+"PO-Revision-Date: 2016-01-09 13:39-0200\n"
+"Last-Translator: Adriano Rafael Gomes \n"
+"Language-Team: Brazilian Portuguese \n"
+"Language: pt_BR\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid "Should the pdsh binary be installed setuid root?"
+msgstr "O binário pdsh deve ser instalado com setuid root?"
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid ""
+"The pdsh program can be installed setuid root, so that it will run with the "
+"permissions of the 'root' user."
+msgstr ""
+"O programa pdsh pode ser instalado com setuid root, assim ele executará com "
+"as permissões do usuário \"root\"."
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid ""
+"This is required for non-root accounts to use the rsh remote-command method "
+"of pdsh. However, enabling this could be a security risk."
+msgstr ""
+"Isso é obrigatório para contas não root poderem usar o método rsh comando-"
+"remoto do pdsh. Entretanto, habilitar isso pode ser um risco de segurança."
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid ""
+"In short, unless you know what you are doing or have a very controlled user "
+"base, you should not enable this feature. If you choose not to enable "
+"setuid root, then you can still use pdsh through tools like sudo or with the "
+"ssh remote-command module."
+msgstr ""
+"Em resumo, a menos que você saiba o que está fazendo, ou tenha uma base de "
+"usuários muito controlada, você não deveria habilitar essa funcionalidade. "
+"Se você escolher não habilitar setuid root, então você ainda pode usar o "
+"pdsh através de ferramentas como sudo ou com o módulo ssh comando-remoto."
diff -Nru pdsh-2.31/debian/rules pdsh-2.31/debian/rules
--- pdsh-2.31/debian/rules 2014-07-06 11:24:03.0 -0600
+++ pdsh-2.31/debian/rules 2022-08-10 10:06:52.0 -0600
@@ -42,6 +42,7 @@
dh_auto_configure -- \
--with-ssh \
--with-genders \
+ --with-readline \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
Bug#1016955: makedumpfile - does not work on arm64 since 5.18
On Wed, Aug 10, 2022 at 04:23:56PM +0200, Bastian Blank wrote: > I don't know how to debug it. With older versions it works. On amd64 it > also works. hey Bastian, makedumpfile often needs updates to adjust to changes in upstream kernel internals, and that tends to lag the kernel releases themselves. If you'd like to help accelerate that, one option might be to report it upstream and possibly provide bisect results showing the kernel change to which makedumpfile needs to adapt. -dann
Bug#1015759: ovmf: OVMF_CODE_4M.ms.fd puts EFI shell first in boot order
tag 1015759 + confirmed
thanks
On Wed, Jul 20, 2022 at 04:45:03PM +, Robert wrote:
> Package: ovmf
> Version: 2022.05-2
> Severity: normal
> X-Debbugs-Cc: robert.schneide...@sap.com
>
> Dear Maintainer,
>
> I'm trying to test an image creation mechanism by booting the resulting
> image with QEMU with Secure Boot enforced. Unfortunately, the
> OVMF_VARS*.ms.fd seems to define a boot order where the EFI shell is
> placed before the disk.
Hm.. that must be a side effect of enrolling the keys, but I'm not
sure why that would be. Certainly we could clear the BootOrder
variable during that process, but I'd like to first understand what is
changing it to begin with.
> In other words, I land in an EFI shell when I try to boot. This only
> happens for the .ms.fd files; the OVMF_{CODE,VARS}_4M.fd directly boot
> the attached disk.
>
> I can change the boot order manually, save a new vars file and then boot
> from the disk using that vars file. However that was not quite easy for
> me to find out, I would appreciate if the secure-boot-enforcing and
> non-enforcing files could behave similarly with regards to the boot order.
>
> My qemu invocation:
>
> qemu-system-x86_64 \
> -machine q35 \
> -global ICH9-LPC.disable_s3=1 \
> -nodefaults \
> -nographic \
> -drive
> if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.ms.fd
> \
> -drive
> if=pflash,format=raw,unit=1,readonly=on,file=/usr/share/OVMF/OVMF_VARS_4M.ms.fd
> \
> -drive file=image.qcow2,media=disk,index=1 \
> -serial mon:stdio
>
> I'm not sure why the -machine and -global options are needed but I guess
> that's an unrelated issue.
Q35 is required for secure boot. The 4M images shouldn't need s3
disabled, but the 2M ones do (they use 64-bit PEI, which doesn't
support S3 w/ SMM).
Bug#1014922: please --enable-rshim
Package: openocd Version: 0.11.0-1+b1 Severity: wishlist I'm using openocd to debug an Nvidia Bluefield device using rshim. In order to do this, I needed to rebuild the package with --enable-rshim. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openocd depends on: ii libc6 2.33-8 ii libcapstone4 4.0.2-5 ii libftdi1-2 1.5-5+b2 ii libgpiod2 1.6.3-1+b2 ii libhidapi-hidraw0 0.11.2-1 ii libjaylink00.2.0-1 ii libjim0.81 0.81+dfsg0-2 ii libusb-0.1-4 2:0.1.12-32 ii libusb-1.0-0 2:1.0.26-1 openocd recommends no packages. openocd suggests no packages. -- no debconf information
Bug#1007793: ovmf: edk2-stable202202 not working with QEMU NVMe
On Wed, Mar 16, 2022 at 09:15:16PM +0100, Mara Sophie Grosch wrote: > Package: ovmf > Version: 2022.02-2 > Severity: important > Tags: upstream patch > > Hi, > > the latest edk2 stable release (202202) introduces an issue with the > NVMe controller in QEMU, recognizing it as not support NVMe command set. > > The problem was introduced by a recent change for a new feature (boot > partition), making broken code look at more bits of the "command sets > supported" register and thus failing by the value QEMU sets. > > I submitted a patch upstream via GitHub PR [1], but since I got bitten by > this via debian package, I figured I report this here, too. Thanks Mara! I've *'d your PR to keep an eye on it. -dann
Bug#1006842: ovmf 2022.02-1 makes TPM unusable in Windows guests
On Sun, Mar 06, 2022 at 04:47:58PM +, Etienne Dechamps wrote: > Package: ovmf > Version: 2022.02-1 > Severity: important > Control: fixed -1 2021.11-1 > > An ovmf regression somewhere between 2021.11-1 and 2022.02-1 makes it > impossible to use a TPM in Windows guest VMs (tested with various > Windows 11 builds). The Windows Device Manager shows the TPM as > defective, with the error "This device cannot start. (Code 10) A > protocol error was detected between the driver and the device". > tpm.msc shows no TPM is available. > > One consequence is that Windows 11 refuses to install with ovmf > 2022.02-1, since the Windows 11 installer demands a functional TPM. > > Steps to reproduce using qemu-system-x86 1:6.2+dfsg-2 and swtpm 0.7.1-1: > > # mkdir /tmp/tpm > # swtpm socket --tpm2 --tpmstate dir=/tmp/tpm --ctrl > type=unixio,path=/tmp/tpm/sock & > # qemu-system-x86_64 -enable-kvm -drive > if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd > -chardev socket,id=tpm,path=/tmp/tpm/sock -tpmdev > emulator,id=tpm,chardev=tpm -device tpm-tis,tpmdev=tpm … > > With ovmf 2021.11-1, the TPM is functional in Windows using the above > parameters; with 2022.02-1, it is not. Switching to "tpm-crb" doesn't > seem to make any difference. > > In Linux guests the TPM appears to be functional, although the guest > kernel outputs the following messages with 2022.02-1: > > tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1, rev-id 1) > tpm tpm0: A TPM error (256) occurred attempting the self test > tpm tpm0: starting up the TPM manually > > With 2021.11-1, the kernel only outputs the first line - no errors. Thanks for the bug report. Apparently upstream renamed the flag to enable the TPM, so we need to adjust the build: https://github.com/tianocore/edk2/commit/4de8d61bcec02a13ceed84f92b0cf3ea58adf9c5 -dann
Bug#1006703: dtrace predictable temp file causes race
Package: systemtap-sdt-dev Version: 4.6-1 Severity: normal dtrace generates .c code in a predictable temporary file which makes it susceptible to crashes. I've seen this happen in practice when rebuilding libvirt/focal on a system with 48 cores. The race window is wide enough that the crash is nearly 100% reproducible. I submitted a patch upstream that has now been accepted: https://sourceware.org/git/?p=systemtap.git;a=commit;h=0de9020c970bceda73e32bbd169c12e7579f21ec Can we get that fix applied to Debian? -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-rc4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemtap-sdt-dev depends on: ii python3 3.9.8-1 systemtap-sdt-dev recommends no packages. systemtap-sdt-dev suggests no packages. -- no debconf information
Bug#1006701: requires golang-github-urfave-cli-v2-dev >= 2.3
Source: rootlesskit Version: 0.14.6-1 Severity: normal rootlesskit uses the "nindent" template function in its help output. This wasn't added to golang-github-urfave-cli-v2 until version 2.3: See: https://github.com/urfave/cli/commit/be9c0378 $ git tag --contains be9c0378 v2.3.0 rootlesskit compiles fine with cli 2.2.0-3, but fails at runtime: $ rootlesskit -h panic: template: help:11: function "trim" not defined goroutine 1 [running]: text/template.Must(...) text/template/helper.go:23 github.com/urfave/cli/v2.printHelpCustom(0x9adb40, 0xc10020, 0xc000156000, 0xb8b, 0x8ec480, 0xc01b00, 0x0) github.com/urfave/cli/v2/help.go:273 +0x50b github.com/urfave/cli/v2.printHelp(0x9adb40, 0xc10020, 0xc000156000, 0xb8b, 0x8ec480, 0xc01b00) github.com/urfave/cli/v2/help.go:288 +0x6d github.com/urfave/cli/v2.ShowAppHelp(0xc60f00, 0xc8ec01, 0x38) github.com/urfave/cli/v2/help.go:81 +0x190 github.com/urfave/cli/v2.(*App).RunContext(0xc01b00, 0x9b6c00, 0xc22060, 0xc0e080, 0x2, 0x2, 0x0, 0x0) github.com/urfave/cli/v2/app.go:263 +0xa59 github.com/urfave/cli/v2.(*App).Run(...) github.com/urfave/cli/v2/app.go:215 main.main() github.com/rootless-containers/rootlesskit/cmd/rootlesskit/main.go:221 +0x1fb8 I therefore suggest versioning the build-dep to e.g. (>= 2.3.0). -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-rc4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1006628: needs versioned build-dep on golang-golang-x-sys-dev
Source: golang-github-moby-sys Version: 0.0~git20201113.5a29239-1 Severity: normal Tags: patch Rebuilding golang-github-moby-sys with an older golang-golang-x-sys-dev fails: golang.org/x/sys/unix path/filepath github.com/moby/sys/mountinfo # github.com/moby/sys/mountinfo src/github.com/moby/sys/mountinfo/mounted_linux.go:15:16: undefined: unix.Openat2 src/github.com/moby/sys/mountinfo/mounted_linux.go:15:50: undefined: unix.OpenHow src/github.com/moby/sys/mountinfo/mounted_linux.go:24:13: undefined: unix.Openat2 src/github.com/moby/sys/mountinfo/mounted_linux.go:24:40: undefined: unix.OpenHow github.com/moby/sys/symlink dh_auto_build: error: cd _build && go install -trimpath -v -p 1 github.com/moby/sys/mount github.com/moby/sys/mountinfo github.com/moby/sys/symlink returned exit code 2 make: *** [debian/rules:6: binary] Error 2 It looks like the first upload w/ Openat2 support was: 0.0~git20201101.da20708-1 So could we add a versioned build-dep? --- debian/control.orig 2022-02-28 22:06:00.957994723 + +++ debian/control 2022-02-28 22:00:28.630593702 + @@ -7,7 +7,7 @@ Build-Depends: debhelper-compat (= 12), dh-golang, golang-any, - golang-golang-x-sys-dev + golang-golang-x-sys-dev (>> 0.0~git20201101.da20708-1~) Standards-Version: 4.5.0 Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-github-moby-sys Vcs-Git: https://salsa.debian.org/go-team/packages/golang-github-moby-sys.git -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-rc4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#988817:
On Fri, Feb 18, 2022 at 1:27 PM Limonciello, Mario wrote: > > [Public] > > > > > On Fri, Feb 18, 2022 at 08:16:00PM +, Limonciello, Mario wrote: > > > [Public] > > > > > > The package is present in Ubuntu (which shares the same source package as > > Debian). So would prefer to keep it in place. > > > > Just a thought, but couldn't you modify the build to dynamically add > > this relationship only when building on Ubuntu? Possibly using > > sustvars or a generated control file like qemu has? > > I mean sure - but isn't it harmless to have an extra Recommends? > Do tools complain? Good question - Robbie, how did you notice this? -dann
Bug#988817:
On Fri, Feb 18, 2022 at 08:16:00PM +, Limonciello, Mario wrote: > [Public] > > The package is present in Ubuntu (which shares the same source package as > Debian). So would prefer to keep it in place. Just a thought, but couldn't you modify the build to dynamically add this relationship only when building on Ubuntu? Possibly using sustvars or a generated control file like qemu has? -dann
Bug#1003480: Using AAVMF32_VARS.fd causes data exception and failure to boot
On Mon, Jan 10, 2022 at 02:50:27PM -0600, Glenn Washburn wrote: > Package: qemu-efi-arm > Version: 2020.11-2 > > Hello Maintainers, > > There seems to be an issue with the 32-bit ARM UEFI firmware VARS file, > at /usr/share/AAVMF/AAVMF32_VARS.fd. When I try to use it, I get a Data > exception and a failure to boot the firmware. > > This issue can be reproduced using the following command: > > qemu-system-arm -display none -machine virt -drive \ > > if=pflash,format=raw,unit=1,readonly=on,file=/usr/share/AAVMF/AAVMF32_VARS.fd > \ > -drive \ > > if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/AAVMF/AAVMF32_CODE.fd > \ > -monitor file:/dev/null -serial file:/dev/stdout > > It can be seen that the VARS file is at issue here because the > following command boots as expected: > > qemu-system-arm -display none -machine virt -drive \ > > if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/AAVMF/AAVMF32_CODE.fd > \ > -monitor file:/dev/null -serial file:/dev/stdout Hi Glenn, The VARS file needs to be writeable. You should typically make a copy per-guest and omit the readonly=on bit for that file on the QEMU command line. -dann
Bug#997913: OVMF-ia32 does not provide file usable by -bios
(sorry for the late response) On Fri, Oct 29, 2021 at 01:03:32PM -0500, Glenn Washburn wrote: > On Thu, 28 Oct 2021 12:00:09 -0600 > dann frazier wrote: > > > On Thu, Oct 28, 2021 at 11:19:06AM -0500, Glenn Washburn wrote: > > > On Thu, 28 Oct 2021 07:46:11 -0600 > > > dann frazier wrote: > > > > On Tue, Oct 26, 2021 at 07:31:38PM -0500, Glenn Washburn wrote: > > > > > Package: ovmf-ia32 > > > > > Version: 2020.11-4 > > > > > > > > > > Hello Maintainers, > > > > > > > > > > I'd like ovmf-ia32 to install a file useable by QEMU's -bios option. > > > > > Currently the package only installs OVMF32_CODE_4M.secboot.fd and > > > > > OVMF32_VARS_4M.fd, but I believe I need a file that combines both code > > > > > and vars. According to the wiki[1], I believe I can use the existing > > > > > files using "-drive if=pflash,..." options, but that is not a great > > > > > option for me. > > > > > > > > Can you elaborate more on your use case? While we do provide such an > > > > image for X64, that is for backwards-compatibility only. > > > > > > I'm working on GRUB2's test suite and it has tests that use QEMU for > > > many of its tests. > > > > edk2's autopkgtest has a testing framework that tests OVMF32, and all > > the other archs, using -pflash. It also does tests with GRUB images > > (e.g. making sure signed versions work w/ SecureBoot enabled, unsigned > > versions do not). Let me know if it'd be useful to collaborate on that > > framework. Here's the main bit: > > > > https://salsa.debian.org/qemu-team/edk2/-/blob/debian/debian/python/UEFI/Qemu.py > > Thanks for the reference, this will be helpful in converting grub tests > to use the pflash instead of -bios option. I'm wondering by the paths > are hard-coded, when it seems that the purpose of the json files in > /usr/share/qemu/firmware is to provide these paths. That's a good point, parsing the descriptors would be more portable (and also let us test the descriptors). > code assumes a debian system and that the paths won't change much. Yes to both > Using the json files in the grub tests is more problematic because they > are in bash. And yes, I could use jq, but I'm reluctant to add another > dependency. I'm still mulling it over. > > > > Specifically, I need the combined firmware file when testing the > > > i386-efi target. > > > > Why? I mean, why can't that testing use a throw-away pflash image for > > VARS like we do in edk2 autopkgtesting? > > Ok, actually, I can use the pflash. I was wanting to avoid that because > it makes things more complicated. I thought it might be easier to get > the combined file included and that it might be useful to others. I > have now tesed using pflash and it does work. > > The issue is that I'd like to have the tests use paths standardized > across distros. When using -bios, the -L option can be used to add to a > search path to find the firmware file. Of course, this doesn't work if > the filenames of the firmware aren't standardized. For ARM/ARM64, it > looks like debian's path for the code and vars is fairly standard > across distros, and to a lesser extent x86_64, but for i386 it looks > like filenames and where they are on the filesystem vary widely. > > I'm seeing now that a good resolution to my issue may lie at the > conjunction of QEMU, OVMF, and distro packaging. > > > > Perhaps, I don't need a binary with combined code and vars. On the ARM > > > and ARM64 EFI targets, I can pass the AAVMF32_CODE.fd to -bios just > > > fine. So perhaps the IA32 firmware is built in such a way that the code > > > file requires the vars, but could be build to not require it? IOW, why > > > can't I just send the firmware CODE file to QEMU using -bios like I can > > > with ARM and ARM64? > > > > I don't know if or why OVMF*_CODE doesn't work with -bios. Separate > > CODE/VARS is the most flexible build (and what people should use > > in production), so that's what we provide. I'd need to be convinced > > that there's a good reason to increase the size of the ovmf-ia32 deb > > for all users to support -bios mode. > > The best of both worlds would be to get a version of OVMF*_CODE that > works with -bios. According to this (old?) document[1], builds using -D > SECURE_BOOT_ENABLE, which I presume is the case here, must use > pflash. Yes, we do build w/ SECURE_BOOT_ENABLE, so that makes sense. > So perhaps the best of both worlds isn't possible now. Is a buil
Bug#997913: OVMF-ia32 does not provide file usable by -bios
On Thu, Oct 28, 2021 at 11:19:06AM -0500, Glenn Washburn wrote: > On Thu, 28 Oct 2021 07:46:11 -0600 > dann frazier wrote: > > On Tue, Oct 26, 2021 at 07:31:38PM -0500, Glenn Washburn wrote: > > > Package: ovmf-ia32 > > > Version: 2020.11-4 > > > > > > Hello Maintainers, > > > > > > I'd like ovmf-ia32 to install a file useable by QEMU's -bios option. > > > Currently the package only installs OVMF32_CODE_4M.secboot.fd and > > > OVMF32_VARS_4M.fd, but I believe I need a file that combines both code > > > and vars. According to the wiki[1], I believe I can use the existing > > > files using "-drive if=pflash,..." options, but that is not a great > > > option for me. > > > > Can you elaborate more on your use case? While we do provide such an > > image for X64, that is for backwards-compatibility only. > > I'm working on GRUB2's test suite and it has tests that use QEMU for > many of its tests. edk2's autopkgtest has a testing framework that tests OVMF32, and all the other archs, using -pflash. It also does tests with GRUB images (e.g. making sure signed versions work w/ SecureBoot enabled, unsigned versions do not). Let me know if it'd be useful to collaborate on that framework. Here's the main bit: https://salsa.debian.org/qemu-team/edk2/-/blob/debian/debian/python/UEFI/Qemu.py > Specifically, I need the combined firmware file when testing the > i386-efi target. Why? I mean, why can't that testing use a throw-away pflash image for VARS like we do in edk2 autopkgtesting? > Perhaps, I don't need a binary with combined code and vars. On the ARM > and ARM64 EFI targets, I can pass the AAVMF32_CODE.fd to -bios just > fine. So perhaps the IA32 firmware is built in such a way that the code > file requires the vars, but could be build to not require it? IOW, why > can't I just send the firmware CODE file to QEMU using -bios like I can > with ARM and ARM64? I don't know if or why OVMF*_CODE doesn't work with -bios. Separate CODE/VARS is the most flexible build (and what people should use in production), so that's what we provide. I'd need to be convinced that there's a good reason to increase the size of the ovmf-ia32 deb for all users to support -bios mode. > Also, I don't need the secure boot feature of the firmware. The wiki > leaves me with the suspicion that I may need to configure some of the > firmware variables before I can boot successfully. Perhaps that would > only be the case if I were wanting to boot with secure boot enabled. > > I'm also curious about the 4M in the file name. My guess is that it > indicates a build option. Could this be part of the equation? Please read through the README.Debian file (latest one from unstable). If that doesn't answer the above 2 points, let me know so I can clarify it there. -dann
Bug#997913: OVMF-ia32 does not provide file usable by -bios
severity 997913 wishlist thanks On Tue, Oct 26, 2021 at 07:31:38PM -0500, Glenn Washburn wrote: > Package: ovmf-ia32 > Version: 2020.11-4 > > Hello Maintainers, > > I'd like ovmf-ia32 to install a file useable by QEMU's -bios option. > Currently the package only installs OVMF32_CODE_4M.secboot.fd and > OVMF32_VARS_4M.fd, but I believe I need a file that combines both code > and vars. According to the wiki[1], I believe I can use the existing > files using "-drive if=pflash,..." options, but that is not a great > option for me. Can you elaborate more on your use case? While we do provide such an image for X64, that is for backwards-compatibility only. -dann
Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
On Tue, Aug 31, 2021 at 10:00:18PM +0300, Michael Tokarev wrote: > 31.08.2021 18:02, dann frazier wrote: > > > char device redirected to /dev/pts/14 (label charserial0) > > about to fire assert: salen=2 > > qemu-system-x86_64: ../../util/qemu-sockets.c:1352: > > socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) > > + 1 && salen <= sizeof(struct sockaddr_un)' failed. > > 2021-08-31 15:01:18.082+: shutting down, reason=crashed > > Thank you very much dann! > So this new assert() is wrong on both min and max sides. Oh well.. ;) > > I cooked another patch to fix this, will upload it asap. > > It is a fun one.. ;) Thanks for the fix Michael! It works for me. -dann
Bug#993145: 1:6.1+dfsg-3 update
Here's an updated assert using 1:6.1+dfsg-3: char device redirected to /dev/pts/8 (label charserial0) qemu-system-x86_64: ../../util/qemu-sockets.c:1349: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un) + su->sun_path[0] ? 1 : 0' failed. 2021-08-31 16:20:42.453+: shutting down, reason=crashed
Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
On Tue, Aug 31, 2021 at 01:13:40AM +0300, Michael Tokarev wrote: > dann, can you please add a printf to util/qemu-sockets.c > before the assert() which is failing, to see what's the > value of salen? since you can reproduce this.. > I'm still not 100% sure what the actual problem is - > or _which_ problem it is in particular. > > It is either one byte too large (for the trailing \0) > or one byte too small (with zero-length sun_path). > > Like this: > > diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c > index f2f3676d1f..89a405476a 100644 > --- a/util/qemu-sockets.c > +++ b/util/qemu-sockets.c > @@ -1345,6 +1345,10 @@ socket_sockaddr_to_address_unix(struct > sockaddr_storage *sa, > SocketAddress *addr; > struct sockaddr_un *su = (struct sockaddr_un *)sa; > > +if(!(salen >= sizeof(su->sun_family) + 1 && > + salen <= sizeof(struct sockaddr_un))) > + fprintf(stderr, "about to fire assert: salen=%d\n", salen); > + > assert(salen >= sizeof(su->sun_family) + 1 && > salen <= sizeof(struct sockaddr_un)); char device redirected to /dev/pts/14 (label charserial0) about to fire assert: salen=2 qemu-system-x86_64: ../../util/qemu-sockets.c:1352: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed. 2021-08-31 15:01:18.082+: shutting down, reason=crashed
Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
On Tue, Aug 31, 2021 at 01:13:40AM +0300, Michael Tokarev wrote: > dann, can you please add a printf to util/qemu-sockets.c > before the assert() which is failing, to see what's the > value of salen? since you can reproduce this.. > I'm still not 100% sure what the actual problem is - > or _which_ problem it is in particular. > > It is either one byte too large (for the trailing \0) > or one byte too small (with zero-length sun_path). > > Like this: > > diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c > index f2f3676d1f..89a405476a 100644 > --- a/util/qemu-sockets.c > +++ b/util/qemu-sockets.c > @@ -1345,6 +1345,10 @@ socket_sockaddr_to_address_unix(struct > sockaddr_storage *sa, > SocketAddress *addr; > struct sockaddr_un *su = (struct sockaddr_un *)sa; > > +if(!(salen >= sizeof(su->sun_family) + 1 && > + salen <= sizeof(struct sockaddr_un))) > + fprintf(stderr, "about to fire assert: salen=%d\n", salen); > + > assert(salen >= sizeof(su->sun_family) + 1 && > salen <= sizeof(struct sockaddr_un)); Sure, build in progress...
Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
On Mon, Aug 30, 2021 at 02:38:30PM -0600, dann frazier wrote:
> On Sat, Aug 28, 2021 at 02:53:01PM +0300, Michael Tokarev wrote:
> > On 27.08.2021 23:25, dann frazier wrote:
> > > Package: qemu-system-x86
> > > Version: 1:6.1+dfsg-1
> > > Severity: normal
> > >
> > >
> > > A VM that I created with either virt-manager or virtinst sometime ago now
> > > crashes when I attempt to start it under QEMU 6.1.
> >
> > Lovely.
> >
> > I can only guess this is due to libvirt's qemu-guest-agent socket, this one:
> >
> > > -chardev socket,id=charchannel0,fd=43,server=on,wait=off \
> > > -device
> > > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
> > > \
> >
> > Dann, can you please disable the socket/qga to verify?
> > If this is the case this is an impotant issue at least,
> > it should definitely be fixed.
>
> Thanks for the response Michael. Unfortunately, I'm not able to
> reproduce at the moment. After filing this bug, I looked through git
> logs and, on a hunch, decided to try w/ the following patch reverted:
>
> 4cfd970ec1 util: fix abstract socket path copy
>
> That seemed to make the issue go away. Today I restored the archive
> versions of the QEMU packages, and the issue no longer
> reproduces. So now I have to question whether or not that revert was
> significant or purely correlation :(
Aha! It seems that the important difference is whether or not the
virt-manager GUI window for the VM is active. If it is active, the VM
crashes regardless of how it is started (virsh console start/clicking
"play" button). If the GUI is not active, the VM always works.
With this knowledge I am able to confidently say that reverting
4cfd970ec1 *does* reliably avoid the problem.
I was also now able to run the requested test, dropping the
qemu-guest-agent socket. This did not avoid the problem:
2021-08-30 21:10:46.931+: starting up libvirt version: 7.6.0, package: 1
(Andrea Bolognani Thu, 19 Aug 2021 21:16:21 +0200), qemu
version: 6.1.0Debian 1:6.1+dfsg-1, kernel: 5.13.0-trunk-amd64, hostname:
xps13.dannf
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \
HOME=/var/lib/libvirt/qemu/domain-24-debian10 \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-24-debian10/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-24-debian10/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-24-debian10/.config \
/usr/bin/qemu-system-x86_64 \
-name guest=debian10,debug-threads=on \
-S \
-object
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-24-debian10/master-key.aes"}'
\
-machine
pc-q35-5.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram
\
-cpu
Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hle=off,rtm=off
\
-m 2048 \
-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":2147483648}' \
-overcommit mem-lock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid REDACTED \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=39,server=on,wait=off \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot menu=on,strict=on \
-device
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
\
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \
-device pcie-pci-bridge,id=pci.9,bus=pci.8,addr=0x0 \
-device pcie-root-port,port=0x18,chassis=10,id=pci.10,bus=pcie.0,addr=0x3 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/images/debian10.raw","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{&quo
Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
On Sat, Aug 28, 2021 at 02:53:01PM +0300, Michael Tokarev wrote: > On 27.08.2021 23:25, dann frazier wrote: > > Package: qemu-system-x86 > > Version: 1:6.1+dfsg-1 > > Severity: normal > > > > > > A VM that I created with either virt-manager or virtinst sometime ago now > > crashes when I attempt to start it under QEMU 6.1. > > Lovely. > > I can only guess this is due to libvirt's qemu-guest-agent socket, this one: > > > -chardev socket,id=charchannel0,fd=43,server=on,wait=off \ > > -device > > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 > > \ > > Dann, can you please disable the socket/qga to verify? > If this is the case this is an impotant issue at least, > it should definitely be fixed. Thanks for the response Michael. Unfortunately, I'm not able to reproduce at the moment. After filing this bug, I looked through git logs and, on a hunch, decided to try w/ the following patch reverted: 4cfd970ec1 util: fix abstract socket path copy That seemed to make the issue go away. Today I restored the archive versions of the QEMU packages, and the issue no longer reproduces. So now I have to question whether or not that revert was significant or purely correlation :( -dann
Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
Package: qemu-system-x86
Version: 1:6.1+dfsg-1
Severity: normal
A VM that I created with either virt-manager or virtinst sometime ago now
crashes when I attempt to start it under QEMU 6.1.
2021-08-27 20:12:17.236+: starting up libvirt version: 7.6.0, package: 1
(Andrea Bolognani Thu, 19 Aug 2021 21:16:21 +0200), qemu
version: 6.1.0Debian 1:6.1+dfsg-1, kernel: 5.13.0-trunk-amd64, hostname:
xps13.dannf
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \
HOME=/var/lib/libvirt/qemu/domain-6-debian10 \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-6-debian10/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-6-debian10/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-6-debian10/.config \
/usr/bin/qemu-system-x86_64 \
-name guest=debian10,debug-threads=on \
-S \
-object
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-6-debian10/master-key.aes"}'
\
-machine
pc-q35-5.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram
\
-cpu
Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hle=off,rtm=off
\
-m 1024 \
-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":1073741824}' \
-overcommit mem-lock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid b1d79aa3-8f43-4f46-b7a4-8332543f320b \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=39,server=on,wait=off \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot menu=on,strict=on \
-device
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
\
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \
-device pcie-pci-bridge,id=pci.9,bus=pci.8,addr=0x0 \
-device pcie-root-port,port=0x18,chassis=10,id=pci.10,bus=pcie.0,addr=0x3 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/images/debian10.raw","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-3-format","read-only":false,"driver":"raw","file":"libvirt-3-storage"}'
\
-device
virtio-blk-pci,bus=pci.4,addr=0x0,drive=libvirt-3-format,id=virtio-disk0,bootindex=1
\
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/images/debian10-seed.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-2-format","read-only":false,"driver":"raw","file":"libvirt-2-storage"}'
\
-device
virtio-blk-pci,bus=pci.7,addr=0x0,drive=libvirt-2-format,id=virtio-disk1 \
-device ide-cd,bus=ide.0,id=sata0-0-0 \
-netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=42 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:XX:XX:XX:XX,bus=pci.1,addr=0x0
\
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=43,server=on,wait=off \
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
\
-device usb-tablet,id=input0,bus=usb.0,port=1 \
-audiodev id=audio1,driver=spice \
-vnc 127.0.0.1:0,audiodev=audio1 \
-spice port=5901,addr=127.0.0.1,disable-ticketing=on,seamless-migration=on \
-device
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1
\
-device virtio-gpu-pci,id=video1,max_outputs=1,bus=pci.10,addr=0x0 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 \
-chardev spicevmc,id=charredir1,name=usbredir \
-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \
-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \
-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 \
-sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
char device redirected to /dev/pts/27 (label charserial0)
qemu-system-x86_64: ../../util/qemu-sockets.c:1348:
socket_sockaddr_to_address_unix: Assertion `salen >=
Bug#992518: bullseye-pu: package edk2/2020.11-2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Fixes a security issue, CVE-2019-11098.
[ Impact ]
The builds we provide shouldn't be impacted by this vulnerability,
at least not as described by the researchers. However, there maybe
other implications - this is purely cautionary.
[ Tests ]
The built-in autopkgtests (actually the newer ones from unstable that are
more complete than the ones in bullseye).
$ ./debian/tests/shell.py
test_aavmf (__main__.BootToShellTest) ... ok
test_aavmf32 (__main__.BootToShellTest) ... ok
test_ovmf32_4m_secboot (__main__.BootToShellTest) ... ok
test_ovmf_4m (__main__.BootToShellTest) ... ok
test_ovmf_4m_ms (__main__.BootToShellTest) ... ok
test_ovmf_4m_secboot (__main__.BootToShellTest) ... ok
test_ovmf_ms (__main__.BootToShellTest) ... ok
test_ovmf_pc (__main__.BootToShellTest) ... ok
test_ovmf_q35 (__main__.BootToShellTest) ... ok
test_ovmf_secboot (__main__.BootToShellTest) ... ok
--
Ran 10 tests in 53.821s
OK
[ Risks ]
The most likely issue is that we introduce a regression that causes
some VMs to fail to boot.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
A cherry pick from upstream that avoids reading GDT from flash.
diff -Nru edk2-2020.11/debian/changelog edk2-2020.11/debian/changelog
--- edk2-2020.11/debian/changelog 2020-12-15 11:42:37.0 -0700
+++ edk2-2020.11/debian/changelog 2021-08-18 16:57:56.0 -0600
@@ -1,3 +1,9 @@
+edk2 (2020.11-2+deb11u1) bullseye; urgency=medium
+
+ * Address Boot Guard TOCTOU vulnerability (CVE-2019-11098) (Closes: #991495)
+
+ -- dann frazier Wed, 18 Aug 2021 16:57:56 -0600
+
edk2 (2020.11-2) unstable; urgency=medium
* autopkgtest: Add allow-stderr to Restrictions to fix failure.
diff -Nru edk2-2020.11/debian/patches/series edk2-2020.11/debian/patches/series
--- edk2-2020.11/debian/patches/series 2020-12-15 11:42:37.0 -0700
+++ edk2-2020.11/debian/patches/series 2021-08-18 16:57:56.0 -0600
@@ -3,3 +3,4 @@
ovmf-vars-generator-Pass-OEM-Strings-to-the-guest.patch
ovmf-vars-generator-ignore-qemu-warnings.patch
ovmf-vars-generator-no-defaults.patch
+UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
diff -Nru
edk2-2020.11/debian/patches/UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
edk2-2020.11/debian/patches/UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
---
edk2-2020.11/debian/patches/UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
1969-12-31 17:00:00.0 -0700
+++
edk2-2020.11/debian/patches/UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
2021-08-18 16:57:56.0 -0600
@@ -0,0 +1,189 @@
+From f6ec1dd34fb6b9757b5ead465ee2ea20c182b0ac Mon Sep 17 00:00:00 2001
+From: Guomin Jiang
+Date: Wed, 13 Jan 2021 18:08:09 +0800
+Subject: [PATCH] UefiCpuPkg: Move MigrateGdt from DiscoverMemory to
+ TempRamDone. (CVE-2019-11098)
+
+REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1614
+REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3160
+
+The GDT still in flash with commit 60b12e69fb1c8c7180fdda92f008248b9ec83db1
+after TempRamDone
+
+So move the action to TempRamDone event to avoid reading GDT from flash.
+
+Signed-off-by: Guomin Jiang
+Cc: Eric Dong
+Cc: Ray Ni
+Cc: Laszlo Ersek
+Cc: Rahul Kumar
+Cc: Debkumar De
+Cc: Harry Han
+Cc: Catharine West
+Reviewed-by: Ray Ni
+
+Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1614
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991495
+Origin: upstream,
https://github.com/tianocore/edk2/commit/f6ec1dd34fb6b9757b5ead465ee2ea20c182b0ac
+Last-Updated: 2021-07-26
+
+diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
+index 40729a09b9..3c1bad6470 100644
+--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
+@@ -429,43 +429,6 @@ GetGdtr (
+ AsmReadGdtr ((IA32_DESCRIPTOR *)Buffer);
+ }
+
+-/**
+- Migrates the Global Descriptor Table (GDT) to permanent memory.
+-
+- @retval EFI_SUCCESS The GDT was migrated successfully.
+- @retval EFI_OUT_OF_RESOURCES The GDT could not be migrated due to lack
of available memory.
+-
+-**/
+-EFI_STATUS
+-MigrateGdt (
+- VOID
+- )
+-{
+- EFI_STATUS Status;
+- UINTN GdtBufferSize;
+- IA32_DESCRIPTOR Gdtr;
+- VOID*GdtBuffer;
+-
+- AsmReadGdtr ((IA32_DESCRIPTOR *) );
+- GdtBufferSize = sizeof (IA32_SEGMENT_DESCRIPTOR) -1 + Gdtr.Limit + 1;
+-
+- Status = PeiServicesAllocatePool (
+- GdtBufferSize,
+-
+- );
+- ASSERT (GdtBuffer != NULL);
+- if (EFI_ERROR (Status)) {
+-return EFI_OUT_OF_RESOURCES
Bug#992100: FTBFS with gcc-11
Source: edk2 Severity: normal Once the default gcc becomes gcc-11, edk2 will begin to FTBFS: "arm-linux-gnueabihf-gcc" -MMD -MF /<>/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/Arm/ashldi3.obj.deps -mthumb -march=armv7-a -E -x assembler-with-cpp -include AutoGen.h -DOPENSBI_EXTERNAL_SBI_TYPES=OpensbiTypes.h -I/<>/ArmPkg/Library/CompilerIntrinsicsLib/Arm -I/<>/ArmPkg/Library/CompilerIntrinsicsLib -I/<>/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/DEBUG -I/<>/MdePkg -I/<>/MdePkg/Include -I/<>/MdePkg/Test/UnitTest/Include -I/<>/MdePkg/Include/Arm -I/<>/ArmPkg -I/<>/ArmPkg/Include /<>/ArmPkg/Library/CompilerIntrinsicsLib/Arm/ashldi3.S > /<>/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/Arm/ashldi3.ii cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU I'm guessing - but haven't tested - that this is fallout from the following change in gcc-11: gcc-11 (11.1.0-2) experimental; urgency=medium [...] * For armhf configure --with-arch=+fp, dropping the --with-fpu= option. [...] -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#991415: unblock: kdump-tools/1:1.6.8.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package kdump-tools [ Reason ] Addresses two bugs: [ Benjamin Drung ] * Fix broken status log messages when dumping w/ FTP (Closes: #991412). [ dann frazier ] * Add /var/lib/kdump to debian/kdump-tools.dirs to avoid errors creating the initial set of boot file symlinks (Closes: #991175). [ Impact ] The first can have a significant impact to users who are trying to setup FTP dumps because the output suggests the package is misconfigured even when it isn't. The second can cause a first boot service startup failure because the boot file symlinking process assumes /var/lib/kdump already exists. [ Tests ] I did a manual FTP dump test to verify the correct messages, as well as upgrade/remove/purge tests. [ Risks ] I consider both bug fixes to be trivial. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock kdump-tools/1:1.6.8.4
Bug#991413: dump_dmesg: Can't find some symbols for log_buf
Package: makedumpfile Version: 1:1.6.8-4 Severity: important makedumpfile in buster does not support extraction of dmesg from buster's kernel: [7.032459] kdump-tools[517]: The dumpfile is saved to STDOUT. [7.034898] kdump-tools[517]: makedumpfile Completed. [7.054470] kdump-tools[498]: kdump-tools: saved vmcore via FTP in 192.168.12 2.57:/files/192.168.122.80-dump.202107221551. [7.065609] kdump-tools[498]: running makedumpfile --dump-dmesg /proc/vmcore /tmp/dmesg.ftp.202107221551. [7.072299] kdump-tools[522]: dump_dmesg: Can't find some symbols for log_buf . [7.075787] kdump-tools[522]: The kernel version is not supported. [7.079931] kdump-tools[522]: The makedumpfile operation may be incomplete. [7.084831] kdump-tools[522]: makedumpfile Failed. [7.089567] kdump-tools[498]: kdump-tools: makedumpfile --dump-dmesg failed. dmesg content will be unavailable ... [7.096158] kdump-tools[523]: failed! [7.099504] kdump-tools[498]: kdump-tools: failed to save dmesg content via F TP in 192.168.122.57:/files/192.168.122.80-dmesg.202107221551 ... [7.108765] kdump-tools[525]: failed! [7.112192] kdump-tools[527]: Thu, 22 Jul 2021 15:51:17 -0600 -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages makedumpfile depends on: ii libc6 2.31-13 ii libdw1 0.183-3 ii libelf10.183-3 ii liblzo2-2 2.10-2 ii perl 5.32.1-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages makedumpfile recommends: ii crash7.2.9-2 ii kexec-tools 1:2.0.22-2 makedumpfile suggests no packages. -- no debconf information
Bug#991412: FTP status messages show wrong remote info
Package: kdump-tools Version: 1:1.6.8.3 Severity: important X-Debbugs-Cc: Benjamin Drung Due to use of the wrong variable names, dumps to an FTP server log incorrect messages. For example: [7.598933] kdump-tools[498]: kdump-tools: saved vmcore via FTP in :. when it should be: [7.196923] kdump-tools[498]: kdump-tools: saved vmcore via FTP in 192.168.12 2.57:/files/192.168.122.80-dump.202107221510. This could lead users to believe their system is misconfigured, leading them down the wrong debug path when trying to enable kdump via FTP. -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kdump-tools depends on: ii bsdextrautils 2.36.1-7 ii bsdmainutils 12.1.7+nmu3 ii busybox-static [busybox] 1:1.30.1-6+b2 ii debconf [debconf-2.0] 1.5.77 ii file 1:5.39-3 ii init-system-helpers 1.60 ii kexec-tools 1:2.0.22-2 ii linux-base4.6 ii lsb-base 11.1.0 ii makedumpfile 1:1.6.8-4 ii ucf 3.0043 Versions of packages kdump-tools recommends: ii initramfs-tools-core 0.140 kdump-tools suggests no packages.
Bug#988647: crash: please update to new upstream release
On Wed, Jul 7, 2021 at 12:17 PM Guilherme Piccoli wrote: > > Hi Troy, I'd like to enforce that request! We want to upgrade crash > version on next Ubuntu release, and the correct process would be to > match Debian's Sid version. > Thanks in advance, Hi Guillherme! Just a heads-up that Debian is currently in freeze (see https://release.debian.org/), so new upstream releases are unlikely to appear in sid until after bullseye releases. Of course, we could bribe Troy for an upload to experimental :) Let us know if we can help at all. -dann
Bug#990547: libsystemd-shared broken in Multi-Arch
Source: systemd Version: 247.3-5 I noticed that systemd-machined was failing to start on an arm64 box. This box had armhf enabled, and turns out systemd had been cross-graded over to systemd:armhf[*]. It still had systemd-container:arm64 installed, so now I had an arm64 /lib/systemd/systemd-machine, but an armhf /lib/systemd/libsystemd-shared-244.so. libsystemd-shared-244.so is from the systemd package. Since systemd is marked Multi-Arch: foreign, systemd:armhf was able to incorrectly satisfy systemd-container:arm64's dependency on systemd. [*] kudos to Multi-Arch that I simply hadn't noticed
Bug#990464: Kdump is unable to use NVME
tag 990464 + moreinfo thanks On Tue, Jun 29, 2021 at 06:25:48PM -0500, Kody Barks wrote: > Package: kdump-tools > Version: 1:1.6.5-1 > > When the kernel panics, it loads the kdump kernel correctly but this kernel > is unable to use NVME, making it unable to mount the root filesystem and > thus making the kdump kernel panic. > I am unable to generate a proper log of this error. The best I could do is > to take a picture of my screen when this happens. This is the attached > file. > I have tried using the boot parameter: "nvme_core.default_ps_max_latency_us=0" > but this made no changes in behavior. > I am using Debian 10 Buster with Linux 5.10.40 with libc6 2.28-10 > My motherboard is the ASUS PRIME x399-a . > The SSD I'm trying to use as the root filesystem is the Intel Corporation > Optane SSD 900P Series [8086:2700]. > It should be noted that outside of kdump, during normal operation, the > device works flawlessly. Only Kdump's kernel has an issue. hey Kody, It's likely that your crashkernel= parameter just doesn't provide enough memory for the crashkernel to initialize all of your devices. This is set in /etc/default/grub.d/kdump-tools.cfg. Try bumping that up to see if it fixes things. Note that after changing it you'll need to 1) sudo update-grub and 2) reboot before it will take effect for the next crash dump. It's unfortunately not possible to provide a static default crashkernel= that works for everyone, so tuning it is often required. -dann
Bug#989840: patch
tags 989840 + patch
thx
diff -Nru nvme-cli-1.12/debian/changelog nvme-cli-1.12/debian/changelog
--- nvme-cli-1.12/debian/changelog 2020-09-22 19:37:51.0 +
+++ nvme-cli-1.12/debian/changelog 2021-06-14 17:50:30.0 +
@@ -1,3 +1,10 @@
+nvme-cli (1.12-5+deb11u1) UNRELEASED; urgency=medium
+
+ * Fix issue where 'showregs' can cause certain Samsung devices
+to go offline. (Closes: #989840)
+
+ -- dann frazier Mon, 14 Jun 2021 11:50:30 -0600
+
nvme-cli (1.12-5) unstable; urgency=medium
* Add uuid-runtime as dependency. (Closes: #970637)
diff -Nru
nvme-cli-1.12/debian/patches/Prevent-compiler-from-optimizing-mmio_read64-to-sing.patch
nvme-cli-1.12/debian/patches/Prevent-compiler-from-optimizing-mmio_read64-to-sing.patch
---
nvme-cli-1.12/debian/patches/Prevent-compiler-from-optimizing-mmio_read64-to-sing.patch
1970-01-01 00:00:00.0 +
+++
nvme-cli-1.12/debian/patches/Prevent-compiler-from-optimizing-mmio_read64-to-sing.patch
2021-06-14 16:51:31.0 +
@@ -0,0 +1,34 @@
+From 33e60ff64a043b189d2661543b417b21b6f3667b Mon Sep 17 00:00:00 2001
+From: Adam Judge
+Date: Tue, 9 Jun 2020 15:58:49 -0400
+Subject: [PATCH] Prevent compiler from optimizing mmio_read64 to single 64b
+ read
+
+Bug-Debian: https://bugs.debian.org/989840
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1931886
+Origin:
https://github.com/linux-nvme/nvme-cli/commit/33e60ff64a043b189d2661543b417b21b6f3667b
+Last-Updated: 2021-06-14
+
+diff --git a/nvme-print.c b/nvme-print.c
+index fc8f99d..c0de928 100644
+--- a/nvme-print.c
b/nvme-print.c
+@@ -1311,9 +1311,13 @@ static inline uint32_t mmio_read32(void *addr)
+ /* Access 64-bit registers as 2 32-bit; Some devices fail 64-bit MMIO. */
+ static inline __u64 mmio_read64(void *addr)
+ {
+- __le32 *p = addr;
++ const volatile __u32 *p = addr;
++ __u32 low, high;
++
++ low = le32_to_cpu(*p);
++ high = le32_to_cpu(*(p + 1));
+
+- return le32_to_cpu(*p) | ((uint64_t)le32_to_cpu(*(p + 1)) << 32);
++ return ((__u64) high << 32) | low;
+ }
+
+ static void json_ctrl_registers(void *bar)
+--
+2.32.0
+
diff -Nru
nvme-cli-1.12/debian/patches/nvme-print-split-pmrmsc-into-pmrmscl-and-pmrmscu.patch
nvme-cli-1.12/debian/patches/nvme-print-split-pmrmsc-into-pmrmscl-and-pmrmscu.patch
---
nvme-cli-1.12/debian/patches/nvme-print-split-pmrmsc-into-pmrmscl-and-pmrmscu.patch
1970-01-01 00:00:00.0 +
+++
nvme-cli-1.12/debian/patches/nvme-print-split-pmrmsc-into-pmrmscl-and-pmrmscu.patch
2021-06-14 16:52:09.0 +
@@ -0,0 +1,139 @@
+From d43d545a68cc6cea5ac78fda4edeedf3b5198847 Mon Sep 17 00:00:00 2001
+From: Gollu Appalanaidu
+Date: Sat, 27 Feb 2021 01:23:44 +0530
+Subject: [PATCH] nvme-print: split pmrmsc into pmrmscl and pmrmscu
+
+Split the PMR Memory Space Control register 64 bits into
+PMR Memory Space Control Lower and Upper 32 bits each as
+per NVM Express Spec. 1.4b changes.
+
+Signed-off-by: Gollu Appalanaidu
+[dannf: Backported to 1.12]
+
+Bug-Debian: https://bugs.debian.org/989840
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1931886
+Origin:
https://github.com/linux-nvme/nvme-cli/commit/d43d545a68cc6cea5ac78fda4edeedf3b5198847
+Last-Updated: 2021-06-14
+
+Index: nvme-cli-1.12/linux/nvme.h
+===
+--- nvme-cli-1.12.orig/linux/nvme.h
nvme-cli-1.12/linux/nvme.h
+@@ -172,7 +172,8 @@ enum {
+ NVME_REG_PMRSTS = 0x0e08, /* Persistent Memory Region Status */
+ NVME_REG_PMREBS = 0x0e0c, /* Persistent Memory Region Elasticity
Buffer Size */
+ NVME_REG_PMRSWTP= 0x0e10, /* Persistent Memory Region Sustained
Write Throughput */
+- NVME_REG_PMRMSC = 0x0e14, /* Persistent Memory Region Controller
Memory Space Control */
++ NVME_REG_PMRMSCL= 0x0e14, /* Persistent Memory Region Controller
Memory Space Control Lower */
++ NVME_REG_PMRMSCU= 0x0e18, /* Persistent Memory Region Controller
Memory Space Control Upper*/
+ NVME_REG_DBS= 0x1000, /* SQ 0 Tail Doorbell */
+ };
+
+Index: nvme-cli-1.12/nvme-print.c
+===
+--- nvme-cli-1.12.orig/nvme-print.c
nvme-cli-1.12/nvme-print.c
+@@ -1293,12 +1293,18 @@ static void nvme_show_registers_pmrswtp(
+ nvme_register_pmr_pmrszu_to_string(pmrswtp & 0x000f));
+ }
+
+-static void nvme_show_registers_pmrmsc(uint64_t pmrmsc)
++static void nvme_show_registers_pmrmscl(uint32_t pmrmscl)
+ {
+- printf("\tController Base Address (CBA) : %" PRIx64 "\n",
+- (pmrmsc & 0xf000) >> 12);
+- printf("\tController Memory Space Enable (CMSE) : %" PRIx64 "\n\n",
+- (pmrmsc & 0x0002) >> 1);
++ printf("\tController Base Address (CBA): %#x\n",
++ (pmrmsc
Bug#989840: show-regs can cause some samsung controllers to go offline
Package: nvme-cli Version: 1.12-5 Severity: important Tags: upstream fixed-upstream nvme show-regs has been found to cause certain Samsung controllers (MZ1L21T9HCLS in particular) to go offline: [963314.311332] nvme nvme2: controller is down; will reset: CSTS=0x3, PCI_STATUS=0x10 [963334.951328] nvme nvme2: Device not ready; aborting reset [963334.963114] nvme nvme2: Removing after probe failure status: -19 [963334.999600] blk_update_request: I/O error, dev nvme2n1, sector 1050640 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 [963335.023410] md: super_written gets error=10 [963335.033842] md/raid1:md0: Disk failure on nvme2n1p2, disabling device. md/raid1:md0: Operation continuing on 1 devices. [ +0.009599] XFS (md127): log I/O error -5 [ +0.015136] XFS (md127): xfs_do_force_shutdown(0x2) called from line 1250 of file fs/xfs/xfs_log.c. Return address = d0ea8129 [ +0.01] XFS (md127): Log I/O Error Detected. Shutting down filesystem [ +0.009290] XFS (md127): Please unmount the filesystem and rectify the problem(s) This has been fixed upstream with the following commits: https://github.com/linux-nvme/nvme-cli/commit/33e60ff64a043b189d2661543b417b21b6f3667b https://github.com/linux-nvme/nvme-cli/commit/d43d545a68cc6cea5ac78fda4edeedf3b5198847 -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nvme-cli depends on: ii libc6 2.31-12 ii libuuid1 2.36.1-7 ii uuid-runtime 2.36.1-7 nvme-cli recommends no packages. nvme-cli suggests no packages. -- no debconf information
Bug#989716: kdump-tools: kdump produces useless "dumps" on i386
On Fri, Jun 11, 2021 at 1:57 AM Rich Ercolani wrote: > > Package: kdump-tools > Version: 1:1.6.5-1 > Severity: important > > Dear Maintainer, > > Installed kdump-tools appear to work, echo 'c' | sudo tee /proc/sysrq-trigger > boots the crashkernel and > takes a dump and reboots, but attempting to use "crash" on the dump in a way > that works > in other configurations (e.g. crash /usr/lib/debug/boot/vmlinux-1234 > /var/crash/1234/dump.1234) reports > (in this example, on buster, with -d1): > > crash: page excluded: kernel virtual address: c19546a4 type: "possible" > WARNING: cannot read cpu_possible_map > crash: page excluded: kernel virtual address: c195469c type: "present" > WARNING: cannot read cpu_present_map > crash: page excluded: kernel virtual address: c19546a0 type: "online" > WARNING: cannot read cpu_online_map > crash: page excluded: kernel virtual address: c1954698 type: "active" > WARNING: cannot read cpu_active_map > crash: page excluded: kernel virtual address: c18c769c type: "pv_init_ops" > crash: page excluded: kernel virtual address: c1a92268 type: > "shadow_timekeeper xtime_sec" > xtime timespec.tv_sec: 9aee2b: Tue Apr 28 08:25:15 1970 > crash: page excluded: kernel virtual address: c18bb1c4 type: "init_uts_ns" > utsname: > sysname: > nodename: > release: > version: > machine: > domainname: > base kernel version: 0.0.0 > crash: page excluded: kernel virtual address: c16a9160 type: "accessible > check" > crash: /usr/lib/debug/vmlinux-4.19.0-16-686-pae and > /var/crash/202106110101/dump.202106110101 do not match! > > And: > # ls -al /var/crash/202106110101/dump.202106110101;file > /var/crash/202106110101/dump.202106110101; > -rw--- 1 root root 21422351 Jun 11 01:01 > /var/crash/202106110101/dump.202106110101 > /var/crash/202106110101/dump.202106110101: Kdump compressed dump v6, system > Linux, node debian32, release 4.19.0-16-686-pae, version #1 SMP Debian > 4.19.181-1 (2021-03-19), machine i686, domain (none) > > crashkernel=512M-:192M, on here, changes the behavior to what #989714 > describes on x86_64 - > no printouts from a crashkernel or anything else, no dump ever saved, just an > indefinite hang. > crashkernel=384M-:192M (or 256M) does not hang, but produces an equally > useless "dump". > > According to the console output when this happens, "makedumpfile Completed" > both times, and > dmesg's output appears intact and complete. > > (I neglected to mention this in #989714, but these are all on > VirtualBox-backed VMs.) > > Please let me know if there's anything further I can do to help debug this. So it sounds like you were able to get a successful dump after adjusting crashkernel, is that correct? And the issue is that crash doesn't deal with it? Wouldn't that be a bug in the crash tool then? -dann
Bug#989580: updated patch
Both patches are now upstream. Here's an updated debdiff. diff -Nru manpages-5.10/debian/changelog manpages-5.10/debian/changelog --- manpages-5.10/debian/changelog 2020-12-22 06:25:08.0 -0700 +++ manpages-5.10/debian/changelog 2021-06-10 13:13:28.0 -0600 @@ -1,3 +1,10 @@ +manpages (5.10-2) UNRELEASED; urgency=medium + + * kernel_lockdown.7: Remove description of unsupported lockdown lift +mechanism via SysRq. (Closes: #989580) (LP: #1931171) + + -- dann frazier Thu, 10 Jun 2021 13:13:28 -0600 + manpages (5.10-1) unstable; urgency=medium * New upstream version 5.10 diff -Nru manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch --- manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch 1969-12-31 17:00:00.0 -0700 +++ manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch 2021-06-10 13:07:18.0 -0600 @@ -0,0 +1,47 @@ +From a989674d441617fe8fb9570dfb395867ff42 Mon Sep 17 00:00:00 2001 +From: dann frazier +Date: Thu, 27 May 2021 09:13:42 +0200 +Subject: [PATCH 1/2] kernel_lockdown.7: Remove description of lifting via + SysRq (not upstream) + +The patch that implemented lockdown lifting via SysRq ended up +getting dropped[*] before the feature was merged upstream. Having +the feature documented but unsupported has caused some confusion +for our users. + +[*] http://archive.lwn.net:8080/linux-kernel/cacdnjuuxam06tcnczoa6nwxhnmqueqqm3ma8btukzpucs+d...@mail.gmail.com/ + +Signed-off-by: dann frazier +Cc: Heinrich Schuchardt +Cc: David Howells +Cc: Pedro Principeza +Cc: Randy Dunlap +Cc: Kyle McMartin +Cc: Matthew Garrett +Signed-off-by: Alejandro Colomar +Signed-off-by: Michael Kerrisk + +Bug-Debian: https://bugs.debian.org/989580 +Bug-Ubuntu: https://bugs.launchpad.net/bugs/1931171 +Origin: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=a989674d441617fe8fb9570dfb395867ff42 +Last-Update: 2021-06-10 + +diff --git a/man7/kernel_lockdown.7 b/man7/kernel_lockdown.7 +index 30863de62..b0442b3b6 100644 +--- a/man7/kernel_lockdown.7 b/man7/kernel_lockdown.7 +@@ -33,11 +33,6 @@ where X indicates the process name and Y indicates what is restricted. + .PP + On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled + if the system boots in EFI Secure Boot mode. +-.PP +-If the kernel is appropriately configured, lockdown may be lifted by typing +-the appropriate sequence on a directly attached physical keyboard. +-For x86 machines, this is +-.IR SysRq+x . + .\" + .SS Coverage + When lockdown is in effect, a number of features are disabled or have their +-- +2.32.0 + diff -Nru manpages-5.10/debian/patches/0015-kernel_lockdown.7.patch manpages-5.10/debian/patches/0015-kernel_lockdown.7.patch --- manpages-5.10/debian/patches/0015-kernel_lockdown.7.patch 1969-12-31 17:00:00.0 -0700 +++ manpages-5.10/debian/patches/0015-kernel_lockdown.7.patch 2021-06-10 13:09:09.0 -0600 @@ -0,0 +1,35 @@ +From 9d39058523043353681a8daa0c59531118ddf06f Mon Sep 17 00:00:00 2001 +From: dann frazier +Date: Mon, 7 Jun 2021 16:19:43 -0600 +Subject: [PATCH 2/2] kernel_lockdown.7: Remove additional text alluding to + lifting via SysRq + +My previous patch intended to drop the docs for the lockdown lift +SysRq, but it missed this other section that refers to lifting it +via a keyboard - an allusion to that same SysRq. + +Signed-off-by: dann frazier +Signed-off-by: Michael Kerrisk + +Bug-Debian: https://bugs.debian.org/989580 +Bug-Ubuntu: https://bugs.launchpad.net/bugs/1931171 +Origin: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=9d39058523043353681a8daa0c59531118ddf06f +Last-Update: 2021-06-10 + +diff --git a/man7/kernel_lockdown.7 b/man7/kernel_lockdown.7 +index b0442b3b6..0c0a9500d 100644 +--- a/man7/kernel_lockdown.7 b/man7/kernel_lockdown.7 +@@ -19,9 +19,6 @@ modification of the kernel image and to prevent access to security and + cryptographic data located in kernel memory, whilst still permitting driver + modules to be loaded. + .PP +-Lockdown is typically enabled during boot and may be terminated, if configured, +-by typing a special key combination on a directly attached physical keyboard. +-.PP + If a prohibited or restricted feature is accessed or used, the kernel will emit + a message that looks like: + .PP +-- +2.32.0 + diff -Nru manpages-5.10/debian/patches/series manpages-5.10/debian/patches/series --- manpages-5.10/debian/patches/series 2020-12-22 06:18:53.0 -0700 +++ manpages-5.10/debian/patches/series 2021-06-10 13:05:50.0 -0600 @@ -10,3 +10,5 @@ 0010-tzfile.5.patch 0011-man.7.patch 0013-rtnetlink.7.patch +0014-kernel_lockdown.7.patch +0015-kernel_lockdown.7.patch
Bug#989580: 2nd patch
Upon proof-reading, I realized I missed another reference: https://lore.kernel.org/linux-man/20210607221943.78414-1-dann.fraz...@canonical.com/T/#u
Bug#989580: patch
Attached. diff -Nru manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch --- manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch 1969-12-31 17:00:00.0 -0700 +++ manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch 2021-06-07 15:55:43.0 -0600 @@ -0,0 +1,45 @@ +From 09df87e9ee3e1a429a2c1709dfd16ec8ff0f6160 Mon Sep 17 00:00:00 2001 +From: dann frazier +Date: Wed, 26 May 2021 11:34:55 -0600 +Subject: [PATCH] kernel_lockdown.7: Remove description of lifting via SysRq + (not upstream) + +The patch that implemented lockdown lifting via SysRq ended up getting +dropped[*] before the feature was merged upstream. Having the feature +documented but unsupported has caused some confusion for our users. + +[*] http://archive.lwn.net:8080/linux-kernel/cacdnjuuxam06tcnczoa6nwxhnmqueqqm3ma8btukzpucs+d...@mail.gmail.com/ + +Signed-off-by: dann frazier +Cc: Heinrich Schuchardt +Cc: David Howells +Cc: Pedro Principeza +Cc: Randy Dunlap +Cc: Kyle McMartin +Cc: Matthew Garrett +Signed-off-by: Alejandro Colomar + +Bug-Debian: https://bugs.debian.org/989580 +Bug-Ubuntu: https://bugs.launchpad.net/bugs/1931171 +Origin: https://github.com/alejandro-colomar/man-pages/commit/09df87e9ee3e1a429a2c1709dfd16ec8ff0f616 +Last-Update: 2021-06-07 + +diff --git a/man7/kernel_lockdown.7 b/man7/kernel_lockdown.7 +index 30863de62..b0442b3b6 100644 +--- a/man7/kernel_lockdown.7 b/man7/kernel_lockdown.7 +@@ -33,11 +33,6 @@ where X indicates the process name and Y indicates what is restricted. + .PP + On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled + if the system boots in EFI Secure Boot mode. +-.PP +-If the kernel is appropriately configured, lockdown may be lifted by typing +-the appropriate sequence on a directly attached physical keyboard. +-For x86 machines, this is +-.IR SysRq+x . + .\" + .SS Coverage + When lockdown is in effect, a number of features are disabled or have their +-- +2.32.0 + diff -Nru manpages-5.10/debian/patches/series manpages-5.10/debian/patches/series --- manpages-5.10/debian/patches/series 2020-12-22 06:18:53.0 -0700 +++ manpages-5.10/debian/patches/series 2021-06-07 15:34:58.0 -0600 @@ -10,3 +10,4 @@ 0010-tzfile.5.patch 0011-man.7.patch 0013-rtnetlink.7.patch +0014-kernel_lockdown.7.patch
Bug#989580: kernel_lockdown(7) describes removed SysRq for lifting lockdown
Package: manpages Version: 5.10-1 Severity: normal Tags: upstream patch The patch that implemented lockdown lifting via SysRq ended up getting dropped[*] before the feature was merged upstream, but the man page still describes it. I've submitted a patch upstream which has been accepted by a comaintainer: https://github.com/alejandro-colomar/man-pages/commit/09df87e9ee3e1a429a2c1709dfd16ec8ff0f616 IMHO, it would be good to see if we can include this in bullseye since Secure Boot/lockdown is becoming more widely used. [*] http://archive.lwn.net:8080/linux-kernel/cacdnjuuxam06tcnczoa6nwxhnmqueqqm3ma8btukzpucs+d...@mail.gmail.com/ -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled manpages depends on no packages. manpages recommends no packages. Versions of packages manpages suggests: ii man-db [man-browser] 2.9.4-2 -- no debconf information
Bug#987851: linux-version sort: argv and stdin behaviors differ
Package: linux-base
Version: 4.6
Severity: normal
Tags: patch
Using argv:
$ linux-version sort 5.8.0-50-generic 5.8.0-50-generic-64k
5.8.0-50-generic
5.8.0-50-generic-64k
Using stdin:
$ cat versions.txt
5.8.0-50-generic
5.8.0-50-generic-64k
$ cat versions.txt | linux-version sort
5.8.0-50-generic-64k
5.8.0-50-generic
It seems the trailing "\n" is unexpectedly being used in the comparison.
Now, perl and I have never really gotten along, but this patch seems to work:
--- /usr/bin/linux-version.orig 2020-06-25 17:23:24.0 +
+++ /usr/bin/linux-version 2021-04-30 20:39:13.708560573 +
@@ -70,7 +70,7 @@
@versions = map({[$_, "\n"]} @_);
} else {
while () {
- /^([^ ]*)(.*\n?)$/ or die;
+ /^([^ \n]*)(.*\n?)$/ or die;
push @versions, [$1, $2];
}
}
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-base depends on:
ii debconf [debconf-2.0] 1.5.76
linux-base recommends no packages.
linux-base suggests no packages.
-- debconf information:
* linux-base/removing-running-kernel: true
linux-base/removing-title:
Bug#986706: unblock: makedumpfile/1:1.6.8-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package makedumpfile
[ Reason ]
Adds necessary fixes for supporting current kernels.
[ Impact ]
makedumpfile will be unable to extract the dmesg from the 5.10 kernel,
and does not support 5.4 and newer kernels on arm64.
[ Tests ]
Forcing a crash dump in an x86 VM and verifying that the dmesg file
is produced and the crash utility is able to analyze the dump.
[ Risks ]
The biggest risk I can think of is that we may have broken support with
some earlier kernel version. But things do work with the kernel version
we're currently planning to release.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
N/A
unblock makedumpfile/1:1.6.8-4
diff -Nru makedumpfile-1.6.8/debian/changelog
makedumpfile-1.6.8/debian/changelog
--- makedumpfile-1.6.8/debian/changelog 2021-01-18 07:50:02.0 -0700
+++ makedumpfile-1.6.8/debian/changelog 2021-04-07 16:32:38.0 -0600
@@ -1,3 +1,13 @@
+makedumpfile (1:1.6.8-4) unstable; urgency=medium
+
+ [ Ioanna Alifieraki ]
+ * Fix failure of dmesg. creation on 5.10+ kernels.
+(Closes: #985896) (LP: #1921403).
+ * Fix makedumpfile failure on arm64 with 5.4 kernels.
+(Closes: #986594) (LP: #1879214)
+
+ -- dann frazier Wed, 07 Apr 2021 16:32:38 -0600
+
makedumpfile (1:1.6.8-3) unstable; urgency=medium
* Drop kdump-tools, which has been split into its own source package.
diff -Nru
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
---
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
1969-12-31 17:00:00.0 -0700
+++
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
2021-04-07 16:32:38.0 -0600
@@ -0,0 +1,587 @@
+From: John Ogness
+Date: Thu, 19 Nov 2020 02:41:21 +
+Subject: [PATCH 1/2] printk: add support for lockless ringbuffer
+
+* Required for kernel 5.10
+
+Linux 5.10 introduces a new lockless ringbuffer. The new ringbuffer
+is structured completely different to the previous iterations.
+Add support for retrieving the ringbuffer from debug information
+and/or using vmcoreinfo. The new ringbuffer is detected based on
+the availability of the "prb" symbol.
+
+Signed-off-by: John Ogness
+Signed-off-by: Kazuhito Hagio
+
+Origin: upstream,
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985896
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1921403
+---
+ Makefile | 2 +-
+ dwarf_info.c | 36 +-
+ makedumpfile.c | 103 ++--
+ makedumpfile.h | 58
+ printk.c | 207 +
+ 5 files changed, 399 insertions(+), 7 deletions(-)
+ create mode 100644 printk.c
+
+diff --git a/Makefile b/Makefile
+index b12bbb0..6f4d0e0 100644
+--- a/Makefile
b/Makefile
+@@ -45,7 +45,7 @@ CFLAGS_ARCH += -m32
+ endif
+
+ SRC_BASE = makedumpfile.c makedumpfile.h diskdump_mod.h sadump_mod.h
sadump_info.h
+-SRC_PART = print_info.c dwarf_info.c elf_info.c erase_info.c sadump_info.c
cache.c tools.c
++SRC_PART = print_info.c dwarf_info.c elf_info.c erase_info.c sadump_info.c
cache.c tools.c printk.c
+ OBJ_PART=$(patsubst %.c,%.o,$(SRC_PART))
+ SRC_ARCH = arch/arm.c arch/arm64.c arch/x86.c arch/x86_64.c arch/ia64.c
arch/ppc64.c arch/s390x.c arch/ppc.c arch/sparc64.c
+ OBJ_ARCH=$(patsubst %.c,%.o,$(SRC_ARCH))
+diff --git a/dwarf_info.c b/dwarf_info.c
+index e42a9f5..543588b 100644
+--- a/dwarf_info.c
b/dwarf_info.c
+@@ -614,6 +614,7 @@ search_structure(Dwarf_Die *die, int *found)
+ {
+ int tag;
+ const char *name;
++ Dwarf_Die die_type;
+
+ /*
+* If we get to here then we don't have any more
+@@ -622,9 +623,31 @@ search_structure(Dwarf_Die *die, int *found)
+ do {
+ tag = dwarf_tag(die);
+ name = dwarf_diename(die);
+- if ((tag != DW_TAG_structure_type) || (!name)
+- || strcmp(name, dwarf_info.struct_name))
++ if ((!name) || strcmp(name, dwarf_info.struct_name))
++ continue;
++
++ if (tag == DW_TAG_typedef) {
++ if (!get_die_type(die, _type)) {
++ ERRMSG("Can't get CU die of DW_AT_type.\n");
++ break;
++ }
++
++ /* Resolve typedefs of typedefs. */
++ while ((tag = dwarf_tag(_type)) == DW_TAG_typedef) {
++ if
Bug#985788: unblock: kdump-tools/1:1.6.8.3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package kdump-tools
[ Reason ]
It contains a single bug fix that fixes a regression which caused kdump-tools
to fail to collect kernel dump files in the common case (the files were
created, but just contained an error message).
[ Impact ]
Data loss - a kernel crash dump will fail to be collected and that
data will be gone after automated reboot.
[ Tests ]
A manual crash dump generation/validation.
[ Risks ]
The code fix is trivial.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
N/A
unblock kdump-tools/1:1.6.8.3
diff -Nru kdump-tools-1.6.8.2/debian/changelog
kdump-tools-1.6.8.3/debian/changelog
--- kdump-tools-1.6.8.2/debian/changelog2021-02-01 13:35:59.0
-0700
+++ kdump-tools-1.6.8.3/debian/changelog2021-03-22 21:39:59.0
-0600
@@ -1,3 +1,10 @@
+kdump-tools (1:1.6.8.3) unstable; urgency=medium
+
+ * kdump-config: Fix storage of local/NFS dump files
+(Closes: #985716) (LP: #1920759).
+
+ -- dann frazier Mon, 22 Mar 2021 21:39:59 -0600
+
kdump-tools (1:1.6.8.2) unstable; urgency=medium
* debian/control: Add Vcs-* tags.
diff -Nru kdump-tools-1.6.8.2/debian/kdump-config.in
kdump-tools-1.6.8.3/debian/kdump-config.in
--- kdump-tools-1.6.8.2/debian/kdump-config.in 2021-02-01 13:35:59.0
-0700
+++ kdump-tools-1.6.8.3/debian/kdump-config.in 2021-03-22 21:39:59.0
-0600
@@ -53,7 +53,10 @@
NFS_RETRANS=${NFS_RETRANS:=3}
NFS_MOUNT_RETRY=${NFS_MOUNT_RETRY:=4}
SSH_KDUMP_RETRY=${SSH_KDUMP_RETRY:=16}
-MAKEDUMP_ARGS=${MAKEDUMP_ARGS:="-c -d 31"}
+MAKEDUMP_ARGS=${MAKEDUMP_ARGS:="-F -c -d 31"}
+# Add '-F' [flatten] to MAKEDUMP_ARGS, if not there:
+[ "${MAKEDUMP_ARGS#-F*}" != "${MAKEDUMP_ARGS}" ] ||
MAKEDUMP_ARGS="${MAKEDUMP_ARGS} -F"
+
KDUMP_CMDLINE_APPEND=${KDUMP_CMDLINE_APPEND:="@KDUMP_CMDLINE_APPEND@"}
KDUMP_KERNEL_HOOK="/etc/kernel/postinst.d/kdump-tools"
[ -d $KDUMP_COREDIR ] || mkdir -p $KDUMP_COREDIR ;
@@ -777,7 +780,7 @@
mkdir -p "$KDUMP_STAMPDIR"
fi
- log_action_msg "running makedumpfile $MAKEDUMP_ARGS $vmcore_file
$KDUMP_CORETEMP"
+ log_action_msg "running makedumpfile $MAKEDUMP_ARGS $vmcore_file |
compress > $KDUMP_CORETEMP"
# shellcheck disable=SC2086
makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress > "$KDUMP_CORETEMP"
ERROR=$?
@@ -876,12 +879,9 @@
FTPPUT_ARGS="$FTPPUT_ARGS -P $FTP_PORT"
fi
- FTP_MAKEDUMP_ARGS="${MAKEDUMP_ARGS}"
- # Add '-F' [flatten] to FTP_MAKEDUMP_ARGS, if not there:
- [ "${FTP_MAKEDUMP_ARGS#-F*}" != "${FTP_MAKEDUMP_ARGS}" ] ||
FTP_MAKEDUMP_ARGS="${FTP_MAKEDUMP_ARGS} -F"
- log_action_msg "sending makedumpfile $FTP_MAKEDUMP_ARGS $vmcore_file
via FTP to $FTP_REMOTE_HOST:$FTP_COREFILE"
+ log_action_msg "sending makedumpfile $MAKEDUMP_ARGS $vmcore_file via
FTP to $FTP_REMOTE_HOST:$FTP_COREFILE"
# shellcheck disable=SC2086
- makedumpfile $FTP_MAKEDUMP_ARGS $vmcore_file | compress | busybox
ftpput $FTPPUT_ARGS "$FTP_REMOTE_HOST" "$FTP_COREFILE" -
+ makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress | busybox ftpput
$FTPPUT_ARGS "$FTP_REMOTE_HOST" "$FTP_COREFILE" -
ERROR=$?
# did we succeed?
@@ -952,12 +952,9 @@
return 1
fi
- SSH_MAKEDUMP_ARGS="${MAKEDUMP_ARGS}"
- # Add '-F' [flatten] to MAKEDUMP_ARGS, if not there:
- [ "${SSH_MAKEDUMP_ARGS#-F*}" != "${SSH_MAKEDUMP_ARGS}" ] ||
SSH_MAKEDUMP_ARGS="${SSH_MAKEDUMP_ARGS} -F"
- log_action_msg "sending makedumpfile $SSH_MAKEDUMP_ARGS $vmcore_file to
$SSH_REMOTE_HOST : $SSH_CORETEMP"
+ log_action_msg "sending makedumpfile $MAKEDUMP_ARGS $vmcore_file to
$SSH_REMOTE_HOST : $SSH_CORETEMP"
# shellcheck disable=SC2086
- makedumpfile $SSH_MAKEDUMP_ARGS $vmcore_file | compress | ssh -i
$SSH_KEY "$SSH_REMOTE_HOST" dd "of=$SSH_CORETEMP"
+ makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress | ssh -i $SSH_KEY
"$SSH_REMOTE_HOST" dd "of=$SSH_CORETEMP"
ERROR=$?
if [ $ERROR -ne 0 ] ; then
log_failure_msg "$NAME: makedumpfile failed, falling back to
'scp'"
Bug#985716: kdump-tools passes wrong arguments to makedumpfile
On Mon, Mar 22, 2021 at 11:31 AM dann frazier wrote: > Thanks for the report Ioanna! Could you test the branch here? I'm > still trying to figure out how to propose it in a merge... > https://salsa.debian.org/dannf/kdump-tools/-/commits/bug985716 Oh, figured it out - please feel free to comment here: https://salsa.debian.org/debian/kdump-tools/-/merge_requests/6
Bug#985716: kdump-tools passes wrong arguments to makedumpfile
On Mon, Mar 22, 2021 at 9:33 AM Ioanna Alifieraki wrote: > > Package: kdump-tools > Version: 1:1.6.8.2 > Severity: normal > X-Debbugs-Cc: ioanna-maria.alifier...@canonical.com > > Dear Maintainer, > > Commit 38fe0c8f41fd (Support compressing the dumpfile) [1] > changes the call to makedumpfile : > - makedumpfile $MAKEDUMP_ARGS $vmcore_file "$KDUMP_CORETEMP" > + makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress > "$KDUMP_CORETEMP" > > This introduces a regression because makedumpfile is called with the wrong > arguments and as a result instead of creating a real dumpfile it creates > a file which contains an error message : > > # cat /var/crash/202103221444/dump.202103221444 > Commandline parameter is invalid. > Try `makedumpfile --help' for more information. > > makedumpfile Failed. Thanks for the report Ioanna! Could you test the branch here? I'm still trying to figure out how to propose it in a merge... https://salsa.debian.org/dannf/kdump-tools/-/commits/bug985716 -dann
Bug#983882: pull request
fyi, I submitted a PR here: https://github.com/mati75/openbox-debian/pull/14
Bug#983882: unstable with more than 2 screens
Package: openbox Version: 3.6.1-9 Severity: normal There's a seemingly obvious bug in screen.c that can cause an infinite loop. A patch was submitted upstream to fix it: https://github.com/AlexGoinsNV/openbox-multiXscreen-bugfix/commit/2635c87d160aa5f6f9e91e290678e99111788d57 Would it be possible to apply this before bullseye? -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openbox depends on: ii libc6 2.31-9 ii libglib2.0-0 2.66.7-1 ii libice6 2:1.0.10-1 ii libobrender32v5 3.6.1-9 ii libobt2v5 3.6.1-9 ii libsm62:1.2.3-1 ii libstartup-notification0 0.12-6+b1 ii libx11-6 2:1.7.0-2 ii libxau6 1:1.0.9-1 ii libxcursor1 1:1.2.0-2 ii libxext6 2:1.3.3-1.1 ii libxi62:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxrandr22:1.5.1-1 ii python3 3.9.1-1 Versions of packages openbox recommends: ii obconf 1:2.0.4+git20150213-2 ii obsession 20140608-2+b1 ii scrot 1.5-1 Versions of packages openbox suggests: ii fonts-dejavu 2.37-2 ii libxml2-dev2.9.10+dfsg-6.3+b1 pn openbox-gnome-session pn openbox-kde-session pn tint2 -- no debconf information
Bug#983486: zipl: allow other packages to provide config snippets
On Thu, Feb 25, 2021 at 6:21 AM Stefan Haberland wrote: > > Am 25.02.21 um 08:30 schrieb Christian Borntraeger: > > > > On 24.02.21 23:40, dann frazier wrote: > >> Source: s390-tools > >> Version: 2.15.1-2 > >> > >> I'm one of the maintainers of kdump-tools, which has a need to manipulate > >> the kernel command line parameters in boot loader configurations. > >> Currently zipl provides no way to do this without modifying > >> /etc/zipl.conf directly. It would be helpful if there was e.g. an > >> /etc/zipl.conf.d/ interface for dropping in additional configuration. > >> > >> As an example, GRUB provides an /etc/default/grub.d/ directory, which > >> allows us to drop in a file like this: > >> > >> $ cat /etc/default/grub.d/kdump-tools.cfg > >> GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT > >> crashkernel=384M-:128M" > >> > >> One idea of how to implement this would be to do something similar to > >> GRUB and ship a tool (say, update-zlib) that generates a static > >> /etc/zlib.conf as directed by a set of shell variables (say > >> /etc/default/zlib). It could then process a directory of snippets (say > >> /etc/default/zlib.d/*) allowing other packages to tweak/override the > >> configuration defined by those variables. > >> > >> I realize that while that this design would have an upgrade problem > >> for existing users, but perhaps we could provide an opt-in-only > >> migration path. > >> > > Newer zipls also provide a way to specify BLS entries > > https://systemd.io/BOOT_LOADER_SPECIFICATION/ > > would that help you? > > > > If something like a zipl.conf.d is still considered valueable, maybe > > open an issue for the > > upstream project https://github.com/ibm-s390-linux/s390-tools/issues > > Hi, > > we currently also have an item in the work that works comparable to > grubs environment block. > Depending on the specific problem that this conf.d directory should > solve, this could also be of help. Hi Christian, I'm not sure sharing a writeable variable store with firmware (my understanding of the env block) would get us there - we really just need to be able to manipulate the default set of kernel command line arguments. fyi, here's a link to the discussion that prompted this bug: https://salsa.debian.org/debian/kdump-tools/-/merge_requests/5#note_229647 -dann
Bug#983486: zipl: allow other packages to provide config snippets
Source: s390-tools Version: 2.15.1-2 I'm one of the maintainers of kdump-tools, which has a need to manipulate the kernel command line parameters in boot loader configurations. Currently zipl provides no way to do this without modifying /etc/zipl.conf directly. It would be helpful if there was e.g. an /etc/zipl.conf.d/ interface for dropping in additional configuration. As an example, GRUB provides an /etc/default/grub.d/ directory, which allows us to drop in a file like this: $ cat /etc/default/grub.d/kdump-tools.cfg GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:128M" One idea of how to implement this would be to do something similar to GRUB and ship a tool (say, update-zlib) that generates a static /etc/zlib.conf as directed by a set of shell variables (say /etc/default/zlib). It could then process a directory of snippets (say /etc/default/zlib.d/*) allowing other packages to tweak/override the configuration defined by those variables. I realize that while that this design would have an upgrade problem for existing users, but perhaps we could provide an opt-in-only migration path.
Bug#979248: autopkgtest dependencies cannot be satisified
On Mon, Jan 4, 2021 at 10:34 AM Christoph Biedl wrote: > > Control: tags 979248 confirmed > > dann frazier wrote... > > > Source: clevis > > Version: 15-1 > > Severity: normal > > > > Now that clevis-dracut depends on dracut[*], the autopkgtest dependencies > > are no longer satisfiable causing the tests to fail. clevis-dracut and > > clevis-initramfs cannot be installed at the same time, as dracut conflicts > > with initramfs-tools. > > Jepp, already on radar. I just had to fix some issues in tang first. I noticed that after dropping the clevis-dracut test dep, that the test loops with .+ curl --output /dev/null --silent --fail http://127.0.0.1:2048/adv + sleep 0.1 + echo -n . .+ curl --output /dev/null --silent --fail http://127.0.0.1:2048/adv + sleep 0.1 + echo -n . Does this happen to be one of the tang issues you are addressing? > Aside, I'm wondering whether such a situation is RC - but in that > particular case, don't waste your time poking bug severities. > > Just let me take the opportunity to thank you for all the additional > testing you've done for clevis and tang in the past. No problem, thanks for your work on the package as well Christoph! -dann
Bug#979248: autopkgtest dependencies cannot be satisified
Source: clevis Version: 15-1 Severity: normal Now that clevis-dracut depends on dracut[*], the autopkgtest dependencies are no longer satisfiable causing the tests to fail. clevis-dracut and clevis-initramfs cannot be installed at the same time, as dracut conflicts with initramfs-tools. [*] https://git.in-ulm.de/cbiedl/clevis/commit/72346519a92f7b03c0b0653f5d06b7c69ed9d2e4
Bug#977511: buster-pu: package edk2/0~20181115.85588389-3+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Address CVE-2019-14584 (#977300), for which the security team has declined to
release a DSA.
[ Impact ]
Possible firmware crash while validating signed payloads.
[ Tests ]
Regression tested by booting a Secure Boot guest.
[ Risks ]
It's a one-liner fix - if it introduced a regression, it could break
certain secure boot guests.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
A clean cherry-pick from upstream to fix a potential NULL pointer
dreference.
[ Other info ]
N/A
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru edk2-0~20181115.85588389/debian/changelog
edk2-0~20181115.85588389/debian/changelog
--- edk2-0~20181115.85588389/debian/changelog 2020-09-17 13:45:52.0
-0600
+++ edk2-0~20181115.85588389/debian/changelog 2020-12-15 12:30:28.0
-0700
@@ -1,3 +1,11 @@
+edk2 (0~20181115.85588389-3+deb10u3) buster; urgency=medium
+
+ * CryptoPkg/BaseCryptLib: fix NULL dereference. (CVE-2019-14584)
+(Closes: #977300)
+ - d/p/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
+
+ -- dann frazier Tue, 15 Dec 2020 12:30:28 -0700
+
edk2 (0~20181115.85588389-3+deb10u2) buster; urgency=medium
* Fix integer overflow in DxeImageVerificationHandler. (CVE-2019-14562)
diff -Nru
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
---
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
1969-12-31 17:00:00.0 -0700
+++
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
2020-12-15 12:30:28.0 -0700
@@ -0,0 +1,51 @@
+From 26442d11e620a9e81c019a24a4ff38441c64ba10 Mon Sep 17 00:00:00 2001
+From: Jian J Wang
+Date: Thu, 25 Apr 2019 23:42:16 +0800
+Subject: [PATCH] CryptoPkg/BaseCryptLib: fix NULL dereference (CVE-2019-14584)
+
+REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1914
+
+AuthenticodeVerify() calls OpenSSLs d2i_PKCS7() API to parse asn encoded
+signed authenticode pkcs#7 data. when this successfully returns, a type
+check is done by calling PKCS7_type_is_signed() and then
+Pkcs7->d.sign->contents->type is used. It is possible to construct an asn1
+blob that successfully decodes and have d2i_PKCS7() return a valid pointer
+and have PKCS7_type_is_signed() also return success but have Pkcs7->d.sign
+be a NULL pointer.
+
+Looking at how PKCS7_verify() [inside of OpenSSL] implements checking for
+pkcs7 structs it does the following:
+- call PKCS7_type_is_signed()
+- call PKCS7_get_detached()
+Looking into how PKCS7_get_detatched() is implemented, it checks to see if
+p7->d.sign is NULL or if p7->d.sign->contents->d.ptr is NULL.
+
+As such, the fix is to do the same as OpenSSL after calling d2i_PKCS7().
+- Add call to PKS7_get_detached() to existing error handling
+
+Cc: Xiaoyu Lu
+Cc: Guomin Jiang
+Cc: Jiewen Yao
+Cc: Laszlo Ersek
+Signed-off-by: Jian J Wang
+Reviewed-by: Laszlo Ersek
+Reviewed-by: Jiewen Yao
+
+Origin: upstream,
https://github.com/tianocore/edk2/commit/26442d11e620a9e81c019a24a4ff38441c64ba10
+Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1914
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977300
+Last-Update: 2020-12-15
+
+Index: edk2/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
+===
+--- edk2.orig/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
edk2/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
+@@ -106,7 +106,7 @@ AuthenticodeVerify (
+ //
+ // Check if it's PKCS#7 Signed Data (for Authenticode Scenario)
+ //
+- if (!PKCS7_type_is_signed (Pkcs7)) {
++ if (!PKCS7_type_is_signed (Pkcs7) || PKCS7_get_detached (Pkcs7)) {
+ goto _Exit;
+ }
+
diff -Nru edk2-0~20181115.85588389/debian/patches/series
edk2-0~20181115.85588389/debian/patches/series
--- edk2-0~20181115.85588389/debian/patches/series 2020-09-17
13:45:52.0 -0600
+++ edk2-0~20181115.85588389/debian/patches/series 2020-12-15
12:30:28.0 -0700
@@ -27,3 +2
Bug#977300: buster debdiff
Attached is a tested debdiff for buster. Does the security team want
to push this out via security or should I propose it for the next
point release?
diff -Nru edk2-0~20181115.85588389/debian/changelog
edk2-0~20181115.85588389/debian/changelog
--- edk2-0~20181115.85588389/debian/changelog 2020-09-17 13:45:52.0
-0600
+++ edk2-0~20181115.85588389/debian/changelog 2020-12-15 12:30:28.0
-0700
@@ -1,3 +1,11 @@
+edk2 (0~20181115.85588389-3+deb10u3) buster; urgency=medium
+
+ * CryptoPkg/BaseCryptLib: fix NULL dereference. (CVE-2019-14584)
+(Closes: #977300)
+ - d/p/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
+
+ -- dann frazier Tue, 15 Dec 2020 12:30:28 -0700
+
edk2 (0~20181115.85588389-3+deb10u2) buster; urgency=medium
* Fix integer overflow in DxeImageVerificationHandler. (CVE-2019-14562)
diff -Nru
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
---
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
1969-12-31 17:00:00.0 -0700
+++
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
2020-12-15 12:30:28.0 -0700
@@ -0,0 +1,51 @@
+From 26442d11e620a9e81c019a24a4ff38441c64ba10 Mon Sep 17 00:00:00 2001
+From: Jian J Wang
+Date: Thu, 25 Apr 2019 23:42:16 +0800
+Subject: [PATCH] CryptoPkg/BaseCryptLib: fix NULL dereference (CVE-2019-14584)
+
+REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1914
+
+AuthenticodeVerify() calls OpenSSLs d2i_PKCS7() API to parse asn encoded
+signed authenticode pkcs#7 data. when this successfully returns, a type
+check is done by calling PKCS7_type_is_signed() and then
+Pkcs7->d.sign->contents->type is used. It is possible to construct an asn1
+blob that successfully decodes and have d2i_PKCS7() return a valid pointer
+and have PKCS7_type_is_signed() also return success but have Pkcs7->d.sign
+be a NULL pointer.
+
+Looking at how PKCS7_verify() [inside of OpenSSL] implements checking for
+pkcs7 structs it does the following:
+- call PKCS7_type_is_signed()
+- call PKCS7_get_detached()
+Looking into how PKCS7_get_detatched() is implemented, it checks to see if
+p7->d.sign is NULL or if p7->d.sign->contents->d.ptr is NULL.
+
+As such, the fix is to do the same as OpenSSL after calling d2i_PKCS7().
+- Add call to PKS7_get_detached() to existing error handling
+
+Cc: Xiaoyu Lu
+Cc: Guomin Jiang
+Cc: Jiewen Yao
+Cc: Laszlo Ersek
+Signed-off-by: Jian J Wang
+Reviewed-by: Laszlo Ersek
+Reviewed-by: Jiewen Yao
+
+Origin: upstream,
https://github.com/tianocore/edk2/commit/26442d11e620a9e81c019a24a4ff38441c64ba10
+Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1914
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977300
+Last-Update: 2020-12-15
+
+Index: edk2/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
+===
+--- edk2.orig/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
edk2/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
+@@ -106,7 +106,7 @@ AuthenticodeVerify (
+ //
+ // Check if it's PKCS#7 Signed Data (for Authenticode Scenario)
+ //
+- if (!PKCS7_type_is_signed (Pkcs7)) {
++ if (!PKCS7_type_is_signed (Pkcs7) || PKCS7_get_detached (Pkcs7)) {
+ goto _Exit;
+ }
+
diff -Nru edk2-0~20181115.85588389/debian/patches/series
edk2-0~20181115.85588389/debian/patches/series
--- edk2-0~20181115.85588389/debian/patches/series 2020-09-17
13:45:52.0 -0600
+++ edk2-0~20181115.85588389/debian/patches/series 2020-12-15
12:30:28.0 -0700
@@ -27,3 +27,4 @@
0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch
0002-SecurityPkg-DxeImageVerificationLib-assign-WinCertif.patch
0003-SecurityPkg-DxeImageVerificationLib-catch-alignment-.patch
+CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
Bug#977301: segfault in audio_init()
Package: qemu-system-x86 Version: 1:5.2+dfsg-2 Severity: normal One of my libvirt/QEMU guests is now segfaulting on startup: Thread 1 (Thread 0x7fcd275e5e80 (LWP 829788)): #0 audio_init (dev=dev@entry=0x0, name=name@entry=0x5590b2b8a27b "hda") at ../../audio/audio.c:1712 #1 0x5590b2890f7a in AUD_register_card (name=name@entry=0x5590b2b8a27b "hda", card=card@entry=0x5590b67676f8) at ../../audio/audio.c:1831 #2 0x5590b28459d5 in hda_audio_init (hda=, desc=0x5590b2f39f60 ) at ../../hw/audio/hda-codec.c:691 #3 0x5590b26dd59a in hda_codec_dev_realize (qdev=, errp=0x7ffd21d56380) at ../../hw/audio/intel-hda.c:74 #4 0x5590b2ae98b1 in device_set_realized (obj=, value=, errp=0x7ffd21d56400) at ../../hw/core/qdev.c:886 #5 0x5590b2ad45c6 in property_set_bool (obj=0x5590b6767660, v=, name=, opaque=0x5590b4e453e0, errp=0x7ffd21d56400) at ../../qom/object.c:2251 #6 0x5590b2ad7418 in object_property_set (obj=obj@entry=0x5590b6767660, name=name@entry=0x5590b2cc2ee9 "realized", v=v@entry=0x5590b676fde0, errp=errp@entry=0x5590b308c010 ) at ../../qom/object.c:1398 #7 0x5590b2ad3580 in object_property_set_qobject (obj=obj@entry=0x5590b6767660, name=name@entry=0x5590b2cc2ee9 "realized", value=value@entry=0x5590b676fd20, errp=errp@entry=0x5590b308c010 ) at ../../qom/qom-qobject.c:28 #8 0x5590b2ad79f5 in object_property_set_bool (obj=0x5590b6767660, name=name@entry=0x5590b2cc2ee9 "realized", value=value@entry=true, errp=errp@entry=0x5590b308c010 ) at ../../qom/object.c:1465 #9 0x5590b2ae9ebe in qdev_realize (dev=, bus=bus@entry=0x5590b6722348, errp=errp@entry=0x5590b308c010 ) at ../../hw/core/qdev.c:399 #10 0x5590b27a3ef7 in qdev_device_add (opts=0x5590b4e43030, errp=errp@entry=0x5590b308c010 ) at ../../softmmu/qdev-monitor.c:676 #11 0x5590b2a05a3f in device_init_func (opaque=, opts=, errp=0x5590b308c010 ) at ../../softmmu/vl.c:2104 #12 0x5590b2b7144a in qemu_opts_foreach (list=, func=func@entry=0x5590b2a05a30 , opaque=opaque@entry=0x0, errp=0x5590b308c010 ) at ../../util/qemu-option.c:1156 #13 0x5590b2a0c4a4 in qemu_init (argc=, argv=, envp=) at ../../softmmu/vl.c:4400 #14 0x5590b26a3479 in main (argc=, argv=, envp=) at ../../softmmu/main.c:49 I'm working around it by removing the sound device from my XML: --- debian10.xml.crashes2020-12-13 10:49:45.376371832 -0700 +++ debian10.xml2020-12-13 10:49:52.812335134 -0700 @@ -135,9 +135,6 @@ - - - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-system-x86 depends on: ii ipxe-qemu 1.0.0+git-20190125.36a4c85-5 ii libaio1 0.3.112-8 ii libc6 2.31-5 ii libcapstone4 4.0.2-3 ii libfdt1 1.6.0-1 ii libgcc-s1 10.2.1-1 ii libglib2.0-0 2.66.3-2 ii libgnutls30 3.7.0-3 ii libibverbs1 32.0-1+b1 ii libjpeg62-turbo 1:2.0.5-1.1 ii libnettle83.6-2 ii libnuma1 2.0.12-1+b1 ii libpixman-1-0 0.40.0-1 ii libpmem1 1.10-1 ii libpng16-16 1.6.37-3 ii librdmacm132.0-1+b1 ii libsasl2-22.1.27+dfsg-2 ii libseccomp2 2.5.0-3+b1 ii libslirp0 4.3.1-1 ii libudev1 247.1-4 ii liburing1 0.7-2 ii libusb-1.0-0 2:1.0.24-1 ii libvdeplug2 4.0.1-2 ii libxendevicemodel14.14.0+80-gd101b417b7-1 ii libxenevtchn1 4.14.0+80-gd101b417b7-1 ii libxenforeignmemory1 4.14.0+80-gd101b417b7-1 ii libxengnttab1 4.14.0+80-gd101b417b7-1 ii libxenmisc4.144.14.0+80-gd101b417b7-1 ii libxenstore3.04.14.0+80-gd101b417b7-1 ii libxentoolcore1 4.14.0+80-gd101b417b7-1 ii qemu-system-common1:5.2+dfsg-2 ii qemu-system-data 1:5.2+dfsg-2 ii seabios 1.14.0-2 ii zlib1g1:1.2.11.dfsg-2 Versions of packages qemu-system-x86 recommends: ii ovmf 2020.11-1 pn qemu-system-gui ii qemu-utils 1:5.2+dfsg-2 Versions of packages qemu-system-x86 suggests: pn qemu-block-extra ii qemu-system-data [sgabios] 1:5.2+dfsg-2 pn samba pn vde2 -- no debconf information
Bug#974844: requires -global ICH9-LPC.disable_s3=1
forcemerge 973783 974844 thanks Since we are targetting the OvmfPkgX64 platform, you currently have to explicitly disable S3 support on the QEMU command line: -global ICH9-LPC.disable_s3=1 We are looking at switching to the OvmfPkgIa32X64 platform, which would not require disabling S3.
Bug#975015: commit message asserts fsync is not enough
Looking at git history, I see this commit that makes an assertion counter to my test results: http://git.grml.org/?p=grml2usb.git;a=commit;h=7a6e10df Previous to that commit, I did not see fsync being used. Michael: is that commit message based on experimentation? If so, perhaps neither sync approach is really sufficient, and maybe we need to implement a retry loop :/
Bug#975015: blockdev: ioctl error on BLKRRPART: Device or resource busy
Package: grml2usb
Version: 0.18.3
Severity: normal
Tags: patch
grml2usb autopkgtest frequently fail in Ubuntu's CI. For example:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/g/grml2usb/20201116_194744_cbe0f@/log.gz
An excerpt showing the error:
2020-11-17 14:14:49,362 Installing default MBR
2020-11-17 14:14:49,363 executing: dd if='/dev/loop0' of='/tmp/tmpa2umy9df' bs=5
12 count=1
2020-11-17 14:14:49,381 executing: dd if=/usr/share/grml2usb/mbr/mbrldr of=/tmp/
tmpa2umy9df bs=439 count=1 conv=notrunc
2020-11-17 14:14:49,385 executing: dd if='/tmp/tmpa2umy9df' of='/dev/loop0' bs=5
12 count=1 conv=notrunc
2020-11-17 14:14:49,401 executing: sync
2020-11-17 14:14:49,433 Probing device via 'blockdev --rereadpt /dev/loop0'
blockdev: ioctl error on BLKRRPART: Device or resource busy
2020-11-17 14:14:49,452 Execution failed: ("Couldn't execute blockdev on '%s' (i
nstall util-linux?)", '/dev/loop0')
I am able to reproduce this on an OpenStack instance with a failure rate of
33% (36 failures, 110 passes). My theory is that the sync is not sufficient,
and that we really need to do a targeted fsync of the file. With the
attached patch, I've yet to see a failure in 42 iterations.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages grml2usb depends on:
ii grub2-common2.04-10
ii kmod27+20200310-2
ii mtools 4.0.25-1
ii python3 3.8.6-1
ii python3-parted 3.11.6-0.1+b1
ii rsync 3.2.3-2
ii syslinux3:6.04~git20190206.bf6db5b4+dfsg1-3
Versions of packages grml2usb recommends:
ii genisoimage 9:1.1.11-3.1
ii isolinux3:6.04~git20190206.bf6db5b4+dfsg1-3
ii syslinux3:6.04~git20190206.bf6db5b4+dfsg1-3
ii syslinux-utils 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii xorriso 1.5.2-1
grml2usb suggests no packages.
-- no debconf information
diff -urp grml2usb-0.18.3.orig/grml2usb grml2usb-0.18.3/grml2usb
--- grml2usb-0.18.3.orig/grml2usb 2020-06-23 10:48:42.0 +
+++ grml2usb-0.18.3/grml2usb2020-11-17 18:49:10.884080710 +
@@ -856,7 +852,9 @@ def install_mbr(mbrtemplate, device, par
set_rw(device)
logging.debug(
-"executing: dd if='%s' of='%s' bs=512 count=1 conv=notrunc",
tmpf.name, device
+"executing: dd if='%s' of='%s' bs=512 count=1 conv=notrunc,fsync",
+tmpf.name,
+device,
)
proc = subprocess.Popen(
[
@@ -865,7 +863,7 @@ def install_mbr(mbrtemplate, device, par
"of=%s" % device,
"bs=512",
"count=1",
-"conv=notrunc",
+"conv=notrunc,fsync",
],
stderr=open(os.devnull, "r+"),
)
@@ -874,11 +872,6 @@ def install_mbr(mbrtemplate, device, par
raise Exception("error executing dd (third run)")
del tmpf
-# make sure we sync filesystems before returning
-logging.debug("executing: sync")
-proc = subprocess.Popen(["sync"])
-proc.wait()
-
logging.debug("Probing device via 'blockdev --rereadpt %s'", device)
proc = subprocess.Popen(["blockdev", "--rereadpt", device])
proc.wait()
Bug#973730: dropping severity
severity 973730 wishlist thanks I had the same concern when I first started working on this package, but I learned that there is no requirement that a package be buildable on any architecture where it can be used. If you believe that is incorrect, please cite a policy section.
Bug#973571: ovmf: does not work with qemu-system-i386 5.1
On Tue, Nov 3, 2020 at 12:45 PM Christian Kastner wrote: > > Control: severity -1 wishlist > > On 11/2/20 8:44 PM, Ryutaroh Matsumoto wrote: > > Control: reassign -1 src:edk2> Control: forcemerge -1 842683 > > > > I am hoping the above control commands merge 973571 and 842683 > > (I don't know how to merge multiple BTS bugs...). > > They did merge, but the bug number should have been the other way > around, I think :-) > > The severity is taken from the first bug, which was "important", but as > the package behaves as designed (it's expressly for 64-bit), I'm afraid > that "wishlist" remains to be applicable. > > However, with the positive results of your experiments, perhaps the > maintainers are more willing to give the i386 version a try? Sure - I'll plan to give it a try before the next upload. -dann
Bug#972688: 1.27.91-1 blows away existing dns nameservers when VPN activates
Package: network-manager Version: 1.27.90-3 Severity: normal After upgrading to 1.27.91-1, I've found that connecting to my VPN causes my existing "nameserver" option to disappear from /etc/resolv.conf. Before connecting: # Generated by NetworkManager nameserver 192.168.1.1 After connecting (actual search domains obfuscated): # Generated by NetworkManager search foo bar baz I've downgraded back to version 1.27.90-3 which restores the desired behavior of retaining the existing nameserver setting: # Generated by NetworkManager search foo bar baz nameserver 192.168.1.1 Note that I have the VPN's "DNS / Automatic" toggle disabled. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser 3.118 ii dbus 1.12.20-1 ii libaudit11:2.8.5-3.1 ii libbluetooth35.55-1 ii libc62.31-4 ii libcurl3-gnutls 7.72.0-1 ii libglib2.0-0 2.66.1-2 ii libgnutls30 3.6.15-4 ii libjansson4 2.13.1-1 ii libmm-glib0 1.14.6-0.1 ii libndp0 1.6-1+b1 ii libnewt0.52 0.52.21-4+b2 ii libnm0 1.27.90-3 ii libpam-systemd 246.6-2 ii libpsl5 0.21.0-1.1 ii libreadline8 8.0-4 ii libselinux1 3.1-2+b1 ii libsystemd0 246.6-2 ii libteamdctl0 1.31-1 ii libudev1 246.6-2 ii libuuid1 2.36-3+b1 ii policykit-1 0.105-29 ii udev 246.6-2 ii wpasupplicant2:2.9.0-15 Versions of packages network-manager recommends: ii crda 4.14+git20191112.9856751-1 ii dnsmasq-base [dnsmasq-base] 2.82-1 ii iptables 1.8.5-3 ii modemmanager 1.14.6-0.1 ii ppp 2.4.7-2+4.1+deb10u1+b1 Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2.1+b2 pn libteam-utils -- no debconf information
Bug#972583: conserver-server.service: Failed with result 'protocol'
Package: conserver-server Version: 8.2.4-2+b1 Severity: important The postinst fails when installing conserver-server: $ sudo apt install conserver-server Reading package lists... Done Building dependency tree Reading state information... Done The following package was automatically installed and is no longer required: libdirectfb-1.7-7 Use 'sudo apt autoremove' to remove it. The following NEW packages will be installed: conserver-server 0 upgraded, 1 newly installed, 0 to remove and 8 not upgraded. Need to get 0 B/181 kB of archives. After this operation, 471 kB of additional disk space will be used. Preconfiguring packages ... Selecting previously unselected package conserver-server. (Reading database ... 438587 files and directories currently installed.) Preparing to unpack .../conserver-server_8.2.4-2+b1_amd64.deb ... Unpacking conserver-server (8.2.4-2+b1) ... Setting up conserver-server (8.2.4-2+b1) ... Job for conserver-server.service failed because the service did not take the ste ps required by its unit configuration. See "systemctl status conserver-server.service" and "journalctl -xe" for details . invoke-rc.d: initscript conserver-server, action "start" failed. ● conserver-server.service - Console server Loaded: loaded (/lib/systemd/system/conserver-server.service; disabled; ven dor preset: enabled) Active: failed (Result: protocol) since Tue 2020-10-20 11:24:30 MDT; 8ms ag o Docs: man:conserver(8) Process: 430561 ExecStart=/usr/sbin/conserver -d $OPTS (code=exited, status= 0/SUCCESS) Oct 20 11:24:30 xps13 systemd[1]: Starting Console server... Oct 20 11:24:30 xps13 conserver[430561]: [Tue Oct 20 11:24:30 2020] conserver (4 30561): conserver.com version 8.2.4 Oct 20 11:24:30 xps13 conserver[430561]: [Tue Oct 20 11:24:30 2020] conserver (4 30561): started as `conservr' by `conservr' Oct 20 11:24:30 xps13 conserver[430561]: [Tue Oct 20 11:24:30 2020] conserver (4 30561): ERROR: no consoles found in configuration file Oct 20 11:24:30 xps13 conserver[430561]: [Tue Oct 20 11:24:30 2020] conserver (4 30561): terminated Oct 20 11:24:30 xps13 systemd[1]: conserver-server.service: Can't open PID file /run/conserver/conserver.pid (yet?) after start: Operation not permitted Oct 20 11:24:30 xps13 systemd[1]: conserver-server.service: Failed with result ' protocol'. Oct 20 11:24:30 xps13 systemd[1]: Failed to start Console server. dpkg: error processing package conserver-server (--configure): installed conserver-server package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.9.3-2) ... Processing triggers for systemd (246.6-2) ... Errors were encountered while processing: conserver-server needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-rc8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages conserver-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.74 ii libc6 2.31-4 ii libcrypt1 1:4.4.17-1 ii libpam0g 1.3.1-5 ii libssl1.1 1.1.1h-1 ii libwrap0 7.6.q-30 ii lsb-base 11.1.0 conserver-server recommends no packages. conserver-server suggests no packages. -- debconf information: conserver-server/run_as_root: false conserver-server/port: 3109 conserver-server/base_port: conserver-server/listen_address:
Bug#972581: enabling ipv6 support broke ipv4 CIDR access list
Package: conserver-server
Version: 8.2.4-2+b1
Severity: normal
Tags: upstream
I'm using an access list that looks like this:
access * {
trusted 127.0.0.1,10.2.3.4,10.5.6.0/18,10.6.7.0/18;
allowed 127.0.0.1,10.2.3.4,10.5.6.0/18,10.6.7.0/18;
}
After upgrading from 8.2.1-1 to 8.2.4-2, conserver began denying access to
clients in these IP ranges:
$ console myhost
10.2.3.4: access from your host refused
I found that the important difference between these two wasn't the source
itself, but rather that --with-ipv6 was enabled for 8.2.4. Rebuilding 8.2.4
w/o --with-ipv6 restored the previous behavior, allowing clients the impacted
clients to connect once again.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-rc8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages conserver-server depends on:
ii adduser3.118
ii debconf [debconf-2.0] 1.5.74
ii libc6 2.31-4
ii libcrypt1 1:4.4.17-1
ii libpam0g 1.3.1-5
ii libssl1.1 1.1.1h-1
ii libwrap0 7.6.q-30
ii lsb-base 11.1.0
conserver-server recommends no packages.
conserver-server suggests no packages.
-- debconf information:
conserver-server/port: 3109
conserver-server/base_port:
conserver-server/listen_address:
conserver-server/run_as_root: false
Bug#971437: recordings blank except for mouse pointer
Package: peek Version: 1.5.1-1 Severity: normal I attempted to record a portion of my (wayland) desktop this morning (mp4), and found on playback that the video was just black except for the mouse pointer. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages peek depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1 ii ffmpeg 7:4.3.1-4 ii gstreamer1.0-plugins-good1.18.0-1 ii libc62.31-3 ii libcairo21.16.0-4 ii libglib2.0-0 2.66.0-2 ii libgtk-3-0 3.24.23-1 ii libkeybinder-3.0-0 0.3.2-1+b1 ii libpango-1.0-0 1.46.2-1 Versions of packages peek recommends: ii gstreamer1.0-plugins-ugly 1.18.0-1 Versions of packages peek suggests: pn gifski -- no debconf information
Bug#970691: please include initramfs fixes from upstream
Package: clevis-initramfs Version: 13-2 Severity: normal Tags: patch I've prepared a branch that backports several fixes to the initramfs support: https://salsa.debian.org/dannf/clevis/-/commits/v13-initramfs-fixes Here's a summary extracted from the changelog: * initramfs: Fix parsing of interface names when bringing the network back down in local-bottom, which also avoids a mess of "ip: can't find device '/sys/class/net/$iface'" errors on the console. LP: #1896294. * initramfs: Warn users with multiple interfaces that they should consider specifying an 'ip=' parameter for reliable operation. LP: #1896289. As a side-effect, also fix interface parsing while bringing links up. LP: #1873593. * initramfs: Wait for interface to appear before attempting configuration. LP: #1873914. The first change is already in v14 upstream, the others aren't yet in an upstream release. Please consider merging :)
Bug#970518: buster-pu: package edk2/0~20181115.85588389-3+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu [ Reason ] I'd like to fix CVE-2019-14562 in edk2 for buster. [ Impact ] Vulnerability to an integer overflow when parsing signatures of a specially crafted PE file. [ Tests ] Regression tested only using the autopkgtests from the unstable version of the package. [ Risks ] A regression could break the booting of QEMU-emulated machines. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Cherry-picks from upstream to resolve CVE-2019-14562. [ Other info ] N/A -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru edk2-0~20181115.85588389/debian/changelog edk2-0~20181115.85588389/debian/changelog --- edk2-0~20181115.85588389/debian/changelog 2020-04-23 13:33:06.0 -0600 +++ edk2-0~20181115.85588389/debian/changelog 2020-09-17 13:45:52.0 -0600 @@ -1,3 +1,13 @@ +edk2 (0~20181115.85588389-3+deb10u2) buster; urgency=medium + + * Fix integer overflow in DxeImageVerificationHandler. (CVE-2019-14562) +(Closes: #968819) + - d/p/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch + - d/p/0002-SecurityPkg-DxeImageVerificationLib-assign-WinCertif.patch + - d/p/0003-SecurityPkg-DxeImageVerificationLib-catch-alignment-.patch + + -- dann frazier Thu, 17 Sep 2020 13:45:52 -0600 + edk2 (0~20181115.85588389-3+deb10u1) buster; urgency=medium * Fix numeric truncation in S3BootScript[Save]*() API. (CVE-2019-14563) diff -Nru edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch --- edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch 1969-12-31 17:00:00.0 -0700 +++ edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch 2020-09-17 13:45:52.0 -0600 @@ -0,0 +1,87 @@ +From 503248ccdf45c14d4040ce44163facdc212e4991 Mon Sep 17 00:00:00 2001 +From: Laszlo Ersek +Date: Tue, 1 Sep 2020 11:12:19 +0200 +Subject: [PATCH 1/3] SecurityPkg/DxeImageVerificationLib: extract + SecDataDirEnd, SecDataDirLeft +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The following two quantities: + + SecDataDir->VirtualAddress + SecDataDir->Size + SecDataDir->VirtualAddress + SecDataDir->Size - OffSet + +are used multiple times in DxeImageVerificationHandler(). Introduce helper +variables for them: "SecDataDirEnd" and "SecDataDirLeft", respectively. +This saves us multiple calculations and significantly simplifies the code. + +Note that all three summands above have type UINT32, therefore the new +variables are also of type UINT32. + +This patch does not change behavior. + +(Note that the code already handles the case when the + + SecDataDir->VirtualAddress + SecDataDir->Size + +UINT32 addition overflows -- namely, in that case, the certificate loop is +never entered, and the corruption check right after the loop fires.) + +Cc: Jian J Wang +Cc: Jiewen Yao +Cc: Min Xu +Cc: Wenyi Xie +Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 +Signed-off-by: Laszlo Ersek +Message-Id: <20200901091221.20948-2-ler...@redhat.com> +Reviewed-by: Philippe Mathieu-Daudé +Tested-by: Wenyi Xie +Reviewed-by: Min M Xu +Reviewed-by: Jiewen Yao + +Origin: https://github.com/tianocore/edk2/commit/503248ccdf45c14d4040ce44163facdc212e4991 +Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 +Bug-Debian: https://bugs.debian.org/968819 +Last-Update: 2020-09-17 + +Index: edk2/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c +=== +--- edk2.orig/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c edk2/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c +@@ -1658,6 +1658,8 @@ DxeImageVerificationHandler ( + UINT8*AuthData; + UINTNAuthDataSize; + EFI_IMAGE_DATA_DIRECTORY *SecDataDir; ++ UINT32 SecDataDirEnd; ++ UINT32
Bug#969184: Upgrade fails when interface name has changed
On Fri, Aug 28, 2020 at 10:38:25PM +0200, Thomas Goirand wrote:
> Hi Dann,
>
> If you look into the minissdpd configuration script (ie:
> /var/lib/dpkg/info/minissdpd.config) it does read what's in the
> /etc/default/minissdpd configuration file before attempting to configure
> the package. Maybe there's a problem in it, and you could try debugging
> it by adding a set -x in there? It would help a lot of you could show
> the output like that, so we can figure out where the problem is.
Thanks for the reply Thomas. I've collected the 'set -x' output in the
following annotated log:
===> Demonstrate that original config includes interface
===> that is no longer available, which I've searched and
===> replaced as enxREDACTED1:
$ cat /etc/default/minissdpd
# MiniSSDPd default configuration
# Set this to 1 if you want to start the daemon
# START_DAEMON deprecated, use service minissdpd enable/disable
#START_DAEMON=1
# Set this to the IP/interface you want the demon to run on
# Notes:
# 1. It is mandatory to use the network interface name in order to enable IPv6
# HTTP is available on all interfaces.
# 2. Specifying IP when built with IPv6 support is disabled by original
# author, so this option may not be available outside Debian.
MiniSSDPd_INTERFACE_ADDRESS="enxREDACTED1"
# This defines other options which you might want to use when
# starting MiniSSDPd.
#MiniSSDPd_OTHER_OPTIONS="-6"
MiniSSDPd_OTHER_OPTIONS=""
===> Here we see the failure I originally reported,
===> this time w/ set -x
$ sudo dpkg --configure -a
Setting up minissdpd (1.5.20190824-1) ...
+ set -e
+ DEFAULT_FILE=/etc/default/minissdpd
+ . /usr/share/debconf/confmodule
+ [ ! ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [ ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/minissdpd.postinst
configure 1.5.20190824-1
+ set -e
+ DEFAULT_FILE=/etc/default/minissdpd
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z ]
+ exec
+ [ ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ [ configure = configure ]
+ [ -x /etc/init.d/minissdpd ]
+ update-rc.d minissdpd defaults-disabled
+ [ configure = configure ]
+ deb-systemd-helper debian-installed minissdpd.service
+ deb-systemd-helper unmask minissdpd.service
+ deb-systemd-helper --quiet was-enabled minissdpd.service
+ deb-systemd-helper enable minissdpd.service
+ deb-systemd-helper update-state minissdpd.service
+ [ -e /etc/default/minissdpd ]
+ db_get minissdpd/listen
+ _db_cmd GET minissdpd/listen
+ _db_internal_IFS=
+ IFS=
+ printf %s\n GET minissdpd/listen
+ IFS=
+ read -r _db_internal_line
+ IFS=
+ RET=enxREDACTED1
+ return 0
+ MiniSSDPd_INTERFACE_ADDRESS=enxREDACTED1
+ replace_config /etc/default/minissdpd MiniSSDPd_INTERFACE_ADDRESS
"enxREDACTED1"
+ [ -s /etc/default/minissdpd ]
+ sed -ri
x
s|^$||
t find
x
b
: find
x
s|^\s*(MiniSSDPd_INTERFACE_ADDRESS=).*|\1"enxREDACTED1"|
t end
s|^#[ \t#]*(MiniSSDPd_INTERFACE_ADDRESS=['"]?"enxREDACTED1"['"]?)\s*$|\1|
t end
s|^#[ \t#]*(MiniSSDPd_INTERFACE_ADDRESS=)\s*$|\1"enxREDACTED1"|
t end
$ aMiniSSDPd_INTERFACE_ADDRESS="enxREDACTED1"
b
: end
h
/etc/default/minissdpd
+ db_get minissdpd/ip6
+ _db_cmd GET minissdpd/ip6
+ _db_internal_IFS=
+ IFS=
+ printf %s\n GET minissdpd/ip6
+ IFS=
+ read -r _db_internal_line
+ IFS=
+ RET=false
+ return 0
+ [ false = true ]
+ echo
+ grep -qn \-6
+ echo
+ sed -r s/^\s+//; s/\s+$//; s/ +/ /g
+ MiniSSDPd_OTHER_OPTIONS=
+ replace_config /etc/default/minissdpd MiniSSDPd_OTHER_OPTIONS ""
+ [ -s /etc/default/minissdpd ]
+ sed -ri
x
s|^$||
t find
x
b
: find
x
s|^\s*(MiniSSDPd_OTHER_OPTIONS=).*|\1""|
t end
s|^#[ \t#]*(MiniSSDPd_OTHER_OPTIONS=['"]?""['"]?)\s*$|\1|
t end
s|^#[ \t#]*(MiniSSDPd_OTHER_OPTIONS=)\s*$|\1""|
t end
$ aMiniSSDPd_OTHER_OPTIONS=""
b
: end
h
/etc/default/minissdpd
+ db_get minissdpd/start_daemon
+ _db_cmd GET minissdpd/start_daemon
+ _db_internal_IFS=
+ IFS=
+ printf %s\n GET minissdpd/start_daemon
+ IFS=
+ read -r _db_internal_line
+ IFS=
+ RET=true
+ return 0
+ [ true = true ]
+ update-rc.d minissdpd enable
+ [ -n 1.5.20190824-1 ]
+ _dh_action=restart
+ invoke-rc.d minissdpd restart
Job for minissdpd.service failed because the control process exited with error
code.
See "systemctl status minissdpd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript minissdpd, action "restart" failed.
● minissdpd.service - keep memory of all UPnP devices that announced themselves
Loaded: loaded (/lib/systemd/system/minissdpd.service; enabled; vendor
preset: enabled)
Active: failed (Result: exit-code) since Wed 2020-09-02 16:24:08 MDT; 6ms
ago
Docs: man:minissdpd(1)
Process: 839116 ExecCondition=/usr/lib/minissdpd/minissdpd-systemd-wrapper
-t ${MiniSSDPd_INTERFACE_ADDRESS} (code=exited, status=0/SUCCESS)
Process: 839117 ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
${MiniSSDPd_INTERFACE_ADDRESS} $MiniSSDPd_OTHER_OPTIONS (code=exited,
status=1/FAILURE)
Sep 02
