Bug#1041015: Drivers for Dell Wireless 380 Bluetooth Card wanted

[Al Ma]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1
In the journal I see red lines
firmware_class: See https://wiki.debian.org/Firmware 
https://wiki.debian.org/Firmware for information about missing firmware
bluetooth hci0: firmware: failed to load brcm/BCM20702A1-413c-8197.hcd (-2)
bluetooth hci0: firmware: failed to load brcm/BCM-413c-8197.hcd (-2)
bluetooth hci0: firmware: failed to load brcm/BCM-413c-8197.hcd (-2)
Bluetooth: hci0: BCM: firmware Patch file not found, tried:
Bluetooth: hci0: BCM: 'brcm/BCM20702A1-413c-8197.hcd'
Bluetooth: hci0: BCM: 'brcm/BCM-413c-8197.hcd'
More errors/warnings concerning bluetooth follow later. The card is a built-in 
“Dell Wireless 380 Bluetooth Card” on a Dell Mobile Precision M6700. I failed 
to find the requested files myself. Any help/remedy/fix?
(As opposed to #1013895, no USB dongles are plugged into our machine; all the 
USB ports are free.)
Gratefully,
AlMa

linux_6.1.38-1_source.changes ACCEPTED into proposed-updates->stable-new

[Debian FTP Masters]

Thank you for your contribution to Debian.

Mapping bookworm to stable.
Mapping stable to proposed-updates.

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 14 Jul 2023 05:46:44 +0200
Source: linux
Architecture: source
Version: 6.1.38-1
Distribution: bookworm
Urgency: medium
Maintainer: Debian Kernel Team 
Changed-By: Salvatore Bonaccorso 
Changes:
 linux (6.1.38-1) bookworm; urgency=medium
 .
   * New upstream stable update:
 https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.38
 - drm/amd/display: Remove optimization for VRR updates
 - drm/amd/display: Do not update DRR while BW optimizations pending
 - PCI/ACPI: Validate acpi_pci_set_power_state() parameter
 - PCI/ACPI: Call _REG when transitioning D-states
 - execve: always mark stack as growing down during early stack setup
 - perf symbols: Symbol lookup with kcore can fail if multiple segments 
match
   stext
 - scripts/tags.sh: Resolve gtags empty index generation
 - drm/amdgpu: Validate VM ioctl flags.
 - drm/amd/display: Ensure vmin and vmax adjust for DCE
 .
   [ Salvatore Bonaccorso ]
   * drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2
   * mm/mmap: Fix VM_LOCKED check in do_vmi_align_munmap()
   * netfilter: nf_tables: do not ignore genmask when looking up chain by id
 (CVE-2023-31248)
   * netfilter: nf_tables: prevent OOB access in nft_byteorder_eval
 (CVE-2023-35001)
Checksums-Sha1:
 b25bbbdf61934b82b6733346b78b3a17129b6c11 290924 linux_6.1.38-1.dsc
 e6aa172bf5986121ed2364580b17199dcd4aa271 137332648 linux_6.1.38.orig.tar.xz
 4f626eca7394af695324b0a2b932f46af6ee 4004596 linux_6.1.38-1.debian.tar.xz
 6a76dcf281fc7b408b84ed6a1c8c36947b8eef4e 6857 linux_6.1.38-1_source.buildinfo
Checksums-Sha256:
 2a2a0b22812f38161a848e3a23913642378de3e3a1900667d1c0c5a0d92b5011 290924 
linux_6.1.38-1.dsc
 89ec2ca3af4376d3ac4adc900920238c76c671f89785746a1b2a498851e47d19 137332648 
linux_6.1.38.orig.tar.xz
 10713975b72d8deec39ec98c279e395c8309804c9ee2149252378aa627805c50 4004596 
linux_6.1.38-1.debian.tar.xz
 1df13282eff785bb4a7996f6a5c6b98adccf70ed4804ec0fd069e9071354beae 6857 
