Bug#1031682: qemu-system-x86: x86 cherrypick break direct kernel boot
cc Jason On Mon, 20 Feb 2023 at 15:22, Michael Tokarev wrote: > > 20.02.2023 16:10, Ard Biesheuvel wrote: > > Package: qemu-system-x86 > > Version: 1:7.2+dfsg-3 > > Severity: normal > > X-Debbugs-Cc: a...@kernel.org > > > > Dear Maintainer, > > > > The latest version of qemu-system-x86 incorporates > > > > x86-don-t-let-decompressed-kernel-image-clobber-setu.patch > > > > which is a cherry pick of a problematic qemu patch, and needs > > to be dropped. > > > > The result is that booting a Linux kernel using OVMF firmware > > and the -kernel command line argument no longer works, and > > instead, other boot options are attempted in turn, which > > generally results in no boot at all, or the wrong boot option > > being chosen. > > In my case, this cherry-pick did the opposite: it allowed me to boot > one of the latest 6.1 kernels in qemu with -kernel which was otherwise > unbootable. Someone else suggested this patch to me, it fixed boot for > them too. > > hwell. > > > Related discussion: > > https://lore.kernel.org/all/20221228143831.396245-1-ja...@zx2c4.com/ > > The whole patch set which introduced the change which is being worked > around in this patch - whole thing should be dropped instead, see > https://lore.kernel.org/all/20230208211212.41951-1-...@redhat.com/ > > I'm not sure what to. It breaks one way or another, and there's no > solution so far. > All my linux-efi jobs in kernelci have started failing for x86 due to a QEMU upgrade to this version, so I would prefer to just revert this patch. It seems everyone on the thread agrees that it is not an improvement. I did not receive any reports regarding v6.1 boot failures on x86: are you booting with OVMF? We added a patch to v6.0 [0] to deal with bogus setup_data when doing EFI boot, so v6.1 should have this change too. Jason, any ideas? [0] commit 63bf28ceb3ebbe76048c3fb2987996ca1ae64f83 Author: Ard Biesheuvel Date: Thu Aug 4 15:39:48 2022 +0200 efi: x86: Wipe setup_data on pure EFI boot
Bug#1031682: qemu-system-x86: x86 cherrypick break direct kernel boot
Package: qemu-system-x86 Version: 1:7.2+dfsg-3 Severity: normal X-Debbugs-Cc: a...@kernel.org Dear Maintainer, The latest version of qemu-system-x86 incorporates x86-don-t-let-decompressed-kernel-image-clobber-setu.patch which is a cherry pick of a problematic qemu patch, and needs to be dropped. The result is that booting a Linux kernel using OVMF firmware and the -kernel command line argument no longer works, and instead, other boot options are attempted in turn, which generally results in no boot at all, or the wrong boot option being chosen. Related discussion: https://lore.kernel.org/all/20221228143831.396245-1-ja...@zx2c4.com/ Regards, Ard. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.1.12+ (SMP w/128 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu-system-x86 depends on: ii ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1 ii libaio1 0.3.113-4 ii libbpf1 1:1.1.0-1 ii libc6 2.36-8 ii libcapstone44.0.2-5 ii libfdt1 1.6.1-4+b1 ii libfuse3-3 3.13.0-2 ii libgcc-s1 12.2.0-14 ii libglib2.0-02.74.5-1 ii libgmp102:6.2.1+dfsg1-1.1 ii libgnutls30 3.7.8-5 ii libhogweed6 3.8.1-2 ii libibverbs1 44.0-2 ii libjpeg62-turbo 1:2.1.5-2 ii libnettle8 3.8.1-2 ii libnuma12.0.16-1 ii libpixman-1-0 0.42.2-1 ii libpmem11.12.1-2 ii libpng16-16 1.6.39-2 ii librdmacm1 44.0-2 ii libsasl2-2 2.1.28+dfsg-10 ii libseccomp2 2.5.4-1+b3 ii libslirp0 4.7.0-1 ii libudev1252.5-2 ii liburing2 2.3-3 ii libvdeplug2 4.0.1-4 ii libzstd11.5.2+dfsg2-3 ii qemu-system-common 1:7.2+dfsg-3 ii qemu-system-data1:7.2+dfsg-3 ii seabios 1.16.0-5 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages qemu-system-x86 recommends: ii ovmf 2022.11-2 ii qemu-block-extra 1:7.2+dfsg-3 ii qemu-system-gui 1:7.2+dfsg-3 ii qemu-utils1:7.2+dfsg-3 Versions of packages qemu-system-x86 suggests: pn samba pn vde2 -- no debconf information
Bug#1026092: grub-efi-arm64: grub2 needs a backport to support EFI zboot
Package: grub-efi-arm64 Version: 2.06-5 Severity: wishlist X-Debbugs-Cc: a...@kernel.org Dear Maintainer, Linux 6.1 and later implement a EFI bootable compressed format called zboot, which does not carry the 'arm64 bare metal boot' magic number because it is EFI-only and cannot be booted in bare metal mode unless the bare metal loader knows how to decode the header and perform the decompression itself. None of this is relevant to GRUB, as it is pure EFI based on arm64. However, it used to check the magic number nonetheless, rejecting these EFI zboot images for no good reason. This is fixed in GRUB upstream by https://git.savannah.gnu.org/cgit/grub.git/commit/?id=69edb31205602c29293a8c6e67363bba2a4a1e66 Please consider this change for backporting to Debian's GRUB so arm64 builds can boot the EFI zboot images. Kind regards and merry christmas,
Bug#1016359: [edk2-devel] [Patch 1/2] OvmfPkg: Change default to disable MptScsi and PvScsi
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. > > On the other hand, I've got to say I use virtio-scsi in all > > my VM testing environments, > > Same here ;) > > take care, > Gerd >
Bug#1016359: [edk2-devel] [Patch 1/2] OvmfPkg: Change default to disable MptScsi and PvScsi
On Wed, 7 Dec 2022 at 08:41, Gerd Hoffmann wrote: > > Hi, > > > A patch mentioned above set MPT_SCSI_ENABLE=FALSE, that removed > > support for LSI 53C1030 and SAS1068. > > These SCSI controllers were emulated by VMware, Parallels and I guess > > VitualBox. > > This is generic setup for VMware VMs, as far as I remember. > > So the booting of such VMs (probably migrated from VMware and others) > > was definitely broken. > > Yes. Problem is there is no maintainer for the driver. There used to > be one, but the email address started bouncing. So we updated > Maintainers.txt and flipped the switch to not build the unmaintained > drivers by default. > > If debian is fine with shipping unmaintained software to its users you > can flip the config switches of course, at least as long as the drivers > are still in the tree. The drivers are at risk of being removed though > in case we don't find a new maintainer within a year or two. > Indeed. These options can be set from the command line when building the image, so the distro wrapper scripts can just en/disable the features they desire. As for maintenance: indeed, lack of maintainership generally also means lack of testing coverage, and if something breaks, we won't notice, and if we do, we may not be able to fix it without running the risk of breaking something else. So at some point, these drivers will be removed rather than kept alive by the core team unless someone steps up.
Bug#1013448: pcre2 relies on write+execute mappings unnecessarily
Source: pcre2 Version: 10.36-2 Severity: important X-Debbugs-Cc: a...@kernel.org Dear Maintainer, Currently, pcre2 is built in a mode where its JIT uses memory mappings that are writable and executable at the same time, which is unsafe and unnecessary. Instead, it is possible to enable a different allocator that uses separate mappings for the same allocation, one with read/write and one with read/executable mappings, the placement of which is randomized in the process's virtual address space, making abuse much harder. Please consider applying the change below to switch all 64-bit architectures to the alternative allocator. 32-bit architectures are far more likely to run out of virtual address space, so there, we should probably stick with the original allocator. --- a/debian/rules +++ b/debian/rules @@ -15,6 +15,10 @@ deb_maint_conf_args = --enable-pcre2-16 --enable-pcre2-32 --disable-pcre2grep-ca #enable JIT only on architectures that support it (see pcre2jit.3) ifneq ($(filter i386 amd64 armel armhf mips mipsel mips64el powerpc sparc arm64 ppc64 ppc64el s390x, $(DEB_HOST_ARCH)),) deb_maint_conf_args +=--enable-jit +ifneq ($(DEB_HOST_ARCH_BITS),32) +#the W^X allocator is safer but uses more virtual address space, so enable it on 64-bit arches only +deb_maint_conf_args +=--enable-jit-sealloc +endif -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.18.4+ (SMP w/128 CPU threads; PREEMPT) Kernel taint flags: TAINT_DIE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1012791: x264: armhf build of libx264.so has executable stack enabled
Package: x264 Severity: important X-Debbugs-Cc: a...@kernel.org Dear Maintainer, When building x264 for the armhf architecture, the resulting package contains a build of libx264.so that has a PT_GNU_STACK ELF program header that identifies the shared object as requiring an executable stack. This is a bad idea from security pov, and only seems to affect the armhf build (the arm64 build is fine). -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.18.3-wxn+ (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages x264 depends on: ii libavcodec58 7:4.3.4-0+deb11u1 ii libavformat58 7:4.3.4-0+deb11u1 ii libavutil567:4.3.4-0+deb11u1 ii libc6 2.31-13+deb11u3 pn libffms2-4 pn libgpac10 ii libswscale57:4.3.4-0+deb11u1 ii libx264-1602:0.160.3011+gitcde9a93-2.1 x264 recommends no packages. x264 suggests no packages.
Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel
On Tue, 23 Nov 2021 at 06:12, Salvatore Bonaccorso wrote: > > Hi Vincent, > > On Fri, Nov 19, 2021 at 10:04:57PM +0100, Vincent Blut wrote: > > Hi, > > > > Le 2021-10-26 17:33, Zameer Manji a écrit : > > > On Tue, Oct 26, 2021 at 5:05 PM Vincent Blut > > > wrote: > > > > > > > Control: reassign -1 src:linux > > > > > > > > Hi, > > > > > > > > Le 2021-10-26 20:44, Zameer Manji a écrit : > > > > > Package: linux-image-arm64 > > > > > Version: 5.14.9-2 > > > > > Severity: important > > > > > > > > > > Dear Maintainer, > > > > > > > > > > In bullseye, version 5.10.70-1 has the > > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER > > > > > kernel configuration set to 'y'. In bookworm it is unset which disable > > > > this feature. > > > > > > > > > > This kernel configuration parameter allows for the EFI stub of the > > > > kernel to > > > > > parse and use a 'initrd=' parameter to set up an initrd when booting > > > > from EFI. > > > > > Boot loaders like 'systemd-boot' or 'refind' set this parameter if > > > > configured > > > > > to pass an initrd. If the kernel configuration parameter is unset, the > > > > > `initrd=` paramater is ignored, and can result in an unbootable system > > > > because > > > > > the initrd has not setup the root filesystem. > > > > > > > > > > Without the kernel configuaration set, it is not possible to use > > > > 'systemd-boot' > > > > > or 'refind' on arm64 as both of these bootloaders assume the kernel > > > > > will > > > > > handle the 'initrd=' flag and setup the initrd. > > > > > > > > > > Please consider enabling > > > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on > > > > > arm64 so using 'systemd-boot' or 'refind' can continue to work. Until > > > > these > > > > > bootloaders have been updated to use an alternative method of passing > > > > > the > > > > > initrd to the EFI stub, it is not possible to have a booting system. > > > > > > > > Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer > > > > enabled > > > > by > > > > default. Please see [1] for some details. > > > > > > > > Cheers, > > > > Vincent > > > > > > > > [1] > > > > https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a > > > > > > > > > > Hello Vincent, > > > > > > I see and understand the rationale of upstream to deprecate this > > > functionality. > > > >From the commit you linked I see another commit [0] which says: > > > > > > > Loading an initrd passed via the kernel command line is deprecated: it > > > > is limited to files that reside in the same volume as the one the kernel > > > > itself was loaded from, and we have more flexible ways to achieve the > > > > same. So make it configurable so new architectures can decide not to > > > > enable it. > > > > > > I assume the 'more flexible ways' to do the same is referencing this > > > feature [1] > > > which is indeed more flexible. The problem is that the firmware/bootloader > > > must > > > support this new functionality, by populating the right EFI file with the > > > right GUID. > > > > > > As far as I can see on arm64 there are three EFI bootloaders: > > > * GRUB2 > > > * systemd-boot > > > * refind > > > > > > Both systemd-boot and refind do not yet support this new mechanism, > > > although I see > > > that systemd has some unreleased code [2] to support the new way. I have > > > not been > > > able to test GRUB2 but my understanding is that this new method is still > > > under active > > > development [3]. > > > > > > The problem is that upstream has deprecated this functionality by assuming > > > the only > > > active use was x86, but was completely possible to use it on arm64 (it > > > works fine for me > > > on bullseye). Since EFI bootloaders have not yet implemented the new way, > > > and still > > > rely on this deprecated method on all architectures, it results in > > > unbootable systems > > > on arm64. > > > > > > I would 100% think this should remain disabled on arm64 if most EFI > > > bootloaders > > > supported the new way, but unfortunately they do not. > > > > > > I hope you would consider enabling this kernel configuration for arm64 > > > until EFI > > > bootloaders catch up to the recommended way. > > > > > > > > > [0] > > > https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5 > > > [1] > > > https://gitlab.com/linux-kernel/stable/-/commit/ec93fc371f014a6fb483e3556061ecad4b40735c > > > [2] > > > https://github.com/systemd/systemd/commit/a6089431d52adda93eec251a3df0dffa1fe0661a#diff-76eb4030e88f340c9133388f17c65774b0f17a0a8105500978f6ce18ca1deb5a > > > [3] https://www.mail-archive.com/grub-devel@gnu.org/msg32272.html > > > > Salvatore, I tend to agree with Zameer. I think we should explicitly enable > > EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER until the support for loading initrd > > from a device path is widespread among bootloaders. > > Yeah I guess it makes sense and understand. Before doing the switch > and re-enabling it explic
Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON
On Sat, 16 Jan 2021 at 18:27, Ard Biesheuvel wrote: > > On Sat, 16 Jan 2021 at 18:24, Diederik de Haas wrote: > > > > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote: > > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64 builds > > > > Is there a reason why it shouldn't be included in armhf builds? If not, then > > I'd like to see it enabled there too. > > (And possibly in linux-image-rpi on armel as well?) > > Agreed for armhf, assuming CONFIG_CRYPTO_ADIANTUM is already enabled > on those platforms too. For armel, it depends on whether kernel mode > NEON is already enabled in the first place. This is enabled now for armhf but not for arm64: linux-signed-arm64 (5.10.9+1) unstable; urgency=medium ... * [arm] Enable CRYPTO_NHPOLY1305_NEON. (closes: #980214)
Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON
On Sat, 16 Jan 2021 at 18:24, Diederik de Haas wrote: > > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote: > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64 builds > > Is there a reason why it shouldn't be included in armhf builds? If not, then > I'd like to see it enabled there too. > (And possibly in linux-image-rpi on armel as well?) Agreed for armhf, assuming CONFIG_CRYPTO_ADIANTUM is already enabled on those platforms too. For armel, it depends on whether kernel mode NEON is already enabled in the first place.
Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON
Package: src:linux Version: 5.10.4-1 Severity: normal Dear Maintainer, Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64 builds of the Linux kernel. This allows platforms that do not support AES instructions (such as Raspberry Pi 3/4) to enable efficient block device encryption, using the 'adiantum' template. Kind regards, Ard. -- Package-specific info: ** Version: Linux version 5.10.0-1-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-3) 10.2.1 20201224, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.4-1 (2020-12-31) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-1-arm64 root=UUID=62fa7565-f531-4b0f-9311-59cb70ba2c93 ro quiet ** Not tainted ** Kernel log: [3.87] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10 [3.822239] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.822247] usb usb1: Product: xHCI Host Controller [3.822254] usb usb1: Manufacturer: Linux 5.10.0-1-arm64 xhci-hcd [3.822261] usb usb1: SerialNumber: PNP0D10:00 [3.822910] hub 1-0:1.0: USB hub found [3.822979] hub 1-0:1.0: 1 port detected [3.823542] xhci-hcd PNP0D10:00: xHCI Host Controller [3.823572] xhci-hcd PNP0D10:00: new USB bus registered, assigned bus number 2 [3.823591] xhci-hcd PNP0D10:00: Host supports USB 3.0 SuperSpeed [3.823752] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [3.823936] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.10 [3.823945] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.823953] usb usb2: Product: xHCI Host Controller [3.823960] usb usb2: Manufacturer: Linux 5.10.0-1-arm64 xhci-hcd [3.823966] usb usb2: SerialNumber: PNP0D10:00 [3.824623] hub 2-0:1.0: USB hub found [3.824677] hub 2-0:1.0: 4 ports detected [3.838859] bcmgenet BCM6E4E:00 enabcm6e4ei0: renamed from eth0 [4.157943] usb 1-1: new high-speed USB device number 2 using xhci-hcd [4.312580] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.21 [4.312595] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [4.312603] usb 1-1: Product: USB2.0 Hub [4.314265] hub 1-1:1.0: USB hub found [4.314540] hub 1-1:1.0: 4 ports detected [4.438232] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd [4.460809] usb 2-2: New USB device found, idVendor=18a5, idProduct=0237, bcdDevice= 5.10 [4.460819] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [4.460827] usb 2-2: Product: Portable USB 3.0 Drive [4.460835] usb 2-2: Manufacturer: Verbatim [4.460842] usb 2-2: SerialNumber: 1407010003245394 [4.498931] SCSI subsystem initialized [4.513467] usb-storage 2-2:1.0: USB Mass Storage device detected [4.514813] scsi host0: usb-storage 2-2:1.0 [4.515356] usbcore: registered new interface driver usb-storage [4.520563] usbcore: registered new interface driver uas [4.673929] libphy: bcmgenet MII bus: probed [4.673945] unimac-mdio unimac-mdio: Broadcom UniMAC MDIO bus [5.535323] scsi 0:0:0:0: Direct-Access Samsung SSD 850 PRO EXM0 PQ: 0 ANSI: 6 [5.556933] sd 0:0:0:0: [sda] 500118188 512-byte logical blocks: (256 GB/238 GiB) [5.557351] sd 0:0:0:0: [sda] Write Protect is off [5.557362] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00 [5.557768] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [5.576531] sda: sda1 sda2 [5.578991] sd 0:0:0:0: [sda] Attached SCSI disk [5.612373] random: fast init done [6.084383] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [6.358453] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [6.530927] systemd[1]: Inserted module 'autofs4' [6.593403] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) [6.594215] systemd[1]: Detected architecture arm64. [6.622998] systemd[1]: Set hostname to . [7.062138] random: systemd: uninitialized urandom read (16 bytes read) [7.067659] random: systemd: uninitialized urandom read (16 bytes read) [7.071927] systemd[1]: Created slice system-systemd\x2dfsck.slice. [7.072502] random: systemd: uninitialized urandom read (16 bytes read) [7.072985] systemd[1]: Listening on Journal Audit Socket. [7.073615] systemd[1]: Listening on Journal Socket (/dev/log). [7.075141] systemd[1]: Created slice system-serial\x2dgetty.slice. [7.076570] systemd[1]: Created slice User and Session Slice. [7.076698] systemd[1]: Reached target Slices. [7.077261] systemd[1]: Listening on udev Kernel Socket. [7.230826] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro [7
Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config
Hello Diederik, On Fri, 11 Dec 2020 at 12:21, Diederik de Haas wrote: > > On Sun, 06 Dec 2020 09:34:36 +0100 Ard Biesheuvel wrote: > > Currently, arm64 kernel packages are built with the following Kconfig > > symbols > unset: > > > > # CONFIG_CRYPTO_SHA512_ARM64 is not set > > # CONFIG_CRYPTO_SHA512_ARM64_CE is not set > > # CONFIG_CRYPTO_SHA3_ARM64 is not set > > # CONFIG_CRYPTO_SM3_ARM64_CE is not set > > # CONFIG_CRYPTO_SM4_ARM64_CE is not set > > # CONFIG_CRYPTO_CRCT10DIF_ARM64_CE is not set > > # CONFIG_CRYPTO_AES_ARM64_NEON_BLK is not set > > # CONFIG_CRYPTO_AES_ARM64_BS is not set > > > > Please consider enabling these as modules. The latter two are especially > relevant, given that scalar AES is susceptible to known-plaintext attacks on > the key due to the fact that it is not time invariant. While most arm64 SoCs > implement the AES instructions and therefore don't rely on these modules, > notable SoCs such as the Raspberry Pi 3 and 4 can only use the NEON version > which is not enabled here. (And on these platforms, these are substantially > faster too) > > Are you the same Ard Biesheuvel that 'Signed-off-by' the patch in: > https://salsa.debian.org/kernel-team/linux/-/commit/ > 8332600d1188a6d1fc835dfcd392a20f6bfc > Presumably, yes. But I cannot access that link. > In that commit a bunch of crypto modules got enabled, but (explicitly) not > CONFIG_CRYPTO_AES_ARM64_NEON_BLK. Do you recall why that happened? (I realize > it's from 2014) > There's an important difference between an 'oversight' and explicitly > disabling > a module and I'd like to have a clarification wrt that. > This code was written before any hardware existed, and at the time, it was not obvious whether it would perform well enough. Six years later, we know that this code works fine, and is faster (and safer!) than any of the non-NEON alternatives. (On Raspberry Pi 3, the non-NEON AES takes 31.5 cycles per byte, whereas the NEON code takes around 22 cycles per byte)
Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config
Package: linux-image-arm64 Version: 5.9.6-1~bpo10+1 Severity: important Dear Maintainer, Currently, arm64 kernel packages are built with the following Kconfig symbols unset: # CONFIG_CRYPTO_SHA512_ARM64 is not set # CONFIG_CRYPTO_SHA512_ARM64_CE is not set # CONFIG_CRYPTO_SHA3_ARM64 is not set # CONFIG_CRYPTO_SM3_ARM64_CE is not set # CONFIG_CRYPTO_SM4_ARM64_CE is not set # CONFIG_CRYPTO_CRCT10DIF_ARM64_CE is not set # CONFIG_CRYPTO_AES_ARM64_NEON_BLK is not set # CONFIG_CRYPTO_AES_ARM64_BS is not set Please consider enabling these as modules. The latter two are especially relevant, given that scalar AES is susceptible to known-plaintext attacks on the key due to the fact that it is not time invariant. While most arm64 SoCs implement the AES instructions and therefore don't rely on these modules, notable SoCs such as the Raspberry Pi 3 and 4 can only use the NEON version which is not enabled here. (And on these platforms, these are substantially faster too) -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.9.0-0.bpo.2-arm64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-arm64 depends on: ii linux-image-5.9.0-0.bpo.2-arm64 5.9.6-1~bpo10+1 linux-image-arm64 recommends no packages. linux-image-arm64 suggests no packages. -- no debconf information
Bug#948285: linux-image-4.19.0-6-arm64: please enable CONFIG_TCG_TIS for TPM support
Package: src:linux Version: 4.19.67-2+deb10u2 Severity: wishlist Dear Maintainer, The current buster kernel for arm64 lacks the TPM TIS module, which means it cannot use TPM based disk encryption using MMIO based TPM2 modules, which is for instance what QEMU emulates, and what TPM enabled versions of the SynQuacer platform implement. So please consider enabling CONFIG_TCG_TIS as a module for upcoming builds of the arm64 buster kernel. Thanks, Ard. -- Package-specific info: ** Version: Linux version 4.19.0-6-arm64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-arm64 root=UUID=dc66b395-cdab-4e57-bf1f-a47424c22356 ro quiet ** Not tainted ** Kernel log: [6.369402] EFI Variables Facility v0.08 2004-May-17 [6.369556] sbsa-gwdt sbsa-gwdt.0: Initialized with 10s timeout @ 25000 Hz, action=0. [6.371101] iommu: Adding device AMDI8001:00 to group 3 [6.372295] amd-xgbe AMDI8001:00 eth0: net device enabled [6.372372] iommu: Adding device AMDI8001:01 to group 4 [6.373313] amd-xgbe AMDI8001:01 eth1: net device enabled [6.375529] input: Apple Inc. Apple Keyboard as /devices/pci:00/:00:02.1/:01:00.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:05AC:024F.0002/input/input1 [6.376687] pstore: Using compression: deflate [6.376937] amd-xgbe AMDI8001:01 enaamdi8001i1: renamed from eth1 [6.379768] pstore: Registered efi as persistent store backend [6.394731] cryptd: max_cpu_qlen set to 1000 [6.402817] iommu: Adding device :02:00.1 to group 0 [6.402964] snd_hda_intel :02:00.1: enabling device ( -> 0002) [6.402971] snd_hda_intel :02:00.1: Force to snoop mode by module option [6.408829] amd-xgbe AMDI8001:00 enaamdi8001i0: renamed from eth0 [6.424808] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:02.2/:02:00.1/sound/card0/input2 [6.436839] apple 0003:05AC:024F.0002: input,hidraw1: USB HID v1.11 Keyboard [Apple Inc. Apple Keyboard] on usb-:01:00.0-1.2/input0 [6.437222] input: Apple Inc. Apple Keyboard as /devices/pci:00/:00:02.1/:01:00.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:05AC:024F.0003/input/input3 [6.496678] apple 0003:05AC:024F.0003: input,hidraw2: USB HID v1.11 Device [Apple Inc. Apple Keyboard] on usb-:01:00.0-1.2/input1 [6.521677] Adding 781308k swap on /dev/sda3. Priority:-2 extents:1 across:781308k SSFS [6.575867] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null) [6.655568] audit: type=1400 audit(1578038684.964:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=500 comm="apparmor_parser" [6.656045] audit: type=1400 audit(1578038684.964:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=495 comm="apparmor_parser" [6.656505] audit: type=1400 audit(1578038684.964:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=497 comm="apparmor_parser" [6.656634] audit: type=1400 audit(1578038684.968:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=501 comm="apparmor_parser" [6.656640] audit: type=1400 audit(1578038684.968:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=501 comm="apparmor_parser" [6.658207] audit: type=1400 audit(1578038684.968:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" pid=502 comm="apparmor_parser" [6.659469] audit: type=1400 audit(1578038684.968:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=504 comm="apparmor_parser" [6.659474] audit: type=1400 audit(1578038684.968:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=504 comm="apparmor_parser" [6.659478] audit: type=1400 audit(1578038684.968:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=504 comm="apparmor_parser" [6.660845] audit: type=1400 audit(1578038684.972:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/cups/backend/cups-pdf" pid=498 comm="apparmor_parser" [7.364023] IPv6: ADDRCONF(NETDEV_UP): enaamdi8001i0: link is not ready [7.406593] IPv6: ADDRCONF(NETDEV_UP): enaamdi8001i0: link is not ready [7.411687] IPv6: ADDRCONF(NETDEV_UP): enaamdi8001i1: link is not ready [7.449215] IPv6: ADDRCONF(NETDEV_UP): enaamdi8001i1: link is not ready [8.420522] amd-xgbe AMDI8001:00 enaamdi8001i0: Link is Up - 1Gbps/Full - flow control off [8.420540] IPv6: ADDRCONF(NETDEV_CHANGE): enaamdi8001i0: link becomes ready [ 13.456021] random: crng init done [ 13.456025] random: 7 urandom warning(s) missed due to ratelimiting [ 46.811694] fuse init (AP
Bug#948137: clevis-dracut: clevis-hook.sh uses a x86 specific path which breaks other architectures
Package: clevis-dracut Version: 11-2 Severity: important Dear Maintainer, clevis-dracut includes a script clevis-hook.sh that refers to the clevis-luks-askpass executable by its full path /usr/lib/x86_64-linux-gnu/clevis-luks-askpass which is obviously only valid on x86 machines. This makes the package unusable on arm64 machines, or any other architecture for that matter. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.4.0+ (SMP w/24 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages clevis-dracut depends on: ii clevis-systemd 11-2 ii dracut-network 048+80-2 clevis-dracut recommends no packages. clevis-dracut suggests no packages. -- no debconf information
Bug#948135: dracut: crypto modules are omitted due to missing arm64 alias
Package: dracut Version: 048+80-2 Severity: important Dear Maintainer, The following line needs to be added to modules.d/90crypt/module-setup.sh in order for arm64 specific crypto modules to be included in the initrd (line 31)[[ $arch == aarch64 ]] && arch=arm64 Without this, the kernel may not be able to mount the encrypted root filesystem, resulting in boot failures. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.4.0+ (SMP w/24 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages dracut depends on: ii dracut-core 048+80-2 dracut recommends no packages. Versions of packages dracut suggests: ii dracut-network 048+80-2 -- no debconf information
Bug#923723: Acknowledgement (linux: amdgpu/radeon driver optimization is broken on ARM/arm64)
The patch has been backported, and was released as part of v4.19.29
Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt
On Mon, 8 Apr 2019 at 02:07, wrote: > > Would you be able to check if this also affects fwupd? The fwupdate binary > was also merged into that project a while back and I would suspect it's > affecting both. > I've had a report that Fedora's version of the fwupdmgr .efi helper is broken, but looking at the binary [0], it appears to be a different problem. PE header starts at 0x40 'PE' 0040 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00 0050 01 00 00 00 a0 00 06 02 0b 02 02 14 00 a0 00 00 0060 00 1c 00 00 00 00 00 00 00 10 00 00 00 10 00 00 0070 00 00 00 00 00 00 00 00 00 10 00 00 00 02 00 00 The section alignment and file alignment are at offsets 0x78 and 0x7c, respectively, so 0x1000 and 0x200 which looks fine. 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090 00 cc 00 00 00 10 00 00 00 00 00 00 0a 00 00 00 Total file size at 0x90, which is 0xcc00 00f0 00 00 00 00 00 00 00 00 2e 74 65 78 74 00 00 00 |.text...| 0100 00 a0 00 00 00 10 00 00 00 a0 00 00 00 10 00 00 || Size and offset of .text section at 0x100 and 0x104: 0xa000 bytes @ 0x1000 0120 2e 64 61 74 61 00 00 00 00 1c 00 00 00 b0 00 00 |.data...| Size and offset of .data section at 0x128 and 0x12c: 0x1c00 bytes @ 0xb000, which brings the total file size to 0xcc00 just like in the main header. [0] http://people.linaro.org/~ard.biesheuvel/fwupdaa64.efi-f29 > -Original Message- > From: Ard Biesheuvel > Sent: Sunday, April 7, 2019 10:46 PM > To: Debian Bug Tracking System > Subject: Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt > > > [EXTERNAL EMAIL] > > Package: fwupdate > Version: 12-4 > Severity: important > > Dear Maintainer, > > Version 12-4 of fwupdate is broken for arm64. The included binary > fwupaa64.efi is corrupt, resulting in EFI_LOAD_ERROR to be returned by the > firmware when trying to invoke it. > > The binary layout looks like this: > > Detected 'AArch64' type PE/COFF image consisting of 2 sections Section > alignment: 0x1000 File alignment: 0x200 Image size: 0xd890 Section '.text' @ > 0x1000 File offset: 0x1000 Virtual size: 0xac20 Raw size: 0xac20 Section > '.data' @ 0xbc20 File offset: 0xbc20 Virtual size: 0x1d70 Raw size: 0x1d70 > > Note that file offset + size of section #2 exceeds the total image size. But > the file offset of that section is not even a multiple of the file alignment, > so the whole image seems pretty broken. > > > > -- System Information: > Debian Release: 9.8 > APT prefers stable > APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') > Architecture: arm64 (aarch64) > > Kernel: Linux 5.1.0-rc2+ (SMP w/24 CPU cores; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages fwupdate depends on: > ii e2fsprogs1.43.4-2 > ii efibootmgr 14-2 > ii libc62.28-8 > ii libefiboot1 37-2 > ii libefivar1 37-2 > ii libfwup1 12-4 > ii libpopt0 1.16-10+b2 > > Versions of packages fwupdate recommends: > ii fwupdate-arm64-signed [fwupdate-signed] 12+4 > > fwupdate suggests no packages. > > -- no debconf information >
Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt
Package: fwupdate Version: 12-4 Severity: important Dear Maintainer, Version 12-4 of fwupdate is broken for arm64. The included binary fwupaa64.efi is corrupt, resulting in EFI_LOAD_ERROR to be returned by the firmware when trying to invoke it. The binary layout looks like this: Detected 'AArch64' type PE/COFF image consisting of 2 sections Section alignment: 0x1000 File alignment: 0x200 Image size: 0xd890 Section '.text' @ 0x1000 File offset: 0x1000 Virtual size: 0xac20 Raw size: 0xac20 Section '.data' @ 0xbc20 File offset: 0xbc20 Virtual size: 0x1d70 Raw size: 0x1d70 Note that file offset + size of section #2 exceeds the total image size. But the file offset of that section is not even a multiple of the file alignment, so the whole image seems pretty broken. -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.1.0-rc2+ (SMP w/24 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fwupdate depends on: ii e2fsprogs1.43.4-2 ii efibootmgr 14-2 ii libc62.28-8 ii libefiboot1 37-2 ii libefivar1 37-2 ii libfwup1 12-4 ii libpopt0 1.16-10+b2 Versions of packages fwupdate recommends: ii fwupdate-arm64-signed [fwupdate-signed] 12+4 fwupdate suggests no packages. -- no debconf information
Bug#924456: linux-image-4.19.0-2-arm64: please enable accelerated arm64 crypto drivers
Package: src:linux Version: 4.19.16-1 Severity: normal Dear Maintainer, Please consider enabling the following Kconfig options for arm64 kernels CONFIG_CRYPTO_SHA256_ARM64=m CONFIG_CRYPTO_SHA512_ARM64=m CONFIG_CRYPTO_SHA512_ARM64_CE=m CONFIG_CRYPTO_SHA3_ARM64=m CONFIG_CRYPTO_SM3_ARM64_CE=m CONFIG_CRYPTO_SM4_ARM64_CE=m CONFIG_CRYPTO_AES_ARM64=m CONFIG_CRYPTO_AES_ARM64_NEON_BLK=m CONFIG_CRYPTO_CHACHA20_NEON=m CONFIG_CRYPTO_NHPOLY1305_NEON=m CONFIG_CRYPTO_AES_ARM64_BS=m and if appropriate CONFIG_CRYPTO_CRCT10DIF_ARM64_CE=m (which depends on whether T10DIF support is enabled) Note that in the case of AES, this is not just a matter of performance - NEON and bit sliced AES routines implement the AES cipher in a time invariant matter, and so without them, arm64 CPUs that do not implement the crypto extensions (such as the Raspberry Pi3) are forced to fall back on the generic, table based C implementation. -- Package-specific info: ** Kernel log: boot messages should be attached -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.0.1+ (SMP w/8 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.19.0-2-arm64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.133 ii kmod26-1 ii linux-base 4.5 Versions of packages linux-image-4.19.0-2-arm64 recommends: ii apparmor 2.13.2-9 pn firmware-linux-free pn irqbalance Versions of packages linux-image-4.19.0-2-arm64 suggests: pn debian-kernel-handbook pn linux-doc-4.19 Versions of packages linux-image-4.19.0-2-arm64 is related to: ii firmware-amd-graphics 20190114-1 pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#924453: linux-image-4.19.0-2-arm64: please enable driver for AMD Seattle RNG
Package: src:linux Version: 4.19.16-1 Severity: normal Dear Maintainer, Please enable the following Kconfig options in the arm64 kernels: CONFIG_CRYPTO_DEV_CCP=y CONFIG_CRYPTO_DEV_CCP_DD=m CONFIG_CRYPTO_DEV_SP_CCP=y CONFIG_CRYPTO_DEV_CCP_CRYPTO=m This is needed to gain access to the crypto accelerator in the ARM Seattle arm64 SoC, which also implements the platform's random number generator. Since the platform does not have any other entropy sources, the lack of access to the on-SoC RNG causes boot delays, SSH logins that time out etc etc -- Package-specific info: ** Kernel log: boot messages should be attached -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.0.1+ (SMP w/8 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.19.0-2-arm64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.133 ii kmod26-1 ii linux-base 4.5 Versions of packages linux-image-4.19.0-2-arm64 recommends: ii apparmor 2.13.2-9 pn firmware-linux-free pn irqbalance Versions of packages linux-image-4.19.0-2-arm64 suggests: pn debian-kernel-handbook pn linux-doc-4.19 Versions of packages linux-image-4.19.0-2-arm64 is related to: ii firmware-amd-graphics 20190114-1 pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#922680: efivar: Debug code is buggy and may corrupt the stack, causing segfaults
Source: efivar
Version: 37
Severity: important
Dear Maintainer,
the efivar source package contains buggy diagnostics printing code, which may
corrupt the stack and cause crashes.
The culprit is the arrow() macro defined in src/util.h, which pokes a couple of
^ characters into a buffer consisting of spaces, in order to point out the
interesting parts of an output string appearing on the previous line. The
string indexing done by the macro may result in ^ or space characters to be
written outside of the allocated buffer, and since the buffer is typically
allocated on the stack, this may corrupt control flow as well as other data.
I have reported the issue here: https://github.com/rhboot/efivar/issues/124
Since we can drop this feature without any loss of functionality, the patch
below is my proposed solution for the time being, while the issue gets
addressed upstream.
--- src/util.h.orig 2019-02-19 12:05:56.620746098 +0100
+++ src/util.h 2019-02-19 12:06:06.265005068 +0100
@@ -379,7 +379,7 @@
#undef log
#endif
#define log(level, fmt, args...) log_(__FILE__, __LINE__, __func__, level,
fmt, ## args)
-#define arrow(l,b,o,p,n,m) ({if(n==m){char c_=b[p+1]; b[o]='^';
b[p+o]='^';b[p+o+1]='\0';log(l,"%s",b);b[o]=' ';b[p+o]=' ';b[p+o+1]=c_;}})
+#define arrow(l,b,o,p,n,m)
#define debug(fmt, args...) log(LOG_DEBUG, fmt, ## args)
#endif /* EFIVAR_UTIL_H */
-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf
Kernel: Linux 4.20.10+ (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#922204: linux-image-4.19.0-3-armmp-lpae: Kernel mode NEON support should be enabled
Package: linux-image-4.19.0-3-armmp-lpae Severity: important Dear Maintainer, Currently, the 32-bit ARM kernels are built without support for kernel mode NEON, which means that none of the modules that depend on it are built either. This mostly affects crypto drivers, as well as RAID6 and XOR. This is mostly a performance problem, although the fact that the non-NEON AES is not time invariant implies that systems may be susceptible to cache timing attacks needlessly. Note that there is also a runtime check, so even with CONFIG_KERNEL_MODE_NEON=y, systems without a NEON implementation will still run as before. The XOR and RAID6 code will automatically be built with NEON support once the CONFIG_KERNEL_MODE_NEON option is set. For the crypto part, the following ones should be set to =m as well. (The CE ones rely on ARMv8 crypto instructions so they are not as relevant, but they can easily be enabled at the same time) config CRYPTO_SHA1_ARM_NEON config CRYPTO_AES_ARM_BS config CRYPTO_CHACHA20_NEON config CRYPTO_SHA1_ARM_CE config CRYPTO_SHA2_ARM_CE config CRYPTO_AES_ARM_CE config CRYPTO_GHASH_ARM_CE config CRYPTO_CRCT10DIF_ARM_CE config CRYPTO_CRC32_ARM_CE Note that this applies equally to the non-LPAE configuration. -- System Information: Debian Release: 9.7 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.0.0-rc6+ (SMP w/24 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#920866: linux-source-4.19: arm64 kernel should have workaround for ARM Cortex-A53 erratum 843419 enabled
Package: linux-source-4.19 Severity: important Dear Maintainer, Currently, the linux-image-arm64 kernel is built with CONFIG_ARM64_ERRATUM_843419 explicitly disabled, while it defaults to on in the Kconfig definition. The GCC toolchain enables a link time workaround for this erratum, and so all fully linked binaries such as userland executables and shared libraries, as well as the core kernel (vmlinux), are built with mitigations that prevent this erratum from being triggered. However, kernel modules are not fully linked binaries (they are partially linked object files), and so without this CONFIG option enabled, the resulting modules may trigger the erratum and crash or corrupt data (or both). Note that the Cortex-A53 used in the Raspberry Pi 3 is affected by this erratum. So please enable CONFIG_ARM64_ERRATUM_843419. -- System Information: Debian Release: 9.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.0.0-rc4+ (SMP w/24 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-source-4.19 depends on: ii binutils 2.28-5 ii xz-utils 5.2.2-1.2+b1 Versions of packages linux-source-4.19 recommends: ii bc1.06.95-9+b3 ii gcc 4:6.3.0-4 ii libc6-dev [libc-dev] 2.24-11+deb9u3 pn linux-config-4.19 ii make 4.1-9.1 Versions of packages linux-source-4.19 suggests: ii libncurses5-dev [ncurses-dev] 6.0+20161126-1+deb9u2 pn libqt4-dev ii pkg-config 0.29-4+b1
Bug#917608: linux-image-4.19.0-1-armmp-lpae: Please enable kernel-mode NEON
Package: src:linux Version: 4.19.12-1 Severity: important Dear Maintainer, Please enable CONFIG_KERNEL_MODE_NEON, at least for the LPAE version. This will automatically enable code paths for the XOR and RAID drivers, and permit the various accelerated crypto drivers in arch/arm/crypto to be enabled as well, including the ones that use special crypto instructions, which are typically 5x - 20x faster (depending on the particular algorithm) -- Package-specific info: ** Version: Linux version 4.19.0-1-armmp-lpae (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-12)) #1 SMP Debian 4.19.12-1 (2018-12-22) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-armmp-lpae root=UUID=aaabcf58-4f83-485b-9461-15abd2fd4437 ro quiet ** Not tainted ** Kernel log: ** Model information [6.007886] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [6.007890] usb usb2: Product: xHCI Host Controller [6.007895] usb usb2: Manufacturer: Linux 4.19.0-1-armmp-lpae xhci-hcd [6.007900] usb usb2: SerialNumber: :00:01.0 [6.008357] hub 2-0:1.0: USB hub found [6.008447] hub 2-0:1.0: 4 ports detected [6.061319] virtio_blk virtio0: [vda] 67108864 512-byte logical blocks (34.4 GB/32.0 GiB) [6.063807] vda: vda1 vda2 [6.066318] virtio_net virtio1 enp0s3: renamed from eth0 [6.289595] EXT4-fs (vda2): mounted filesystem with ordered data mode. Opts: (null) [6.349208] usb 1-1: new high-speed USB device number 2 using xhci_hcd [6.466139] random: fast init done [6.499430] usb 1-1: New USB device found, idVendor=0627, idProduct=0001, bcdDevice= 0.00 [6.499439] usb 1-1: New USB device strings: Mfr=1, Product=4, SerialNumber=5 [6.499444] usb 1-1: Product: QEMU USB Keyboard [6.499449] usb 1-1: Manufacturer: QEMU [6.499453] usb 1-1: SerialNumber: 42 [6.629264] usb 1-2: new high-speed USB device number 3 using xhci_hcd [6.629836] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) [6.629941] systemd[1]: Detected virtualization kvm. [6.629960] systemd[1]: Detected architecture arm. [6.641065] systemd[1]: Set hostname to . [6.778423] usb 1-2: New USB device found, idVendor=0627, idProduct=0001, bcdDevice= 0.00 [6.778432] usb 1-2: New USB device strings: Mfr=1, Product=3, SerialNumber=5 [6.778437] usb 1-2: Product: QEMU USB Tablet [6.778441] usb 1-2: Manufacturer: QEMU [6.778446] usb 1-2: SerialNumber: 42 [7.017476] random: systemd: uninitialized urandom read (16 bytes read) [7.021828] systemd[1]: Created slice User and Session Slice. [7.022272] random: systemd: uninitialized urandom read (16 bytes read) [7.022799] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [7.022920] random: systemd: uninitialized urandom read (16 bytes read) [7.023111] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. [7.025094] systemd[1]: Created slice system-systemd\x2dfsck.slice. [7.025279] systemd[1]: Reached target Swap. [7.025918] systemd[1]: Listening on Journal Audit Socket. [7.127876] EXT4-fs (vda2): re-mounted. Opts: errors=remount-ro [7.238072] systemd-journald[211]: Received request to flush runtime journal from PID 1 [7.745992] EFI Variables Facility v0.08 2004-May-17 [7.765948] random: crng init done [7.765957] random: 7 urandom warning(s) missed due to ratelimiting [7.889152] hidraw: raw HID events driver (C) Jiri Kosina [7.891705] [drm] pci: virtio-gpu-pci detected at :00:05.0 [7.894015] [drm] virgl 3d acceleration enabled [7.897229] [TTM] Zone kernel: Available graphics memory: 362162 kiB [7.897235] [TTM] Zone highmem: Available graphics memory: 2526942 kiB [7.897254] [TTM] Initializing pool allocator [7.897302] [TTM] Initializing DMA pool allocator [7.897397] [drm] number of scanouts: 1 [7.897413] [drm] number of cap sets: 1 [7.935766] [drm] cap set 0: id 1, max-version 1, max-size 308 [7.941395] usbcore: registered new interface driver usbhid [7.941400] usbhid: USB HID core driver [7.960197] Console: switching to colour frame buffer device 128x48 [8.031802] input: QEMU QEMU USB Keyboard as /devices/platform/3f00.pcie/pci:00/:00:01.0/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input1 [8.041530] virtio_gpu virtio3: fb0: virtiodrmfb frame buffer device [8.077273] [drm] Initialized virtio_gpu 0.0.1 0 for virtio3 on minor 0 [8.115421] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v1.11 Keyboard [QEMU QEMU USB Keyboard] on usb-:00:01.0-1/input0 [8.116205] input: QEMU QEMU USB Tablet as /devices/platform/3f00.pcie/pci:00/:00:01.0/usb1/1-2/1-2:1.0/0003:0627:0001.0002/input/input2 [8.116919] hid-gene
Bug#891787: linux-image-4.15.0-1-arm64: Socionext SynQuacer support not enabled
On 28 February 2018 at 20:43, Ard Biesheuvel wrote: > Package: src:linux > Version: 4.15.4-1 > Severity: normal > > Dear Maintainer, > > Support for Socionext SynQuacer based platforms (a 24 core arm64 SoC) has > landed in v4.15 mainline. > > Please enable this support in the Debian kernel as well: > CONFIG_ARCH_SYNQUACER=y > CONFIG_SNI_NETSEC=m > CONFIG_MMC_SDHCI_F_SDH30=m > CONFIG_GPIO_MB86S7X=m > Actually, NETSEC support did not make it into v4.15 after all but was pulled into v4.16 instead. The SoC has PCIe support, so it can be used with PCIe NICs instead, and so it would still be useful to enable the other pieces. Thanks, Ard. > > -- Package-specific info: > ** Version: > Linux version 4.15.0-1-arm64 (debian-ker...@lists.debian.org) (gcc version > 7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.15.4-1 (2018-02-18) > > ** Command line: > BOOT_IMAGE=/boot/vmlinuz-4.15.0-1-arm64 > root=UUID=4e4cd64e-fe66-44c6-ae59-4c8f8fada27d ro earlycon > > ** Tainted: O (4096) > * Out-of-tree module has been loaded. > > ** Kernel log: > [2.572430] pci 0001:00:00.0: BAR 0: assigned [mem > 0x3f-0x3f3fff 64bit] > [2.580576] vgaarb: loaded > [2.583622] EDAC MC: Ver: 3.0.0 > [2.587045] dmi: Firmware registration failed. > [2.591498] Registered efivars operations > [2.597581] clocksource: Switched to clocksource arch_sys_counter > [2.647787] VFS: Disk quotas dquot_6.6.0 > [2.651808] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > [2.659117] AppArmor: AppArmor Filesystem Enabled > [2.663943] pnp: PnP ACPI init > [2.710945] system 00:00: [mem 0x7000-0x77ef] could not be reserved > [2.717930] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active) > [2.717941] pnp: PnP ACPI: found 1 devices > [2.728872] NET: Registered protocol family 2 > [2.733841] TCP established hash table entries: 32768 (order: 6, 262144 > bytes) > [2.741430] TCP bind hash table entries: 32768 (order: 7, 524288 bytes) > [2.748510] TCP: Hash tables configured (established 32768 bind 32768) > [2.755274] UDP hash table entries: 2048 (order: 4, 65536 bytes) > [2.761390] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) > [2.768200] NET: Registered protocol family 1 > [2.772594] PCI: CLS 0 bytes, default 128 > [2.772776] Unpacking initramfs... > [3.775379] Freeing initrd memory: 18460K > [3.781356] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 > counters available > [3.789398] kvm [1]: 8-bit VMID > [3.792543] kvm [1]: IDMAP page: 808b2000 > [3.796551] kvm [1]: HYP VA range: 8000: > [3.803083] kvm [1]: vgic-v2@2c02 > [3.806800] kvm [1]: GIC system register CPU interface enabled > [3.813166] kvm [1]: vgic interrupt IRQ1 > [3.817109] kvm [1]: virtual timer IRQ3 > [3.821557] kvm [1]: Hyp mode initialized successfully > [3.830044] Initialise system trusted keyrings > [3.834634] workingset: timestamp_bits=44 max_order=20 bucket_order=0 > [3.845934] zbud: loaded > [5.139407] Key type asymmetric registered > [5.143515] Asymmetric key parser 'x509' registered > [5.148554] Block layer SCSI generic (bsg) driver version 0.4 loaded > (major 246) > [5.156157] io scheduler noop registered > [5.160090] io scheduler deadline registered > [5.164583] io scheduler cfq registered (default) > [5.169289] io scheduler mq-deadline registered > [5.177066] ACPI GTDT: found 1 SBSA generic Watchdog(s). > [5.183192] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [5.190393] Serial: AMBA driver > [5.193625] msm_serial: driver initialized > [5.198236] cacheinfo: Unable to detect cache hierarchy for CPU 0 > [5.204767] mousedev: PS/2 mouse device common for all mice > [5.211741] ledtrig-cpu: registered to indicate activity on CPUs > [5.217772] dmi-sysfs: dmi entry is absent. > [5.222849] NET: Registered protocol family 10 > [5.240755] Segment Routing with IPv6 > [5.244479] mip6: Mobile IPv6 > [5.247452] NET: Registered protocol family 17 > [5.251904] mpls_gso: MPLS GSO support > [5.256247] registered taskstats version 1 > [5.260351] Loading compiled-in X.509 certificates > [5.426174] Loaded X.509 cert 'Debian Project: Ben Hutchings: > 008a018dca80932630' > [5.433813] zswap: loaded using pool lzo/zbud > [5.438349] AppArmor: AppArmor sha1 policy hashing enabled > [5.443843] ima: No TPM chip found, activating TPM-bypass! (rc=-19) > [5.450360] hctosys: unable to open rtc device (rtc0) > [5.466502] Freeing unused kernel memory: 4544K >
Bug#891787: linux-image-4.15.0-1-arm64: Socionext SynQuacer support not enabled
Package: src:linux Version: 4.15.4-1 Severity: normal Dear Maintainer, Support for Socionext SynQuacer based platforms (a 24 core arm64 SoC) has landed in v4.15 mainline. Please enable this support in the Debian kernel as well: CONFIG_ARCH_SYNQUACER=y CONFIG_SNI_NETSEC=m CONFIG_MMC_SDHCI_F_SDH30=m CONFIG_GPIO_MB86S7X=m -- Package-specific info: ** Version: Linux version 4.15.0-1-arm64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.15.4-1 (2018-02-18) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1-arm64 root=UUID=4e4cd64e-fe66-44c6-ae59-4c8f8fada27d ro earlycon ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [2.572430] pci 0001:00:00.0: BAR 0: assigned [mem 0x3f-0x3f3fff 64bit] [2.580576] vgaarb: loaded [2.583622] EDAC MC: Ver: 3.0.0 [2.587045] dmi: Firmware registration failed. [2.591498] Registered efivars operations [2.597581] clocksource: Switched to clocksource arch_sys_counter [2.647787] VFS: Disk quotas dquot_6.6.0 [2.651808] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [2.659117] AppArmor: AppArmor Filesystem Enabled [2.663943] pnp: PnP ACPI init [2.710945] system 00:00: [mem 0x7000-0x77ef] could not be reserved [2.717930] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active) [2.717941] pnp: PnP ACPI: found 1 devices [2.728872] NET: Registered protocol family 2 [2.733841] TCP established hash table entries: 32768 (order: 6, 262144 bytes) [2.741430] TCP bind hash table entries: 32768 (order: 7, 524288 bytes) [2.748510] TCP: Hash tables configured (established 32768 bind 32768) [2.755274] UDP hash table entries: 2048 (order: 4, 65536 bytes) [2.761390] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) [2.768200] NET: Registered protocol family 1 [2.772594] PCI: CLS 0 bytes, default 128 [2.772776] Unpacking initramfs... [3.775379] Freeing initrd memory: 18460K [3.781356] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 counters available [3.789398] kvm [1]: 8-bit VMID [3.792543] kvm [1]: IDMAP page: 808b2000 [3.796551] kvm [1]: HYP VA range: 8000: [3.803083] kvm [1]: vgic-v2@2c02 [3.806800] kvm [1]: GIC system register CPU interface enabled [3.813166] kvm [1]: vgic interrupt IRQ1 [3.817109] kvm [1]: virtual timer IRQ3 [3.821557] kvm [1]: Hyp mode initialized successfully [3.830044] Initialise system trusted keyrings [3.834634] workingset: timestamp_bits=44 max_order=20 bucket_order=0 [3.845934] zbud: loaded [5.139407] Key type asymmetric registered [5.143515] Asymmetric key parser 'x509' registered [5.148554] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 246) [5.156157] io scheduler noop registered [5.160090] io scheduler deadline registered [5.164583] io scheduler cfq registered (default) [5.169289] io scheduler mq-deadline registered [5.177066] ACPI GTDT: found 1 SBSA generic Watchdog(s). [5.183192] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [5.190393] Serial: AMBA driver [5.193625] msm_serial: driver initialized [5.198236] cacheinfo: Unable to detect cache hierarchy for CPU 0 [5.204767] mousedev: PS/2 mouse device common for all mice [5.211741] ledtrig-cpu: registered to indicate activity on CPUs [5.217772] dmi-sysfs: dmi entry is absent. [5.222849] NET: Registered protocol family 10 [5.240755] Segment Routing with IPv6 [5.244479] mip6: Mobile IPv6 [5.247452] NET: Registered protocol family 17 [5.251904] mpls_gso: MPLS GSO support [5.256247] registered taskstats version 1 [5.260351] Loading compiled-in X.509 certificates [5.426174] Loaded X.509 cert 'Debian Project: Ben Hutchings: 008a018dca80932630' [5.433813] zswap: loaded using pool lzo/zbud [5.438349] AppArmor: AppArmor sha1 policy hashing enabled [5.443843] ima: No TPM chip found, activating TPM-bypass! (rc=-19) [5.450360] hctosys: unable to open rtc device (rtc0) [5.466502] Freeing unused kernel memory: 4544K [5.608443] nvme nvme0: pci function 0001:00:00.0 [5.871879] blk_queue_max_hw_sectors: set to minimum 8 [5.890416] blk_queue_max_hw_sectors: set to minimum 8 [5.905751] nvme0n1: p1 p2 p3 p4 [6.706212] PM: Starting manual resume from disk [6.711061] PM: Image not found (code -22) [6.842702] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Opts: (null) [7.020882] systemd[1]: System time before build time, advancing clock. [7.045997] ip_tables: (C) 2000-2006 Netfilter Core Team [7.071928] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) [7.090621] systemd[1]: Detected architecture arm64. [7.10
Bug#879106: debian-installer-utils: "list-devices disk" should consider persistent memory block devices
Package: debian-installer-utils Version: 1.119 Severity: normal Tags: d-i Dear Maintainer, When booting an .iso image via HTTP boot from UEFI, the .iso image will be exposed to the OS as a ramdisk via the ACPI NFIT table, and will be picked up by the existing NFIT code in the kernel, which will expose it as a /dev/pmemXXX device. For example, # blkid /dev/pmem0: UUID="2017-10-17-14-41-11-00" LABEL="ISOIMAGE" TYPE="iso9660" Currently, debian-installer will fail to find this block device, and complain that the installer media cannot be found. Please add support for pmemXXX block device nodes to list-devices so that they may be found automatically when using HTTP boot to install. -- Ard. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 4.14.0-rc4-00014-g981584ed1827 (SMP w/24 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#870071: linux-image-4.9.0-3-arm64: Kconfig option for console on frame buffer device is missing
Package: src:linux Version: 4.9.30-2+deb9u2 Severity: normal Dear Maintainer, Please enable CONFIG_FRAMEBUFFER_CONSOLE (preferably as a builtin) in the arm64's kernel image configuration so that systems with a graphics card installed can get a console on the frame buffer rather than only via serial. -- Package-specific info: ** Version: Linux version 4.9.0-3-arm64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-arm64 root=UUID=f3b7c265-d79f-4dce-8c44-d6120d9111e7 ro console=ttyAMA0 console=tty0 ** Not tainted ** Kernel log: [2.477111] usb 1-1: new high-speed USB device number 2 using xhci_hcd [2.631395] usb 1-1: New USB device found, idVendor=05ac, idProduct=1006 [2.638097] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [2.645227] usb 1-1: Product: Keyboard Hub [2.649319] usb 1-1: Manufacturer: Apple, Inc. [2.653757] usb 1-1: SerialNumber: [2.660074] hub 1-1:1.0: USB hub found [2.664135] hub 1-1:1.0: 3 ports detected [2.783268] ata2: SATA link down (SStatus 0 SControl 300) [2.957106] usb 1-1.1: new low-speed USB device number 3 using xhci_hcd [3.072863] usb 1-1.1: New USB device found, idVendor=413c, idProduct=3012 [3.079735] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.087042] usb 1-1.1: Product: Dell USB Optical Mouse [3.092175] usb 1-1.1: Manufacturer: Dell [3.100842] hidraw: raw HID events driver (C) Jiri Kosina [3.103266] ata3: SATA link down (SStatus 0 SControl 300) [3.115764] usbcore: registered new interface driver usbhid [3.121341] usbhid: USB HID core driver [3.125960] input: Dell Dell USB Optical Mouse as /devices/platform/smb/f000.pcie/pci:00/:00:02.2/:02:00.0/usb1/1-1/1-1.1/1-1.1:1.0/0003:413C:3012.0001/input/input0 [3.142168] hid-generic 0003:413C:3012.0001: input,hidraw0: USB HID v1.11 Mouse [Dell Dell USB Optical Mouse] on usb-:02:00.0-1.1/input0 [3.177110] usb 1-1.2: new low-speed USB device number 4 using xhci_hcd [3.294036] usb 1-1.2: New USB device found, idVendor=05ac, idProduct=024f [3.300910] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.308217] usb 1-1.2: Product: Apple Keyboard [3.312656] usb 1-1.2: Manufacturer: Apple Inc. [3.327778] input: Apple Inc. Apple Keyboard as /devices/platform/smb/f000.pcie/pci:00/:00:02.2/:02:00.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:05AC:024F.0002/input/input1 [3.401366] apple 0003:05AC:024F.0002: input,hidraw1: USB HID v1.11 Keyboard [Apple Inc. Apple Keyboard] on usb-:02:00.0-1.2/input0 [3.414198] input: Apple Inc. Apple Keyboard as /devices/platform/smb/f000.pcie/pci:00/:00:02.2/:02:00.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:05AC:024F.0003/input/input2 [3.415263] ata4: SATA link down (SStatus 0 SControl 300) [3.493164] apple 0003:05AC:024F.0003: input,hidraw2: USB HID v1.11 Device [Apple Inc. Apple Keyboard] on usb-:02:00.0-1.2/input1 [3.727269] ata5: SATA link down (SStatus 0 SControl 300) [4.209110] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [4.216467] ata6.00: ATA-9: SanDisk Ultra II 240GB, X41200RL, max UDMA/133 [4.223345] ata6.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 31/32) [4.231248] ata6.00: configured for UDMA/133 [4.235759] scsi 5:0:0:0: Direct-Access ATA SanDisk Ultra II 00RL PQ: 0 ANSI: 5 [4.587265] ata7: SATA link down (SStatus 0 SControl 300) [4.907267] ata8: SATA link down (SStatus 0 SControl 300) [4.920097] sd 5:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB) [4.927659] sd 5:0:0:0: [sda] Write Protect is off [4.932451] sd 5:0:0:0: [sda] Mode Sense: 00 3a 00 00 [4.932474] sd 5:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [4.948846] sda: sda1 sda2 sda3 sda4 [4.953073] sd 5:0:0:0: [sda] Attached SCSI disk [4.994067] PM: Starting manual resume from disk [4.998724] PM: Hibernation image partition 8:3 present [4.998726] PM: Looking for hibernation image. [4.998871] random: fast init done [5.002349] PM: Image not found (code -22) [5.002351] PM: Hibernation image not present or could not be loaded. [5.053585] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [5.158112] ip_tables: (C) 2000-2006 Netfilter Core Team [5.171529] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) [5.189751] systemd[1]: Detected architecture arm64. [5.196476] systemd[1]: Set hostname to . [5.210572] uart-pl011 e101.serial: no DMA platform data [5.253903] systemd[1]: Listening on Journal Socket (/dev/log). [5.260032] sys
Bug#867611: linux-image-4.9.0-3-arm64: snd-hda-intel.ko module missing
Package: src:linux Version: 4.9.30-2+deb9u2 Severity: normal Dear Maintainer, Please consider adding CONFIG_SND_HDA_INTEL=m to the arm64 kernel config. -- Package-specific info: ** Version: Linux version 4.9.0-3-arm64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-arm64 root=UUID=f3b7c265-d79f-4dce-8c44-d6120d9111e7 ro earlycon ** Tainted: WI (2560) * Taint on warning. * Working around severe firmware bug. ** Kernel log: [6.089313] systemd[1]: Listening on Journal Socket (/dev/log). [6.109283] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. [6.129535] systemd[1]: Created slice System Slice. [6.145453] systemd[1]: Created slice system-systemd\x2dfsck.slice. [6.165443] systemd[1]: Created slice system-serial\x2dgetty.slice. [6.185365] systemd[1]: Listening on Journal Audit Socket. [6.435663] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro [6.744776] EFI Variables Facility v0.08 2004-May-17 [6.749803] efi_call_virt_check_flags: 268 callbacks suppressed [6.755747] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.765128] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.768835] alg: No test for __ecb-aes-ce (__driver-ecb-aes-ce) [6.768967] sd 4:0:0:0: Attached scsi generic sg0 type 0 [6.780236] alg: No test for __ecb-aes-ce (cryptd(__driver-ecb-aes-ce)) [6.784251] systemd-journald[214]: Received request to flush runtime journal from PID 1 [6.800167] [drm] Initialized [6.803346] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.803380] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.803410] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.803438] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.803465] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.803493] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.803520] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.803547] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_next_variable [6.813510] pstore: using zlib compression [6.816906] pstore: Registered efi as persistent store backend [6.926537] nouveau :01:00.0: NVIDIA GT218 (0a8280b1) [7.038991] Adding 976892k swap on /dev/sda3. Priority:-1 extents:1 across:976892k SSFS [7.166280] nouveau :01:00.0: bios: version 70.18.8a.00.06 [7.167145] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at usb-:02:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 50:3f:56:00:23:f5 [7.167203] usbcore: registered new interface driver ax88179_178a [7.171345] ax88179_178a 2-1:1.0 enx503f560023f5: renamed from eth0 [7.254405] nouveau :01:00.0: fb: 1024 MiB DDR3 [7.280057] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null) [7.834658] IPv6: ADDRCONF(NETDEV_UP): enx503f560023f5: link is not ready [8.561510] [TTM] Zone kernel: Available graphics memory: 8190650 kiB [8.568041] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [8.574569] [TTM] Initializing pool allocator [8.578937] [TTM] Initializing DMA pool allocator [8.583669] nouveau :01:00.0: DRM: VRAM: 1024 MiB [8.588719] nouveau :01:00.0: DRM: GART: 1048576 MiB [8.594040] nouveau :01:00.0: DRM: TMDS table version 2.0 [8.599789] nouveau :01:00.0: DRM: DCB version 4.0 [8.604929] nouveau :01:00.0: DRM: DCB outp 00: 02000300 [8.611370] nouveau :01:00.0: DRM: DCB outp 01: 01000302 00020030 [8.617811] nouveau :01:00.0: DRM: DCB outp 02: 02021362 00020010 [8.624253] nouveau :01:00.0: DRM: DCB outp 04: 01032310 [8.630699] nouveau :01:00.0: DRM: DCB conn 00: 1030 [8.636358] nouveau :01:00.0: DRM: DCB conn 01: 2161 [8.642017] nouveau :01:00.0: DRM: DCB conn 02: 0200 [8.657437] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [8.664052] [drm] Driver supports precise vblank timestamp query. [8.699486] nouveau :01:00.0: DRM: MM: using COPY for buffer copies [8.729230] nouveau :01:00.0: No connectors reported connected with modes [8.736366] [drm] Cannot find any crtc or sizes - going 1024x768 [8.746063] nouveau :01:00.0: DRM: allocated 1024x768 fb: 0x7, bo 8c556ae7ec00 [8.754469] nouveau :01:00.0: fb0: nouveaufb frame buffer device [8.777201] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on minor 0 [ 10.40707
Bug#834505: arm64 boot failure with large physical memory range
On Sun, 21 Aug 2016 01:11:15 +0100 Ben Hutchings wrote: > On Fri, 2016-08-19 at 13:42 +0100, Leif Lindholm wrote: > > On Fri, Aug 19, 2016 at 12:50:49PM +0100, Ben Hutchings wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > everything using mozilla-js). > > > > > [...] > > > > > > > > > > Could we possibly work around that by reducing > > > > > CONFIG_ARCH_MMAP_RND_BITS_MAX? Â (That's not directly configurable; it > > > > > requires patching arch/arm64/Kconfig.) > > > > > > > > I think this would be opening up a real can of worms. Not all sizes > > > > are supported by the architecture, and only certain VA_BITS/pagesize > > > > combinations work in the kernel. > > > > > > > > We could switch to 42-bit VA, but that would require switching to 64K > > > > pagesize, which would be an even huger can. > > > > > > I'm not suggesting using any unusual page table configuration. Just > > > reducing the ASLR range that is currently implied by a 48-bit VA. > > > > But would that help anything? > > Even if you don't allocate to the top bits, if they're used for > > tagging, you'll still segfault. > > I seem to remember that AArch64 has the ill-advised rule that VA bits > outside the range of the current page table format are ignored, so > presumably you're concerned that the code relies on this. Â But since > other 64-bit architectures (at least x86, PowerPC and SPARC) behave > otherwise, I would expect semi-portable code to mask out the tag bits. > Indeed. The most likely failure mode (but we'd need to check to be sure) is that the JITs 'clean up' the addresses before dereferencing them by masking bits that have a special meaning to them, and inadvertently clear upper address bits in the process. My concern with changing CONFIG_ARCH_MMAP_RND_BITS_MAX is that it is not a guarantee that mmap() will not be called with explicit addr values in the problematic range. (In some cases, munmap() is used to detect the VA range, given that munmap() turns out to succeed for non-existent mappings unless the address value exceeds the VA size). It's unlikely that an affected JIT would do both things at the same time, i.e., steal upper address bits and perform mmap() allocations in the problematic range, but we'd need to confirm it nonetheless. -- Ard.
