Bug#953017: Fixes in Upstream
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
Bug#954294: __X32_SYSCALL_BIT being defined as UL constant breaks userspace
On Wed, Apr 8, 2020 at 7:34 AM Thorsten Glaser wrote: > > Hello, > > I’m writing to you because your name shows up on this: > > commit 45e29d119e9923ff14dfb840e3482bef1667bbfb > Author: Andy Lutomirski > Date: Wed Jul 3 13:34:05 2019 -0700 > > x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long > > Currently, it's an int. This is bizarre. Fortunately, the code using it > still works: ~__X32_SYSCALL_BIT is also int, so, if nr is unsigned long, > then C kindly sign-extends the ~__X32_SYSCALL_BIT part, and it actually > results in the desired value. > > This is far more subtle than it deserves to be. Syscall numbers are, for > all practical purposes, unsigned long, so make __X32_SYSCALL_BIT be > unsigned long. > > Signed-off-by: Andy Lutomirski > Signed-off-by: Thomas Gleixner > Link: > https://lkml.kernel.org/r/99b0d83ad891c67105470a1a6b63243fd63a5061.1562185330.git.l...@kernel.org > > This commit changed an uapi header, breaking userspace. Long debugging > story (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294 if you > are interested) short, it goes like this: > > libseccomp exposes an interface SCMP_SYS() which is designed to expand > to an int and be usable in cpp context. It redirects to the __NR_* > constants from . > > Example: SCMP_SYS(mmap) becomes __NR_mmap or __NR_mmap2 (depending on > the architecture). > > Now, most architectures define __NR_mmap as a mere integer number: > > asm/unistd_32.h:#define __NR_mmap 90 > asm/unistd_64.h:#define __NR_mmap 9 > > x32 differs: > > asm/unistd_x32.h:#define __NR_mmap (__X32_SYSCALL_BIT + 9) > > This construct is, thankfully, still usable in something like > #if (__NR_mmap > __NR_somethingelse) > but as __X32_SYSCALL_BIT is no longer int its type also isn’t. > > Therefore I ask you to revert this change, bringing x32 closer > to all other architectures. > One might reasonably ask whether it makes sense for syscall nrs to be signed at all. But regardless, this breaks userspace and we should fix it. I can whip up a patch to split it into X32_SYSCALL_BIT (unsigned long) and __X32_SYSCALL_BIT (uapi, int). Thomas, etc, does this seem reasonable? (For those not following all the machinations, this change caused some userspace build failures in libseccomp and/or systemd for reasons that are vaguely silly.) > > Syscall numbers are, for > > all practical purposes, unsigned long > > Yes, except for the one purpose of the C data type of the > syscall constants exposed to userspace, they are. > > Feel free to handle __X32_SYSCALL_BIT differently in the > kernel (although even there it *will* introduce subtle > differences from other architectures), but please keep it > as int as visible from userspace. > > Thanks in advance, > //mirabilos > > PS: Please keep both me *and* the Debian bug in Cc, but > feel free to forward to relevant lists and persons; > I’m unsure where exactly to write to about this. > > @bwh: commit 45e29d119e9923ff14dfb840e3482bef1667bbfb is > literally just this… > -#define __X32_SYSCALL_BIT 0x4000 > +#define __X32_SYSCALL_BIT 0x4000UL > … so can you please revert it in Debian in the meantime, > even if you said you won’t spend time on this? > -- > tarent solutions GmbH > Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ > Tel: +49 228 54881-393 • Fax: +49 228 54881-235 > HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 > Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg > > ** > > Mit der tarent Academy bieten wir auch Trainings und Schulungen in den > Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. > > Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. > > **
Bug#950578: Linux 5.5.0-1-arm64: kernel panic after module bcmgenet was loaded
Package: src:linux Version: 5.5.13-2 Severity: normal Dear Maintainer, I created an arm64 live system for Raspberry Pi 4 using Debian live-build, and it successfully booted into the initramfs. However, after the network module bcmgenet was loaded, I got the kernel panic. Attached please find the output messages on the serial console. If you need more info or tests, please let me know. Thank you very much. Steven -- Steven Shiau Public Key Server PGP Key ID: 4096R/163E3FB0 Fingerprint: EB1D D5BF 6F88 820B BCF5 356C 8E94 C9CD 163E 3FB0 [0.00] Booting Linux on physical CPU 0x00 [0x410fd083] [0.00] Linux version 5.5.0-1-arm64 (debian-kernel@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30) [0.00] Machine model: Raspberry Pi 4 Model B Rev 1.1 [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] cma: Reserved 256 MiB at 0xec00 [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x-0xfbff] [0.00] NUMA: NODE_DATA [mem 0xeb9a9100-0xeb9aafff] [0.00] Zone ranges: [0.00] DMA [mem 0x-0x3fff] [0.00] DMA32[mem 0x4000-0xfbff] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x07ff] [0.00] node 0: [mem 0x4000-0xfbff] [0.00] Initmem setup node 0 [mem 0x-0xfbff] [0.00] percpu: Embedded 32 pages/cpu s93656 r8192 d29224 u131072 [0.00] Detected PIPT I-cache on CPU0 [0.00] CPU features: detected: EL2 vector hardening [0.00] CPU features: kernel page table isolation forced ON by KASLR [0.00] CPU features: detected: Kernel page table isolation (KPTI) [0.00] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware [0.00] CPU features: detected: ARM erratum 1319367 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 790272 [0.00] Policy zone: DMA32 [0.00] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 cma=64M cma=256M cma=256M video=HDMI-A-1:1920x1080M@60,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48 smsc95xx.macaddr=DC:A6:32:55:44:A4 vc_mem.mem_base=0xec0 vc_mem.mem_size=0x1000 boot=live union=overlay config components noswap edd=on nomodeset enforcing=0 locales=en_US keyboard-layouts=en ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_batch="no" net.ifnames=0 noeject fetch=http://192.168.76.254/filesystem-czarm64.squashfs ocs_daemonon="ssh" console=ttyAMA0,115200n81 [0.00] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) [0.00] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] software IO TLB: mapped [mem 0x02684000-0x06684000] (64MB) [0.00] Memory: 2757316K/3211264K available (9980K kernel code, 1758K rwdata, 3684K rodata, 5120K init, 552K bss, 191804K reserved, 262144K cma-reserved) [0.00] random: get_random_u64 called from __kmem_cache_create+0x44/0x5c0 with crng_init=0 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] ftrace: allocating 35767 entries in 140 pages [0.00] ftrace: allocated 140 pages with 3 groups [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 [0.00] GIC: Using split EOI/Deactivate mode [0.00] arch_timer: cp15 timer(s) running at 54.00MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns [0.06] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns [0.000318] Console: colour dummy device 80x25 [0.000446] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=216000) [0.000460] pid_max: default: 32768 minimum: 301 [0.000628] LSM: Security Framework initializing [0.000660] Yama: disabled by default; enable with sysctl kernel.yama.* [0.000756] AppArmor: AppArmor initialized [0.000769] TOMOYO Linux initialized [0.000905] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) [0.000966] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) [0.003000] ASID allocator initialised with 32768 entries [0.003135]
Bug#956226: linux: dh-thin-pool module missing in md-modules udeb, d-i unable to remove thinly provisioned logical volume
Source: linux Version: 4.19.67-2+deb10u2 Severity: normal Tags: d-i patch The dm-thin-pool module is required when you want to run d-i on a machine which contains thinly provisioned logical volumes. Otherwise d-i is unable to remove them and you see messages like this from partman-lvm: > modprobe: FATAL: Module dm-thin-pool not found in directory > /lib/modules/4.9.0-9-amd64 [...] > Can't process LV vg_system/lv_system: thin-pool target support missing from > kernel? Thus I attach a patch to add the missing module in md-modules. I have also included the dependencies (dm-persistent-data and dm-bio-prison), I'm not sure if it's required... Cheers, Raphaël. -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS >From 3b91afe0e9bc9626d81ae6695a7072e4bd792ef3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= Date: Wed, 8 Apr 2020 17:51:54 +0200 Subject: [PATCH] udeb: add dm-thin-pool in md-modules udeb That module is required when you want to run d-i on a machine which contains thinly provisioned logical volumes. Otherwise d-i is unable to remove them and you see messages like this from partman-lvm: modprobe: FATAL: Module dm-thin-pool not found in directory /lib/modules/4.9.0-9-amd64 Can't process LV vg_system/lv_system: thin-pool target support missing from kernel? --- debian/installer/modules/md-modules | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/installer/modules/md-modules b/debian/installer/modules/md-modules index d4f710406d46..d2da3b835d4f 100644 --- a/debian/installer/modules/md-modules +++ b/debian/installer/modules/md-modules @@ -6,9 +6,12 @@ raid0 raid1 raid456 raid10 +dm-bio-prison dm-mirror +dm-persistent-data dm-raid dm-snapshot +dm-thin-pool bcache # RAID-related libraries, also used by btrfs -- 2.26.0
Bug#956224: firmware-realtek: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169
Package: firmware-realtek Version: 20190717-2 Severity: normal Hi! It seems that we are also missing /lib/firmware/rtl_nic/rtl8168fp-3.fw now: = update-initramfs: Generating /boot/initrd.img-5.5.0-1-amd64 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169 = Thank you! Best regards, Nelson -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools 0.136 -- no debconf information
linux-signed-i386_5.5.13+2_source.changes ACCEPTED into unstable, unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 30 Mar 2020 23:06:57 +0200 Source: linux-signed-i386 Architecture: source Version: 5.5.13+2 Distribution: sid Urgency: medium Maintainer: Debian Kernel Team Changed-By: Salvatore Bonaccorso Changes: linux-signed-i386 (5.5.13+2) unstable; urgency=medium . * Sign kernel from linux 5.5.13-2 . * bpf: Undo incorrect __reg_bound_offset32 handling (CVE-2020-8835) Checksums-Sha1: c50551902747b3140d785315bfdf783c790668f3 13606 linux-signed-i386_5.5.13+2.dsc c7b0dce3c9a77fa3efe1f53ac9949eb6fa48d8c6 2158448 linux-signed-i386_5.5.13+2.tar.xz Checksums-Sha256: 4ac627e578eeccbea7758fc0d7f39e8ac56e92b500fe402d2bc326cb0ed596f7 13606 linux-signed-i386_5.5.13+2.dsc 7baa796868f4b27a825ccf3f4bea50028b5a2fe068de0f958a07104b3a1fa42c 2158448 linux-signed-i386_5.5.13+2.tar.xz Files: 5aa573234f2faba760d7b042316c100f 13606 kernel optional linux-signed-i386_5.5.13+2.dsc 679578d3960174dc1101af1682c6efb3 2158448 kernel optional linux-signed-i386_5.5.13+2.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE8nXL3e4u3Tgu6Vp6qgZoiu+K+NUFAl6N0G8ACgkQqgZoiu+K +NUFyxAA5xQ5P2cnjv3ulqwRjF5cnQTjiaAsuX5DNB/dtAAUwIgoQ8XxMqs8+px6 anorchZzjjKBZIM94xq5E2CZq4vOFZYbK/zFDWLDWz9zyuQ9eYpqsi6B9aId2xiq O0UJPT5IzvwOrq31TVpJ2pKiLsIKBUKTt2E/FgXjyHF5hpvu5AWDG9ZKz8iswlko fyYPUsQM51JTd1LrDyNGzdY/SEZTzzL3+9fDMR2pckqp7HIG1jcfZFVbp55lhHXy ZGeBR/SJPEoiyWe/zsMgvT8jmJASCjrJOd/eXqQbvSDScOvgIilVHupCM10LVUXZ /gKpLBh+s+ZGgx3/3B8XxNfRqq5HxlEdkkb1CHgNiu002rGjq6qrBp9TeFCR5zdu 0bEsMEKtVud6inVtkSagX6oS6+eDlToDf2nGhoOuNkica3EW4Etp74YWHZeae7jl wWRg02WT2yAYkyaafxCItbbZsRG4LKrNrpN14LOeLzNgKRAXfziTJBhNdo4sJRVy CNwvq5IQ12ivJP42BoCffj98SZw19ojvpnPHbHrfQ3mX7O4uRhrBBPIlwJpo99m8 4KcfahxDAyk/gftD5iVHJONIagVCnD+TjWHVtzj+GTVAskUUppdeO25KaM15oKCQ Zukhp4ZnM4GOmVSWuHqmLBrq2pA3pRKwdwwNWgZRdVO7UCuSNR8= =m/Yd -END PGP SIGNATURE- Thank you for your contribution to Debian.
linux-signed-i386_5.5.13+2_source.changes is NEW
Mapping sid to unstable. binary:linux-image-5.5.0-1-686 is NEW. binary:linux-image-5.5.0-1-686-pae is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
Bug#956221: firmware-misc-nonfree: missing firmware i915/{icl_dmc_ver1_09,tgl_dmc_ver2_04,{skl,bxt,kbl,glk,cml,icl,ehl,tgl…
Package: firmware-misc-nonfree Version: 20190717-2 Severity: normal Setting up linux-image-5.5.0-1-amd64 (5.5.13-2) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.4.0-4-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-5.4.0-4-amd64 I: /vmlinuz is now a symlink to boot/vmlinuz-5.5.0-1-amd64 I: /initrd.img is now a symlink to boot/initrd.img-5.5.0-1-amd64 /etc/kernel/postinst.d/initramfs-tools: 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 -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) firmware-misc-nonfree depends on no packages. firmware-misc-nonfree recommends no packages. Versions of packages firmware-misc-nonfree suggests: ii initramfs-tools 0.136 -- no debconf information
Bug#954294: linux: __X32_SYSCALL_BIT being defined as UL constant breaks userspace (was Re: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to for
On Wed, 8 Apr 2020, Ben Hutchings wrote: > You should not expect me to spend time talking to upstream about non- > release architectures. That is way down the priority list. DevRef §5.8.3.(6) is a “must”, but you’re lucky: it turns out that this is a recent isolated change, so I can write to the persons in that commit. (Will do so in a follow-up mail, so they’re not confu‐ sed by Debian specifics.) The rationale for DevRef §5.8.3.(6) is that I, as user, would not know whom to contact on the upstream side: especially with the Linux kernel, there’s tons of maintainers, subsystems, mailing lists, etc. and I’d not have an idea where to contact. (Luckily, I *was* able to isolate it… this time. But I expect you to do at least the talking, generally.) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#954294: __X32_SYSCALL_BIT being defined as UL constant breaks userspace
Hello, I’m writing to you because your name shows up on this: commit 45e29d119e9923ff14dfb840e3482bef1667bbfb Author: Andy Lutomirski Date: Wed Jul 3 13:34:05 2019 -0700 x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long Currently, it's an int. This is bizarre. Fortunately, the code using it still works: ~__X32_SYSCALL_BIT is also int, so, if nr is unsigned long, then C kindly sign-extends the ~__X32_SYSCALL_BIT part, and it actually results in the desired value. This is far more subtle than it deserves to be. Syscall numbers are, for all practical purposes, unsigned long, so make __X32_SYSCALL_BIT be unsigned long. Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/99b0d83ad891c67105470a1a6b63243fd63a5061.1562185330.git.l...@kernel.org This commit changed an uapi header, breaking userspace. Long debugging story (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294 if you are interested) short, it goes like this: libseccomp exposes an interface SCMP_SYS() which is designed to expand to an int and be usable in cpp context. It redirects to the __NR_* constants from . Example: SCMP_SYS(mmap) becomes __NR_mmap or __NR_mmap2 (depending on the architecture). Now, most architectures define __NR_mmap as a mere integer number: asm/unistd_32.h:#define __NR_mmap 90 asm/unistd_64.h:#define __NR_mmap 9 x32 differs: asm/unistd_x32.h:#define __NR_mmap (__X32_SYSCALL_BIT + 9) This construct is, thankfully, still usable in something like #if (__NR_mmap > __NR_somethingelse) but as __X32_SYSCALL_BIT is no longer int its type also isn’t. Therefore I ask you to revert this change, bringing x32 closer to all other architectures. > Syscall numbers are, for > all practical purposes, unsigned long Yes, except for the one purpose of the C data type of the syscall constants exposed to userspace, they are. Feel free to handle __X32_SYSCALL_BIT differently in the kernel (although even there it *will* introduce subtle differences from other architectures), but please keep it as int as visible from userspace. Thanks in advance, //mirabilos PS: Please keep both me *and* the Debian bug in Cc, but feel free to forward to relevant lists and persons; I’m unsure where exactly to write to about this. @bwh: commit 45e29d119e9923ff14dfb840e3482bef1667bbfb is literally just this… -#define __X32_SYSCALL_BIT 0x4000 +#define __X32_SYSCALL_BIT 0x4000UL … so can you please revert it in Debian in the meantime, even if you said you won’t spend time on this? -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#954294: linux: __X32_SYSCALL_BIT being defined as UL constant breaks userspace (was Re: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to for
On Tue, 2020-04-07 at 14:40 +0200, Thorsten Glaser wrote: > Dear kernel team, > > libseccomp uses the __NR_* constants from in its > macro SCMP_SYS() which is designed to return int. > > However, on x32 some codes return unsigned long instead, breaking this. > The cause is that this… > > > /usr/include/x86_64-linux-gnux32/asm/unistd.h:#define __X32_SYSCALL_BIT > > 0x4000UL > > … is OR’d into the numbers. > > I’d like to propose the change… > -#define __X32_SYSCALL_BIT 0x4000UL > +#define __X32_SYSCALL_BIT 0x4000 > … which should be safe to do as the number fits into signed int, > but must be checked against other users (especially in the kernel > itself I’d guess). > > This should also technically be correct, since on all(?) other > architectures syscall numbers are int constants. > > Please forward this to upstream. You should not expect me to spend time talking to upstream about non- release architectures. That is way down the priority list. Ben. -- Ben Hutchings It's easier to fight for one's principles than to live up to them. signature.asc Description: This is a digitally signed message part
Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)
On Wed, 8 Apr 2020, Michael Biebl wrote: >> Is this workaround permanent or will systemd FTBFS again in the future? It is not inherently permanent. If a new libseccomp version gets uploaded it will pop back up. In these cases, I’ll most likely notice it due to Multi-Arch skew (my x32 system has libudev1:i386 and libudev1:x32 installed, so when the former shows up in apt’s output of “not updated” packages I’ll know), and it’s a matter of maybe half an hour to bring the hack back, and I’ve got permissions to give-back the systemd package so the buildds will build it. >> If seccomp support on x32 is causing so much trouble, we can just as >> well disable it in systemd for the time being by dropping libseccomp-dev >> from Build-Depends. My hope is to get this fixed in the kernel headers instead; it seems like a straight-forward fix, aligns x32 more with other architectures and seems to be the technically more correct solution, plus other packages might be similarily affected (but don’t show it as they don’t build with -Werror=format). >... on x32 only, of course. Yes, of course. >> Let me know what you prefer. For now, don’t take any action in systemd, and we’ll hope some kernel developer picks it up, but thanks for the offer. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Processing of linux-signed-i386_5.5.13+2_source.changes
linux-signed-i386_5.5.13+2_source.changes uploaded successfully to localhost along with the files: linux-signed-i386_5.5.13+2.dsc linux-signed-i386_5.5.13+2.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
linux-signed-arm64_5.5.13+2_source.changes ACCEPTED into unstable, unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 30 Mar 2020 23:06:57 +0200 Source: linux-signed-arm64 Architecture: source Version: 5.5.13+2 Distribution: sid Urgency: medium Maintainer: Debian Kernel Team Changed-By: Salvatore Bonaccorso Changes: linux-signed-arm64 (5.5.13+2) unstable; urgency=medium . * Sign kernel from linux 5.5.13-2 . * bpf: Undo incorrect __reg_bound_offset32 handling (CVE-2020-8835) Checksums-Sha1: 1805cc9eddd61781faacebe82c6abea1c1ddad01 6833 linux-signed-arm64_5.5.13+2.dsc 433aa3a2baf4f83231cfe49d0380460f0534038d 1179680 linux-signed-arm64_5.5.13+2.tar.xz Checksums-Sha256: 73d7ab75523ffeeefe5efde9cdf96510b3df181e4228fbb63c01e9cbdb041c45 6833 linux-signed-arm64_5.5.13+2.dsc 942dd62c5d8c6212e4d3d72ac9b8a9eb3d6c16fddc6936c0a9dd1b5d09ace08f 1179680 linux-signed-arm64_5.5.13+2.tar.xz Files: b2e7e0aecd6f7e46a24328109320ab24 6833 kernel optional linux-signed-arm64_5.5.13+2.dsc fc187e29d7b3d39c74d971aadd98fb36 1179680 kernel optional linux-signed-arm64_5.5.13+2.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE8nXL3e4u3Tgu6Vp6qgZoiu+K+NUFAl6Nt0UACgkQqgZoiu+K +NXpuxAA0GdWpn9QWAA3YCXFBEFMCCFFTNqK54SKh2rSIBhE+QjBt1tJ5btSTdbz hbqthqFJZDOiqHrEVDrFPQm8hTW2gp0GH5794woJH8KxwDq71RZVyM/To20sttnt NqjsgxWK8QoMQcsWGtz3Kbb+M40BolodRkvhExNU9B0OgS7gRVf+Di++yqHWhl7Z VW4PGp7LGaMvAcvxfekEjJll5TAn7PiDGAgdvyPMgDUlljg6VzRHGwJH6Ax6omci 7Y3qAiqPkBvfDfWgQPzAOu6vm9g3KdExuH6t6eVBFcH1fEjiyakk0t1AIfqTt++Y OwWRDb3l0naF+vLs/4ZSkjnrm32qzIlKO4v3MnnBIurR0U0HW5gj6jn0qzDpc6qi 4/JNKdHXBzHqUgmv7T6PtA9YBzIL6BS/a9pguT4U51N/DzadUZp7NLHrMN09/j56 0P5c0XlkhQuF087j6T5EQyUk3mz3fXhNqqjOmSQ2cpU7rUCSSe1mlSGnmsLSHZjl CfP/eUDqwn432NOzhgZtARtn/g1lTKVFznfLKp2XuIlREztsizqLqP5xBtc5XGhw PODSLf2IsfeZHRjl+Bfm7prf7Pl2/UcJlWnp1h4WZp611jrmCtirJ8lLHxEmSHXq lHhOtHSwVBlsRe8shgS47998xi/1ZwF81iq0IiXyB03LkUr6QbE= =C6J8 -END PGP SIGNATURE- Thank you for your contribution to Debian.
linux-signed-arm64_5.5.13+2_source.changes is NEW
Mapping sid to unstable. binary:linux-headers-cloud-arm64 is NEW. binary:linux-image-5.5.0-1-arm64 is NEW. binary:linux-image-5.5.0-1-cloud-arm64 is NEW. binary:linux-image-cloud-arm64 is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
linux-signed-amd64_5.5.13+2_source.changes ACCEPTED into unstable, unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 30 Mar 2020 23:06:57 +0200 Source: linux-signed-amd64 Architecture: source Version: 5.5.13+2 Distribution: sid Urgency: medium Maintainer: Debian Kernel Team Changed-By: Salvatore Bonaccorso Changes: linux-signed-amd64 (5.5.13+2) unstable; urgency=medium . * Sign kernel from linux 5.5.13-2 . * bpf: Undo incorrect __reg_bound_offset32 handling (CVE-2020-8835) Checksums-Sha1: fe1066123825c329fa98ead4ecc5d97e6892660a 8057 linux-signed-amd64_5.5.13+2.dsc bbf83d15143f90f8ecfeb2fdc1a5056f9b6d779b 1338704 linux-signed-amd64_5.5.13+2.tar.xz Checksums-Sha256: 572a404402b3a921a637622b18967b5fc8b062c8463f378efeb40278536a7c09 8057 linux-signed-amd64_5.5.13+2.dsc 7babee811ff32ee741eb6e4aba7bf71dc8a333699e6ce9fc022d64e1433c537c 1338704 linux-signed-amd64_5.5.13+2.tar.xz Files: 45087f6a633cddade81c96c86408 8057 kernel optional linux-signed-amd64_5.5.13+2.dsc bfd454adefaee9cfdc78d28826410e31 1338704 kernel optional linux-signed-amd64_5.5.13+2.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE8nXL3e4u3Tgu6Vp6qgZoiu+K+NUFAl6NsrMACgkQqgZoiu+K +NWrIg//eC1APb/aa9KmmzEELnZ4x+M91nhBVF2zwmUPogHxeVvQuQ5Sd4eik+Mk 5gULnJQk0shJ9ekbEgYCcrdbgcJFmXl7GgVXmgqT3+KKnvRmLkY/Jq3lbdSP/zSI wFObbksymL+id0EWK4MyyGGQJR5YfChmcBKHCXu9Wt4AZDsvJCqhhaGq3i415xDC qz7TpGdb+r4T+wc2H5IwThk4O1tozH0MP1yYHN349BDogN9a0UYUVi5pGh7Aetbv JSpHuh4SokQ17A7IWtIgdjcstrJuJff/TfH717VgxsVcVsZHOXFDm6tDLfbPi+wO OS1KsGVFI4kskxouHlaGmuFig+IO9qkw3X2x5ycwRHPXF2RkeJ6cWRLkd0FqSw8G ujqxdCz1Kqhd+AxZXnjAfbI8keDPiB1D+l4iOrxKOwlZ+gFTvCR3uwi482nS6fRb BobJEOHfOJIimYL9rIKN20KbvfN3BY5KqtPplABRIB5RxmViq9W8WUpCHI03BEA5 atMEvtgJr310+MX09km2JcmJGFPIY6VOdLg15u6SBGXkuzOIyawuUq5GpX3b7IG/ W2M/q+J6LWQncyIvOcozogq9JsKiH+xECVDjIsXqivg3efIPOogIxucfdZSdX7sO aqLwH7nwfEnhhF4XF8TNnwVwqXqqWyCK7Kbd+a5cmTMMTGfv23M= =LIHu -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of linux-signed-arm64_5.5.13+2_source.changes
linux-signed-arm64_5.5.13+2_source.changes uploaded successfully to localhost along with the files: linux-signed-arm64_5.5.13+2.dsc linux-signed-arm64_5.5.13+2.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
linux-signed-amd64_5.5.13+2_source.changes is NEW
Mapping sid to unstable. binary:linux-image-5.5.0-1-amd64 is NEW. binary:linux-image-5.5.0-1-cloud-amd64 is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
Processing of linux-signed-amd64_5.5.13+2_source.changes
linux-signed-amd64_5.5.13+2_source.changes uploaded successfully to localhost along with the files: linux-signed-amd64_5.5.13+2.dsc linux-signed-amd64_5.5.13+2.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#956197: src:linux: lockdown: set default (with Secure Boot) to LOCKDOWN_INTEGRITY_MAX
Source: linux Version: 5.5.13-2 Severity: wishlist Tags: patch X-Debbugs-CC: quen...@isovalent.com Dear Maintainer(s), LOCKDOWN_CONFIDENTIALITY_MAX restricts a lot of useful features, even security ones (like monitoring via BPF), while not adding that much value for common use cases. Recently, Ubuntu, RedHat and SUSE changed the default to LOCKDOWN_INTEGRITY_MAX. I believe we should do the same. MR: https://salsa.debian.org/kernel-team/linux/-/merge_requests/230 References: https://github.com/iovisor/bcc/issues/2565#issuecomment-606566675 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1868626 https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/?id=ef7c6600bb3e https://bugzilla.redhat.com/show_bug.cgi?id=1815571 Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)
Am 08.04.20 um 09:56 schrieb Michael Biebl: > If seccomp support on x32 is causing so much trouble, we can just as > well disable it in systemd for the time being by dropping libseccomp-dev > from Build-Depends ... on x32 only, of course. signature.asc Description: OpenPGP digital signature
Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)
Am 07.04.20 um 14:26 schrieb Thorsten Glaser:
> retitle 954294 linux: __X32_SYSCALL_BIT being defined as UL constant breaks
> userspace
> reassign 954294
> found 954294 5.5.13-2
> thanks
>
> Dixi quod…
>
>>> -#define SCMP_SYS(x) (__SNR_##x)
>>> +#define SCMP_SYS(x) ((int)__SNR_##x)
>>
>> Ouch, this hasn’t worked:
>>
>> ../src/shared/seccomp-util.c: In function ‘seccomp_restrict_sxid’:
>>
>> ../src/shared/seccomp-util.c:1977:5: error: missing binary operator before
>> token "("
>> 1977 | #if SCMP_SYS(open) > 0
>>
>> | ^~~~
>>
>
> Turns out that __X32_SYSCALL_BIT is OR’d into the __NR_* things
> and defined, by default, as unsigned long constant.
>
> /usr/include/x86_64-linux-gnux32/asm/unistd.h:#define __X32_SYSCALL_BIT
> 0x4000UL
>
> I’ve uploaded a workaround (attached); reassigning.
Is this workaround permanent or will systemd FTBFS again in the future?
If seccomp support on x32 is causing so much trouble, we can just as
well disable it in systemd for the time being by dropping libseccomp-dev
from Build-Depends.
Let me know what you prefer.
Michael
signature.asc
Description: OpenPGP digital signature