linux_6.1.38-1_source.buildinfo
Files:
 0fa834bfad1f90ebc8cab2c023637055 290924 kernel optional linux_6.1.38-1.dsc
 ac1b8c9b011c057362e5a228d1268517 137332648 kernel optional 
linux_6.1.38.orig.tar.xz
 eb4ce40bb9d20d0a2434a1212a393a2e 4004596 kernel optional 
linux_6.1.38-1.debian.tar.xz
 40fb02d58fbeb637ce141c139f910b6b 6857 kernel optional 
linux_6.1.38-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmSwxgJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk
ZWJpYW4ub3JnAAoJEAVMuPMTQ89ECCgP/i4HgMv8bYzHzmWb4ru1Tzxuij+UleJW
otLTWpzmyoh2yRsFPI3LBQRyK6UN4y4pkNW8h3Iy9IF/EOYW4gmglJNeoFuAzB/i
lilzZYTnwEbchPOL1etQ3IYHJNcHbL1tNYJMqf8lyYdwgcEZpuoIhug79lRnIrJM
NuhHmZMGRKcguHFozUvPCqrMDq/CVdaYPmmxGKVxRy71FSUpFaz4HFLG28yxkUIM
MGLdksZMG7Tp4y/CuqMFZCsYrJB7JIgQxZiZrLoccK/o3Wp3zTkrWAEoJaJyKO/b
D9pyXRh/C5ZcHLPBn0P/McAHaV2LEHfoxls/lq296P9HgOHPJEJMOT42BYO3k5/b
bsIJEPlmaJ1htSvWEF/Swb1nP3AWZYzAyk9jpuF8WcybqSiFLoMo7iduWN+2ib2m
h4PsB5fRFk5IBSxpzyvcNwLPMfaWaBE5j8OaxxiD4N1lnbLmaYOAM/fswDCcgiXU
j6iwZkGkzCTedXEpDq0EMBcjvg0kg3c5QFtGc+a4vDjO9HRslFFPKzGgE14DfNDF
gAy4PRoEqs0KMpyI4F4d82T+nOyZiFfRDGyQ7aYgvcMkhwVlFEYUl8O2JwqZya7x
CpVyXaQnd0+kTaA1BGxgeBc9XE5nl2MgIStgp2kjilNNMLK7NljX8n8OOHNQCn3x
nqpMhOVZxn+7
=F+3D
-END PGP SIGNATURE-

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Helge Deller]

On 7/14/23 01:56, Thorsten Glaser wrote:

Dixi quod…


My guess here is that it’s, as usual, the fault of qemu-user,


Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:

$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)


what does this show?:
QEMU_STRACE=1 qemu-arm-static -d cpu ./fstype --help

I still believe, that the problem is that qemu's brk(NULL) doesn't return
a page-aligned address, which will have lots of other side-effects.
(see Andreas' RISC-V crash here: 
https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg00645.html)

Helge

Processing of linux_6.1.38-1_source.changes

[Debian FTP Masters]

linux_6.1.38-1_source.changes uploaded successfully to localhost
along with the files:
  linux_6.1.38-1.dsc
  linux_6.1.38.orig.tar.xz
  linux_6.1.38-1.debian.tar.xz
  linux_6.1.38-1_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Dixi quod…

>My guess here is that it’s, as usual, the fault of qemu-user,

Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:

$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

And:

GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/qemu-arm-static...
Downloading separate debug info for /usr/bin/qemu-arm-static...
Reading symbols from 
/home/tglase/.cache/debuginfod_client/5a14d0155c981c94a528d6468ded2c203f1e1908/debuginfo...
(gdb) r
Starting program: /usr/bin/qemu-arm-static ./fstype --help
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x77ff8700 (LWP 27273)]

