Bug#898446: Please reconsider enabling the user namespaces by default
On Tue, 2020-10-20 at 17:21 +0100, Simon McVittie wrote: > On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote: > > I don't think we should keep patching in > > kernel.unprivileged_userns_clone forever, so the documented way to > > disable user namespaces should be setting user.max_user_namespaces to > > 0. But then there's no good way to have a drop-in file that changes > > back to the upstream default, because that's dependent on system memory > > size. > > > > So I think we should do something like this: > > > > * Document user.max_user_namespaces in procps's shipped > > /etc/sysctl.conf > > * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate > > it (log a warning if it's changed) > > * Document the change in bullseye release notes > > Is this something you intend to do before bullseye, or is it now going > to be after bullseye? I would like to do this for bullseye. However, this has to be a collective decision of the team. > If this is intended to happen before bullseye, I'd like enough time > before the freeze to put an as-graceful-as-possible transition in place > in the bubblewrap package. > > (I'm not sure what form that transition should take - suggestions welcome! > Ideally I'd like bubblewrap to be setuid root if and only if we are still > using a kernel where it needs to be.) The only way I see to do that properly is to run a program at boot that sets the setuid bit correctly for the running kernel. You can get close with a kernel postinst hook, but you'd be changing the bit before the new kernel is running, and for non-official kernel packages you won't know whether they allow unprivileged user-namespace creation. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#972709: Wishlist/RFC: Change to CONFIG_PREEMPT_NONE in linux-image-cloud-*
On Thu, 2020-10-22 at 13:43 -0700, Flavio Veloso wrote:
> Package: linux-image-cloud-amd64
> Version: 4.19+105+deb10u7
> Severity: wishlist
>
> Since cloud images are mostly run for server workloads in headless
> environments accessed via network only, it would be better if
> "linux-image-cloud-*" kernels were compiled with CONFIG_PREEMPT_NONE=y
> ("No Forced Preemption (Server)").
>
> Currently those packages use CONFIG_PREEMPT_VOLUNTARY=y ("Voluntary
> Kernel Preemption (Desktop)")
>
> CONFIG_PREEMPT_NONE description from kernel help:
[...]
I know what it says, but I think the notion that latency is less
important on servers is outdated.
It's well known that people give up quickly on web pages that are slow
to load:
Bug#972794: linux-image-4.19.0-12-amd64: amdgpu-dkms 19.50-20.40 fails to build with error: implicit declaration of function ‘pci_platform_rom’;
Control: severity -1 normal
Control: tag -1 wontfix
The Linux kernel does not have a stable API for modules, and we make no
promises that third party ("out-of-tree") modules will continue to
work. Kernel API changes in a stable branch are rare but sometimes
found to be necessary as part of a bug fix.
As the modules in question don't appear to come from a Debian package,
I'm marking this wontfix.
Ben.
--
Ben Hutchings
The world is coming to an end. Please log off.
Processed: Re: Bug#972794: linux-image-4.19.0-12-amd64: amdgpu-dkms 19.50-20.40 fails to build with error: implicit declaration of function ‘pci_platform_rom’;
Processing control commands: > severity -1 normal Bug #972794 [src:linux] linux-image-4.19.0-12-amd64: amdgpu-dkms 19.50-20.40 fails to build with error: implicit declaration of function ‘pci_platform_rom’; Severity set to 'normal' from 'important' > tag -1 wontfix Bug #972794 [src:linux] linux-image-4.19.0-12-amd64: amdgpu-dkms 19.50-20.40 fails to build with error: implicit declaration of function ‘pci_platform_rom’; Added tag(s) wontfix. -- 972794: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972794 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972794: linux-image-4.19.0-12-amd64: amdgpu-dkms 19.50-20.40 fails to build with error: implicit declaration of function âpci _platform_rom’ ;
Dear All,
For amdgpu 20.10, patching amd/amdgpu/amdgpu_bios.c in
/usr/src/amdgpu-5.4.7.53-1048554/ with the attached patch (posted
by Mikel Rychliski at https://lore.kernel.org/amd-gfx/20200319021623.5426-1-
mi...@mikelr.com/#Z30drivers:gpu:drm:amd:amdgpu:amdgpu_bios.c) fixes the issue.
Best wishes:
Elemér K. Nagy
--- a/amd/amdgpu/amdgpu_bios.c
+++ b/amd/amdgpu/amdgpu_bios.c
@@ -192,30 +192,35 @@ static bool amdgpu_read_bios_from_rom(struct amdgpu_device *adev)
static bool amdgpu_read_platform_bios(struct amdgpu_device *adev)
{
- uint8_t __iomem *bios;
- size_t size;
+ phys_addr_t rom = adev->pdev->rom;
+ size_t romlen = adev->pdev->romlen;
+ void __iomem *bios;
adev->bios = NULL;
- bios = pci_platform_rom(adev->pdev, );
- if (!bios) {
+ if (!rom || romlen == 0)
return false;
- }
- adev->bios = kzalloc(size, GFP_KERNEL);
- if (adev->bios == NULL)
+ adev->bios = kzalloc(romlen, GFP_KERNEL);
+ if (!adev->bios)
return false;
- memcpy_fromio(adev->bios, bios, size);
+ bios = ioremap(rom, romlen);
+ if (!bios)
+ goto free_bios;
- if (!check_atom_bios(adev->bios, size)) {
- kfree(adev->bios);
- return false;
- }
+ memcpy_fromio(adev->bios, bios, romlen);
+ iounmap(bios);
- adev->bios_size = size;
+ if (!check_atom_bios(adev->bios, romlen))
+ goto free_bios;
+
+ adev->bios_size = romlen;
return true;
+free_bios:
+ kfree(adev->bios);
+ return false;
}
#ifdef CONFIG_ACPI
Bug#898446: Please reconsider enabling the user namespaces by default
I think there are two aspects here. (In)security of unpriv user ns is one of them - personally I'm in favor of opinions from people who argue that the attack vector they open will remain for foreseeable future because kernel is simply too big to fix all bugs. The other thing is that containers & sandboxes ecosystem moved strong towards unpriv user ns which makes them nerfed or unusable on systems which don't support them. In result this is the choice between insecurity and obscurity. In current state downstream devs may just not care about debian, ask users to enable unpriv user ns or prepare special "debian edition" version of their stuff like suid bwrap which brings security issues on their own[1] (among other problems). As it was noted vast majority of other distros calculated the costs in favor of enabling unpriv user ns but one need to know that equation has two sides and whether you think unpriv user ns are secure or not is only one of them. Jordan [1] https://github.com/containers/bubblewrap/security/advisories/GHSA-j2qp-rvxj-43vj
Bug#972794: linux-image-4.19.0-12-amd64: amdgpu-dkms 19.50-20.40 fails to build with error: implicit declaration of function ‘pci_platform_rom’;
Package: src:linux Version: 4.19.152-1 Severity: important Dear Maintainer, The amdgpu-dkms (Radeon™ Software for Linux®) fails to build to the amdgpu kernel module with dkms on linux-image-4.19.0-12-amd64, making my laptop mostly unusable. Multiple versions of amdgpu-dkms (tested with 19.50-20.40) are affected. It builds and works with linux-image-4.19.0-11-amd64 (thus, suspected regression due to kernel interface changes). The error message: /var/lib/dkms/amdgpu/5.4.7.53-1048554/build/amd/amdgpu/amdgpu_bios.c:200:9: error: implicit declaration of function ‘pci_platform_rom’; did you mean ‘pci_map_rom’? [-Werror=implicit-function -declaration] bios = pci_platform_rom(adev->pdev, ); ^~~~ pci_map_rom How to reproduce (on a Lenovo V155 with Ryzen 3500U): 1. Install linux-image-4.19.0-X-amd64 with X<12, install dkms, install amdgpu-dkms as of https://wiki.debian.org/AMDGPUDriverOnStretchAndBuster2 TL; DR: dpkg -i amdgpu-dkms-firmware_*.deb ; dpkg -i amdgpu-core_*.deb amdgpu-dkms_*.deb 2. Try to upgrade to linux-image-4.19.0-12-amd64 -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 81V5 product_version: Lenovo V155-15API chassis_vendor: LENOVO chassis_version: Lenovo V155-15API bios_vendor: LENOVO bios_version: ARCN34WW board_vendor: LENOVO board_name: LNVNB161216 board_version: No DPK ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex [1022:15d0] Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex [1022:15d0] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus B [1022:15dc] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) Subsystem: Lenovo FCH SMBus Controller [17aa:3820] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: nvme Kernel modules: nvme 02:00.0 Network controller [0280]: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter [168c:0042] (rev 31) Subsystem: Lenovo QCA9377 802.11ac Wireless
Bug#971270: Bug#972678: initramfs-tools: bad error message when zstd requested but not installed
On Thu, Oct 22, 2020 at 8:06 AM Florian La Roche wrote: > > Hello Russel Coker, > > a fix is in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971270 > > best regards, greetings to you Russell, > > Florian La Roche > Tested your patch on initramfs-tools 0.139 -- which conf/initramfs.conf was modified to default to Zstd -- on an VirtualBox 6.1.16 Debian instance without Zstd package installed. < https://metztli.blog/media/blogs/ixiptli/139-with-non-existing-zstd-package.png?mtime=1603447297 > It fulfilled its intended purpose. Thank you, as well! Best Professional Regards. -- Jose R R http://metztli.it - Download Metztli Reiser4: Debian Buster w/ Linux 5.7.19 AMD64 - feats ZSTD compression https://sf.net/projects/metztli-reiser4/ --- Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
Bug#898446: Please reconsider enabling the user namespaces by default
On Thu, Oct 22, 2020 at 10:55:33PM +0200, Salvatore Bonaccorso wrote: > TBH, I think not having it enabled by default until now saved us a > couple of time from needing to release urgent fixes. It is more a gut > feeling and might not have enough weight: but having it still disabled > in bullseye by default we would be still better of from security > releases/DSA's perspectives. And how does it help if all people enable it, because common software, like chromium, actually require it to run? Then it does not help at all against being forced to publish fixes. Bastian -- If there are self-made purgatories, then we all have to live in them. -- Spock, "This Side of Paradise", stardate 3417.7
