Bug#928362: Enable some kernel hardening by default
Package: linux-image-amd64 Version: 4.19+104 Severity: important Hi, It would be great if Debian included some kernel hardening by default. These settings would offer great security benefits and no or very minimal performance decrease. Setting “kernel.kptr_restrict=1” with sysctl makes kernel symbols in /proc/kallsyms only accessible to root which can make it more difficult for a kernel exploit to resolve addresses/symbols. Setting it to 2 hides the symbols regardless of privileges. Setting “kernel.dmesg_restrict=1” with sysctl restricts access to the kernel logs which can give an attacker less information on what they can do. Setting “kernel.unprivileged_bpf_disabled=1” and “net.core.bpf_jit_harden=2” with sysctl hardens the BPF JIT compiler and restricts it to root. It comes with a performance drop on systems that use the JIT compiler a lot but this should only really effect servers. Setting “vm.mmap_rnd_bits=32” and “vm.mmap_rnd_compat_bits=16” with sysctl improves KASLR effectiveness for mmap. This might break some things but I haven't had anything break on me yet. Adding “slab_nomerge” as a boot parameter may also be useful. slab_nomerge disables the merging of slabs of similar sizes. Sometimes a slab can be used in a vulnerable way which an attacker can exploit. This may have a slight increase in memory usage. Mounting /proc with hidepid=2 in /etc/fstab will hide other users’ processes from unprivileged users. This makes it a lot harder for an attacker to get information about other running processes. Some processes (like systemd-logind) will break but you can add exceptions for them. If Debian could include any of these by default then that would be great. Best Regards.
Processed: tagging 928125
Processing commands for cont...@bugs.debian.org: > tags 928125 + pending Bug #928125 [src:linux] losetup causes Dead systemd-udevd processes, blocks forever Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 928125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928125 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)
Hello,
On Tue, Apr 30, 2019 at 10:12:27AM +0200, Uwe Kleine-König wrote:
> On Thu, Apr 25, 2019 at 09:17:32PM +0200, Aurelien Jarno wrote:
> > On 2019-04-25 14:50, Aurelien Jarno wrote:
> > > On 2019-04-23 22:16, Aurelien Jarno wrote:
> > > > Source: linux
> > > > Version: 4.19.28-2
> > > > Severity: important
> > > >
> > > > After upgrading hartmann.debian.org (an armhf buildd using an Armada XP
> > > > GP board) from buster to stretch, the ethernet device is not working
>
> "upgrading from buster to stretch" doesn't make sense. I think you meant
> from stretch to buster.
>
> > >
> > > More precisely the board is a "Marvell Armada XP Development Board
> > > DB-MV784MP-GP"
> > >
> > > > anymore. Using tcpdump on both the buildd and a remote host, it appears
> > > > that the packets correctly leave the board and that the reception side
> > > > fails.
>
> If you can send to a remote host at least ARP (or ND) must be working,
> so some reception still works, right?
>
> > > > The module used for the ethernet device is mvneta. The corresponding DT
> > > > compatible entry is "marvell,armada-xp-neta".
> > > >
> > >
> > > I have started a "bisection" with the kernels from snapshot. This is
> > > what I have found so far:
> > >
> > > This one works:
> > > - linux-image-4.19.0-rc6-armmp-lpae_4.19~rc6-1~exp1_armhf.deb
> > >
> > > The following ones don't:
> > > - linux-image-4.19.0-rc7-armmp-lpae_4.19~rc7-1~exp1_armhf.deb
> > > - linux-image-5.0.0-trunk-armmp_5.0.2-1~exp1_armhf.deb
> > >
> > > My guess (I don't have time to try more now) is that the issue is caused
> > > by the following change:
> > >
> > > | [ Uwe Kleine-König ]
> > > | * [armhf] enable MVNETA_BM_ENABLE and CAN_FLEXCAN as a module
> > >
> >
> > I confirm this is the issue. Disabling MVNETA_BM_ENABLE on kernel
> > 4.19.28-2 fixes the issue. Note that it breaks the ABI.
>
> A colleague happens to work with an XP based machine with a (nearly)
> vanilla kernel based on 5.1.0-rc6 and there enabling MVNETA_BM_ENABLE
> doesn't render networking nonfunctional.
>
> Looking through the changes to drivers/net/ethernet/marvell/mvneta*
> between 5.0 and 5.1-rc6 there isn't something that would explain a fix
> though. There doesn't seem to be a good explanation in the debian
> specific patches either.
>
> So this problem is either machine specific or it works with the mvneta
> driver builtin. (I didn't double check, but guess that my colleague uses
> =y and the Debian kernel =m). Well, or I missed something.
>
> Is it possible to test a few things on hartmann? I'd suggest:
>
> - try (vanilla) 5.1-rc6 with MVNETA=y
> - try an older kernel (maybe 4.6 as the buffer manager stuff was
>introduced in dc35a10f68d3 ("net: mvneta: bm: add support for
>hardware buffer management") which made it into 4.6-rc1) with
>MVNETA_BM_ENABLE=[ym].
Thanks to Steve McIntyre I got access to a DB-MV784MP-GP and did the
second test. I used mvebu_v7_defconfig and enabled CGROUPS and AUTOFS4
(to please systemd) and MVNETA_BM_ENABLE=y on 4.6. The latter breaks
networking similar to newer kernel versions.
So I guess the buffer management never worked on that board.
I don't have the time to debug this issue further, but will disable
buffer management for the Debian kernel again.
Best regards
Uwe
signature.asc
Description: PGP signature
linux-4.9_4.9.168-1~deb8u1_multi.changes REJECTED
Uploads to oldstable-proposed-updates are not accepted. Mapping oldstable-security to oldstable-proposed-updates. === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
[bts-link] source package src:linux
# # bts-link upstream status pull for source package src:linux # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #928125 (http://bugs.debian.org/928125) # Bug title: losetup causes Dead systemd-udevd processes, blocks forever # * http://bugzilla.kernel.org/show_bug.cgi?id=202985 # * remote status changed: (?) -> NEW usertags 928125 + status-NEW thanks
Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever
Hi, v4.9.172 is out with the offending commit reverted. Is there a stretch update with the same revert planned soon to address this? And via which suite? Thanks.
Bug#927972: jitterentropy_rng.ko never loads
On 4/30/19 11:38 AM, Patrick Schleizer wrote: > On https://www.whonix.org/pipermail/whonix-devel/2019-April/001371.html > its developer wrote: > >> [...] >> - the in-kernel crypto API has an RNG framework that provides a DRBG. > This > DRBG is used for in-kernel crypto API purposes. It may be accessed from > user > space via AF_ALG [2]. Yet, this is not accessible from /dev/random, /dev/ > urandom or getrandom. The DRBG uses the in-kernel JitterRNG to seed itself. >> [...] > Better entropy for in-kernel crypto API purposes sounds good as a > general security enhancement. > > Fedora enables this kernel module by default, too. > > Does this sound like a good idea to enable loading this kernel module by > default in Debian? > Stephan confirms that the Kernel DRBG is also important for crypto operations that don't use /dev/random like the ECC cipher and much more. I think it is important to revisit this in that case and add the jitter module to the initramfs: Stephan: "Always assume that a weak RNG is bad. The DRBG is used for kernel crypto API for generating keys and other data. For example, the ECC key generation uses the DRBG and NOT the get_random_bytes (the /dev/urandom in-kernel equivalent). There are quite a number of other use cases. I know, it is unfortunate that we have 2 RNGs in the kernel. But a consolitation approach I offered at [1] was not considered." "So, the jitterentropy kernel module is only used by the kernel DRBG. And it will load the jitterentropy kernel module automatically considering that the module name is the same as the cipher name "jitterentropy_rng". Of course, this only applies if the kernel module is available in the execution environment (like the initramfs) and the DRBG is initialized during that time."
Bug#921019: arm64: Please provide sound modules for Allwinner A64 based systems
Andrei POPESCU writes: > On Jo, 31 ian 19, 17:21:54, Harald Geyer wrote: > > > Please enable the following Kconfig symbols as modules: > > > > CONFIG_SND_SUN50I_CODEC_ANALOG > > CONFIG_SND_SUN8I_CODEC > > CONFIG_SND_SUN4I_I2S > > CONFIG_SND_SOC_SIMPLE_AMPLIFIER > > CONFIG_SND_SIMPLE_CARD > > > > These are necessary for sound support on pinebook, Olimex TERES-I, etc. > > The drivers are available upstream since 4.20. > > Pinebook has sound enabled in devicetree starting with 5.0 > > Would this enable also the S/PDIF or is something else needed > (CONFIG_SND_SUN4I_SPDIF maybe?)? Indeed, for S/PDIF on A64 CONFIG_SND_SUN4I_SPDIF is needed. However AFAICS debian ships no sun50i-a64 devicetrees where S/PDIF is enabled. You would need a custom DT or an overlay, to make the debian kernel actually load the module. BTW there have been two uploads of linux 5.0 to experimental since this bug was opened. Would be nice if somebody could address this for the next upload. Harald
Uploading linux (4.19.37-1)
I intend to upload linux to unstable on Friday or Saturday. The pending changes include upstream stable updates with a large number of fixes, and: * [powerpc*] vdso: Make vdso32 installation conditional in vdso_install (Closes: #785065) * [armhf,arm64] Revert "net: stmmac: Send TSO packets always from Queue 0" * [armel/marvell] Disable HW_RANDOM as no HWRNG drivers are usable here * udeb: Add all HWRNG drivers to kernel-image (see #923675) * lockdown: Refer to Debian wiki until manual page exists * [powerpc,ppc64,ppc64el] linux-image: Recommend grub-ieee1275 * [i386] Add grub-efi-ia32 as an alternate recommended bootloader * linux-source: Recommend bison and flex, always needed to build the kernel * [armel/marvell,sh4] linux-image: Recommend apparmor, like all other configs * udeb: Drop unused ntfs-modules packages * ntfs: Disable NTFS_FS due to lack of upstream security support (CVE-2018-12929, CVE-2018-12930, CVE-2018-12931) * [x86] platform: Enable INTEL_ATOMISP2_PM as module * [armhf] Enable SND_SOC_SPDIF for Cubietruck (Closes: #884562) * libbpf-dev: generate pkg-config file for libbpf by backporting libbpf-generate-pkg-config.patch from bpf-next. * Don't longer recommend irqbalance. (closes: #926967) * xen/pciback: Don't disable PCI_COMMAND on PCI device reset. (CVE-2015-8553) * [x86] Disable R3964 due to lack of security support * [mips] Fix indirect syscall tracing & seccomp filtering for big endian MIPS64 kernels with 32-bit userland. * [rt] Update to 4.19.37-rt19 These changes only affect non-release architectures: * [riscv64] linux-image-dbg: Include vdso debug symbols * [ia64] linux-image: Recommend grub-efi-ia64 instead of (removed) elilo * [sparc64] linux-image: Recommend grub-ieee1275 instead of (removed) silo * [sparc64] linux-image: Install uncompressed kernel image * [mips*r6] Re-enable CONFIG_JUMP_LABEL, which has been fixed in upstream. There will be an ABI bump. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Bug#928340: Linux 4.9.0-9-686: Boot hangs on Geode LX.
On Thu, 2019-05-02 at 14:44 +0200, Björn Persson wrote: > Package: src:linux > Version: 4.9.168-1 > Severity: critical > File: /boot/vmlinuz-4.9.0-9-686 > Justification: breaks the whole system > > Dear Maintainer, > > Debian 9 fails to boot on a Soekris net5501 with a Geode LX processor. > Debian 8 worked fine. Running Debian 9 on Linux 3.16.0-8-586 from Debian > 8 works. (That's what I'm running Reportbug on.) Linux 4.9.0-7-686, > 4.9.0-8-686 and 4.9.0-9-686 appear to hang early in the boot process. > The disk activity light remains lit when the system hangs. I'm attaching > a boot log acquired over a serial console. > > I'm reporting this against the kernel because replacing only the kernel > works around the problem, but it looks like SystemD has been started > when the hang occurs, so I suppose a userspace issue can't be completely > ruled out. > > Given that a kernel compiled for i586 works and one compiled for i686 > does not, one might suspect that the processor isn't i686-compatible. > This seems to be rather unclear. According to the release notes this > processor should still be supported. It has all of the flags that this > script tests for: > https://www.debian.org/releases/stretch/i386/release-notes/ch-information#i386-is-now-almost-i686 [...] The Geode LX's CPUID has family=5 (586), but I agree with your understanding that it has all the important features of a 686 and should still be supported. In fact, I've specifically enabled continued support for it in the current (buster/sid) 686 kernel configuration. I'm afraid I don't have any immediate ideas for how to fix or debug this. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Processed: severity of 928340 is important
Processing commands for cont...@bugs.debian.org: > severity 928340 important Bug #928340 [src:linux] Linux 4.9.0-9-686: Boot hangs on Geode LX. Severity set to 'important' from 'critical' > thanks Stopping processing here. Please contact me if you need assistance. -- 928340: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928340 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#928328: Intel I350-NIC shuts down ports after loosing carrier
No, i210 and i219 detect the carrier correctly even when un-plugging and plugging back the cable. Only the i350 fails to reconnect. Regards, Renne
Bug#928340: Linux 4.9.0-9-686: Boot hangs on Geode LX.
Package: src:linux Version: 4.9.168-1 Severity: critical File: /boot/vmlinuz-4.9.0-9-686 Justification: breaks the whole system Dear Maintainer, Debian 9 fails to boot on a Soekris net5501 with a Geode LX processor. Debian 8 worked fine. Running Debian 9 on Linux 3.16.0-8-586 from Debian 8 works. (That's what I'm running Reportbug on.) Linux 4.9.0-7-686, 4.9.0-8-686 and 4.9.0-9-686 appear to hang early in the boot process. The disk activity light remains lit when the system hangs. I'm attaching a boot log acquired over a serial console. I'm reporting this against the kernel because replacing only the kernel works around the problem, but it looks like SystemD has been started when the hang occurs, so I suppose a userspace issue can't be completely ruled out. Given that a kernel compiled for i586 works and one compiled for i686 does not, one might suspect that the processor isn't i686-compatible. This seems to be rather unclear. According to the release notes this processor should still be supported. It has all of the flags that this script tests for: https://www.debian.org/releases/stretch/i386/release-notes/ch-information#i386-is-now-almost-i686 On the debian-user mailing list, some people say that support for Geode LX has been dropped. Others say it should work. If it is actually no longer supported, then please reassign this bug report to the release notes. In that case the release notes should be updated to document this, and provide an accurate test. As near as I can tell this processor is a Geode LX 800. The bios boot screen calls it "Geode LX 500 MHz". It looks very much like this: https://commons.wikimedia.org/wiki/File:AMD_Geode_LX_800_CPU.jpg The text on the processor is: AMD Geode ALXC800EETJCVC 0703CQA 2003-05 C1 TAIWAN $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 microcode : 0x8b cpu MHz : 499.900 cache size : 128 KB fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow vmmcall bogomips: 999.80 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information ** PCI devices: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] Host Bridge [1022:2080] (rev 31) Subsystem: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] Host Bridge [1022:2080] 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- Kernel driver in use: via-rhine Kernel modules: via_rhine 00:07.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:3053] (rev 96) Subsystem: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:0106] 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: via-rhine Kernel modules: via_rhine 00:08.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:3053] (rev 96) Subsystem: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:0106] 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: via-rhine Kernel modules: via_rhine 00:09.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:3053] (rev 96) Subsystem: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:0106] 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: via-rhine Kernel modules: via_rhine 00:14.0 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] ISA [1022:2090] (rev 03) Subsystem: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] ISA [1022:2090] 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- ii grub-pc 2.02~beta3-5+deb9u1 pn linux-doc-4.9 Versions of packages linux-image-4.9.0-9-686 is related to: pn firmware-amd-graphics
Bug#928328: Intel I350-NIC shuts down ports after loosing carrier
Are other Intel NICs affected by this problem as well? Regards Harri
Processed: reassign 928328 to src:linux
Processing commands for cont...@bugs.debian.org: > reassign 928328 src:linux 4.19.28-2 Bug #928328 [linux-image ???] Intel I350-NIC shuts down ports after loosing carrier Warning: Unknown package 'linux-image' Bug reassigned from package 'linux-image ???' to 'src:linux'. No longer marked as found in versions 4.19.28-2. Ignoring request to alter fixed versions of bug #928328 to the same values previously set Bug #928328 [src:linux] Intel I350-NIC shuts down ports after loosing carrier Marked as found in versions linux/4.19.28-2. > thanks Stopping processing here. Please contact me if you need assistance. -- 928328: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928328 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