Thread 1 "qemu-arm-static" received signal SIGSEGV, Segmentation fault.
0x004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) at 
./include/qemu/bswap.h:329
Download failed: Invalid argument.  Continuing without source file 
./b/user-static/./include/qemu/bswap.h.
329 ./include/qemu/bswap.h: No such file or directory.
(gdb) bt
#0  0x004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) 
at ./include/qemu/bswap.h:329
#1  0x0045c9ac in translator_lduw_swap (do_swap=false, pc=, env=0xcbed30)
at ./include/exec/translator.h:178
#2  arm_lduw_code (sctlr_b=false, addr=, env=0xcbed30) at 
../../target/arm/arm_ldst.h:44
#3  thumb_tr_translate_insn (dcbase=0x7fffdd50, cpu=) at 
../../target/arm/translate.c:9054
#4  0x004bc1e9 in translator_loop (ops=0xa7f180 , 
db=db@entry=0x7fffdd50,
cpu=cpu@entry=0xcb6a60, tb=tb@entry=0x7fffe840 , 
max_insns=max_insns@entry=512)
at ../../accel/tcg/translator.c:103
#5  0x00463eb3 in gen_intermediate_code (cpu=cpu@entry=0xcb6a60,
tb=tb@entry=0x7fffe840 , 
max_insns=max_insns@entry=512)
at ../../target/arm/translate.c:9283
#6  0x00512d75 in tb_gen_code (cpu=cpu@entry=0xcb6a60, pc=3670264, 
cs_base=0, flags=1196288,
cflags=-16777216, cflags@entry=0) at ../../accel/tcg/translate-all.c:1744
#7  0x004b4734 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, 
cpu=0xcb6a60)
at ../../accel/tcg/cpu-exec.c:414
#8  cpu_exec (cpu=cpu@entry=0xcb6a60) at ../../accel/tcg/cpu-exec.c:770
#9  0x00422608 in cpu_loop (env=env@entry=0xcbed30) at 
../../linux-user/arm/cpu_loop.c:237
#10 0x00402949 in main (argc=, argv=0x7fffe230, 
envp=)
at ../../linux-user/main.c:882
(gdb) info r
rax0x40d94000  1087979520
rbx0x7fffdd50  140737488346448
rcx0xd9a72814264104
rdx0xc64d6012995936
rsi0x3800f83670264
rdi0xcbed3013364528
rbp0x0 0x0
rsp0x7fffdc48  0x7fffdc48
r8 0xc64d6012995936
r9 0xc656e812998376
r100x0 0
r110x0 0
r120xcbed3013364528
r130x0 0
r140x0 0
r150x7fffdd50  140737488346448
rip0x4c5cb60x4c5cb6 
eflags 0x10246 [ PF ZF IF RF ]
cs 0x3351
ss 0x2b43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) disas
Dump of assembler code for function cpu_lduw_code:
   0x004c5ca0 <+0>: movQWORD PTR fs:0xff58,0x1
   0x004c5cad <+13>:movesi,esi
   0x004c5caf <+15>:movrax,QWORD PTR [rip+0x79efa2]# 
0xc64c58 
=> 0x004c5cb6 <+22>:movzx  eax,WORD PTR [rax+rsi*1]
   0x004c5cba <+26>:movQWORD PTR fs:0xff58,0x0
   0x004c5cc7 <+39>:ret
End of assembler dump.


The content of rax (guest_base) looks legit:

$ cat /proc/27269/maps
0040-00401000 r--p  fd:00 2624234
/usr/bin/qemu-arm-static
00401000-0071e000 r-xp 1000 fd:00 2624234

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Hi Helge,

>Can you check if this patch fixes the problem:
>https://patchew.org/QEMU/mvmpm55qnno@suse.de/
>(linux-user: make sure brk(0) returns a page-aligned value,   from Andreas 
>Schwab)

I doubt it, klibc malloc uses mmap(2) normally.

(And given I tested it on a bullseye system, the mmap bug in the
bookworm kernel is also not applicable.)

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Helge Deller]

Can you check if this patch fixes the problem:
https://patchew.org/QEMU/mvmpm55qnno@suse.de/
(linux-user: make sure brk(0) returns a page-aligned value,   from Andreas 
Schwab)
 Ursprüngliche Nachricht Von: Thorsten Glaser  
