Bug#948576: Update - tested with 5.5.4
On Tue, 2020-02-18 at 23:45 +0100, Josua Mayer wrote: > Hi everybody, > > I have rebased my patch on 5.5.4-1~exp1 from the packaging master branch. > While at it I have also cleaned it up removing any options that were > implicitly selected, leaving only those that really need to be enabled > manually. > > Boot tested, everything that worked before still does, namely the > standalone ethernet port, USB, microSD and eMMC. > > Please consider enabling these config options - The device-tree for the > Honeycomb Workstation has been merged with 5.6-rc1 and it would be great > to have Debian work as pieces start landing upstream. I've applied these changes with some minor fix-ups: - CONFIG_FSL_GUTS is automatic, so don't specify it - COFNIG_DPAA2_CONSOLE was not given a value; make it modular I also noticed that the qoriq-cpufreq driver won't automatically get loaded when it's built as a module. This can probably be fixed by adding the line: MODULE_DEVICE_TABLE(of, node_matches); but I'll leave it to you to test that and send a patch upstream. :-) Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Processed: forcibly merging 951409 948298
Processing commands for cont...@bugs.debian.org: > forcemerge 951409 948298 Bug #951409 [src:linux] Marvell A38x ClearFog mvneta eth device regression Bug #951409 [src:linux] Marvell A38x ClearFog mvneta eth device regression The source linux and version 5.3.9-2~bpo10+1sr1 do not appear to match any binary packages Marked as found in versions linux/5.3.9-2~bpo10+1sr1. Bug #948298 [src:linux] linux-image-5.3.0-0.bpo.2-armmp: please enable armada 38x comphy driver for armmp Severity set to 'important' from 'normal' Merged 948298 951409 > thanks Stopping processing here. Please contact me if you need assistance. -- 948298: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948298 951409: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951409 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#898446: Please reconsider enabling the user namespaces by default
On Mon, 2020-03-30 at 10:56 +0100, Simon McVittie wrote: > On Fri, 11 May 2018 at 20:44:50 +0200, Laurent Bigonville wrote: > > Firefox (and probably other applications) are using user namespaces these > > days to enhance the security. > > > > Debian is disabling these since 2013, the original patch states it's a > > short term solution, but we are here 5 years later and they are still > > disabled. > > > > Apparently debian (and ubuntu) and arch are the only distributions > > disabling the user namespaces. > > A cross-distro status update: > > - Debian still disables user namespaces by default with our > /proc/sys/kernel/unprivileged_userns_clone patch. > > - Ubuntu now enables user namespaces by default. I think they still apply > the /proc/sys/kernel/unprivileged_userns_clone patch, but with the > default flipped? > > - Arch Linux now enables user namespaces in their default kernel. There > is a non-default kernel, "linux-hardened", which applies the same patch > as Debian. > > - Apparently RHEL 7 also disables user namespaces, although instead of > patching in a new sysctl, they set /proc/sys/user/max_user_namespaces > to 0 (which is an upstream thing since Linux 4.9). And CentOS 8 appears to enable user namespaces by default. So at this point I think we probably need to follow suit, if only because users and developers will expect it to be enabled. > On Sun, 13 May 2018 at 22:57:56 +0200, Moritz Mühlenhoff wrote: > > Ben Hutchings wrote: > > > And this still mitigates a significant fraction of the security issues > > > found in the kernel. > > > > A quite significant fraction; on average this neutralises a root privilege > > escalation every month or so. This is really not something that we should > > re-enable any time soon. > > Is this still the case, or has the status of user namespaces settled down? I certinaly have the impression that things have settled down. I'd need to spend some time reviewing recent security issues, to be sure of that. > bubblewrap works around the restriction by being setuid root (and > imposing restrictions in user-space that are intended to be more > restrictive than those imposed by upstream kernels), but this makes > bubblewrap bugs into potential root privilege escalations, so I would love > to see bubblewrap no longer need to be setuid (like in Ubuntu). [...] > In > Firefox, if I understand correctly, the fallback path is to not sandbox > in this way at all; in Chrome/Chromium, there is a setuid fallback > (which is enabled by the Debian chromium package), but it does not > receive new upstream development, and it seems to be ambiguous whether > its use is discouraged. [...] I think you've made a good case that user namespaces are likely to be a net positive for security on Debian desktop systems. This might not be true yet for servers that aren't container hosts. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Re: Persistent Keyring support in the Kernel
On Wed, 2020-04-01 at 12:43 -0400, Keohane, Donovan wrote: > Hello, > > Recently, I have been working with the kernel keyring and noticed that > persistent keyring support > isn't enabled by default in the Debian kernel config > (CONFIG_PERSISTENT_KEYRINGS). Is there a reason > behind not enabling support for them by default? Not that I recall. I'll enable it. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#953017: marked as done (linux-image-amd64: Regression from "mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()")
Your message dated Wed, 15 Apr 2020 01:32:18 +0100 with message-id and subject line Re: Bug#953017: Fixes in Upstream has caused the Debian Bug report #953017, regarding linux-image-amd64: Regression from "mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()" to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 953017: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953017 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-image-amd64 Version: 5.4.13-1~bpo10+1 Severity: important Tags: upstream patch Dear Maintainer, A performance regression stemming from the patch "mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()" in all mainline and current stable kernels, except 3.16.y, was reported by multiple persons [1]. The regression involves any activity that exercises vmalloc a lot, such as creating threads with CONFIG_VMAP_STACK=y or tty allocation (for example by SSH servers). A fix [2] for this was posted last October and was picked up in the -mm tree last November [3]. However this fix did not make it into v5.6-rc or any other release. It is still only in the -mm tree. AFAICT this regression only impacts x86 platforms, as it is the only platform that has a custom vmalloc_sync_all() instead of the standard no-op stub. As per my report to upstream, I currently have one production server running with the offending patch reverted. I also have another with the fix applied, and that seems to work well. Please consider adding the fix to Debian kernel images until upstream kernels have it. [1] https://www.spinics.net/lists/stable/msg349763.html [2] https://patchwork.kernel.org/patch/11181159/ [3] https://www.spinics.net/lists/mm-commits/msg141749.html -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armhf, i386, arm64 Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), LANGUAGE=zh_TW.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages linux-image-amd64 depends on: ii linux-image-5.4.0-0.bpo.3-amd64 5.4.13-1~bpo10+1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Version: 5.5.13-1 On Thu, 2020-04-09 at 13:40 +0800, Chen-Yu Tsai wrote: > The fix for this issue has been merged in v5.6-rc7 and is part of the > v5.6 release. The commit in upstream is: > > 763802b53a42 x86/mm: split vmalloc_sync_all() > > This has also been backported to all current LTS kernels except 3.16 > in the following releases: > > v4.4.218 > v4.9.218 > v4.14.175 > v4.19.113 > v5.4.28 ...and 5.5.12, so this is fixed in unstable. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part --- End Message ---
Bug#933302: RTL8723DE not working
On Sun, 2020-04-12 at 15:38 -0600, Jesse Rhodes wrote: [...] > - Ubuntu's 5.4 kernel *does* have support, but it's via the RTW88 > driver that should be unrelated aiui because the 8723DE nic is 802.11n > and RTW88 is specifically 802.11ac, and yet: > > jesse@bivouac:~/temp/ubuntu$ grep -i rtw88 boot/config-5.4.0-21-generic > CONFIG_RTW88=m > CONFIG_RTW88_CORE=m > CONFIG_RTW88_PCI=m > CONFIG_RTW88_8822BE=y > CONFIG_RTW88_8822CE=y > CONFIG_RTW88_8723DE=y [...] I'm afraid that option doesn't exist in the upstream Linux version of rtw88 (not even in 5.7-rc1). Until it is added, we can't enable it in Debian. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Upcoming stable point release (10.4)
Hi, The next point release for "buster" (10.4) is scheduled for Saturday, May 9th. Processing of new uploads into buster-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Bug#956703: linux-image-5.5: 5.5 kernel seems to break pulseaudio HDMI detection
On Tue, Apr 14, 2020 at 02:06:30PM +0100, Simon John wrote: > Booting into 5.5 on Sid gives me no audio out via HDMI. I can confirm similar HDMI audio breakage with 5.5.13 on a Thinkpad X1 Carbon (gen2) with the following audio devices: 00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b) Subsystem: Lenovo Haswell-ULT HD Audio Controller 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: snd_hda_intel Kernel modules: snd_hda_intel 00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04) Subsystem: Lenovo 8 Series HD Audio Controller 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: snd_hda_intel Kernel modules: snd_hda_intel
Processed: tagging 947759
Processing commands for cont...@bugs.debian.org: > tags 947759 + pending Bug #947759 [src:linux] Configuration optimizations for the cloud variant Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 947759: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947759 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#939545: marked as done (Debian 10 Buster - Sound on 3.5 jack audio problem with Kernel v 4.19.0-5-amd64 (LTS))
Your message dated Tue, 14 Apr 2020 12:56:25 +0300 with message-id and subject line Re: Bug#939545: Debian 10 Buster - Sound on 3.5 jack audio problem with Kernel v 4.19.0-5-amd64 (LTS) has caused the Debian Bug report #939545, regarding Debian 10 Buster - Sound on 3.5 jack audio problem with Kernel v 4.19.0-5-amd64 (LTS) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 939545: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939545 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-image Version: 4.19.0-5-amd64 Bug Description Unbearable whistling in headphones plugged into 3,5 mm audio jack port during the absence of broadcast (music/movie ended, paused, etc.) My Dell XPS 9570 with the kernel 4.19.0-5-amd64 (LTS) are impacted by this bug ;( I have to use headphones the night for 3-4 hours to make no noise, it hurts my ears and this situation starts very seriously to exasperate me. Best regards. Philippe--- End Message --- --- Begin Message --- Version: 5.4.19-1~bpo10+1 On Mon, 13 Apr 2020 19:54:01 +0200 (CEST) "pham...@bluewin.ch" wrote: > Problem is solved with Powertop v.2.11 from testing and Kernel 5.4 from > backports. > Thank you very much for your work. > The ticket can be considered as resolved. > Powertop v.2.11 should be in backport, it works very fine !!! > Regards. > Philippe Hi! This can be done by sending mail to <939545-d...@bugs.debian.org> and I have just done that. Source: https://www.debian.org/Bugs/Developer#closing Regards, Juhani--- End Message ---
Bug#931930: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin
Now with the arrival of kernel 5.5 to unstable the situation has worsened: update-initramfs: Generating /boot/initrd.img-5.5.0-1-amd64 W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_09.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module i915 W: Possible missing firmware /lib/firmware/i915/skl_huc_2.0.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_huc_2.0.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/glk_huc_4.0.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/cml_huc_4.0.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/cml_guc_33.0.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/icl_huc_9.0.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/ehl_huc_9.0.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/ehl_guc_33.0.4.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_guc_35.2.0.bin for module i915
Bug#956676: firmware-iwlwifi: Can't get device info: No such device
Package: firmware-iwlwifi Version: 20190114-2 Severity: normal Dear Maintainer, * What led up to the situation? fresh install. * What exactly did you do (or not do) that was effective (or ineffective)? downloaded and tested kernel and firwmare from backports, reinstalled firmware and kernel from statble buster. * What was the outcome of this action? None, same, no efect what's so ever. * What outcome did you expect instead? The bluetooth interface to show up! -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (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 firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.133+deb10u1 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux lspci|grep -i wire 03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) dmesg |grep -i blue [ 2402.044618] Bluetooth: Core ver 2.22 [ 2402.044637] Bluetooth: HCI device and connection manager initialized [ 2402.044641] Bluetooth: HCI socket layer initialized [ 2402.044646] Bluetooth: L2CAP socket layer initialized [ 2402.044651] Bluetooth: SCO socket layer initialized -- no debconf information
