Re: Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
Dear Henrique, It be great to get your input, hence repinging (; Especially as linux-firmware is the common upstream source, it be ideal to ship the amd64 mircrocode out of our firmware packages. Thanks for letting us know. kind regards, maximilian On Sun, Sep 20, 2020 at 10:36:12AM +0200, maximilian attems wrote: > Dear Henrique, dear debian kernel maintainers, Cc: Michael, > > Would you agree to generate the amd64-firmware packages directly out of the > debian > linux-firmware source package? > > This way the microcode would be updated on every linux-firmware non-free > upload? > I am asking as it keeps nugging me to have to outcomment the updates of that > microcode in the changelog (there is again a new one for the upcoming > 20200918). > > Would you want to be added in counterpart to the uploaders of > firmware-nonfree? > > Thank you very much for your amd64 microcode work. > > kind regards, > maximilian > > On Tue, Sep 15, 2020 at 04:55:43PM +0200, Michael Musenbrock wrote: > > Source: firmware-nonfree > > Severity: important > > > > Dear maintainer, > > > > first of all thanks for maintaining and packaging the linux-firmware files > > repository as debian packages. > > > > We currently need to manually obtain the > > linux-firmware.git:amd/amd_sev_fam17h_model3xh.sbin [1] file on > > our AMD EPYC servers. The firmware files containing the AMD SEV firmware > > closing security vulnerabilities [2] > > and fixes bugs and adds improvements to the AMD SEV implementation. > > > > I'm most likely unqualified for legal questions but the LICENSE.amd-sev [3] > > reads quite similar to the already > > added amdgpu license [4]. So I hope this is not the reason, why those files > > were not added in the past. > > > > The severity was choosen because it fixes a security vulnerability, please > > change accordingly if you think > > it is wrong. > > > > Thanks in advance. Best regards, > > michael > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd > > [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9836 > > [3] > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amd-sev > > [4] > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amdgpu > > signature.asc Description: PGP signature
Bug#970736: linux-image-5.7.0-0.bpo.2-amd64 also crashes
I upgraded to linux-image-5.7.0-0.bpo.2-amd64 from buster-backports, and observed another crash: [164111.200474] general protection fault, probably for non-canonical address 0x72f851fc45fa91dd: [#1] SMP NOPTI [164111.210876] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.7.0-0.bpo.2-amd64 #1 Debian 5.7.10-1~bpo10+1 [164111.220169] Hardware name: PC Engines apu3/apu3, BIOS v4.12.0.2 06/28/2020 [164111.227268] RIP: 0010:kmem_cache_alloc+0x74/0x220 [164111.232168] Code: 9e 01 00 00 4d 8b 06 65 49 8b 50 08 65 4c 03 05 aa 1e 7a 44 49 8b 28 48 85 ed 0f 84 89 01 00 00 41 8b 46 20 49 8b 3e 48 01 e8 <48> 8b 18 48 89 c1 49 33 9e 70 01 00 00 48 89 e8 48 0f c9 48 31 cb [164111.251087] RSP: 0018:ba90800c8e10 EFLAGS: 00010206 [164111.256500] RAX: 72f851fc45fa91dd RBX: RCX: 7fdb [164111.263808] RDX: 03eddd90 RSI: 0a20 RDI: 00032a90 [164111.271103] RBP: 72f851fc45fa916d R08: 8dc32acb2a90 R09: 8dc324e75000 [164111.278401] R10: 8dc235478040 R11: R12: 0a20 [164111.285705] R13: bbc4c2cd R14: 8dc307d66a80 R15: 8dc307d66a80 [164111.293122] FS: () GS:8dc32ac8() knlGS: [164111.301431] CS: 0010 DS: ES: CR0: 80050033 [164111.307357] CR2: 7ffdf448cb38 CR3: 35722000 CR4: 000406e0 [164111.307939] [ cut here ] [164111.314702] Call Trace: [164111.314719] [164111.314791] __build_skb+0x1d/0x50 [164111.314801] __netdev_alloc_skb+0xbd/0x150 [164111.314829] cdc_mbim_rx_fixup+0x1e2/0x578 [cdc_mbim] [164111.314856] ? usbnet_update_max_qlen+0x8/0x70 [usbnet] [164111.314875] usbnet_bh+0xd8/0x2c0 [usbnet] [164111.319750] VFS: brelse: Trying to free free buffer [164111.322356] tasklet_action_common.isra.20+0x5a/0x100 [164111.324890] WARNING: CPU: 3 PID: 7662 at fs/buffer.c:1179 __brelse+0x1d/0x20 [164111.328049] __do_softirq+0xdf/0x2e5 [164111.328267] [ cut here ] [164111.328279] kernel BUG at fs/ext4/inode.c:1717! [164111.332223] Modules linked in: xt_nat xt_tcpudp nft_compat veth nft_counter xt_conntrack bridge nf_conntrack_netlink xfrm_user xfrm_algo overlay cdc_mbim cdc_wdm cdc_ncm 8021q garp stp mrp llc amd64_edac_mod edac_mce_amd cdc_ether option usbnet mii kvm_amd usb_wwan usbserial kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel libaes crypto_simd cryptd glue_helper k10temp evdev pcspkr sp5100_tco fam15h_power sg ccp watchdog rng_core nft_reject_inet nf_reject_ipv4 leds_gpio nf_reject_ipv6 button nft_reject acpi_cpufreq nft_ct nft_masq nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sch_fq_codel nf_tables nfnetlink ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod t10_pi crc_t10dif crct10dif_generic ahci libahci xhci_pci ehci_pci libata xhci_hcd ehci_hcd sdhci_pci cqhci sdhci crct10dif_pclmul crct10dif_common [164111.332483] usbcore [164111.337503] ? ioapic_ack_level+0x6d/0x150 [164111.342832] igb scsi_mod mmc_core crc32c_intel i2c_piix4 i2c_algo_bit dca ptp usb_common pps_core gpio_keys [164111.347112] irq_exit+0xa3/0xb0 [164111.352136] CPU: 3 PID: 7662 Comm: https-jsse-nio- Not tainted 5.7.0-0.bpo.2-amd64 #1 Debian 5.7.10-1~bpo10+1 [164111.357388] do_IRQ+0x56/0xe0 [164111.364586] Hardware name: PC Engines apu3/apu3, BIOS v4.12.0.2 06/28/2020 [164111.368361] common_interrupt+0xf/0xf [164111.373144] RIP: 0010:__brelse+0x1d/0x20 [164111.377859] [164111.466113] Code: 00 00 e8 46 ff ff ff 31 c0 c3 0f 1f 00 0f 1f 44 00 00 8b 47 60 85 c0 74 05 f0 ff 4f 60 c3 48 c7 c7 a0 35 50 bc e8 7e 20 da ff <0f> 0b c3 0f 1f 44 00 00 55 53 48 c7 c3 80 a8 02 00 65 48 03 1d b2 [164111.468475] RIP: 0010:cpuidle_enter_state+0xbe/0x3f0 [164111.472692] RSP: 0018:ba90862779d8 EFLAGS: 00010286 [164111.482731] Code: e8 c7 93 a9 ff 80 7c 24 13 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 d5 02 00 00 31 ff e8 79 ec af ff fb 66 0f 1f 44 00 00 <85> ed 0f 88 42 02 00 00 48 63 c5 4c 8b 3c 24 4c 2b 7c 24 08 48 8d [164111.486012] RAX: RBX: 8dc3259e1f70 RCX: [164111.496133] RSP: 0018:ba9080083e70 EFLAGS: 0246 ORIG_RAX: ffdc [164111.499244] RDX: 8dc32ada9900 RSI: 8dc32ad99ac8 RDI: 8dc32ad99ac8 [164111.506305] RAX: 8dc32acacc00 RBX: 8dc323738800 RCX: 001f [164111.510129] RBP: 0002a880 R08: 94ff583d7fa5 R09: 0003 [164111.514191] RDX: 95421dc88d10 RSI: 803d74ed RDI: [164111.516440] R10: R11: ba9086277880 R12: 8dc3259e1f70 [164111.535443] RBP: 0002 R08: 0002 R09: 0002c480 [164111.540613] R13: 8dc324aa2700 R14: 0018247e R15: 8dc324aa27d8 [164111.546014] R10: 94ff50d811
Bug#592519: initramfs-tools: COMPRESS option should be more flexible
Package: initramfs-tools Version: 0.139 Followup-For: Bug #592519 X-Debbugs-Cc: b...@debian.org, m...@debian.org, debian-kernel@lists.debian.org Hi. In a similar vein to what was reported by Roger Shimizu, it takes ages to compress with xz on an armel system with only 128MB of RAM. By default, (which is what is used) xz uses level 6 compression and that is what takes a lot of time to compress. I switched to gzip and the initrd is quite larger. I just performed some tests with perf stat running 3 times a lot of commands to compress my current initrd.img-5.8.0-1-marvell and I found xz -0 both to be faster than gzip -9 *and* generating a smaller file as a result. Here are some results that I gathered. I didn't wait for xz with the default -6 level to finish... | compressor | time | size | |--++--| | gzip -9nk| 69.264 | 5980207 | | gzip -nk | 34.468 | 5995619 | | xz -0k | 35.280 | 5000752 | | xz -1k | 45.351 | 4868388 | | xz --check=crc32 -1k | 44.902 | 4868384 | | bzip2 -k | 51.750 | 5709152 | | uncompressed | 0 | 12965376 | Passing an option to xz (or, in general, to any compressor) would be, indeed, very nice. OTOH, on a fast machine, I would like to use something like xz -9e (that is, maximum compression---probably overkill for not so large files---but with "extreme" searches for more compression). Thanks, Rogério Brito. -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#968335: kernel hangs on linux-image-4.19.0-10-amd64
I have also seen a number of systems hang after upgrading to this kernel version. It appears to happen when the system has docker containers running, possibly related to the virtual ethernet devices. On some systems, I can trigger the bug within an hour or two of uptime. Rolling back to 4.19.0-9 resolves the problem. I also tried 4.19.0-11 from buster-proposed-updates on one system, and the system seems to be stable on that kernel as well. -Mike
Bug#970984: linux-image-5.8.0-2-amd64: Please replace console scrollback
Package: src:linux Version: 5.8.10-1 Severity: normal X-Debbugs-Cc: Asher Gordon Dear Maintainer, After upgrading to linux-image-5.8.0-2, I noticed that scrollback is no longer available in the console. A quick look at the changelog ('apt changelog linux-image-amd64') indicates that this was done to fix CVE-2020-14390. Surely however, there must be a better way to fix this than simply removing this code entirely? It is pretty annoying not having scrollback, and I'm sure I'm not the only one who would like scrollback replaced. Thanks, Asher -- Package-specific info: ** Version: Linux version 5.8.0-2-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.10-1 (2020-09-19) ** Command line: BOOT_IMAGE=/vmlinuz root=/dev/sda1 rw quiet splash ** Tainted: I (2048) * workaround for bug in platform firmware applied ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Libiquity product_name: Taurinus X200 product_version: 1.0 chassis_vendor: Libiquity chassis_version: bios_vendor: coreboot bios_version: CBET4000 4.0 board_vendor: Libiquity board_name: Taurinus X200 board_version: 1.0 ** Loaded modules: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device fuse ctr ccm bnep btusb btrtl ath9k btbcm btintel ath9k_common ath9k_hw bluetooth ath coretemp kvm_intel mac80211 uvcvideo snd_hda_codec_conexant snd_hda_codec_generic kvm jitterentropy_rng videobuf2_vmalloc snd_hda_intel videobuf2_memops snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec drbg cfg80211 videodev aes_generic snd_hda_core snd_hwdep crypto_simd irqbypass cryptd glue_helper snd_pcm mc sg iTCO_wdt serio_raw intel_pmc_bxt iTCO_vendor_support pcspkr ansi_cprng snd_timer watchdog nvram ledtrig_audio snd ecdh_generic ecc libaes libarc4 soundcore rfkill ac evdev acpi_cpufreq binfmt_misc ecryptfs parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic xor zstd_decompress zstd_compress raid6_pq libcrc32c crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_common i915 ahci libahci i2c_algo_bit libata drm_kms_helper cec ehci_pci uhci_hcd scsi_mod drm ehci_hcd psmouse e1000e usbcore i2c_i801 i2c_smbus lpc_ich ptp pps_core usb_common battery video button ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) Subsystem: Lenovo ThinkPad T400 [17aa:20e0] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03) Subsystem: Lenovo ThinkPad T400 [17aa:20ee] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: e1000e Kernel modules: e1000e 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI]) Subsystem: Lenovo ThinkPad T400 [17aa:20f0] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) (prog-if 00 [UHCI]) Subsystem: Lenovo ThinkPad T400 [17aa:20f0] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1a.2 US
Bug#592519: initramfs-tools: COMPRESS option should be more flexible
On Fri, 2020-09-25 at 14:19 -0300, Rogério Brito wrote: > Package: initramfs-tools > Version: 0.139 > Followup-For: Bug #592519 > X-Debbugs-Cc: b...@debian.org, m...@debian.org, debian-kernel@lists.debian.org > > > Hi. > > In a similar vein to what was reported by Roger Shimizu, it takes ages to > compress with xz on an armel system with only 128MB of RAM. By default, > (which is what is used) xz uses level 6 compression and that is what takes a > lot of time to compress. > > I switched to gzip and the initrd is quite larger. I just performed some > tests with perf stat running 3 times a lot of commands to compress my > current initrd.img-5.8.0-1-marvell and I found xz -0 both to be faster than > gzip -9 *and* generating a smaller file as a result. [...] Try zstd? If you still feel you need this flexibility, I'm open to taking a patch that allows specifying the compression level *only*. I don't want to allow specifying arbitrary options. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part