Datum: 14.07.23  00:48  (GMT+01:00) An: venkata.p...@toshiba-tsip.com, 
1040...@bugs.debian.org, pkg-qemu-de...@lists.alioth.debian.org Cc: 
dinesh.ku...@toshiba-tsip.com Betreff: Bug#1040981: klibc-utils: Segmentation 
fault while executin klibc binaries in armhf architecture under qemu-user 
retitle 1040981 klibc-utils: segfault executing armhf binaries under 
qemu-userthanksvenkata.p...@toshiba-tsip.com dixit:>Follow below steps to 
reproduce this issue>```>$ sudo debootstrap --arch=arm bookworm 
arm-bookworm-rootfs/ http://deb.debian.org/debian/>$ sudo chroot arm-bookworm/ 
apt-update && apt install -y klibc-utils>$ sudo chroot arm-bookworm/ 
/usr/lib/klibc/bin/fstype --help>qemu: uncaught target signal 11 (Segmentation 
fault) - core dumped>Segmentation fault>```Same when just copying 
klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so outof libklibc_2.0.12-1_armhf.deb into 
/lib/ and extracting fstypefrom klibc-utils_2.0.12-1_armhf.deb… however it 
works both on areal-metal ARM box (amdahl.d.o) and a statically(!) linked 
mkshagainst klibc :/My guess here is that it’s, as usual, the fault of 
qemu-user,which has multiple outstanding emulation bugs, some of whichaffecting 
klibc-built binaries especially, though this, sincea statically linked mksh 
works, is probably an issue with howqemu-user handles .interp *shrug*Since your 
one-stage debootstrap succeeds, can you not do theremaining steps booting into 
the image-under-preparation andrun them there? Here, qemu-system-armhf should 
probably suffice.I know, it’s just as a workaround, until the people in 
questionfigure out why this happens.bye,//mirabilos-- Solange man keine 
schmutzigen Tricks macht, und ich meine *wirklich*schmutzige Tricks, wie bei 
einer doppelt verketteten Liste beidePointer XORen und in nur einem Word 
speichern, funktioniert Boehm ganzhervorragend.   -- Andreas Bogk über 
boehm-gc in d.a.s.r

Processed: Re: Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
Bug #1040981 [klibc-utils] klibc-utils: Segmentation fault while executin klibc 
binaries in armhf architecture
Changed Bug title to 'klibc-utils: segfault executing armhf binaries under 
qemu-user' from 'klibc-utils: Segmentation fault while executin klibc binaries 
in armhf architecture'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1040981: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040981
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Dixi quod…

>My guess here is that it’s, as usual, the fault of qemu-user,
>which has multiple outstanding emulation bugs, some of which
>affecting klibc-built binaries especially, though this, since
>a statically linked mksh works, is probably an issue with how
>qemu-user handles .interp *shrug*

An interesting data point (here on a bullseye/amd64 system):

$ /usr/lib/klibc/bin/fstype --help
--help: No such file or directory
$ /lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so  /usr/lib/klibc/bin/fstype --help
Segmentation fault (core dumped)

So running the interpreter directly is already not supported.
I’m guessing that that is what qemu-user tries, though.

Wild shoot into the blue but maybe it helps…

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Thorsten Glaser]

retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
thanks

venkata.p...@toshiba-tsip.com dixit:

>Follow below steps to reproduce this issue
>```
>$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ 
>http://deb.debian.org/debian/
>$ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
>$ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
>qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>Segmentation fault
>```

Same when just copying klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so out
of libklibc_2.0.12-1_armhf.deb into /lib/ and extracting fstype
from klibc-utils_2.0.12-1_armhf.deb… however it works both on a
real-metal ARM box (amdahl.d.o) and a statically(!) linked mksh
against klibc :/

My guess here is that it’s, as usual, the fault of qemu-user,
which has multiple outstanding emulation bugs, some of which
affecting klibc-built binaries especially, though this, since
a statically linked mksh works, is probably an issue with how
qemu-user handles .interp *shrug*

Since your one-stage debootstrap succeeds, can you not do the
remaining steps booting into the image-under-preparation and
run them there? Here, qemu-system-armhf should probably suffice.
I know, it’s just as a workaround, until the people in question
figure out why this happens.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#1041007: linux-image-6.1.0-0.deb11.7-amd64: Please enable TPM hardware RNG support (CONFIG_HW_RANDOM_TPM)

[jflf_kernel]

Package: src:linux
Version: 6.1.20-2~bpo11+1
Severity: normal
X-Debbugs-Cc: jflf_ker...@gmx.com

Dear Maintainer,

Currently no Debian kernel enables support for TPM hardware RNG. On one of my
systems:

$ uname -a
Linux XXX 6.1.0-0.deb11.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.20-2~bpo11+1 (2023-04-23) x86_64 GNU/Linux

$ cat /sys/class/tpm/tpm0/device/description
TPM 2.0 Device

$ ls /dev/tpm*
/dev/tpm0  /dev/tpmrm0

$ sudo tpm2_getrandom 16 | xxd -p
7ba65632453b191385a3989485ac80a3

$ grep HW_RANDOM_TPM /boot/config-$(uname -r)


$ find /lib/modules/$(uname -r) -iname \*tpm\*rng\*


$ ls /dev/hwrng
ls: cannot access '/dev/hwrng': No such file or directory


I have checked the current bookworm and trixie kernel debs, and they don't
include it either. It should be enabled there too.

I manage multiple older amd64 machines that have discrete TPM chips, but no
RDRAND instruction or any other hardware RNG. Enabling support for the TPM RNG
would provide the kernel with additional entropy earlier in the boot process.

Thank you very much!


-- Package-specific info:
** Version:
Linux version 6.1.0-0.deb11.7-amd64 (debian-kernel@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP PREEMPT_DYNAMIC Debian 6.1.20-2~bpo11+1 (2023-04-23)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.7-amd64 
root=UUID=0c206836-a588-4a57-9c6d-92d3f3e20d01 ro quiet nmi_watchdog=0

** Tainted: PUOE (12353)
 * proprietary module was loaded
 * taint requested by userspace application
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Jul 13 07:19:40 silverpad kernel: ACPI: SSDT 0xD7FFA000 0004B7 (v02 
LENOVO Tpm2Tabl 1000 INTL 20141107)
Jul 13 07:19:40 silverpad kernel: ACPI: TPM2 0xD7FF8000 34 (v03 
LENOVO TP-R0C   1370 PTEC 0002)
Jul 13 07:19:40 silverpad kernel: ACPI: Reserving TPM2 table memory at [mem 
0xd7ff8000-0xd7ff8033]

** Model information
sys_vendor: LENOVO
product_name: 20GJCTO1WW
product_version: ThinkPad 13
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: R0CET49W (1.37 )
board_vendor: LENOVO
board_name: 20GJCTO1WW
board_version: SDK0J40709 WIN

** Loaded modules:
isofs
cdrom
uas
usb_storage
uinput
ctr
ccm
rfcomm
nft_fib_inet
nft_fib_ipv4
nft_fib_ipv6
nft_fib
nft_reject_inet
nf_reject_ipv4
vboxnetadp(OE)
nf_reject_ipv6
vboxnetflt(OE)
nft_reject
nft_ct
nft_chain_nat
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
vboxdrv(OE)
ip_set
nf_tables
nfnetlink
zstd
zstd_compress
cmac
algif_hash
algif_skcipher
zram
af_alg
zsmalloc
bnep
zfs(POE)
zunicode(POE)
zzstd(OE)
zlua(OE)
zavl(POE)
icp(POE)
zcommon(POE)
znvpair(POE)
spl(OE)
hid_logitech
ff_memless
hid_generic
snd_usb_audio
usbhid
snd_usbmidi_lib
snd_rawmidi
hid
snd_seq_device
cdc_ether
usbnet
r8152
mii
btusb
btrtl
btbcm
btintel
btmtk
bluetooth
jitterentropy_rng
uvcvideo
videobuf2_vmalloc
drbg
videobuf2_memops
videobuf2_v4l2
ansi_cprng
videobuf2_common
ecdh_generic
ecc
videodev
crc16
mc
snd_sof_pci_intel_skl
intel_rapl_msr
intel_rapl_common
snd_sof_intel_hda_common
snd_hda_codec_hdmi
x86_pkg_temp_thermal
intel_powerclamp
soundwire_intel
soundwire_generic_allocation
soundwire_cadence
coretemp
snd_sof_intel_hda
crc32_pclmul
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
soundwire_bus
ghash_clmulni_intel
sha512_ssse3
sha512_generic
snd_soc_skl
snd_soc_hdac_hda
snd_ctl_led
snd_hda_ext_core
snd_soc_sst_ipc
snd_hda_codec_realtek
snd_soc_sst_dsp
snd_soc_acpi_intel_match
snd_soc_acpi
snd_hda_codec_generic
snd_soc_core
snd_compress
iwlmvm
snd_hda_intel
snd_intel_dspcfg
snd_intel_sdw_acpi
snd_hda_codec
intel_xhci_usb_role_switch
roles
snd_hda_core
aesni_intel
mac80211
crypto_simd
snd_hwdep
xhci_pci
cryptd
xhci_hcd
snd_pcm
mei_hdcp
ee1004
nls_ascii
rapl
libarc4
iwlwifi
e1000e
thinkpad_acpi
usbcore
nls_cp437
i2c_i801
mei_me
ptp
snd_timer
nvram
think_lmi
intel_lpss_pci
intel_cstate
platform_profile
vfat
intel_lpss
ledtrig_audio
fat
cfg80211
intel_uncore
intel_wmi_thunderbolt
wmi_bmof
firmware_attributes_class
pps_core
mei
i2c_smbus
usb_common
snd
idma64
intel_pch_thermal
battery
soundcore
rfkill
ac
button
intel_pmc_core
acpi_pad
joydev
sg
msr
sunrpc
ecryptfs
fuse
efi_pstore
configfs
ip_tables
x_tables
xfs
efivarfs
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
xor
async_tx
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
i915
i2c_algo_bit
drm_buddy
drm_display_helper
sd_mod
t10_pi
drm_kms_helper
crc64_rocksoft
crc64
crc_t10dif
cec
crct10dif_generic
rc_core
ahci
crct10dif_pclmul
libahci
ttm
crct10dif_common
libata
drm
crc32c_intel
psmouse
scsi_mod
evdev
serio_raw
scsi_common
video
wmi

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/4 CPU threads; 

Re: Debian Kernel version and ABI in respect of #1040901

[Adrian Bunk]

On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote:
>...
> ### NMU
> 
> Can be easily added back by adding "bX" or so to the ABI.

That would be confusing, bX is naming convention for binNMUs in Debian 
revisions.

> ### BinNMU
> 
> Is impossible to support.  The version change requires changes in the
> names of the created packages.
>...

It should only be impossible to make them co-installable,
or what other reason requires a rename?

cu
Adrian

Bug#1040901: linux modules must not be signed with CA key, bump ABI every upload

[Ben Hutchings]

On Wed, 12 Jul 2023 10:05:03 +0200 Julian Andres Klode 
wrote:
[...]
> A reasonable compromise at a first step for a limited time is to
> ensure that
> 
> 1) the kernel refuses to load modules for a different ABI in
lockdown,
>    for example, the modprobe --force-vermagic does not work anymore.
[...]

I already implemented that in 2016.  Did it break?

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug



signature.asc
Description: This is a digitally signed message part

Processed: severity of 1040966 is important

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 1040966 important
Bug #1040966 [src:linux] linux-image-6.1.0-9-amd64: Thinkpad T470 fails to wake 
from suspend after bookworm upgrade
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1040966: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040966
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Debian Kernel version and ABI in respect of #1040901

[Bastian Blank]

Hi folks

You might have heard that the masters of Linux Secure Boot, aka shim
reviewers, have spoken.  They have told us that our way of handling
kernel modules is not longer acceptable.  For some context see #1040901.

This means for us that we have to make sure that kernel and modules
can't be mixed between different builds.  If we want to continue with
the current behaviour, where you can keep old kernels usable, we have to
rename packages and kernel internal ABI on every upload.

This is the first version of a proposal that should work. But it also
ignores some Debian and release policy points to avoid some problematic
behaviour.  For example it should not possible for package names to grow
unrestricted.

Please share your thoughts or if we have a better solution overall.

Regards,
Bastian

## Current behaviour

Currently in use are the following types:

* experimental:
Version 6.1~rc2-3~exp4, 6.1.2-3~exp4
ABI 6.1.0-0-arm64
* unstable/testing/stable:
Version 6.1.2-3
ABI 6.1.0-1-arm64
* security/LTS:
Version 6.1.2-3~deb12u4
ABI 6.1.0-1-arm64
* backports:
Version 6.1.2-3~bpo12+4
ABI 6.1.0-0.bpo.1-arm64

But our version check allows allow more variants, including NMU, BinNMU,
local versions, +bpo, ~deb11u1~deb10u1.

## Proposed behaviour

This tries to make sure everything apart from experimental gets new
names and ABI on every upload.

* experimental:
Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4
Keep ABI 6.1.0-0-arm64
* unstable/testing/stable:
Keep version 6.1.2-3
ABI 6.1.2-3-arm64
* security:
Use same version ranges as stable, makes it impossible to do stable
and security with the same minor.
Version 6.1.2-3
ABI 6.1.2-3-arm64
* backports:
Keep version 6.1.2-3~bpo12+4
ABI 6.1.2-3.bpo12.4-arm64
* LTS:
Version 6.1.2-3~deb12u4
ABI 6.1.2-3.deb12.4-arm64
* Everything else:
Not for Debian archive.
Keep version
ABI 6.1.2-local

## Removed feature for now

### NMU

Can be easily added back by adding "bX" or so to the ABI.

### BinNMU

Is impossible to support.  The version change requires changes in the
names of the created packages.

### Release team prefix

The release team mandated debXuY suffix is not used for any
stable/security or similar release.  Only the LTS one for now uses that.

This makes sure we never accrue more then one such suffix in any
version, to make sure it does not grow unlimited.

New stable uploads always try to gather new upstream minor releases, so
we should be safe.

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture

[Venkata.Pyla]

Package: klibc-utils
Version: 2.0.12-1
Severity: normal

Hi,

I observed segfaults in armhf architecture when executing any of the
binaries /usr/lib/klibc/bin/{fstype, ls, cat, ...}, same is not seen in
amd64 and arm64 architectures.

This issue originally occurred when I am updating initramfs using
command `update-initramfs -u` which internally [1] uses klibc binary
`/usr/lib/klibc/bin/fstype` to check the fstype, it doesn't stop
creating initramfs but it creates core dumps in the rootfs and that
makes our images non-reproducible.

Follow below steps to reproduce this issue
```
$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ 
http://deb.debian.org/debian/
$ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
$ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
```

Expectation:
It should not generate core dumps

Kindly suggest us what is going wrong where all the binaries are generating 
core dumps in armhf architecture?

[1] 
https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/v0.142/hooks/fsck?ref_type=tags#L55


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_IN, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to 
default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_IN:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages klibc-utils depends on:
ii  libklibc  2.0.12-1

klibc-utils recommends no packages.

klibc-utils suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_IN:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_IN"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Bug#1040966: linux-image-6.1.0-9-amd64: Thinkpad T470 fails to wake from suspend after bookworm upgrade

[Caren Hern]

Package: src:linux
Version: 6.1.27-1
Severity: serious
Justification: 0 (Preface)
X-Debbugs-Cc: senc...@riseup.net

Dear Maintainer,

after a running the bookworm update I have frequent and recurring problems 
waking the machine from sleep.
I have seen two possible states after waking up:
1. Completely unresponsive with dark screen: Power LED is lit. FnLock LED 
doesn't respond. MagicSysrq doesn't work.
2. Completely unresponsive with lock screen: Screen wakes up and show the gnome 
screen. FnLock can be toggled. Otherwise no interaction possible. MagicSysrq 
doesn't do anything.

Before the upgrade Suspend to RAM worked completely fine. For some time I 
suspected tl-smapi-dkms to be the cause, but this was ruled out now (it just 
happened again after removing the package).
The only other kernel module I am aware of is the broadcom-sta-dkms. I tried to 
unload it before sleep, but the issue happened again. 

journalctl revealed no interesting messages before sleep, and nothing after a 
failed wake up.


-- Package-specific info:
** Version:
Linux version 6.1.0-9-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-9-amd64 
root=UUID=2258140b-a9a9-46ab-94ae-4c5e09a007d6 ro

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[   19.930813] intel_rapl_common: Found RAPL domain uncore
[   19.930815] intel_rapl_common: Found RAPL domain dram
[   19.930817] intel_rapl_common: Found RAPL domain psys
[   19.943525] audit: type=1400 audit(1689240616.727:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=854 
comm="apparmor_parser"
[   19.947026] audit: type=1400 audit(1689240616.731:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="firejail-default" pid=853 
comm="apparmor_parser"
[   19.951740] audit: type=1400 audit(1689240616.735:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="ping" pid=847 
comm="apparmor_parser"
[   19.957230] audit: type=1400 audit(1689240616.739:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lxc-container-default" 
pid=855 comm="apparmor_parser"
[   19.958443] audit: type=1400 audit(1689240616.739:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lxc-container-default-cgns" 
pid=855 comm="apparmor_parser"
[   19.959416] audit: type=1400 audit(1689240616.739:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="lxc-container-default-with-mounting" pid=855 comm="apparmor_parser"
[   19.960453] audit: type=1400 audit(1689240616.739:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="lxc-container-default-with-nesting" pid=855 comm="apparmor_parser"
[   20.358776] Adding 12597056k swap on /dev/mapper/swap.  Priority:-2 
extents:1 across:12597056k SSFS
[   20.403115] mc: Linux media interface: v0.10
[   20.431583] videodev: Linux video capture interface: v2.00
[   20.551062] input: keyd virtual keyboard as /devices/virtual/input/input23
[   20.551189] input: keyd virtual pointer as /devices/virtual/input/input24
[   20.593068] usb 1-8: Found UVC 1.00 device Integrated Camera (5986:111c)
[   20.622551] input: Integrated Camera: Integrated C as 
/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/input/input25
[   20.623878] usbcore: registered new interface driver uvcvideo
[   20.674648] Process accounting resumed
[   20.943691] IPv6: ADDRCONF(NETDEV_CHANGE): v-peer1: link becomes ready
[   20.944744] IPv6: ADDRCONF(NETDEV_CHANGE): v-eth1: link becomes ready
[   20.968704] usbcore: registered new device driver apple-mfi-fastcharge
[   21.009079] systemd-journald[469]: File 
/var/log/journal/2452626f3a7f4738ab5cba389727f188/user-1000.journal corrupted 
or uncleanly shut down, renaming and replacing.
[   21.304365] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   21.615076] Bluetooth: Core ver 2.22
[   21.616164] NET: Registered PF_BLUETOOTH protocol family
[   21.617211] Bluetooth: HCI device and connection manager initialized
[   21.619479] Bluetooth: HCI socket layer initialized
[   21.620499] Bluetooth: L2CAP socket layer initialized
[   21.621504] Bluetooth: SCO socket layer initialized
[   21.689563] usbcore: registered new interface driver btusb
[   21.715416] usb 1-7.1: USB disconnect, device number 4
[   21.811326] Bluetooth: hci0: BCM: chip id 73 build 1125
[   21.813302] Bluetooth: hci0: BCM: product 05ac:828d
[   21.815314] Bluetooth: hci0: BCM: features 0x07
[   21.832308] Bluetooth: hci0: BCM20702B0 Generic USB Class 1 @ 20 MHz
[   21.888108] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   21.889080] Bluetooth: BNEP filters: protocol multicast
[   21.894728] Bluetooth: BNEP socket layer initialized
[   21.899522] Bluetooth: MGMT