Bug#1064035: Missing documentation due to error in kernel-doc script

[Ben Hutchings]

Package: linux-doc-5.10
Version: 5.10.209-1
Severity: important

The backport of commit 3080ea5553cc "stddef: Introduce
DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and
introduced a syntax error:

Global symbol "$args" requires explicit package name (did you forget to declare 
"my $args"?) at ./scripts/kernel-doc line 1236.
Global symbol "$args" requires explicit package name (did you forget to declare 
"my $args"?) at ./scripts/kernel-doc line 1236.
Execution of ./scripts/kernel-doc aborted due to compilation errors.

This doesn't stop the documentation build process, but causes the
documentation that should be extracted by kernel-doc to be missing
from linux-doc-5.10.

We should be able to fix this by eithering backport commit
e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions
into variables" or replacing /$args/ with /([^,)]+)/.

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1061095: linux-image-6.6.11-amd64: 2.5gbit USB device with r8152 chipset only does 100baset

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 2024-01-18 at 13:42 +1100, Russell Coker wrote:
> Package: src:linux
> Version: 6.6.11-1
> Severity: normal
> Tags: upstream
> 
> [51076.208113] r8152-cfgselector 2-1: reset SuperSpeed USB device number 6 
> using xhci_hcd
> [51076.236596] r8152 2-1:1.0: firmware: direct-loading firmware 
> rtl_nic/rtl8156b-2.fw
> [51076.258622] r8152 2-1:1.0: ram code speedup mode fail
> [51076.258647] r8152 2-1:1.0: load rtl8156b-2 v2 04/27/23 successfully
> [51076.301913] r8152 2-1:1.0 eth0: v1.12.13
> [51076.697896] r8152 2-1:1.0 usb2.5g: renamed from eth0
> [51079.489807] r8152 2-1:1.0 usb2.5g: carrier on
> [51079.745192] r8152 2-1:1.0 usb2.5g: carrier off
> [51082.561105] r8152 2-1:1.0 usb2.5g: carrier on
> [51152.705733] r8152 2-1:1.0 usb2.5g: carrier off
> [51156.353013] r8152-cfgselector 2-1: USB disconnect, device number 6
> [51156.353455] xhci_hcd :00:14.0: WARN Set TR Deq Ptr cmd failed due to 
> incorrect slot or ep state.
> [51156.353492] r8152 2-1:1.0 usb2.5g: Stop submitting intr, status -108
> 
> Above is the relevant kernel message logs.
> 
> # mii-tool usb2.5g
> usb2.5g: 100 Mbit, half duplex, link ok

You should not use mii-tool for this; it only works speeds up to
1 Gbit (and even then only with some PHYs).  Please provide information
from ethtool.

> Above is the output of mii-tool, also the lights on the switch indicate
> 100mbit speed.   It gets 100mbit on a 1000baset switch too, so it's not a
> switch issue.
> 
> [66653.451043] cdc_ncm 2-1.2:2.0 enx00e04c680225: renamed from eth0
> [66656.811499] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66657.067647] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04c680225: link becomes 
> ready
> [66657.323360] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66657.835395] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66658.347355] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66658.859227] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66659.371242] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66659.883190] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> 
> Above is the dmesg output from a LicheePi4A running the
> 5.10.113-g387b6863253c-dirty kernel it ships with, when it does this the
> switch LEDs indicate that it's 2500 speed.  This indicates that it's not
> a problem with the hardware in the USB device but a problem with the kernel.
> 
> # ethtool usb2.5g
> Settings for usb2.5g:
>   Supported ports: [  ]
>   Supported link modes:   Not reported

!!

>   Supported pause frame use: No
>   Supports auto-negotiation: No
>   Supported FEC modes: Not reported
>   Advertised link modes:  Not reported
>   Advertised pause frame use: No
>   Advertised auto-negotiation: No
>   Advertised FEC modes: Not reported
>   Speed: 1000Mb/s
>   Duplex: Half
>   Auto-negotiation: off

!!

>   Port: Twisted Pair
>   PHYAD: 0
>   Transceiver: internal
>   MDI-X: Unknown
> Current message level: 0x0007 (7)
>drv probe link
>   Link detected: yes
> 
> Above is the output of running ethtool on a Debian/Stable system running
> kernel 6.1.0-13-amd64.

Is this using the cdc-ncm or r8152 driver?

> Half duplex is a problem, but less of a problem than
> 100baseT.  This is a regression from Debian/Stable.

The above also looks very broken, so I would hesitate to say that this
has regressed as opposed to showing different symptoms.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.



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

Bug#1058937: Conflicts with libnfsidmap{2,-regex} involving aliased file locations)

[Ben Hutchings]

Control: user helm...@debian.org
Control: usertag -1 dep17p1

According to the classification in DEP-17
<https://subdivi.de/~helmut/dep17.html> this is problem type P1.

libnfsidmap1 includes mitigation M7 (Conflicts with the other packages)
since version 1:2.5.4-1~exp2, but although this usually avoids P1 we
now know that this is not always the case.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer



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

Bug#1058937: Conflicts with libnfsidmap{2,-regex} involving aliased file locations

[Ben Hutchings]

Package: libnfsidmap1
Version: 1:2.5.4-1~exp1
Severity: serious

As receently disvovered by Helmut Grohne, a conflict between binary
packages does not ensure that the files of one will be removed before
the files of the other are installed.  This can result in file loss
when the conflict involves aliased filenames rather than exactly the
same filenames.

This specific scenario exists when installing libnfsidmap1 as a
replacement for libnfsidmap{2,-regex} packages.  I was able to
reproduce it with the following sequence of commands in a minimal
bullseye amd64 chroot:

# apt -y install usrmerge
# apt -y install libnfsidmap{2,-regex}
# sed -i 's/bullseye/bookworm/' /etc/apt/sources.list
# apt update
# apt -d -y install libnfsidmap1
# (cd /var/cache/apt/archives && \
   dpkg -i libc{6,-bin}_2.36-9+deb12u3_amd64.deb \
   libsasl2-{2,modules-db}_2.1.28+dfsg-10_amd64.deb \
   libgmp10_2%3a6.2.1+dfsg1-1.1_amd64.deb \
   libgnutls30_3.7.9-2_amd64.deb libldap-2.5-0_2.5.13+dfsg-5_amd64.deb)
# dpkg -i /var/cache/apt/archives/libnfsidmap1_1%3a2.6.2-4_amd64.deb

Ben.

Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive

[Ben Hutchings]

Control: reassign -1 src:linux 6.5.3-1~bpo12+1
Control: tag -1 moreinfo

On Sat, 2023-12-02 at 18:11 +0100, Paul Gevers wrote:
> Package: linux-image-6.5.0-0.deb12.1-arm64
> Version: 6.5.3-1~bpo12+1
> Severity: serious
> Justification: system stops responding
> 
> Dear kernel maintainers,
> 
> Thursday 30 November I upgraded the ci.debian.net workers. We're running 
> the backports kernel there due to issues we discussed earlier, but after 
> upgrading, we lost access to our arm64 hosts one after the other. We're 
> running the 6.4 kernel again now, and I extracted some of the logs. 
> Please let me know if you need more info.

The first error logged in this file has:

> CPU: 6 PID: 15039 Comm: lxc-start Tainted: G  D WL 
> 6.5.0-0.deb12.1-arm64 #1  Debian 6.5.3-1~bpo12+1

The D and W flags mean there were prior BUG and WARN errors logged. 
Please send those as well.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman



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

Bug#1057147: Acknowledgement (Does not look for config in ~/.config/dput/dput.cf)

[Ben Hutchings]

Control: tag -1 patch

I opened a merge request to fix this:
<https://salsa.debian.org/debian/dput-ng/-/merge_requests/30>

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#1057147: Does not look for config in ~/.config/dput/dput.cf

[Ben Hutchings]

Package: dput-ng
Version: 1.37
Severity: normal

dput now looks for its config in ~/.config/dput/dput.cf as well as
~/.dput.cf.  (The ~/.config prefix should also be overridable by
setting $XDG_CONFIG_HOME, but I haven't checked whether dput
implements that.)

Please add support for this alternate location.

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dput-ng depends on:
ii  python3   3.11.4-5+b1
ii  python3-dput  1.37

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  

-- debconf-show failed

Bug#1053122: Fwd: Re: Bug#1053122: linux-image-6.5.0-1-amd64: using smp_processor_id() in preemptible

[Ben Hutchings]

Control: tag -1 - moreinfo

 Forwarded Message 
From: Gabriel Francisco 
To: Ben Hutchings 
Subject: Re: Bug#1053122: linux-image-6.5.0-1-amd64: using
smp_processor_id() in preemptible
Date: 12/10/23 20:23:30
Message-Id:


Hi,

> The CPU registers contain several addresses starting 89, except for
> rbx which starts 99 (and is the faulting address).  That looks like
> a single bit got flipped.

Thanks for the explanation! (now I know how to detect bit flips) :D

> The first BUG message should be more meaningful that what comes after.
> This shows the kernel tried to access non-existent memory.

Yes, I should have reported the first one indeed, I thought too much and
ended reporting the second one. Sorry about that.

> This could be due to a kernel bug, but is more likely a hardware
> problem.  Please test the RAM with memtest86+.  Also if you've enabled
> any overclocking options, turn those off.

Even with XMP(3000@1.35v) enabled (F4-3000C16-16GISB), memtest86+ ran for 3
hours and printed PASS in the screen.
I removed the XMP profile from my memories and ordered new rams to check if
my current ones are faulty (or not).

The message in dmesg was only one occasion. (but I reported it anyways)

The hang does still happens with/without XMP when running 6.5.x kernel
series. It happens when maximizing a video (or time-to-time when my cursor
enters the video area) when using kernel 6.5.x. It does not happen with
kernel 6.1.x series.

I'm using amgpu module.

Greetings,

*Gabriel Francisco*
Linux User #507840
email: frc.gabriel[at]gmail.com 


On Thu, Oct 5, 2023 at 1:15 AM Ben Hutchings  wrote:

> Control: retitle -1 linux-image-6.5.0-1-amd64: Kernel page fault in
> process exit due to bit flip
> Control: tag -1 moreinfo
> 
> On Wed, 2023-09-27 at 20:45 +0200, Gabriel Francisco wrote:
> > Package: src:linux
> > Version: 6.5.3-1
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: frc.gabr...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > First of all thanks for your hard work!
> > 
> > I noticed my computer started freezing for few seconds when
> entering/exiting
> > full screen videos in youtube using firefox and while trying to check if
> the
> > issue also afected chromium I saw the following message in dmesg:
> > 
> > [12569.564300] BUG: unable to handle page fault for address:
> 991989e936b8
> > [12569.564304] #PF: supervisor write access in kernel mode
> > [12569.564306] #PF: error_code(0x0002) - not-present page
> 
> The first BUG message should be more meaningful that what comes after.
> This shows the kernel tried to access non-existent memory.
> 
> > [12569.564308] PGD 0 P4D 0
> > [12569.564311] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > [12569.564314] CPU: 10 PID: 328649 Comm: Chroot Helper Not tainted
> 6.5.0-1-amd64 #1  Debian 6.5.3-1
> > [12569.564317] Hardware name: ASUS System Product Name/ROG STRIX B550-F
> GAMING WIFI II, BIOS 3205 08/14/2023
> > [12569.564318] RIP: 0010:down_write+0x23/0x70
> > [12569.564324] Code: 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53
> 48 89 fb e8 2e bc ff ff bf 01 00 00 00 e8 74 3a 53 ff 31 c0 ba 01 00 00 00
>  48 0f b1 13 75 33 65 48 8b 04 25 80 29 03 00 48 89 43 08 bf 01
> > [12569.564326] RSP: 0018:a189d736fc70 EFLAGS: 00010246
> > [12569.564328] RAX:  RBX: 991989e936b8 RCX:
> 891797aaef00
> > [12569.564330] RDX: 0001 RSI: 891989e645c0 RDI:
> 8e7c95dc
> > [12569.564331] RBP:  R08: 0060 R09:
> 80400014
> > [12569.564333] R10: 8918cbfeb7f8 R11: 0006 R12:
> 7f7e5fd0
> > [12569.564334] R13: 0001 R14: 891989e645c0 R15:
> 891989e64958
> 
> The CPU registers contain several addresses starting 89, except for
> rbx which starts 99 (and is the faulting address).  That looks like
> a single bit got flipped.
> 
> This could be due to a kernel bug, but is more likely a hardware
> problem.  Please test the RAM with memtest86+.  Also if you've enabled
> any overclocking options, turn those off.
> 
> [...]
> > After that the computer can't shutdown and systemd keeps waiting on
> process PID 328649 (Chroot Helper).
> 
> This (and the other BUG messages) are because that process crashed in
> kernel mode and couldn't properly exit.
> 
> Ben.
> 
> --
> Ben Hutchings
> Beware of bugs in the above code;
> I have only proved it correct, not tried it. - Donald Knuth
> 
> 

Hi,> The CPU registers contain several addresses starting 89, except for
> rbx which starts 99 (and is the faulting address).  That looks like> a single bit got flipped.Thanks for the explanati

Bug#1052676: linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK)

[Ben Hutchings]

Control: severity -1 important

On Tue, 2023-09-26 at 22:45 +0200, Diederik de Haas wrote:
[...]
> I don't know *IF* it's possible to still add hardware support to the 6.1 
> kernel which is used in Stable/Bookworm. Assuming the platforms were properly 
> supported in the upstream 6.1 kernel, then there still has been zero testing 
> with it on a Debian system, which does not sound ideal for Stable.
> One of the Debian kernel maintainers would have to answer whether it is 
> possible at all for 6.1/Stable/Bookworm.
[...]

I'm not sure if it's documented anywhere, but release team policy has
been that hardware enablement is allowed in stable updates.  (If that
involves changes to a driver we already enabled, the benefit has to be
weighed against the risk of regressions for previously supported
devices.  But I don't that's being proposed here.)

Even though there won't have been broad testing of the Debian kernel
configuration on the Mediatek SoCs, this can't possibly be a regression
for them.

Ben.


-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth



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

Bug#1053122: linux-image-6.5.0-1-amd64: using smp_processor_id() in preemptible

[Ben Hutchings]

Control: retitle -1 linux-image-6.5.0-1-amd64: Kernel page fault in
process exit due to bit flip
Control: tag -1 moreinfo

On Wed, 2023-09-27 at 20:45 +0200, Gabriel Francisco wrote:
> Package: src:linux
> Version: 6.5.3-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: frc.gabr...@gmail.com
> 
> Dear Maintainer,
> 
> First of all thanks for your hard work!
> 
> I noticed my computer started freezing for few seconds when entering/exiting
> full screen videos in youtube using firefox and while trying to check if the
> issue also afected chromium I saw the following message in dmesg:
> 
> [12569.564300] BUG: unable to handle page fault for address: 991989e936b8
> [12569.564304] #PF: supervisor write access in kernel mode
> [12569.564306] #PF: error_code(0x0002) - not-present page

The first BUG message should be more meaningful that what comes after.
This shows the kernel tried to access non-existent memory.

> [12569.564308] PGD 0 P4D 0 
> [12569.564311] Oops: 0002 [#1] PREEMPT SMP NOPTI
> [12569.564314] CPU: 10 PID: 328649 Comm: Chroot Helper Not tainted 
> 6.5.0-1-amd64 #1  Debian 6.5.3-1
> [12569.564317] Hardware name: ASUS System Product Name/ROG STRIX B550-F 
> GAMING WIFI II, BIOS 3205 08/14/2023
> [12569.564318] RIP: 0010:down_write+0x23/0x70
> [12569.564324] Code: 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 48 89 
> fb e8 2e bc ff ff bf 01 00 00 00 e8 74 3a 53 ff 31 c0 ba 01 00 00 00  48 
> 0f b1 13 75 33 65 48 8b 04 25 80 29 03 00 48 89 43 08 bf 01
> [12569.564326] RSP: 0018:a189d736fc70 EFLAGS: 00010246
> [12569.564328] RAX:  RBX: 991989e936b8 RCX: 
> 891797aaef00
> [12569.564330] RDX: 0001 RSI: 891989e645c0 RDI: 
> 8e7c95dc
> [12569.564331] RBP:  R08: 0060 R09: 
> 80400014
> [12569.564333] R10: 8918cbfeb7f8 R11: 0006 R12: 
> 7f7e5fd0
> [12569.564334] R13: 0001 R14: 891989e645c0 R15: 
> 891989e64958

The CPU registers contain several addresses starting 89, except for
rbx which starts 99 (and is the faulting address).  That looks like
a single bit got flipped.

This could be due to a kernel bug, but is more likely a hardware
problem.  Please test the RAM with memtest86+.  Also if you've enabled
any overclocking options, turn those off.

[...]
> After that the computer can't shutdown and systemd keeps waiting on process 
> PID 328649 (Chroot Helper).

This (and the other BUG messages) are because that process crashed in
kernel mode and couldn't properly exit.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth



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

Bug#1052472: linux-image-6.5.0-1-powerpc64: Can't run program if its executable file was made immutable via chattr(1)

[Ben Hutchings]

Control: reassign -1 src:zfs-linux

On Fri, 2023-09-22 at 16:13 +, WHR wrote:
> Package: src:linux
> Version: 6.5.3-1
> Severity: normal
> X-Debbugs-Cc: msl023...@gmail.com, msl023...@gmail.com
> 
> 
> Taking executable file /usr/bin/ssh to demonstrate the issue:
> 
>   # which ssh
>   /usr/bin/ssh
>   # ssh   
>
>   usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
>  [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
>  [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
>  [-i identity_file] [-J [user@]host[:port]] [-L address]
>  [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p 
> port]
>  [-Q query_option] [-R address] [-S ctl_path] [-W host:port]
>  [-w local_tun[:remote_tun]] destination [command]
>   # chattr +i /usr/bin/ssh
>
>   # ssh
>   Segmentation fault
> 
> 
> By trying to load the program via ld.so(1) with truss (actually strace), it 
> shows that a mmap(2) call used to load the data segument failed due to EPERM:
> 
>   # truss -s 128 -f /lib/powerpc64-linux-gnu/ld64.so.1 /usr/bin/ssh
>   execve("/lib/powerpc64-linux-gnu/ld64.so.1", 
> ["/lib/powerpc64-linux-gnu/ld64.so.1", "/usr/bin/ssh"], 0x7fffc0380530 /* 29 
> vars */) = 0
>   brk(NULL)   = 0x1000db6
>   openat(AT_FDCWD, "/usr/bin/ssh", O_RDONLY|O_CLOEXEC) = 3
>   read(3, 
> "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\22h\220\0\0\0\0\0\0\0@\0\0\0\0\0\22\4\330\0\0\0\1\0@\08\0\t\0@\0\35\0\34\0\0\0\6\0\0\0\4\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\1\370\0\0\0\0\0\0\1\370\0\0\0\0\0\0\0\10\0\0\0\3\0\0\0\4"...,
>  832) = 832
>   mmap(NULL, 1259760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
> 0) = 0x7fff9372
>   mprotect(0x7fff9383, 65536, PROT_NONE) = 0
>   mmap(0x7fff9384, 131072, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11) = -1 EPERM (Operation not 
> permitted)
>   close(3)= 0
>   writev(2, [{iov_base="/usr/bin/ssh", iov_len=12}, {iov_base=": ", 
> iov_len=2}, {iov_base="error while loading shared libraries", iov_len=36}, 
> {iov_base=": ", iov_len=2}, {iov_base="/usr/bin/ssh", iov_len=12}, 
> {iov_base=": ", iov_len=2}, {iov_base="failed to map segment from shared 
> object", iov_len=40}, {iov_base="", iov_len=0}, {iov_base="", iov_len=0}, 
> {iov_base="\n", iov_len=1}], 10/usr/bin/ssh: error while loading shared 
> libraries: /usr/bin/ssh: failed to map segment from shared object
>   ) = 107
>   exit_group(127) = ?
>   +++ exited with 127 +++
> 
> 
> I can also reproduce this issue on Bullseye (with Linux 5.10.0-21-amd64);
> while Buster (Linux 4.19.0-23-amd64) is fine.
[...]
> ** Command line:
> root=ZFS=zr/ROOT/debiansid-be ro quiet 
> cgroup_enable=cpuset,cpu,cpuacct,blkio,memory,devices,freezer,net_cls,perf_event,net_prio
>  systemd.unified_cgroup_hierarchy=0 
> net.ifname-policy=keep,onboard,slot,path,kernel zfs.zfs_txg_timeout=60 
> zfs.zfs_arc_max=2166172771 init=/init
[...]

I can't reproduce this on an ext4 filesystem, so I think ZFS is the
problem.

ZFS has its own check that blocks a writable mmap of an immutable file,
without taking MAP_PRIVATE into account:
https://sources.debian.org/src/zfs-linux/2.1.12-2/module/os/linux/zfs/zfs_vnops_os.c/#L3908

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.



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

Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Ben Hutchings]

On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
[...]
> ## Kernel modules will be signed with an ephemeral key
> 
> The modules will not longer be signed using the Secure Boot CA like the
> EFI kernel image itself.  Instead a key will be created during the build
> and thrown away after.
> 
> Yes, this will make the build unreproducible, but no better solution
> currently exists.  There are some plans, but no-one is working on them.
> If a suitable replacement shows up, we can always switch to that
> solution.

Builds for the architectures involved are already unreproducible due to
inconsistent generation of BTF in both the kernel and modules. 
Additionally, my "plan" would also get rid of signing modules with the
Secure Boot CA, so I'm not going to object to this.


[...]
> ## Image packages contains more version info
> 
> By renaming the kernel packages we try to make several kernels
> installable at the same time.  In contrast to rpm, where you can have
> the same package installed multiple times in different versions, dpkg
> only supports a single one at the same time.  So the co-installable
> versions needs to have different package names.
> 
> The packages will include the full upstream version.  There exists the
> exception of devel builds and uploads to experimental, wich will contain
> even less of the version, to avoid new names in that cases.
> 
> Example: linux-image-6.5.3-cloud-arm64
> 
> There are some drawbacks.
> 
> The same upstream version in testing and backports will have the same
> package name.

This is not OK, because they will be incompatible on architectures
supporting SB (and sometimes incompatible on others due to compiler
differences or required config changes).

If someone upgrades from stable + backports to testing, and has OOT
modules:
- With DKMS, will a rebuild be triggered if the linux-image package
  name doesn't change?
- With module-assistant, the new linux-image package will satisfy
  dependencies of the old modules even though they are incompatible.

> Multiple uploads of the same upstream version will have
> the same package name, but those rarely happens.

Those happen fairly often for urgent security updates.

> Those packages will
> not be compatible and a reboot is necessary to be able to load modules
> again.
> 
> It will not longer be possible to reliably derive the package name from
> kernel release (see above), as both values are not really related
> anymore.

Given all the drawbacks, I don't see the benefit of decoupling package
names from release strings.

In the same way that shared library packages must be renamed for every
backward-incompatible ABI changes, I believe we should keep doing this
for linux-image packages.

> ## Header and tool packages will not longer contain version
> 
> The headers packages will not longer include the version.  It won't be
> reliably possible to derive the package name anyway from the running
> kernel.
>
> This means that only headers of one single version can be available on
> the system at one time.  This might be a bit inconvinient for dkms, as
> it can't longer build modules for multiple versions.
>
> But we too often have the problem that image and headers go out of sync
> and then you can't find the correct ones anyway.
> 
> Example: linux-headers-cloud-arm64

This is all downside with no justification given.  Please explain what
the benefit is.

> ## Installer packages will not longer contain too much version
> 
> The installer can only ever handle one version of kernel.  Also it got
> an internal mechanism to detect which packages belong together
> (the Kernel-Version control entry).  So we have no need to rename them
> and force a matching change in d-i itself just because a new kernel
> exists.  So it will not longer contain the full version in the package
> names if not needed.
[...]

In the installer, netboot images break every time the kernel ABI is
bumped.  I think there's a specific check and error message for this,
but I'm not exactly sure.  It should be verified that this detection
will work the way you expect, so that the error message doesn't change
and create a support burden for the installer team.

Currently kernel-wedge generates the udeb package names and would need
to add an option to leave out the version part of the names.  I'm happy
to work on that once we have an agreement for what to do.


Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.



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

Bug#1051678: RFP: ublksrv -- Daemon and library for user-space block devices

[Ben Hutchings]

Package: wnpp
Severity: wishlist

* Package name: ublksrv
  Version : 1.1-rc1
  Upstream Contact: Ming Lei < tom.leim...@gmail.com>
* URL : https://github.com/ming1/ubdsrv
* License : GPL-2, LGPL-2.1, MIT
  Programming Lang: C++, C
  Description : Support for Linux user-space block devices

This is the user-space code that works with the ublk driver introduced
in Linux 6.0.  There is a daemon to handle requests and a library for
writing individual user-space block drivers.  It includes drivers for
loop, nbd, and qcow2 block devices.

Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast

[Ben Hutchings]

On Wed, 2023-08-09 at 13:35 +0200, kolafl...@kolahilft.de wrote:
> I was able to resolve the issue with my ASRock J4105-ITX board (Celeron 
> J4105) on Debian-12. I just had to
>apt install intel-microcode
> and reboot. After 4 weeks of running the system 23/7 I had no further 
> crashes.
> 
> Without that intel-microcode package
>/sys/devices/system/cpu/cpu*/microcode/version
> is 0x26 (38 decimal).
> And with intel-microcode-3.20230512.1 the version is 0x3e (decimal 62).
> 
> 
> I'm not sure why intel-microcode was not installed by default. All my 
> other Debian computers have that package installed automatically.
[...]

We didn't use to install intel-microcode by default because it's non-
free.  Starting with Debian 12, non-free firmware and microcode are
installed on systems where they are useful, but upgrades from older
versions won't change this.

But I'm fairly sure what you've found is a different issue from what
Olivier originally reported.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
 - Maurice Wilkes, 1949



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

Bug#1042978: Tests invalid package upgrades

[Ben Hutchings]

On Thu, 2023-08-03 at 22:01 +0200, Paul Gevers wrote:
> Control: reassign -1 release.debian.org
> 
> Hi Ben,
> 
> On 03-08-2023 18:01, Ben Hutchings wrote:
> > ci.debian.net must therefore also test updating the binaries from all
> > these source packages together, not just those built from linux.
> 
> But ci.debian.net just does what it's been asked to do by the client, in 
> this case britney. So, if anything it's britney2 that needs to be 
> changed to support this.

Thank you for redirecting this appropriately.

> But, britney2 tries to deduce what needs to be 
> tested together from the package relations. Normally, what you're seeing 
> here is the result of a test where the signed packages haven't been 
> build yet. britney retries tests after 24 hours and normally it retries 
> with linux-signed-* in the list of pinned packages as you can see in the 
> dkms history. The question that now arises is why it doesn't do that now.

I suspect that the difference is that most linux updates bump ABI (thus
changing package names) and this last update did not need to.  The
package that linux-headers-amd64/unstable depends on typically don't
exist in testing at all, but in this case it does (at the wrong
version).  Perhaps something in britney's invocation of debci isn't
paying attention to all the version constraints.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.



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

Bug#1042978: Acknowledgement (Tests invalid package upgrades)

[Ben Hutchings]

The test log for reference:
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dkms/36392756/log.gz

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



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

Bug#1042978: Tests invalid package upgrades

[Ben Hutchings]

Package: debci
Severity: serious
X-Debbugs-Cc: debian-ker...@lists.debian.org

ci.debian.net is running dkms's autopkgtest with packages from testing
except for linux's binaries updated from unstable.  The test fails
because linux-headers-amd64 is uninstallable in this scenario:

* The available version of linux-headers-amd64 will be the latest,
  6.4.4-2.  It depends on (currently) linux-headers-6.4.0-1-amd64
  at the same version.
* The available version of linux-headers-6.4.0-1-amd64 (built from
  src:linux-signed-amd64) will be 6.4.4-1.

This cross-source-package version lock is unusual but has been
implemented deliberately to ensure that linux and linux-signed-*
always migrate from unstable to testing together.

ci.debian.net must therefore also test updating the binaries from all
these source packages together, not just those built from linux.  If
it's not possible to do this in a general way then we need a specific
workaround that can be used in dkms and any other affected packages
to prevent this invalid test scenario.

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debci depends on:
ii  adduser 3.137
pn  amqp-tools  
ii  bsdmainutils12.1.8
ii  curl7.88.1-10
ii  dctrl-tools 2.24-3+b1
ii  debian-archive-keyring  2023.3
ii  debootstrap 1.0.128+nmu5
ii  devscripts  2.23.5
ii  distro-info 1.5
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  jq  1.6-2.1
pn  libjs-bootstrap 
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
pn  libjs-jquery-flot   
ii  moreutils   0.67-1
ii  netcat-openbsd  1.225-1
ii  netcat-traditional  1.10-47
pn  parallel
ii  patchutils  0.4.2-1
pn  retry   
ii  rsync   3.2.7-1
ii  ruby1:3.1
pn  ruby-activerecord   
pn  ruby-bunny  
pn  ruby-erubi  
pn  ruby-kaminari-activerecord  
pn  ruby-minitar
pn  ruby-omniauth-gitlab
pn  ruby-sinatra
pn  ruby-sinatra-contrib
pn  ruby-sqlite3 | ruby-pg  
pn  ruby-thor   
ii  sudo1.9.14p2-1

Versions of packages debci recommends:
ii  systemd-timesyncd [time-daemon]  254~rc3-3

Versions of packages debci suggests:
pn  apt-cacher-ng   
pn  auto-apt-proxy  

Bug#1041142: closed by Diederik de Haas (Re: Debian's BTS is not for regular user questions)

[Ben Hutchings]

On Tue, 2023-08-01 at 02:49 +0200, AlMa wrote:
> On 01.08.23 01:12, Debian Bug Tracking System wrote:
> > You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile
> > Precision M6700 ... and not once did you say what actual problem you
> > experienced?!?
> 
> That's wrong.
> Before I posted some (not all) of the bug reports, the Dell laptop 
> stopped booting properly rather early; the root cause is still unknown 
> (though an intermediate cause is finally resolved now, the bug report is 
> already closed).  It took me a bit to get a working console, a mouse and 
> network going so as to simply be able to start debugging.  Some other 
> machines I manage had (and still have) other, less severe symptoms, 
> e.g., Wayland and programs depending on Wayland (e.g., “foot”) failing 
> to start after Debian upgrade.
> 
> If your computer doesn't boot properly, you go one by one through every 
> suspicious message you find. The fact that some messages are shown as 
> warnings and others as errors is clearly meant to warn whoever reads 
> them (i.e., the admin) and make him/her concerned.  By the definition of 
> the terms “warning” and “error”!

This is a rather naive understanding of how logging is done in
practice.  The reality is that developers often don't know (and maybe
can't know) just how severe an odd condition may be in practice.

>   If these messages shouldn't make the 
> admin concerned, well, then the journalctl shouldn't show these messages 
> as warnings (AFAIK, yellow) and errors (red according to `man 
> journalctl`).  Please don't try to unload on me because of this mess; 
> I'm just an admin, and not even a developer.
> 
> Therefore, please restore the bug reports you closed.

I agree with Diederik's closing these bug reports.  We as kernel
maintainers have limited time and resources for investigating bugs, and
we are certainly not able to provide individual support for users and
administrators.  Investigating warning messages one by one is not a
priority at all.

If there is still an actual problem on this machine (not just warning
messages), please open *1* bug report that describes the actual problem
and the log messages.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.



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

Bug#1042374: linux-image-6.1.0-0.deb11.9-amd64: After the removal of a module package, the system reboots infinitively

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 2023-07-27 at 09:30 +0200, rpnpif wrote:
> Package: src:linux
> Version: 6.1.27-1~bpo11+1
> Severity: important
> File: linux-image-6.1.0-0.deb11.9-amd64
> 
> Dear Maintainer,
> 
> After the obsolete removal of hubicfuse package automatically by apt, the 
> kernel boots normally 
> but while mounting devices, the system reboots.
> This rebooting was randomly but occured about 2 times out of 3, or 4
> times out of 5 and rarely reboots while working.
> 
> The rescue mode from grub work fine almost all the time but not always.
> 
> I checked temperature and RAM and disks status that are normal.

Have you checked voltages?

How many physical storage devices (SSDs or hard disks) are in the
computer?

> My workaround had been to remove the line
> hubicfuse /mnt/hubic fuse user,noauto 0 0
> from /etc/fstab.
> After this workaround, the system seems to be working normally for two
> days.

This mount is marked as noauto, so it should not be mounted during boot
anyway.  So I wonder whether this change actually did anything.

> I am not sure that linux-image-6.1.0-0.deb11.9-amd64 is the culprit.
> Systemd and udev 252.5-2~bpo11+1 packages was updated at the same time.
> 
> Expected: Even a module for a secondary mounting from /etc/fstab is missing, 
> the system
> should not reboot but displays or logs a warning.
[...]

I agree, but a silent reboot is almost always the result of a hardware
fault.

Ben.


-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



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

Bug#1042363: Regression in expansion of commands starting with tilde

[Ben Hutchings]

on-monthly-0anacron.service
Tue 2023-08-01 00:20:00 CEST   4 days Sat 2023-07-08 15:22:45 CEST- 
cron-monthly-debsums.timer cron-monthly-debsums.service

30 timers listed.
Pass --all to see loaded but inactive timers, too.
-- output of systemd-delta

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd-cron depends on:
ii  cron-daemon-common  3.0pl1-162
ii  libc6   2.37-6
ii  python3 3.11.4-5
ii  systemd [systemd-sysusers]  254~rc3-3
ii  systemd-sysv254~rc3-3

systemd-cron recommends no packages.

Versions of packages systemd-cron suggests:
ii  exim4  4.96-16
ii  exim4-daemon-light [mail-transport-agent]  4.96-16

-- debconf-show failed
>From f139068a8fb06affdad2ba9cceea4a5ca8e40c16 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Thu, 27 Jul 2023 01:39:25 +0200
Subject: [PATCH] Fix expansion of commands starting with '~/'

We need to replace the '~' with home but keep '/' and everything
afterwards, i.e. slice [1:] from the command.  This was recently
changed to take slice [2:], losing the '/'.

Fixes: 9ef7b89523e8 ("keep job.command as a List[str] all along")
---
 src/bin/systemd-crontab-generator.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/systemd-crontab-generator.py 
b/src/bin/systemd-crontab-generator.py
index 785e977..4a3708a 100755
--- a/src/bin/systemd-crontab-generator.py
+++ b/src/bin/systemd-crontab-generator.py
@@ -276,7 +276,7 @@ CROND2TIMER = {
 pass
 if self.home:
 if self.command[0].startswith('~/'):
-self.command[0] = self.home + self.command[0][2:]
+self.command[0] = self.home + self.command[0][1:]
 
 if 'PATH' in self.environment:
 parts = self.environment['PATH'].split(':')

Bug#1042068: linux-image-6.4.0-1-amd64 boot kernel panic

[Ben Hutchings]

Control: reassign -1 src:linux 6.4.4-1
Control: tag -1 moreinfo

On Wed, 2023-07-26 at 10:59 +0800, Terrance Hendrik wrote:
> Package: linux-image-6.4.0-1-amd64
> Version: 6.4.4-1
> system info:
> 
> ```
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux trixie/sid
> Release:n/a
> Codename:   trixie
> $ lscpu
> Architecture:x86_64
>   CPU op-mode(s):32-bit, 64-bit
>   Address sizes: 39 bits physical, 48 bits virtual
>   Byte Order:Little Endian
> CPU(s):  20
>   On-line CPU(s) list:   0-19
> Vendor ID:   GenuineIntel
>   Model name:12th Gen Intel(R) Core(TM) i7-12700H
> ...
> ```
> 
> Root FS is **btrfs**
> 
> 
> Boot log (photo OCR, unable to save log, might have some errors)
[...]
> [0.704503] List of all partitions:
> 
> [0.705638] No filesystem could mount root, tried:
[...]

It seems that your boot loader tried to boot this kernel without an
initramfs.

- Which boot loader are you using?
- Does /boot/initrd.img-6.4.0-1-amd64 exist?
- Does "dpkg --configure -a" do anything or show any errors?

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

Bug#1041855: linux-image-6.4.0-1-amd64: IO wait regression

[Ben Hutchings]

Control: severity -1 important

On Mon, 2023-07-24 at 15:40 +0200, Christian Göttsche wrote:
> Package: src:linux
> Version: 6.4.4-1
> Severity: serious
> 
> Dear Maintainer,
> 
> Kernel 6.4.4 is affected by a regression causing one core be report
> high IO wait utilization.
> 
> See https://lore.kernel.org/lkml/12251678.o9o76zd...@natalenko.name/

There is no such thing as a CPU having "high IO wait utilization". 
When tasks are in I/O wait state, they are not using a CPU.

Unfortunately, for historical reasons Linux includes such tasks in the
load average and reports a CPU as being in I/O wait state when it's
idle and the last task running on it went into I/O wait state (at least
I think that's what the rule is).

So this bug is about an unwanted change in task/CPU state reporting,
not tasks suddenly using much more CPU time.  For that reason, I don't
think it should "serious", i.e. a blocker for testing propagation.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.



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

Bug#1041552: HFS/HFS+ are insecure

[Ben Hutchings]

On Fri, 2023-07-21 at 18:35 +0100, Matthew Garrett wrote:
> On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:
> 
> > Unless somebody has a better idea then then my plan is to ship in the 
> > next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist 
> > directive to prevent automatically loading some file system modules.
> 
> I think this would break any existing fstab entries that reference hfs 
> and hfsplus, and the convenient way to integrate Linux boot with x86 
> Macs is certainly to have an hfsplus EFI partition so this may be a 
> legitimate use-case. It also means that anyone who has a need to use one 
> of these filesystems in a static manner is vulnerable to automount 
> attacks using them.

Right, auto-loading of filesystems has to keep working.  And since
mount() of arbitrary filesystems is restricted to root (CAP_NET_ADMIN
in the initial namespace), we should let the callers apply a block- or
allow-list.

The reason we have to disable auto-loading of network protocols is that
socket creation is generally an unprivileged operation, so there's no
trusted user-space that can apply the policy (besides kmod).

> Completely untested, but I think something along the lines of:
> 
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
> LABEL="udisks_insecure_fs_end"
> 
> in a udev fragment should work? Any static fstab or mount units should 
> still work, but it should disable udisks automounting regardless of the 
> desktop agent involved, even if the fs modules are already loaded.

I agree we should not have UDisks probing for any of the (many) kernel
filesystems that aren't being actively maintained including responding
to security issues.

Beyond that, I would also like to see libmount limiting the filesystems
that it will probe when the fstab type is "auto".  But since UDisks
normally handles mounting for unprivileged users, that's probably less
of a concern.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.



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

Bug#1041643: ITP: ktls-utils -- TLS handshake utilities for in-kernel TLS consumers

[Ben Hutchings]

I've prepared a package in the Git repository
<https://salsa.debian.org/kernel-team/ktls-utils>.

As of Linux 6.4, the only in-kernel user of TLS is the NFS server. 
Linux 6.5 adds support in the NFS client.  With just the NFS server
supporting TLS, I can't do an end-to-end test.

Once we have Linux 6.5 packaged, I can test and hopefully upload this
package.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.



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

Bug#1041643: ITP: ktls-utils -- TLS handshake utilities for in-kernel TLS consumers

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ker...@lists.debian.org, 
Steve Dickson , Chuck Lever III 

* Package name: ktls-utils
  Version : 0.9
  Upstream Contact: kernel-tls-handsh...@lists.linux.dev
* URL : https://github.com/oracle/ktls-utils
* License : GPLv2
  Programming Lang: C
  Description : TLS handshake utilities for in-kernel TLS consumers

In-kernel TLS consumers need a mechanism to perform TLS handshakes on
a connected socket to negotiate TLS session parameters that can then
be programmed into the kernel's TLS record protocol engine.

This package of software provides a TLS handshake user agent that
listens for kernel requests and then materializes a user space socket
endpoint on which to perform these handshakes. The resulting
negotiated session parameters are passed back to the kernel via
standard kTLS socket options.

This will be maintained by the kernel team.

Bug#1040343: linux-image-5.10.0-9-amd64: Kernel silenty de-supported nfsv3 UDP mounts

[Ben Hutchings]

On Mon, 2023-07-17 at 09:05 +0200, Hauke Fath wrote:
> On Sun, 16 Jul 2023 20:14:20 +0200, Ben Hutchings wrote:
> > > 
> > > nfsv3 over tcp works, but is subobtimal , as described - when the router 
> > > goes down, the tcp mounts will hang, and the machine will have to be 
> > > rebooted.
> > [...]
> > 
> > Does this mean you are using the "soft" mount option?  Without that, I
> > would expect access to the mount to hang until the network connection
> > is restored, regardless of whether the TCP or UDP transport is used.
> 
> No, we use hard mounts.
> 
> But the router's package filter will have lost state after a reboot, 
> and reject packets from tcp connections that the clients assume to 
> exist. This is not a problem with udp, because connection-less.

Ah, I see.  You didn't mention that there was dynamic NAT involved
before.

If an NFS server is rebooted abruptly (so it doesn't properly close TCP
connections), once it's back up it will respond to any requests from
clients with a TCP RST, and they should reconnect.

If a NAT router between client and server is rebooted, I think that
something similar should happen, but the router would need to send the
TCP RST instead.

Is your router configured to send a TCP RST when receiving a packet for
an unknown connection, or does it just drop those packets?  (In
iptables this is the difference between REJECT and DROP policies.)

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.



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

Bug#1040343: linux-image-5.10.0-9-amd64: Kernel silenty de-supported nfsv3 UDP mounts

[Ben Hutchings]

On Wed, 2023-07-05 at 15:18 +0200, Hauke Fath wrote:
> On 7/5/23 10:20, Bastian Blank wrote:
> > On Tue, Jul 04, 2023 at 06:35:44PM +0200, Hauke Fath wrote:
> > > /misc /etc/auto.misc  
> > > -nfsvers=3,proto=udp,resvport,retrans=5,rsize=16384,wsize=16384,rw,hard
> > And if you set it to TCP (the default) or better directly switch to
> > NFSv4?
> 
> nfsv3 over tcp works, but is subobtimal , as described - when the router 
> goes down, the tcp mounts will hang, and the machine will have to be 
> rebooted.
[...]

Does this mean you are using the "soft" mount option?  Without that, I
would expect access to the mount to hang until the network connection
is restored, regardless of whether the TCP or UDP transport is used.

The default retry and timeout behaviour *is* different between
transports, though.  See the "timeo" and "retrans" options in nfs(5). 
You may wish to override the defaults in your environment.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice - John Levine



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

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

[Ben Hutchings]

On Fri, 2023-07-14 at 22:08 +, Thorsten Glaser wrote:
> Michael Tokarev dixit:
> 
> > > 
> > > From the comment, it reserves 16 MiB after the main executable.
> > > 
> > > In klibc/armhf, however, the main executable starts around
> > > 0x0001 whereas the interpreter starts after that, around
> > > 0x0038…
> > 
> > Aren't it happens on all architectures, not just armhf?
> 
> bullseye/amd64:
> 
> 0x0020 interp
> 0x0040 main executable
> 
> So no, this applies only to some architectures, but not because…
> 
> > I had an impression it is not arch-specific. $subject
> 
> … it’s arch-specific but because klibc memory map is, so the
> effect only occurs on those arches where klibc puts the interp
> before the main executable.

You mean after, but it's more specific than that in practice.

> This is unfortunately hard to grep for, because…
> 
> usr/klibc/arch/arm/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x38
> 
> … this applies to the interp, but for the main executables
> it uses the linker’s default AFAICT.
> 
> There is…
> 
> usr/klibc/arch/arm64/MCONFIG:KLIBCLDFLAGS  = $(LD_IMAGE_BASE_OPT) 0x0040
> usr/klibc/arch/arm64/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x020
> 
> … which does transfer to main at 0040 interp at 0020 respectively,
> but only arm64 and “x32”, which really builds as amd64, do that.
> 
> And Itanic uses a linker script, putting the interp at
> 0x2000 (which seems to be standard for ia64).
> 0x41c8 is the beginning of the main executable
> there, from analysing the built binaries.
> 
> It would be more robust if klibc always specified both.
[...]

It would be a little more robust, and certainly easier to understand.

Here's what we have now:

Architecture  klibc base (hex)  Exec base (hex) Offset (MiB)
-
alpha1_c0001_2000* -2_560
arm [THUMB=y]38 1**-3
arm [THUMB=n]   180 1**   -24
arm642040   2
i386600   800* 32
ia64  2000_ 4000_** 2_199_023_255_552
loongarch64  1_27E01_2000*   -126
m68k   b000  8000*   -768
mips 2040*  2
mips64   1_2FE01_2000*   -254
parisc 40001000 1**-1_024
ppc f80  1000*  8
ppc64   f00  1000* 16
riscv64  20 1* -2
s390   400040**-1_020
s390x  4000   100**-1_008
sh   2040*  2
sparc  4000 1* -1_024
sparc64800010* -2_047
x86_64   2040   2

* Assumption commented in MCONFIG.
** Observed with objdump.

In 12 cases (a majority), the offset between klibc.so and the
executable is negative.  However, only riscv64 and arm with THUMB=y
have such small negative offsets (-2 and -3.4375 MiB respectively)
which I suppose puts them more at risk from this bug.

The Debian package is built with THUMB=y for armhf but not armel, which
seems like a mistake because the Arm EABI requires Thumb support.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



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

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

[Ben Hutchings]

On Thu, 2023-07-13 at 22:27 +, Thorsten Glaser wrote:
> 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*
[...]

I use QEMU to test klibc changes on as many architectures as possible.
For a long time I used QEMU 3.1 with some cherry-picked bug fixes.  
All the GNU-built binaries would run successfully on that, but Clang-
built binaries for some architectures did not.

Switching klibc to the time64 kernel API forced me to update to QEMU
7.2.  This introduced regressions for shared-library executables for
armhf and riscv64.

There is some more detail on this at
<https://git.kernel.org/pub/scm/linux/kernel/git/bwh/klibc-maint.git/plain/status.md>

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.



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

Bug#1033663: linux: reproducible-builds: Embedded build path in various binaries

[Ben Hutchings]

On Wed, 2023-03-29 at 09:58 -0700, Vagrant Cascadian wrote:
> Source: linux
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> The build path is embedded in various binaries:
> 
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/linux.html
> 
>   /usr/sbin/bpftool
> 
>   /build/1st/linux-6.1.20/tools/lib/bpf/libbpf.c:805
>   vs.
>   /build/2/linux-6.1.20/2nd/tools/lib/bpf/libbpf.c:805  
> 
> This *seems* like a regression from earlier versions, though I have not
> tracked down when the tools started embedding the build paths...
[...]

Please see
<https://salsa.debian.org/kernel-team/linux/-/merge_requests/741>.

The embedded paths are mostly fixed by:
<https://salsa.debian.org/kernel-team/linux/-/merge_requests/741/diffs?commit_id=7293fda0eef37c07214d1e0c4e5ff1d1fa3e2e60>.

Perhaps I should finalise that MR even though it doesn't fix
everything?

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.



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

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

Bug#1040178: Kernel modules will not build, missing asm/orc_header.h

[Ben Hutchings]

On Wed, 2023-07-05 at 13:52 +0200, Bastian Blank wrote:
> Control: reassign -1 dkms
> 
> On Wed, Jul 05, 2023 at 10:53:19AM +0200, Vincent Lefevre wrote:
> > On 2023-07-04 16:13:56 +0200, Andreas Beckmann wrote:
> > > This needs to be fixed before linux 6.3.0-2-* can migrate to testing,
> > > otherwise it will break dkms module building for everyone still having
> > > linux-headers-6.3.0-1-* installed (which is probably for the currently
> > > running kernel).
> > On one of my machines, the upgrade was fine, but this is because the
> > NVIDIA kernel module wasn't rebuilt for the 6.3.0-1 kernel (despite
> > I have autoinstall_all_kernels="1" in /etc/dkms/framework.conf). So
> > I suppose that this bug would affect the machine only if the NVIDIA
> > packages are upgraded.
> 
> This is dkms failing to build a module for an incompatible kernel.
> Nothing can be done by the kernel to fix this as the kernel internal
> interfaces are not stable, the module needs to be upgrade accordingly to
> support the new interface.

No, this is modpost inserting a reference to a new header.  The
incompatibility is in our own packages.

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'



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

Bug#1037261: Bookworm - OOM-killer called before partition hard drives

[Ben Hutchings]

On Fri, 2023-06-09 at 17:16 +0200, Anael Mobilia wrote:
[...]
> During the launch of the partition (before the installer provide the
> choice on how did I want to partition manually, automatically, ...),
> OOM-killer is called, stopping the installation
> 
> Syslog :
> Jun  9 14:50:43 syslogd started: BusyBox v1.36.1
> Jun  9 14:50:43 kernel: klogd started: BusyBox v1.36.1 (Debian 1:1.36.1-1)
> Jun  9 14:50:43 kernel: [0.00] Linux version 6.1.0-9-amd64 
> (debian-ker...@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)
> Jun  9 14:50:43 kernel: [0.00] Command line: 
> BOOT_IMAGE=/install.amd/vmlinuz priority=low vga=788 
> initrd=/install.amd/initrd.gz ---
> Jun  9 14:50:43 kernel: [0.00] x86/fpu: x87 FPU will use FXSAVE
> Jun  9 14:50:43 kernel: [0.00] signal: max sigframe size: 1440
> Jun  9 14:50:43 kernel: [0.00] BIOS-provided physical RAM map:
> Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
> 0x-0x0009fbff] usable
> Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
> 0x0009fc00-0x0009] reserved
> Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
> 0x000f-0x000f] reserved
> Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
> 0x0010-0x3ffc9fff] usable
> Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
> 0x3ffca000-0x3fff] reserved
> Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
> 0xfeffc000-0xfeff] reserved
> Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
> 0xfffc-0x] reserved

That's 1 GiB RAM, not 32 GiB.  Still, that should be more than enough
for installation.

[...]
> Jun  9 14:55:00 kernel: [  260.262259] active_anon:35811 inactive_anon:26906 
> isolated_anon:0
> Jun  9 14:55:00 kernel: [  260.262259]  active_file:0 inactive_file:0 
> isolated_file:0
> Jun  9 14:55:00 kernel: [  260.262259]  unevictable:0 dirty:0 writeback:0
> Jun  9 14:55:00 kernel: [  260.262259]  slab_reclaimable:4417 
> slab_unreclaimable:7292
> Jun  9 14:55:00 kernel: [  260.262259]  mapped:2481 shmem:54494 pagetables:198
> Jun  9 14:55:00 kernel: [  260.262259]  sec_pagetables:0 bounce:0
> Jun  9 14:55:00 kernel: [  260.262259]  kernel_misc_reclaimable:0
> Jun  9 14:55:00 kernel: [  260.262259]  free:11279 free_pcp:2112 free_cma:0
> Jun  9 14:55:00 kernel: [  260.262273] Node 0 active_anon:53632kB 
> inactive_anon:60236kB active_file:0kB inactive_file:0kB unevictable:0kB 
> isolated(anon):0kB isolated(file):0kB mapped:9860kB dirty:0kB writeback:0kB 
> shmem:90728kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 14336kB 
> writeback_tmp:0kB kernel_stack:2032kB pagetables:620kB sec_pagetables:0kB 
> all_unreclaimable? yes
> Jun  9 14:55:00 kernel: [  260.262283] Node 1 active_anon:89612kB 
> inactive_anon:47388kB active_file:0kB inactive_file:0kB unevictable:0kB 
> isolated(anon):0kB isolated(file):0kB mapped:64kB dirty:0kB writeback:0kB 
> shmem:127248kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 4096kB 
> writeback_tmp:0kB kernel_stack:392kB pagetables:172kB sec_pagetables:0kB 
> all_unreclaimable? yes
[...]

So that's approximately:

 46 MiB of slab (kernel heap)
213 MiB of shmem (mostly initramfs files)
263 MiB of anon (process heap and stack)
 13 MiB of other stuff
---
536 MiB

which is well under 1 GiB.  It seems like there must be a lot of kernel
memory allocations that aren't being accounted here, and might have
been leaked.

But you will probably succeed in installing if you correct the memory
allocation for this VM to the intended 32 GiB.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice - John Levine



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

Bug#1038754: random hangs during boot inside qemu

[Ben Hutchings]

Control: tag -1 upstream

On Tue, 2023-06-20 at 23:36 +0200, Johannes Schauer Marin Rodrigues
wrote:
> Source: linux
> Severity: normal
> Tags: patch
> 

Which version are you using - is it 6.3.7-1 from unstable?

> Hi,
> 
> the jenkins job of my package mmdebstrap spawns ~260 qemu virtual
> machines on amd64 to run the test cases in. For about a week now I'm
> seeing random (about every ~300) hangs during boot. The effect can be
> seen in these logs:
> 
>  - https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/311/consoleText
>  - https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/313/consoleText
>  - https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/314/consoleText
> 
> Ctrl+F the logs for "qemu-system-x86_64: terminating on signal 15 from
> pid XXX (timeout)".
> 
> On #debian-devel, f_g suggested that this is a fixed problem:
> 
> https://lore.kernel.org/stable/c4724b40-89f6-5aa7-720d-c4a4af57c...@amazon.com/#r
> https://lore.kernel.org/all/5a56290d-806e-b9a5-f37c-f21958b5a...@grsecurity.net
> https://lore.kernel.org/stable/20230615091830.rxmv2...@linutronix.de/
> 
> Is there a chance to see a stable update with
> e9523a0d81899361214d118ad60ef76f0e92f71d applied?

That's the *breaking* change, not the fix.

The fix would seem to be
<https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=13bb06f8dd42071cb9a49f6e21099eea05d4b856>
but that hasn't even reached mainline yet.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken



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

Bug#1034903: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin navi10_mes.bin for module amdgpu

[Ben Hutchings]

On Thu, 27 Apr 2023 15:43:28 +0800 xiao sheng wen(肖盛文）
 wrote:
> Package: firmware-amd-graphics
> Version: 20230310-1~exp1
> Severity: normal
> X-Debbugs-Cc: atzli...@sina.com
> 
> Hi,
> 
>  When I upgrade to kernel 5.10.0-22-arm64, there are following error
>  infos:
> 
> W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin for 
> module amdgpu
> W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module 
> amdgpu
[...]

I see that the amdgpu driver has had references to these files for
several years, but they've never been added to linux-firmware.git.
More recently amdgpu added:

MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes.bin");
MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes_2.bin");
MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes1.bin");

and these are also missing from linux-firmware.git.

Is this firmware intended to be available to the public?

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source



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

Bug#989441: Missing Nvidia /lib/firmware/nouveau/nv106_fuc084

[Ben Hutchings]

Control: tag -1 wontfix

I don't think we're allowed to extract and redistribute firmware from
the Nvidia package.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source



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

Bug#1038610: firmware-bnx2x has an older version of broadcom drivers. This has been fixed for bookworm but not bullseye

[Ben Hutchings]

Control: fixed -1 20220913-1
Control: tag -1 bullseye
Control: severity -1 important

On Sun, 2023-06-18 at 18:15 -0500, tomas347 wrote:
> Package: firmware-bnx2x
> Version: 20210315-3
> Severity: minor
> Tags: patch
> X-Debbugs-Cc: tomas.leite.cas...@tecnico.ulisboa.pt
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
>I found that my network card was crashing and eventually lost all
>network connectivity and the OS stopped recognizing the card. I
>initially had to replace the card but the same thing happened on
>bullseye.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  I manually installed bnx2x-e1-7.13.21.0.fw, bnx2x-e1h-7.13.21.0.fw,
>  bnx2x-e2-7.13.21.0.fw, and now it works perfectly. This has been
>  fixed for bookworm but not bullseye. There are many people with
>  this issue and I found this workaround after many people debugged
>  it.
[...]

I think we never added this because we didn't expect stable kernel
changes to require newer firmware.

I'll try to get this fixed in the next point release for bullseye.

Ben.


-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source



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

Bug#1038625: firmware-realtek: Add configuration for stable connection (rtw88)

[Ben Hutchings]

Control: reassign -1 src:linux 6.1.27-1
Control: retitle -1 rtw88_pci: RX DMA errors despite rx_no_aspm workaround
Control: tag -1 upstream patch moreinfo

On Mon, 2023-06-19 at 03:20 -0300, Leandro Cunha wrote:
> Package: firmware-realtek
> Version: 20230404-1
> Severity: important
> 
> This firmware contains the rtw88 module

It doesn't - firmware and drivers are two different things.

> and needs some settings to
> have a stable connection, like disabling the ASPM (Active State Power
> Management)
[...]

OK, but if this is a general problem it should be fixed in the driver
and not by adding a configuration file.

This *was* supposed to have been fixed by
<https://git.kernel.org/linus/24f5e38a13b5ae2b6105cda8bb47c19108e62a9a>
but apparently not.

Could you please test whether the attached patch fixes this (without
also using disable_aspm=1)?  Instructions for rebuilding the kernel are
at
<https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official>.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

From 44b626514f8064f721c694ce977cf3a14da75047 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Tue, 20 Jun 2023 19:46:47 +0200
Subject: [PATCH] rtw88_pci: Apply rx_no_aspm workaround for longer

In certain configurations we need to keep the PCIe link in L0 to avoid
RX DMA errors.  Currently we do this while the poll function is
running, but this only roughly corresponds to when RX DMA is
happening.

Instead, keep the link in L0 for the whole time that NAPI polling is
enabled.  Use napi_schedule_prep()+__napi_schedule() rather than
napi_schedule(), so that we know for sure when we start and stop
polling.

Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/realtek/rtw88/pci.c | 27 +---
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index 672ddde80816..406bb12374d1 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -1014,7 +1014,15 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev)
 	struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
 	struct napi_struct *napi = >napi;
 
-	napi_schedule(napi);
+	if (napi_schedule_prep(napi)) {
+		__napi_schedule(napi);
+
+		/* If necessary, keep link in L0 so long as we are in
+		 * NAPI polling
+		 */
+		if (rtwpci->rx_no_aspm)
+			rtw_pci_link_ps(rtwdev, false);
+	}
 }
 
 static int rtw_pci_get_hw_rx_ring_nr(struct rtw_dev *rtwdev,
@@ -1644,9 +1652,6 @@ static int rtw_pci_napi_poll(struct napi_struct *napi, int budget)
 	  priv);
 	int work_done = 0;
 
-	if (rtwpci->rx_no_aspm)
-		rtw_pci_link_ps(rtwdev, false);
-
 	while (work_done < budget) {
 		u32 work_done_once;
 
@@ -1667,11 +1672,17 @@ static int rtw_pci_napi_poll(struct napi_struct *napi, int budget)
 		 * not be processed immediately. Check whether dma ring is
 		 * empty and perform napi_schedule accordingly.
 		 */
-		if (rtw_pci_get_hw_rx_ring_nr(rtwdev, rtwpci))
-			napi_schedule(napi);
+		if (rtw_pci_get_hw_rx_ring_nr(rtwdev, rtwpci) &&
+		napi_schedule_prep(napi)) {
+			__napi_schedule(napi);
+		} else {
+			/* If we kept link into L0, allow it to
+			 * re-enter L1 until next IRQ
+			 */
+			if (rtwpci->rx_no_aspm)
+rtw_pci_link_ps(rtwdev, true);
+		}
 	}
-	if (rtwpci->rx_no_aspm)
-		rtw_pci_link_ps(rtwdev, true);
 
 	return work_done;
 }


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

Bug#1038720: Missing hyperv_fb.ko in debian 12.0 kernel image 6.1.0-9-amd64

[Ben Hutchings]

On Tue, 2023-06-20 at 17:03 +0200, Bastian Blank wrote:
> On Tue, Jun 20, 2023 at 03:32:19PM +0200, RSA wrote:
> > Hello, I think kernel module hyperv_fb.ko is missing in the package. It was 
> > present in version 5.10.0-22 before upgrading to debian 12.
> > 
> > $ find /lib/modules/5.10.0-23-amd64 -name hyperv_fb.ko
> > /lib/modules/5.10.0-23-amd64/kernel/drivers/video/fbdev/hyperv_fb.ko
> > $ find /lib/modules/6.1.0-9-amd64 -name hyperv_fb.ko
> > 
> > The impact is a regression when using debian as an Hyper-V vm. Screen 
> > resolution can not be changed anymore when editing 
> > GRUB_CMDLINE_LINUX_DEFAULT.
> 
> This was replaced by hyperv_drm, which provides a standard mode
> selection output.

...although we do still build hyperv_fb for the cloud-amd64 flavour,
which seems like a mistake.

Ben.

> Not sure what you did with the kernel command line.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source



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

Bug#1038652: RM: odhcp6c/experimental -- ROM; unreleased, redundant with dhcpcd

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: odhc...@packages.debian.org
Control: affects -1 + src:odhcp6c

I originally packaged this program because I needed support for DHCPv6
PDs together with SLAAC.  I never integrated it with ifupdown, and the
same functionality is now available in dhcpcd and probably other
daemons.

Bug#1011089: nfs-utils: old configs /etc/default/nfs-* should have warnings

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 16 May 2022 15:13:07 -0300 Andreas Hasenack
 wrote:
> Package: nfs-utils
> Version: 1:2.6.1-2
> Severity: Normal
> 
> Dear Maintainer,
> 
> the config files in /etc/default/nfs-* should have a warning at the
> top stating that they are left there only for SySV systems that do not
> use systemd. In other words, they are ignored when systemd is used,
> and the configuration should be done in /etc/nfs.conf in that case.
> Otherwise users might get confused because changes they make to those
> files are not reflected in the actual services.
> 
> Alternatively, but probably not feasible for Debian yet, is to remove
> /etc/default/nfs-* entirely.

I intend to remove support in the init scripts for setting command line
options through these config files, and to update the default config
accordingly.  However, the config files will still be needed by the
init scripts to control which daemons are started.

Will that address your concerns?

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC



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

Bug#849942: rpc.svcgssd: systemd service file tests for wrong keytab

[Ben Hutchings]

Control: severity -1 wishlist
Control: tag -1 wontfix

This can be handled by adding a local systemd drop-in config file that
overrides the conditions:

[Unit]
ConditionPathExists=
ConditionPathExists=

Or you can symlink /etc/krb5.keytab to your actual keytab path.

Given that these options exist, I don't think it's worth the effort to
handle this in the package.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC



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

Bug#947685: still occuring on Linux 6.1.0-9-amd64 x86_64

[Ben Hutchings]

On Sun, 2023-05-28 at 21:22 +0200, Christian wrote:
> I am plagued with this on current Linux 6.1.0-9-amd64 x86_64.
> 
> As soon as load on the system increases, the error comes up and
> apparently it takes some other things (SATA) with it. Leaving the
> system workable, but slowly failing.
> 
> Happy to provide more information or test things.

Please open a new bug report.  Seeing the same message doesn't mean
you're seeing the same bug.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken


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

Bug#1036842: RM: raidutils -- RoQA; Depends on kernel driver that has been removed

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: raidut...@packages.debian.org, Barak A. Pearlmutter 

Control: affects -1 + src:raidutils

raidutils supports Adaptec (formerly DPT) I2O RAID controllers that
were handled by the Linux dpt_i2o driver.

The driver had some serious bugs that resulted in it being removed in
Linux 6.0.  As a result, raidutils can no longer be used with the
kernel in testing or unstable.

Bug#1036543: [PATCH 5.10 076/529] crypto: ccp: Use the stack for small SEV command buffers

[Ben Hutchings]

On Wed, 2023-05-17 at 16:06 +0200, Greg Kroah-Hartman wrote:
> On Wed, May 17, 2023 at 04:02:35PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 17, 2023 at 02:56:21PM +0200, Ben Hutchings wrote:
> > > On Fri, 2023-03-10 at 14:33 +0100, Greg Kroah-Hartman wrote:
> > > > From: Sean Christopherson 
> > > > 
> > > > [ Upstream commit e4a9af799e5539b0feb99571f0aaed5a3c81dc5a ]
> > > > 
> > > > For commands with small input/output buffers, use the local stack to
> > > > "allocate" the structures used to communicate with the PSP.   Now that
> > > > __sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no
> > > > reason to avoid using the stack, e.g. CONFIG_VMAP_STACK=y will just 
> > > > work.
> > > [...]
> > > 
> > > Julien Cristau reported a regression in ccp - the
> > > WARN_ON_ONCE(!virt_addr_valid(data)) is now being triggered.  I believe
> > > this was introduced by the above commit, which depends on:
> > > 
> > > commit 8347b99473a313be6549a5b940bc3c56a71be81c
> > > Author: Sean Christopherson 
> > > Date:   Tue Apr 6 15:49:48 2021 -0700
> > >  
> > > crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
> > > 
> > > Ben.
> > > 
> > 
> > Thanks for letting me know, now queued up.
> 
> Nope, now dropped, it breaks the build :(

I've now looked further and found that we need both:

d5760dee127b crypto: ccp: Reject SEV commands with mismatching command buffer
8347b99473a3 crypto: ccp: Play nice with vmalloc'd memory for SEV command 
structs

(Not yet tested; I'll ask Julien if he can do that.)

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


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

Bug#1036744: PTP in combination with vclocks partially broken on Debian kernels

[Ben Hutchings]

On Thu, 2023-05-25 at 10:37 +0200, Salvatore Bonaccorso wrote:
> Hi Florian,
> 
> [dropping a typoed mail from my to not cause further bounces]
> 
> On Thu, May 25, 2023 at 10:18:46AM +0200, Florian Bezdeka wrote:
> > On Thu, 2023-05-25 at 10:03 +0200, Salvatore Bonaccorso wrote:
[...]
> > 
> > > Ben, would you agree on make the PTP support.
> > > 
> > > > It would be possible that we provide a merge request on
> > > > salsa.debian.org. Just tell me the correct target branch. We would be
> > > > very happy to have it in 6.1 (bookworm) and of course in all kernel
> > > > flavors/feature sets.
> > > 
> > > I do not plan do accept any further bookworm targetting updates *right
> > > now*, mabye later for bookworm point releases as we are now in full
> > > freeze. There is no further upload planned for the 6.1.y series to
> > > unstable, following to be migrated in testing before the bookworm
> > > release. We can first apply to master and experimental upload if
> > > agreed on the following change above and then consider it later for
> > > bookworm. 
> > 
> > I think a point release would be acceptable for us. Sounds like a plan!
> > Thanks!
> 
> Let's see if there are comments from Ben or Arnd on the proposed
> change.

I agree we should make this built-in (except on armel/marvell).

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

Bug#1036446: Please enable udhcpc6

[Ben Hutchings]

Package: udhcpc
Version: 1:1.35.0-4+b2
Severity: wishlist
Tags: ipv6

Busybox has a DHCPv6 client (udhcpc6) but this is not included
in the Debian packages.

Please enable CONFIG_UDHCPC6 and the dependent features.

Ben.

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages busybox depends on:
ii  libc6  2.36-8

busybox recommends no packages.

busybox suggests no packages.

-- debconf-show failed

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Ben Hutchings]

On Sun, 2023-05-14 at 19:40 +0200, Ben Hutchings wrote:
[...]
> This works for me with all the QEMU graphics devices.  But I haven't
> tested on real hardware.

Now tested successfully on 2 custom desktops:

- Asus P8Z68-V LX motherboard, Intel Core i5 2500 CPU, integrated GPU
- ASRock B450 PRO4, AMD Ryzen 5 3600 CPU, Radeon RX580 GPU

and 2 laptops:

- Lenovo ThinkPad T420, Intel Core i5 2nd gen CPU, integrated GPU
- Lenovo ThinkPad T460, Intel Core i5 6th gen CPU, integrated GPU

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Ben Hutchings]

Control: tag -1 patch

On Sun, 2023-05-14 at 00:21 +0200, Ben Hutchings wrote:
[...]
> So I suppose there's a regression in either efifb or fbdev_drv.

I'm not spotting any functional changes in fbdev or the submodules it
depends on between bullseye and bookworm.  So this implicates either
efifb or, as you mentioned, GRUB.

> > Via QEMU, under BIOS and UEFI, results are:
> > 
> >   +-+-+-+-+
> >   |  Graphics   |  Bullseye 11.7  |  Bookworm RC 2  |  Daily builds   |
> >   +-+++++++
> >   | |  BIOS  |  UEFI  |  BIOS  |  UEFI  |  BIOS  |  UEFI  |
> >   +-+++++++
> >   | |   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga std|   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga cirrus |   OK   |   OK   |   OK   |  KO-S  |   OK   |  KO-S  |
> >   | -vga qxl|   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga virtio |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga vmware |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   +-+++++++
> 
> I started testing with QEMU and OVMF from unstable, and I'm instead
> seeing Xorg failing to start in the same cases you see glitches.  The
> relevant error message seems to be this one:
> http://codesearch.debian.net/show?file=xorg-server_2%3A21.1.7-3%2Fhw%2Fxfree86%2Ffbdevhw%2Ffbdevhw.c=504
[...]

I tested with QEMU from bullseye and OVMF from unstable, and again I
saw Xorg failing to start, rather than glitches.  Weird.

I also patched the kernel to report the internal screen_info structure
and the fb_var_screeninfo structure passed in and out of
FBIOPUT_VSCREENINFO.  The key difference is:

- With -vga qxl, screen_info says 32 bpp, X wants 32 bpp, the kernel
  agrees with that.
- With -vga std or -vga cirrus screen_info says 24 bpp, X wants 32
  bpp, and the kernel says 24 bpp.

I think the problem is this GRUB has native drivers for Bochs and
Cirrus that reprogram the framebuffer bit depth, and the kernel is then
confused about what the bit depth is supposed to be.  With QXL, GRUB
doesn't have a native driver so it doesn't reconfigure the framebuffer.

Unfortunately, with Secure Boot we have to use a monolithic GRUB build
so I can't easily exclude video_bochs and video_cirrus to see if that
improves matters.

But what does works for me is:

--- a/build/boot/x86/grub/grub-efi.cfg
+++ b/build/boot/x86/grub/grub-efi.cfg
@@ -5,7 +5,7 @@ else
 fi
 
 if loadfont $font ; then
-  set gfxmode=800x600
+  set gfxmode=800x600x32
   set gfxpayload=keep
   insmod efi_gop
   insmod efi_uga
--- END ---

A full patch is attached.

This works for me with all the QEMU graphics devices.  But I haven't
tested on real hardware.


Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
From 49a5e562850e3ae4f64ed2d61bd582d8adedc393 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Sun, 14 May 2023 19:17:45 +0200
Subject: [PATCH] Always use 32 bpp for GRUB EFI graphical menu (Closes:
 #1036019)

---
 build/boot/x86/grub/grub-efi.cfg | 2 +-
 debian/changelog | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/build/boot/x86/grub/grub-efi.cfg b/build/boot/x86/grub/grub-efi.cfg
index 0a9a67d48..14708c7bc 100644
--- a/build/boot/x86/grub/grub-efi.cfg
+++ b/build/boot/x86/grub/grub-efi.cfg
@@ -5,7 +5,7 @@ else
 fi
 
 if loadfont $font ; then
-  set gfxmode=800x600
+  set gfxmode=800x600x32
   set gfxpayload=keep
   insmod efi_gop
   insmod efi_uga
diff --git a/debian/changelog b/debian/changelog
index 4624187fe..6be6864b5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,12 @@
 debian-installer (20230428) UNRELEASED; urgency=medium
 
+  [ Cyril Brulebois ]
   * Bump Linux kernel ABI to 6.1.0-9.
   * Switch source format from 1.0 to 3.0 (native).
 
+  [ Ben Hutchings ]
+  * Always use 32 bpp for GRUB EFI graphical menu (Closes: #1036019)
+
  -- Cyril Brulebois   Thu, 27 Apr 2023 22:52:15 +0200
 
 debian-installer (20230427) unstable; urgency=medium


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

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Ben Hutchings]

note, keeping the bundling in src:debian-installer for the
> next few weeks makes us autonomous: we can enable and disable those
> extra modules without requiring a new linux upload… so it's nasty but I
> actually thought about the few advantages we were getting out of this!
> 
> We should also be OK legal-wise, given we already have linux in
> Built-Using via its udebs, so copying things around from linux-image
> wouldn't change anything there, would it?
> 
> Of course in the long run, if having those modules is desired, it will
> be better to have them merged in linux and to drop the nasty code, e.g.
> in a point release.
[...]

Definitely.

I will spend some time investigating this, but I doubt I'll come up
with a better fix in time.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


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

Bug#1035769: unblock: kernel-handbook/1.0.21

[Ben Hutchings]

bk 2023-05-08 23:05:29.0 
+0200
@@ -67,7 +67,18 @@
 part of the kernel version to mark ABI changes that aren't due to a new
 upstream version.  This part comes from the abiname setting
 in debian/config/defines.  We use either a number or 
'trunk'
-(for experimental), but for a custom package it should be some other string.
+(for experimental).
+
+
+If you are rebuilding the package with local modifications, you should
+change the ABI name to some other string, for example
+0.local.  Then run the command
+
+
+$ debian/rules debian/control-real
+
+
+to regenerate the package definitions for this ABI name.
 
 
 
@@ -109,7 +120,7 @@
 debian/config/defines.  Then run the command
 
 
-$ fakeroot debian/rules 
debian/control-real
+$ debian/rules debian/control-real
 
 
 to regenerate the package definitions for this ABI name.
diff -Nru kernel-handbook-1.0.20/debian/changelog 
kernel-handbook-1.0.21/debian/changelog
--- kernel-handbook-1.0.20/debian/changelog 2022-10-03 01:56:35.0 
+0200
+++ kernel-handbook-1.0.21/debian/changelog 2023-05-08 23:17:30.0 
+0200
@@ -1,3 +1,20 @@
+kernel-handbook (1.0.21) unstable; urgency=medium
+
+  * Try to reduce pain points in rebuilding official kernel packages
+(Closes: #1022061):
+- Reorder sections in "Common kernel-related tasks" to reduce confusion
+- Deprecate older versions of test-patches
+- Recommend changing ABI name before rebuilding
+- Add command to enable parallel builds when invoking make directly
+- Avoid using fakeroot
+  * Remove obsolete text referring to "patchlevels" in source packages
+  * Remove redundant "bash" from debian/bin/test-patches command lines
+  * Update instructions for disabling debug info (Closes: #1023773)
+  * Update instructions for building linux-headers-common package
+  * Update copyright years
+
+ -- Ben Hutchings   Mon, 08 May 2023 23:17:30 +0200
+
 kernel-handbook (1.0.20) unstable; urgency=medium
 
   [ Tomasz Warniełło ]
diff -Nru kernel-handbook-1.0.20/debian/copyright 
kernel-handbook-1.0.21/debian/copyright
--- kernel-handbook-1.0.20/debian/copyright 2022-07-18 16:08:26.0 
+0200
+++ kernel-handbook-1.0.21/debian/copyright 2023-05-08 23:17:14.0 
+0200
@@ -1,7 +1,7 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 
 Files: *
-Copyright: 2005-2018, 2020, 2022 Debian Kernel Handbook Project
+Copyright: 2005-2018, 2020, 2022-2023 Debian Kernel Handbook Project
 License: GPL-2+
  This package is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
diff -Nru kernel-handbook-1.0.20/kernel-handbook.dbk 
kernel-handbook-1.0.21/kernel-handbook.dbk
--- kernel-handbook-1.0.20/kernel-handbook.dbk  2022-07-18 16:08:22.0 
+0200
+++ kernel-handbook-1.0.21/kernel-handbook.dbk  2023-05-08 23:16:37.0 
+0200
@@ -21,7 +21,7 @@
 
 
 
-2005-2018, 2020, 2022Debian Kernel Handbook 
Project
+2005-2018, 2020, 2022-2023Debian Kernel 
Handbook Project
 
 
 This handbook is free software; you may redistribute it and/or modify it under
diff -Nru kernel-handbook-1.0.20/po4a/kernel-handbook.ja.po 
kernel-handbook-1.0.21/po4a/kernel-handbook.ja.po
--- kernel-handbook-1.0.20/po4a/kernel-handbook.ja.po   2022-10-03 
00:55:55.0 +0200
+++ kernel-handbook-1.0.21/po4a/kernel-handbook.ja.po   2023-05-08 
23:05:29.0 +0200
@@ -1704,8 +1704,8 @@
 #. type: Content of: 
 #: chapter-versions.dbk:112
 #, no-wrap
-msgid "$ fakeroot debian/rules 
debian/control-real\n"
-msgstr "$ fakeroot debian/rules 
debian/control-real\n"
+msgid "$ debian/rules 
debian/control-real\n"
+msgstr "$ debian/rules 
debian/control-real\n"
 
 #. type: Content of: 
 #: chapter-versions.dbk:115
@@ -1908,11 +1908,9 @@
 #. type: Content of: 

 #: chapter-common-tasks.dbk:34
 msgid ""
-"# apt-get install build-essential fakeroot"
+"# apt-get install build-essential"
 msgstr ""
-"# apt-get install build-essential fakeroot"
+"# apt-get install build-essential"
 
 #. type: Content of: 
 #: chapter-common-tasks.dbk:35 chapter-common-tasks.dbk:221
@@ -2023,10 +2021,10 @@
 #, no-wrap
 msgid ""
 "# apt-get install devscripts\n"
-"$ bash debian/bin/test-patches 
../fix-bug123456.patch ../add-foo-driver.patch\n"
+"$ debian/bin/test-patches ../fix-bug123456.patch 
../add-foo-driver.patch\n"
 msgstr ""
 "# apt-get install devscripts\n"
-"$ bash debian/bin/test-patches 
../fix-bug123456.patch ../add-foo-driver.patch\n"
+"$ debian/bin/test-patches ../fix-bug123456.patch 
../add-foo-driver.patch\n"
 
 #. type: Content of: 
 #: chapter-common-tasks.dbk:98
@@ -2040,8 +2038,8 @@
 #. type: Content of: 
 #: chapter-common-tasks.dbk:102
 #, no-wrap
-msgid "$ bash 
debian/bin/test-patches\n"
-msgstr &qu

Bug#1034550: r8168-dkms: Excessive network latency with PREEMPT_RT kernel without the R8168-dkms driver

[Ben Hutchings]

On Mon, 2023-04-24 at 07:00 +1000, Rod Webster wrote:

[...]
> I have not kept my .config files as PC's have been reformatted so many
> times. However, my kernels and the steps used to build them are available
> in my google drive. They will show what we have changed. Here is the link
> to the 6.1.0-rt5 kernel
> https://drive.google.com/drive/folders/1jGc6AUYKMPvsSOdWRdvhWeDX1P96tsFQ?usp=sharing
> <https://drive.google.com/drive/folders/1jGc6AUYKMPvsSOdWRdvhWeDX1P96tsFQ?usp=sharing>
> I
> will redo this for the final 6.1 kernel and share the config to get in step
> with Debian Bookworm's current state.
[...]
> 

I'm not spotting any particular interesting differences in the config
there, unfortunately.  And from your earlier messages, it sounded like
you didn't have so much of a problem with the Debian packages for Linux
6.1 anyway.

If you still have custom packages of Linux 5.10 where the r8169
driver's network latency is OK, I would like to see those.

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#1034550: r8168-dkms: Excessive network latency with PREEMPT_RT kernel without the R8168-dkms driver

[Ben Hutchings]

Control: retitle -1 linux-image-rt-amd64: High network latency with r8169 driver
Control: tag -1 moreinfo

On Sun, 2023-04-23 at 09:14 +1000, Rod Webster wrote:
> Thanks.
> That is really a disappointing response because:
> 1. Hardware selected based on  Debian  4.x kernels in Buster that operated
> safely was broken by the 5.10 and above kernels in Bullseye and Bookworm
> 2. You ask us to report a bug if the R8168-dkms package has to be used so
> we did, now no interest is shown in actioning the report
> 3. It does not address the excessive latency in the Debian RT kernel that
> is not present in the upstream version at kernel.org
> 4. It has taken a lot of work from a lot of Linuxcnc users to identify the
> issues before this report could be made.
> 
> The official ISO release of Linuxcnc is still based on Buster so not many
> users ventured into the later kernels hence the delay in reporting.
> Linuxcnc is packaged in Bookworm so the issue will be more prevalent moving
> forward.
> 
> I was told by a Debian developer involved in linuxcnc that if there were
> issues affecting us, they would be fixed. I hope something comes of this.
[...]

I'm not dismissing this bug report, but I wanted to first make it clear
that we cannot take any responsibility for safety-critical
applications.

As to the general issue of network latency:
- What was the latest Debian packaged kernel version you used?
- You've said that installing r8168-dkms resolves the issue. Am I
correct in assuming that when you ran the Debian packaged kernel, the
r8169 driver was used?
- Have you tested on any other machines with different network
hardware?
- We don't make a lot of changes to the kernel source, but our build
configuration will be different. Can you confirm exactly which upstream
release you've tested, and provide the configuration (.config) file you
used?

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#1034550: r8168-dkms: Excessive network latency with PREEMPT_RT kernel without the R8168-dkms driver

[Ben Hutchings]

On Tue, 18 Apr 2023 12:12:58 +1000 Rod Webster  wrote:
[...]
> Linuxcnc uses a 1 ms realtime thread and we regularly see "Error Finishing
> Read" reported.  This error disables the connection becasue our 1 ms thread 
> has
> been overrun. This issue mainly affects Realtek NIC hardware and s of real
> concern where the motion hardware could be commanding components weiging
> several thousand pounds.
[...]

The real-time kernel packages are provided as a convenience for users
that have non-safety-critical real-time requirements, such as audio
production.

For safety-critical applications, you must take responsibility (or find
a supplier who can) for selecting and validating software that meets
the real-time and other reliability requirements.

As a reminder, "Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to
the extent permitted by applicable law."

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice - John Levine


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

Bug#1034648: postinst runs linux-update-symlinks before initrd exists

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 2023-04-20 at 16:09 -0400, Joey Hess wrote:
> Source: linux
> Version: 6.1.20-2
> Severity: normal
> 
> I was upgrading a slow arm board and noticed this:
> 
> Setting up linux-image-6.1.0-7-armmp-lpae (6.1.20-2) ...
> I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.18.0-4-armmp-lpae
> I: /initrd.img.old is now a symlink to boot/initrd.img-5.18.0-4-armmp-lpae
> I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-7-armmp-lpae
> I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-7-armmp-lpae
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-6.1.0-7-armmp-lpae
> 
> It probably took 5 minutes to generate the initrd, and until then
> /initrd.img was a dangling symlink. A power failure in this wide window would
> not be fun.

This behaviour is intentional.  The expectation is that these symlinks
are used by programs that update the boot loader configuration later
on, and those will be run only after the initramfs has been generated.
What do you think will go wrong here?

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice - John Levine


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

Bug#1034190: More security bugs in game loading

[Ben Hutchings]

On Thu, 2023-04-20 at 10:01 +0200, Paul Gevers wrote:
> Hi Ben,
> 
> On Mon, 10 Apr 2023 22:01:04 +0200 Ben Hutchings  
> wrote:
> > Package: sgt-puzzles
> > Severity: serious
> 
> The fix for this bug will not automatically migrate to testing because 
> the package doesn't have autopkgtests and we're in the freeze. The 
> changes are massive,

They're actually not that massive, but split into a lot of small
patches.

> so I'd like to confirm in an unblock bug that all 
> changes are indeed targeted fixes before unblocking. Can you file such 
> an unblock request if you don't want the package to be autoremoved (or 
> add a non-superficial autopkgtest if that makes sense)?

Yes, I will file an unblock request.

Ben.

-- 
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding
stump of a severed limb. - me, 29 June 1999


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

Bug#1034190: More security bugs in game loading

[Ben Hutchings]

Package: sgt-puzzles
Version: 20230122.806ae71-1
Severity: serious
Tags: security upstream fixed-upstream
X-Debbugs-Cc: Debian Security Team 

Ben Harris found multiple issues in sgt-puzzles where a malformed game
description or save file can lead to a buffer overflow, buffer
overread, use of an uniniitialised pointer, integer overflow, null
pointer dereference, division by zero, assertion failure, or memory
leak.  These were fixed upstream over the past few months.

The Debian package doesn't register any media type handler for save
files, so I think this can only be exploited by social-engineering a
user into loading such a file or description.

For most of these bugs, the impact is limited to a crash of the
application.  However, the various memory safety errors may be more
serious.  On some architectures, division by zero does not cause an
exception and this might also be exploitable.

Ben.

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sgt-puzzles depends on:
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libgtk-3-0   3.24.37-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1

Versions of packages sgt-puzzles recommends:
ii  chromium [www-browser]  111.0.5563.64-1
ii  firefox [www-browser]   111.0-3
ii  lynx [www-browser]  2.9.0dev.12-1
ii  xdg-utils   1.1.3-4.1

sgt-puzzles suggests no packages.

-- debconf-show failed

Bug#1033329: Bad symbol versions on 32-bit architectures

[Ben Hutchings]

Source: linux
Version: 6.1.20-1
Severity: important
Tags: upstream patch

On 32-bit architectures, many symbol versions (CRCs) are recorded in
Module.symvers as 0x7fff.

This is a regression, and I have bisected it to the upstream change:

commit f292d875d0dc700b3af0bef04c5abc1dc7b3b62c
Author: Masahiro Yamada 
Date:   Fri May 13 20:39:21 2022 +0900

modpost: extract symbol versions from *.cmd files

modpost now reads CRCs from .*.cmd files, parsing them using strtol().
This is inconsistent with its parsing of Module.symvers and with their
definition as *unsigned* 32-bit values.

strtol() clamps values to [LONG_MIN, LONG_MAX], and when building on a
32-bit system this changes all CRCs >= 0x8000 to be 0x7fff.

Ben.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 8a2d6347c9b3caed32c3e8dc4e219f43d9410d01 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Wed, 22 Mar 2023 18:51:42 +0100
Subject: [PATCH] modpost: Fix processing of CRCs on 32-bit build machines

modpost now reads CRCs from .*.cmd files, parsing them using strtol().
This is inconsistent with its parsing of Module.symvers and with their
definition as *unsigned* 32-bit values.

strtol() clamps values to [LONG_MIN, LONG_MAX], and when building on a
32-bit system this changes all CRCs >= 0x8000 to be 0x7fff.

Change extract_crcs_for_object() to use strtoul() instead.

Cc: sta...@vger.kernel.org
Fixes: f292d875d0dc ("modpost: extract symbol versions from *.cmd files")
Signed-off-by: Ben Hutchings 
---
 scripts/mod/modpost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 2c80da0220c3..1dfa80c6b471 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1722,7 +1722,7 @@ static void extract_crcs_for_object(const char *object, 
struct module *mod)
if (!isdigit(*p))
continue;   /* skip this line */
 
-   crc = strtol(p, , 0);
+   crc = strtoul(p, , 0);
if (*p != '\n')
continue;   /* skip this line */
 

Bug#925134: grub-efi-amd64-signed: doesn't mount cryptodisk

[Ben Hutchings]

It seems like this bug is related to GRUB lacking LUKS2 support.  Back
in buster, GRUB only supported LUKS1, so this bug could only be worked-
around by using LUKS1 for /boot.

Now GRUB has some support for LUKS2 at boot time, but grub-probe
doesn't recognise LUKS2 devices properly so the necessary modules don't
get loaded automatically.

There is a separate bug report #1028301 explicitly relating to grub-
probe.  I found the upstream commits that seem to fix it and added them
to that bug report.  Perhaps they would also fix this?

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#926689: cryptsetup-initramfs: config lines in grub.cfg for cryptodisk/luks and other modules missing

[Ben Hutchings]

This appears to be the same as #1028301, for which I've attached
upstream patchs.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#1030280: general: General non-recognized errors (im novice) after the installation: drivers, battery, booting errors...

[Ben Hutchings]

Control: reassign -1 installation-reports
Control: tag -1 moreinfo

On Thu, 2023-02-02 at 00:18 +0100, Miguel González Jiménez wrote:
> Package: general
> Severity: normal
> X-Debbugs-Cc: migui...@hotmail.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> After the installation, I proceed to use the hardware and no correct firmware 
> had been installed. Couldn't use neither the touchpad, the wifi card (AX200 
> Intel) nor several screen caracteristics.
> I've tried to install its drivers but they dont work. I think something went 
> wrong during the installation. Besides, battery is running out quite fast and 
> fans are most of the time active. After installing wifi card Intel drivers, 
> booting errors has became to show up on the log booting screen, refeering 
> bugs about usb and bluetooth ports.
> The partition on the solid disk (what also holds Windows 10) has been made 
> fine I think.
> 

Unfortunately the official installation images for Debian 11 do not
include non-free firmware that's required to support some devices.
There are alternate images with non-free firmware included at
<https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/>.

For the next release, Debian 12 "bookworm", we will include and install
non-free firmware by default.  If you want to test the next release,
installation images for that are at
<https://www.debian.org/devel/debian-installer/>.

Please report back whether you still have problems after using one of
these installers.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#1013594: insubstantial: FTBFS: Caused by: : java.lang.VerifyError: Expecting a stackmap frame at branch target 33

[Ben Hutchings]

The laf-widget library that's part of this package generates some Java
bytecode directly:
<https://sources.debian.org/src/insubstantial/7.3+dfsg3-5/laf-widget/src/main/java/org/pushingpixels/lafwidget/ant/LafMainClassAugmenter.java/?hl=174>.
Since Java 11, additional metadata (the "stackmap frame") appears to be
required for Java bytecode, and is not generated by laf-widget.

However, this code generation is apparently only used to "augment" the
rendering of other widget classes and does not seem to be essential for
the function of the library.  In fact, it was completely removed in a
later version of laf-widget:
https://github.com/kirill-grouchnikov/laf-widget/commit/8b0871e84ca6b6c0c479a6033998eb39e0fc767d

I patched the Gradle build files to disable this code generation and
the build succeeded.  I tested triplea with the old and new binaries
built from insubstantial: start the program, install the "Tutorial"
map, and start a local game with that map.  I didn't see any
regressions.  As I expected, the GUI rendering is different but only
slightly; see the attached "old" and "new" screenshots.

scilab is already broken (#1030205) so I couldn't test it.

I will NMU with the attached changes shortly.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
diff -Nru insubstantial-7.3+dfsg3/debian/changelog insubstantial-7.3+dfsg3/debian/changelog
--- insubstantial-7.3+dfsg3/debian/changelog	2019-08-26 13:49:59.0 +0200
+++ insubstantial-7.3+dfsg3/debian/changelog	2023-03-03 23:42:05.0 +0100
@@ -1,3 +1,10 @@
+insubstantial (7.3+dfsg3-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Java 11: disable augmentation (fixes FTBFS) (Closes: #1013594)
+
+ -- Ben Hutchings   Fri, 03 Mar 2023 23:42:05 +0100
+
 insubstantial (7.3+dfsg3-5) unstable; urgency=medium
 
   [ Andrius Merkys ]
diff -Nru insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch
--- insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch	1970-01-01 01:00:00.0 +0100
+++ insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch	2023-03-03 23:11:22.0 +0100
@@ -0,0 +1,51 @@
+From: Ben Hutchings 
+Subject: Java 11: disable augmentation
+Date: Fri, 03 Mar 2023 23:11:14 +0100
+Bug-Debian: https://bugs.debian.org/1013594
+
+Since Java 11, Java bytecode is required to include some additional
+metadata.  The bytecode generated by laf-widget for "augmentation" of
+other widget libraries does not follow this requirement, resulting in
+a build failure.
+
+A later version of laf-widget has removed this augmentation rather
+than fixing it:
+https://github.com/kirill-grouchnikov/laf-widget/commit/8b0871e84ca6b6c0c479a6033998eb39e0fc767d
+
+This augmentation does not seem to be essential, so disable it until
+it is fixed or properly removed.
+
+---
+--- a/substance-flamingo/build.gradle
 b/substance-flamingo/build.gradle
+@@ -24,6 +24,8 @@ dependencies {
+ 
+ task augmentation(dependsOn: classes) {
+   description = "Performs code augmentaiton for the laf-plugin and laf-widget libraries on the substance jar classes"
++  // Broken under Java 11 - see Debian bug #1013594
++  enabled = false
+ 
+   doLast {
+ def augmentClassPath = configurations.toolsCompile.asPath + File.pathSeparator + configurations.compile.asPath
+--- a/substance-swingx/build.gradle
 b/substance-swingx/build.gradle
+@@ -25,6 +25,8 @@ dependencies {
+ 
+ task augmentation(dependsOn: classes) {
+   description = "Performs code augmentaiton for the laf-plugin and laf-widget libraries on the substance jar classes"
++  // Broken under Java 11 - see Debian bug #1013594
++  enabled = false
+ 
+   doLast {
+ def augmentClassPath = configurations.toolsCompile.asPath + File.pathSeparator + configurations.compile.asPath
+--- a/substance/build.gradle
 b/substance/build.gradle
+@@ -28,6 +28,8 @@ dependencies {
+ 
+ task augmentation(dependsOn: classes) {
+   description = "Performs code augmentaiton for the laf-plugin and laf-widget libraries on the substance jar classes"
++  // Broken under Java 11 - see Debian bug #1013594
++  enabled = false
+ 
+   doLast {
+ def augmentClassPath = configurations.toolsCompile.asPath
diff -Nru insubstantial-7.3+dfsg3/debian/patches/series insubstantial-7.3+dfsg3/debian/patches/series
--- insubstantial-7.3+dfsg3/debian/patches/series	2019-08-26 13:49:59.0 +0200
+++ insubstantial-7.3+dfsg3/debian/patches/series	2023-03-03 22:31:44.0 +0100
@@ -4,3 +4,4 @@
 asm5.patch
 java9-compatibility.patch
 fix-56.patch
+java-11-disable-augmentation.patch


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

Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation

[Ben Hutchings]

Control: tag -1 upstream fixed-upstream patch

On Mon, 09 Jan 2023 12:12:19 +0100 Laurent Bigonville
 wrote:
> Package: grub-common
> Version: 2.06-7
> Severity: serious
> File: /usr/sbin/grub-probe
> 
> Hello,
> 
> On a newly installed laptop, it seems that grub-probe is not able to
> detect that files are on an encrypted FS.
> 
> New laptop:
> 
> $ sudo grub-probe -t abstraction 
> /usr/share/images/desktop-base/desktop-grub.png
> lvm
> 
> $ sudo lsblk
> NAME  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
> nvme0n1   259:0    0 476,9G  0 disk
> ├─nvme0n1p1   259:1    0   512M  0 part  /boot/efi
> ├─nvme0n1p2   259:2    0   488M  0 part  /boot
> └─nvme0n1p3   259:3    0   476G  0 part
>   └─nvme0n1p3_crypt   254:0    0 475,9G  0 crypt
> ├─new_laptop--vg-root    254:1    0  27,9G  0 lvm   /
> ├─new_laptop--vg-swap_1  254:2    0   976M  0 lvm   [SWAP]
> ├─new_laptop--vg-home    254:3    0    40G  0 lvm   /home
> └─new_laptop--vg-libvirt 254:4    0    60G  0 lvm   /var/lib/libvirt
[...]

I can reproduce this. What changed is that we now use LUKS2 instead of
LUKS1. Although GRUB has some LUKS2 support, it doesn't probe LUKS2
volumes automatically.

I found the 3 upstream commits that are enough to make the "grub-probe
..." line work and am attaching a debdiff with those.  I don't know
whether this is enough to completely fix the problem.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.

diff -Nru grub2-2.06/debian/changelog grub2-2.06/debian/changelog
--- grub2-2.06/debian/changelog	2023-02-25 21:16:55.0 +0100
+++ grub2-2.06/debian/changelog	2023-03-03 19:21:28.0 +0100
@@ -1,3 +1,15 @@
+grub2 (2.06-8.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix probing of LUKS2 devices (Closes: #1028301):
+- disk/cryptodisk: When cheatmounting, use the sector info of the cheat
+  device
+- osdep/devmapper/getroot: Have devmapper recognize LUKS2
+- osdep/devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM
+  parameters
+
+ -- Ben Hutchings   Fri, 03 Mar 2023 19:21:28 +0100
+
 grub2 (2.06-8.1) experimental; urgency=medium
 
   * Non-maintainer upload.
diff -Nru grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
--- grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch	1970-01-01 01:00:00.0 +0100
+++ grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch	2023-03-03 19:21:28.0 +0100
@@ -0,0 +1,72 @@
+From: Fabian Vogt 
+Date: Thu, 12 Jan 2023 17:05:07 -0600
+Subject: disk/cryptodisk: When cheatmounting, use the sector info of the cheat
+ device
+Origin: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=efc9c363b2aab222586b420508eb46fc13242739
+Bug-Debian: https://bugs.debian.org/1028301
+
+When using grub-probe with cryptodisk, the mapped block device from the host
+is used directly instead of decrypting the source device in GRUB code.
+In that case, the sector size and count of the host device needs to be used.
+This is especially important when using LUKS2, which does not assign
+total_sectors and log_sector_size when scanning, but only later when the
+segments in the JSON area are evaluated. With an unset log_sector_size,
+grub_device_open() complains.
+
+This fixes grub-probe failing with
+"error: sector sizes of 1 bytes aren't supported yet.".
+
+Signed-off-by: Fabian Vogt 
+Reviewed-by: Patrick Steinhardt 
+Tested-by: Glenn Washburn 
+Reviewed-by: Glenn Washburn 
+Reviewed-by: Patrick Steinhardt 
+Reviewed-by: Daniel Kiper 
+---
+ grub-core/disk/cryptodisk.c | 20 ++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+--- a/grub-core/disk/cryptodisk.c
 b/grub-core/disk/cryptodisk.c
+@@ -694,16 +694,31 @@ grub_cryptodisk_open (const char *name,
+   if (!dev)
+ return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No such device");
+ 
+-  disk->log_sector_size = dev->log_sector_size;
+-
+ #ifdef GRUB_UTIL
+   if (dev->cheat)
+ {
++  grub_uint64_t cheat_dev_size;
++  unsigned int cheat_log_sector_size;
++
+   if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
+ 	dev->cheat_fd = grub_util_fd_open (dev->cheat, GRUB_UTIL_FD_O_RDONLY);
+   if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
+ 	return grub_error (GRUB_ERR_IO, N_("cannot open `%s': %s"),
+ 			   dev->cheat, grub_util_fd_strerror ());
++
++  /* Use the sector size and count of the cheat device. */
++  cheat_dev_size = grub_util_get_fd_size (dev->cheat_fd, dev->cheat, _log_sector_size);
++  if (cheat_dev_size 

Bug#1018235: sgt-puzzles: Updated German man page / halibut translation

[Ben Hutchings]

On Sat, 2022-08-27 at 17:21 +0200, Helge Kreutzmann wrote:
> Package: sgt-puzzles
> Version: 20220801.89391ba-1
> Severity: wishlist
> Tags: patch l10n
> 
> The last update reminded me to actually use sgt-puzzles (had not done
> so for quite some time) and since I had forgotten the rules, I read my
> own translation and spotted some typos. Once you upload your next
> version, could you include the updated de.po (attached)?

Thanks, I've now applied these changes in Git.


> Finally I noticed that you are in quite close contact with upstream. I
> noticed that some links in the documentation are broken, e.g.
> http://www.nikoli.com/en/puzzles/slitherlink.html
> 
> Maybe upstream wants to review this? (I can open a separate bug if
> you want).

These have since been fixed upstream (without my intervention).

I've prepared an update to the current upstream version and pushed that
to Salsa.  Note that I gave up on using git-debrebase, so you again
need to run "QUILT_PATCHES=debian/patches quilt push -a" to create the
po/de.po file.

I've updated the translations for some strings that became fuzzy
(commit dfcf98bb) but there is still one new untranslated string. 
Could you have a look at that?

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


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

Bug#1028986: Multiple integer overflow and buffer overflow issues in game loading

[Ben Hutchings]

Package: sgt-puzzles
Version: 20220801.89391ba-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Ben Harris found multiple issues in sgt-puzzles where a malformed game
description or save file can lead to integer overflow or buffer
overflow.  These were fixed upstream today, and I'll upload the
changes to unstable shortly.

The Debian package doesn't register any media type handler for save
files, so I think this can only be exploited by social-engineering a
user into loading such a file or description.

Ben.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sgt-puzzles depends on:
ii  libc62.36-6
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.3-1
ii  libgtk-3-0   3.24.35-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1

Versions of packages sgt-puzzles recommends:
ii  chromium [www-browser]  108.0.5359.124-1
ii  firefox [www-browser]   108.0-2
ii  lynx [www-browser]  2.9.0dev.10-1+b1
ii  xdg-utils   1.1.3-4.1

sgt-puzzles suggests no packages.

-- debconf-show failed

Bug#1016632: firmware-atheros: Missing binary in firmware-atheros package

[Ben Hutchings]

Control: reassign -1 src:linux 5.18.14-1
Control: retitle -1 ath10k: Spurious warning for missing calibration file

On Thu, 04 Aug 2022 10:46:05 +0200 marc  wrote:
> Package: firmware-atheros
> Version: 20210818-1
> Severity: normal
> X-Debbugs-Cc: m...@gallifrey-blr.fr
> 
> Dear Maintainer,
> 
> On the boot of my laptop (DELL Latitude 7480) I have one error
message.
> Here the result of "dmesg | grep -iE 'firmware|microcode'" :
[...]
> [    5.077307] ath10k_pci :02:00.0: firmware: failed to load ath10k/pre-
> cal-pci-:02:00.0.bin (-2)
> [    5.077342] firmware_class: See https://wiki.debian.org/Firmware for
> information about missing firmware
> [    5.077384] ath10k_pci :02:00.0: firmware: failed to load ath10k/cal-
> pci-:02:00.0.bin (-2)
[...]
> After some research on internet it appears some optional binary are
missing
> from firmware-atheros package.
> I don't have issues with my wifi card. Apparently it works.

I don't think there's anything we can provide.  This file seems like it
would have to be created for your specific computer since the name
includes the card's PCI address.  So this is a bug in the driver;
possibly our fault as we change the way missing firmware is logged.

Ben.

-- 
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.


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

Bug#1021012: marked as done (linux-image-amd64 depends on linux-image-4.19.0-22-amd64, but this package is not available)

[Ben Hutchings]

On Sat, 2022-10-01 at 12:23 +0200, Bastian Blank wrote:
> On Sat, Oct 01, 2022 at 06:45:03AM +, Debian Bug Tracking System wrote:
> > This will resolve itself automatically once the signed packages are
> > available as well (they are in progress of beeing dealt with but needs
> > a manual interaction of ftp-masters).
> 
> Looks like we need to backport the changes that moved the meta package
> into linux-signed-*.  This now also affects the build of the cloud
> images and breaks them.

In buster, the metapackages are still built from linux-latest.  This
has a fake build-dependency on linux-headers--all to ensure it
waits for linux to be built, but it doesn't have any such relation to
linux-signed-*.

I don't think I should try to move binary packages around post-release,
so probably the best approach is to wait to upload linux-latest in
future.

(This wasn't a problem with stretch LTS because we didn't do code
signing, and it wasn't a problem with buster prior to LTS because
security updates and point releases would release all related packages
at once.)

Ben

-- 
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding
stump of a severed limb. - me, 29 June 1999


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

Bug#1017720: nfs-common: No such file or directory

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2022-08-19 at 13:16 +, Jason Breitman wrote:
> Package: nfs-common
> Version: 1:1.3.4-6
> Severity: important
> 
> Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64
> GNU/Linux
> 
> -- Description
> After updating and or creating new files on our file server via
> rsync, we see many files report the error message below from NFSv4
> clients since upgrading from Debian 10.8 to Debian 11.4.
> Clearing the dentry cache resolves the issue right away.
> I am not sure that nfs-common is the package to blame, but listed
> it based on the bug submission recommendations. 

The NFS implementation is mostly in the kernel, so probably this issue
belongs there.  But the kernel team is responsible for both packages.

[...]
> -- Error message
> ls: cannot access 'filename': No such file or directory
> -? ? ???? filename
[...]

So we know the file's there but can't stat it.  I think this means the
client has cached the handle of the old file of that name, which has
been deleted.

- Are client and server clocks closely synchronised?  If not, that
needs to be fixed.

- Are clients likely to read this directory while rsync is running, or
shortly before?  If so, it may help to reduce the attribute caching
timeout on the client.  See the "Directory entry caching" section in
the nfs(5) manual page.

I don't know why you're only seeing this after an upgrade of the
clients, though.  I'm not aware that there has been any big change to
attribute caching.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


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

Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

[Ben Hutchings]

On Fri, 2022-08-19 at 13:01 +0200, Peter Zijlstra wrote:
> On Fri, Aug 19, 2022 at 10:47:21AM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote:
> > > From: Ben Hutchings 
> > > 
> > > The mitigation for PBRSB includes adding LFENCE instructions to the
> > > RSB filling sequence.  However, RSB filling is done on some older CPUs
> > > that don't support the LFENCE instruction.
> > > 
> > 
> > Wait; what? There are chips that enable the RSB mitigations and DONT
> > have LFENCE ?!?
> 
> So I gave in and clicked on the horrible bugzilla thing. Apparently this
> is P3/Athlon64 era crud.
> 
> Anyway, the added LFENCE isn't because of retbleed; it is because you
> can steer the jnz and terminate the loop early and then not actually
> complete the RSB stuffing.

I know, I corrected that further down.

> New insights etc.. So it's a geniune fix for the existing rsb stuffing.
> 
> I'm not entirly sure what to do here. On the one hand, it's 32bit, so
> who gives a crap, otoh we shouldn't break these ancient chips either I
> suppose.
> 
> How's something like so then? It goes on top of my other patch cleaning
> up this RSB mess:
> 
>   
> https://lkml.kernel.org/r/Yv9m%2FhuNJLuyviIn%40worktop.programming.kicks-ass.net
[...]

That should be:
https://lore.kernel.org/all/yv9m%2fhunjluyv...@worktop.programming.kicks-ass.net/
(the redirector unescapes the URL-escaped /).

So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
we can't have nested alternatives.  That's unfortunate.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


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

Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

[Ben Hutchings]

On Fri, 2022-08-19 at 10:47 +0200, Peter Zijlstra wrote:
> On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote:
> > From: Ben Hutchings 
> > 
> > The mitigation for PBRSB includes adding LFENCE instructions to the
> > RSB filling sequence.  However, RSB filling is done on some older CPUs
> > that don't support the LFENCE instruction.
> > 
> 
> Wait; what? There are chips that enable the RSB mitigations and DONT
> have LFENCE ?!?

Yes, X86_FEATURE_RSB_CTXSW is enabled if any other Spectre v2
mitigation is enabled.  And all Intel family 6 (except some early
Atoms) and AMD family 5+ get Spectre v2 mitigation by default.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


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

Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

[Ben Hutchings]

From: Ben Hutchings 

The mitigation for PBRSB includes adding LFENCE instructions to the
RSB filling sequence.  However, RSB filling is done on some older CPUs
that don't support the LFENCE instruction.

Define and use a BARRIER_NOSPEC macro which makes the LFENCE
conditional on X86_FEATURE_LFENCE_RDTSC, like the barrier_nospec()
macro defined for C code in .

Reported-by: Martin-Éric Racine 
References: https://bugs.debian.org/1017425
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Cc: Daniel Sneddon 
Cc: Pawan Gupta 
Fixes: 2b1299322016 ("x86/speculation: Add RSB VM Exit protections")
Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence")
Signed-off-by: Ben Hutchings 
---
Re-sending this with properly matched From address and server.
Apologies if you got 2 copies.

Ben.

 arch/x86/include/asm/nospec-branch.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/nospec-branch.h 
b/arch/x86/include/asm/nospec-branch.h
index e64fd20778b6..b1029fd88474 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -34,6 +34,11 @@
 
 #define RSB_CLEAR_LOOPS32  /* To forcibly overwrite all 
entries */
 
+#ifdef __ASSEMBLY__
+
+/* Prevent speculative execution past this barrier. */
+#define BARRIER_NOSPEC ALTERNATIVE "", "lfence", X86_FEATURE_LFENCE_RDTSC
+
 /*
  * Google experimented with loop-unrolling and this turned out to be
  * the optimal version - two calls, each with their own speculation
@@ -62,9 +67,7 @@
dec reg;\
jnz 771b;   \
/* barrier for jnz misprediction */ \
-   lfence;
-
-#ifdef __ASSEMBLY__
+   BARRIER_NOSPEC;
 
 /*
  * This should be used immediately before an indirect jump/call. It tells
@@ -138,7 +141,7 @@
int3
 .Lunbalanced_ret_guard_\@:
add $(BITS_PER_LONG/8), %_ASM_SP
-   lfence
+   BARRIER_NOSPEC
 .endm
 
  /*


signature.asc
Description: PGP signature

Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

[Ben Hutchings]

The mitigation for PBRSB includes adding LFENCE instructions to the
RSB filling sequence.  However, RSB filling is done on some older CPUs
that don't support the LFENCE instruction.

Define and use a BARRIER_NOSPEC macro which makes the LFENCE
conditional on X86_FEATURE_LFENCE_RDTSC, like the barrier_nospec()
macro defined for C code in .

Reported-by: Martin-Éric Racine 
References: https://bugs.debian.org/1017425
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Cc: Daniel Sneddon 
Cc: Pawan Gupta 
Fixes: 2b1299322016 ("x86/speculation: Add RSB VM Exit protections")
Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence")
Signed-off-by: Ben Hutchings 
---
 arch/x86/include/asm/nospec-branch.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/nospec-branch.h 
b/arch/x86/include/asm/nospec-branch.h
index e64fd20778b6..b1029fd88474 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -34,6 +34,11 @@
 
 #define RSB_CLEAR_LOOPS32  /* To forcibly overwrite all 
entries */
 
+#ifdef __ASSEMBLY__
+
+/* Prevent speculative execution past this barrier. */
+#define BARRIER_NOSPEC ALTERNATIVE "", "lfence", X86_FEATURE_LFENCE_RDTSC
+
 /*
  * Google experimented with loop-unrolling and this turned out to be
  * the optimal version - two calls, each with their own speculation
@@ -62,9 +67,7 @@
dec reg;\
jnz 771b;   \
/* barrier for jnz misprediction */ \
-   lfence;
-
-#ifdef __ASSEMBLY__
+   BARRIER_NOSPEC;
 
 /*
  * This should be used immediately before an indirect jump/call. It tells
@@ -138,7 +141,7 @@
int3
 .Lunbalanced_ret_guard_\@:
add $(BITS_PER_LONG/8), %_ASM_SP
-   lfence
+   BARRIER_NOSPEC
 .endm
 
  /*


signature.asc
Description: PGP signature

Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]

[Ben Hutchings]

On Thu, 2022-08-18 at 23:11 +0300, Martin-Éric Racine wrote:
> On Thu, Aug 18, 2022 at 10:59 PM Ben Hutchings  wrote:
> > 
> > Control: retitle -1 [i386] Unconditional LFENCE instructions in 
> > FILL_RETURN_BUFFER
> > Control: tag -1 confirmed upstream
> > Control: found -1 5.18.14-1
> > 
> > On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote:
> > > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA
> > > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on
> > > boot.
> > > 
> > > I suspect someone thought it would be a good idea to compile the kernel
> > > for P4 only, as both PIII and Athlon XP processors lack the SSE2
> > > instruction set.
> > > 
> > 
> > That was a good guess, though we don't change the configuration like
> > that in stable updates.
> > 
> > The RETbleed mitigations, which are not needed on these CPUs or even
> > functional on 32-bit kernels, interact with the Spectre v2 mitigations,
> > which *are* used on these CPUs.  And unfortunately the RETbleed
> > mitigations added some unconditional LFENCE instructions, which should
> > be conditional since they are part of SSE2.
> > 
> > As a temporary workaround, disabling the Spectre v2 mitigation with the
> > kernel parameter "nospectre_v2" should allow this kernel version to run
> > on older CPUs without SSE2.  We'll fix this properly in a later update.
> 
> That breakage affects Stable.
> 
> Expecting people to go and use workarounds on what was meant to be a
> stable update isn't acceptable.

Martin, you know we're all volunteers here, so don't take that tone.
I was trying to be helpful in offering an alternative to holding back
the upgrade.

> I really hope that the fix will be pushed within the next 24 hours
> with high urgency.

This is unlikely to happen.

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


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

Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]

[Ben Hutchings]

On Thu, 2022-08-18 at 21:59 +0200, Ben Hutchings wrote:
> Control: retitle -1 [i386] Unconditional LFENCE instructions in 
> FILL_RETURN_BUFFER
> Control: tag -1 confirmed upstream
> Control: found -1 5.18.14-1
> 
> On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote:
> > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA 
> > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on
> > boot.
> > 
> > I suspect someone thought it would be a good idea to compile the kernel
> > for P4 only, as both PIII and Athlon XP processors lack the SSE2
> > instruction set.
> > 
> 
> That was a good guess, though we don't change the configuration like
> that in stable updates.
> 
> The RETbleed mitigations, which are not needed on these CPUs or even

I mean PBRSB, not RETbleed.  There are so many different issues to keep
track of...

Ben.

> functional on 32-bit kernels, interact with the Spectre v2 mitigations,
> which *are* used on these CPUs.  And unfortunately the RETbleed
> mitigations added some unconditional LFENCE instructions, which should
> be conditional since they are part of SSE2.
> 
> As a temporary workaround, disabling the Spectre v2 mitigation with the
> kernel parameter "nospectre_v2" should allow this kernel version to run
> on older CPUs without SSE2.  We'll fix this properly in a later update.
> 
> Ben.
> 

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


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

Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]

[Ben Hutchings]

Control: retitle -1 [i386] Unconditional LFENCE instructions in 
FILL_RETURN_BUFFER
Control: tag -1 confirmed upstream
Control: found -1 5.18.14-1

On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote:
> I can confirm that this bug also occurs on Athlon XP systems (Generic VIA 
> KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on
> boot.
> 
> I suspect someone thought it would be a good idea to compile the kernel
> for P4 only, as both PIII and Athlon XP processors lack the SSE2
> instruction set.
> 

That was a good guess, though we don't change the configuration like
that in stable updates.

The RETbleed mitigations, which are not needed on these CPUs or even
functional on 32-bit kernels, interact with the Spectre v2 mitigations,
which *are* used on these CPUs.  And unfortunately the RETbleed
mitigations added some unconditional LFENCE instructions, which should
be conditional since they are part of SSE2.

As a temporary workaround, disabling the Spectre v2 mitigation with the
kernel parameter "nospectre_v2" should allow this kernel version to run
on older CPUs without SSE2.  We'll fix this properly in a later update.

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


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

Bug#1016718: binfmt_elf: May fail to load executable with no static data next to BSS

[Ben Hutchings]

Source: linux
Version: 5.19-1~exp1
Severity: normal
Tags: upstream

I'm doing some test builds of klibc
 and found a
regression for arm64.  What changed is binutils, and I've reported
bug #1016717 there, but it seems to be triggering an existing bug in
the kernel.

Loading some of klibc's test programs (getoptlong.shared,
malloctest2.shared, setjmptest.shared, sigint.shared) fails, with
execve() returning EFAULT.  This happens past the point of no return,
so the kernel kills the process with SIGSEGV.

The reason for this seems to be that:

1. All of these programs have a BSS section but not a data section.
2. The BSS section is not page-aligned (it now starts at 0xffe8).
3. binfmt_elf assumes that a non-page-aligned BSS section is placed
   immediately after a writable data section in memory, and tries to
   clear memory from the start of the BSS section up to the page
   boundary.
4. In this case, there is no data section and no file mapping before
   the BSS, so this results in an EFAULT.  This happens past the point
   of no return, so the kernel kills the process.

With older versions of binutils, the BSS section was still misaligned
on arm64 but started within the same 4K page as another section.

binfmt_elf should check whether it created a mapping before a non-
aligned BSS section; if not then it should round down the start of the
zero mapping instead of trying to clear part of a mapping that's not
there.

Ben.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1016586: bpftool: Dump of jited version of the BPF program requires libbfd support

[Ben Hutchings]

Control: tag -1 wontfix

On Wed, 2022-08-03 at 18:01 +0200, Emmanuel Fleury wrote:
[...]
> I suppose that the support for BPF must be add to libbfd in the binutils-dev 
> package by default.
> 
> Feel free to ask for more details if I was not clear in my report.

We don't and can't link with libbfd because of licence incompatibility.
Sorry.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.


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

Bug#1014633: linux-headers-5.19.0-rc4-common: file check-local-export does not exist

[Ben Hutchings]

On Sun, 2022-07-31 at 23:02 +0200, Andreas Beckmann wrote:
> Followup-For: Bug #1014633
> 
> What about adding a superficial autopkgtest that tries to compile a
> dummy third-party kernel module using kbuild? That should help noticing
> such breakage earlier.

This is such an obviously good idea that I already did it in version
5.18.14-1. :-)

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


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

Bug#1013035: sgt-puzzles: ftbfs with GCC-12

[Ben Hutchings]

On Fri, 2022-07-29 at 10:04 +0100, Simon Tatham wrote:
> Ben Hutchings  wrote:
> > I should patch out the use of -Werror in this package though.
> 
> FWIW, I've already done this upstream. Since commit 79a5378 I've
> completely reworked the build system (it's now a unified cmake setup
> rather than my own horrible mkfiles.pl cruft feeding into autotools),
> and removed the default -Werror. And a test build with gcc 12 worked
> fine for me just now with the current upstream code.

Thanks for the reminder to update, and I appreciate the move to CMake.
I've now uploaded version 20220613.387d323.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed

[Ben Hutchings]

On Fri, 2022-07-29 at 01:17 +0200, Chris Hofstaedtler wrote:
> * Ben Hutchings :
> [..] 
> > Right.  So this seems like a botched transition - fuse3 should have
> > taken over the fuse binary package but instead each reverse-dependency
> > has to be updated.  I agree it would make sense in the short term to
> > force fuse3 installation.
> [..]
> > Thank you for pointing out the problem.  Even if the exact issue
> > doesn't occur in Debian, we should sort out fuse vs fuse3.
> 
> I would imagine #918984 is related.

Right.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.


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

Bug#1016151: linux-image-686: (EE) open /dev/dri/card0: No such file or directory with Intel 82810E iGPU

[Ben Hutchings]

Control: reassign -1 src:linux
Control: tag -1 upstream wontfix

The i810 driver is not compatible with full preemption.  Since the
introduction of PREEMPT_DYNAMIC, our standard kernel supports full
preemption and the i810 driver is not built.  This is unlikely ever to
be fixed.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.


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

Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed

[Ben Hutchings]

On Wed, 2022-07-27 at 14:25 +0200, Arnaud Rebillout wrote:
> On Thu, 14 Jul 2022 20:14:15 +0200 Ben Hutchings  
> wrote:
>  >
>  > You should find out why that is, before proposing to override it. What
>  > if something in KDE really does need FUSE 2?
> 
> I don't think that it can happen. A package might need FUSE3 (in such 
> case it depends on fuse3), or it might need FUSE (any implementation) 
> (in such case it depends on fuse, and it's either fuse or fuse3 that 
> will be installed, as fuse3 Provides fuse). But it cannot really ask for 
> FUSE2, as far as I understand (there's no fuse2 package).

That makes sense.

> In the case I described above, if fuse gets installed, it's not because 
> a package needs FUSE2, it's because no package needs FUSE3. So apt picks 
> fuse rather than fuse3.
> 

Right.  So this seems like a botched transition - fuse3 should have
taken over the fuse binary package but instead each reverse-dependency
has to be updated.  I agree it would make sense in the short term to
force fuse3 installation.

>  > (Since you found that removing fuse doesn't remove anything else, this
>  > implies that the relationship is only a Recommends and not a Depends.
>  > But that doesn't mean that removal won't break anything.)
> 
> I believe that if replacing fuse by fuse3 doesn't remove anything, it's 
> because fuse3 Provides fuse.
> 
> In any case: in Kali we solved that by recommending fuse3 in 
> kali-desktop-core, a metapackage that is always installed with every 
> Kali desktop. Therefore we're sure to have fuse3 (we don't let apt 
> guess), and we're sure that open-vm-tools will be installed if needed. 
> It's a better solution than modifying hw-detect as I suggested here.
> 
> Therefore I'll close this bug, as I don't think it affects Debian anyway.
> 
> Thanks for your feedback, and sorry for the noise.

Thank you for pointing out the problem.  Even if the exact issue
doesn't occur in Debian, we should sort out fuse vs fuse3.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.


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

Bug#1015240: Acknowledgement (linux: rejecting DMA map of vmalloc memory)

[Ben Hutchings]

Control: fixed -1 5.19~rc6-1~exp1
Control: tag -1 pending

On Tue, 2022-07-19 at 18:45 +0200, Kurt Roeckx wrote:
> On Tue, Jul 19, 2022 at 06:11:23PM +0200, Diederik de Haas wrote:
> > According to that bug report it should be fixed with 5.19-rc6 and that 
> > version 
> > is available in experimental. Can you verify whether it also fixes your 
> > issue?
> 
> With that version the error goes away.

The fix is also in 5.18.11 and will be included in the next unstable
upload.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#1014851: x86: Document new hardening options

[Ben Hutchings]

Here's a patch for the documentation.  This is a combination of the
omitted parts of the 3 upstream commits that touched it.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.
From: Ben Hutchings 
Date: Mon, 18 Jul 2022 15:50:38 +0200
Subject: x86: Document new hardening options
Origin: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=39d944c4237e5d35e28a2668d3b9a2e0f6f7bd01
Origin: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d928740a533cd9e78673fad7ea86d20b2142277
Origin: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=58a4e292e8507a2968bfd2b10631ba95d5440c97

Changes to the docs from "x86: Add
-mharden-sls=[none|all|return|indirect-branch]", "x86: Add
-mindirect-branch-cs-prefix", and "x86: Rename
-harden-sls=indirect-branch to -harden-sls=indirect-jmp".
---
diff -u a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1409,7 +1409,8 @@
 -mstack-protector-guard-symbol=@var{symbol} @gol
 -mgeneral-regs-only  -mcall-ms2sysv-xlogues @gol
 -mindirect-branch=@var{choice}  -mfunction-return=@var{choice} @gol
--mindirect-branch-register -mneeded}
+-mindirect-branch-register -mharden-sls=@var{choice} @gol
+-mindirect-branch-cs-prefix -mneeded}
 
 @emph{x86 Windows Options}
 @gccoptlist{-mconsole  -mcygwin  -mno-cygwin  -mdll @gol
@@ -31724,6 +31725,21 @@
 @opindex mindirect-branch-register
 Force indirect call and jump via register.
 
+@item -mharden-sls=@var{choice}
+@opindex mharden-sls
+Generate code to mitigate against straight line speculation (SLS) with
+@var{choice}.  The default is @samp{none} which disables all SLS
+hardening.  @samp{return} enables SLS hardening for function returns.
+@samp{indirect-jmp} enables SLS hardening for indirect jumps.
+@samp{all} enables all SLS hardening.
+
+@item -mindirect-branch-cs-prefix
+@opindex mindirect-branch-cs-prefix
+Add CS prefix to call and jmp to indirect thunk with branch target in
+r8-r15 registers so that the call and jmp instruction length is 6 bytes
+to allow them to be replaced with @samp{lfence; call *%r8-r15} or
+@samp{lfence; jmp *%r8-r15} at run-time.
+
 @end table
 
 These @samp{-m} switches are supported in addition to the above


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

Bug#882640: ITP: dm-zoned-tools -- utilities for the dm-zoned device mapper

[Ben Hutchings]

Control: retitle -1 RFP: dm-zoned-tools -- utilities for the dm-zoned device 
mapper
Control: noowner -1

I'm moving this back to RFP status, because this package didn't get
sponsored and seems to have disappeared now.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


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

Bug#976015: debian-kernel-handbook: Document how to produce a custom kernel for UEFI Secure Boot

[Ben Hutchings]

On Sat, 28 Nov 2020 11:25:23 +0100 Mattia Monga 
wrote:
> Package: debian-kernel-handbook
> Version: 1.0.19
> Severity: wishlist
> X-Debbugs-Cc: mo...@debian.org
> 
> The procedure needed to produce a signed custom kernel suitable for UEFI 
> Secure
> Boot is not documented (although the Debian kernel packages are correctly
> signed). Even https://wiki.debian.org/SecureBoot explains how to add a Machine
> Owner Key to the system, but not how produce a signed kernel.
[...]

It should go something like:

1. Generate a certificate and private key
2. Add the certificate to MOK (or db)
3. (Optional) Enable CONFIG_SECURITY_LOCKDOWN_LSM in the kernel config
4. Build the kernel and modules (but not a package)
5. Use sbsigntool to sign the kernel
6. Build the package (make bindeb-pkg)

I don't feel like spending the time to test and write precise
instructions for this, but if someone else does I'd be happy to review
and add them.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

Bug#958559: debian-kernel-handbook: document how to verify authenticity of git sources

[Ben Hutchings]

Control: tag -1 pending

On Sat, 2020-04-25 at 23:01 +0100, Ben Hutchings wrote:
> On Thu, 2020-04-23 at 19:30 +0200, Christoph Anton Mitterer wrote:
> [...]
> > It would be nice if the handbook tells people how to verify their
> > repos by proper git means, i.e. verify signautres on tags.
> 
> Yes, definitely.

I've finally got back to looking at the wording here.

The one place we refer to
<https://salsa.debian.org/kernel-team/linux.git> is in the section
"Building a development version of the Debian kernel package".  This is
about building unreleased changes, which of course are not tagged.  I
don't think we can reasonably give instructions for verifying them.

For ,
I have changed the URL to use "https:" and changed the instructions to
include tag verification with the aid of the Debian source package. 
It's annoyingly complex but should work:
https://kernel-team.pages.debian.net/kernel-handbook/ch-bugs.html#s9.2.1

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed

[Ben Hutchings]

On Thu, 2022-07-14 at 16:56 +0200, Arnaud Rebillout wrote:
> Source: hw-detect
> Version: 1.147
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
> 
> Dear Maintainer,
> 
> The package open-vm-tools 11.3.5, released in January 2022, depends on
> fuse3 rather than fuse [1].
> 
> As a consequence, hw-detect fails to install open-vm-tools if ever the
> package fuse was already installed. This is because installing fuse3
> would cause the removal of fuse, and removals are not allowed.
> 
> This can be seen in the logs of the installer:
> 
> in-target: The following additional packages will be installed:
> in-target:   ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
> in-target:   libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
> in-target:   libsigc++-2.0-0v5 open-vm-tools zerofree
> in-target: Suggested packages:
> in-target:   cloud-init
> in-target: The following packages will be REMOVED:
> in-target:   fuse
> in-target: The following NEW packages will be installed:
> in-target:   ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
> in-target:   libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
> in-target:   libsigc++-2.0-0v5 open-vm-tools open-vm-tools-desktop zerofree
> in-target: 0 upgraded, 13 newly installed, 1 to remove and 0 not upgraded.
> in-target: E: Packages need to be removed but remove is disabled.
> 
> In practice, it hits Kali Linux users, as reported in [2]. For some
> reasons, fuse gets installed if users install the KDE desktop for Kali.
[...]

You should find out why that is, before proposing to override it.  What
if something in KDE really does need FUSE 2?

(Since you found that removing fuse doesn't remove anything else, this
implies that the relationship is only a Recommends and not a Depends. 
But that doesn't mean that removal won't break anything.)

If we find that it's not really needed, then a better fix may be to
remove the recommendation(s) or change them to "fuse3 | fuse".

Ben.


-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


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

Bug#1014898: ITP: gcompat -- The GNU C library compatibility layer for musl

[Ben Hutchings]

On Thu, 2022-07-14 at 14:15 +0900, Nobuhiro Iwamatsu wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nobuhiro Iwamatsu 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: gcompat
>   Version : 1.0.0
>   Upstream Author : A. Wilcox
> * URL : https://git.adelielinux.org/adelie/gcompat
> * License : Expat
>   Programming Lang: C
>   Description : The GNU C library compatibility layer for musl
> 
>   The gcompat provides glibc-compatible APIs for use on musl libc systems.
>   .
>   This library is designed to be used for binaries that are already
>   compiled against glibc. It does not contain any headers, and cannot be
>   used to build software that requires glibc. It is instead recommended
>   that any software that requires glibc APIs be modified to become more
>   portable.
>   .
>   This library can optionally be compiled with other libraries to make a
>   single, unfied solution. This can include fts, libucontext, obstack,
>   and others.
>   .
>   gcompat additionally provides a loader stub. This is a small library
>   that has the same name as the glibc dynamic linker on glibc platforms;
>   when a binary is run that uses glibc as its dynamic linker, the stub
>   will run, redirecting it to use musl and automatically preloading the
>   gcompat library.
> 

How would this be used in Debian, when all our ports already use glibc?

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


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

Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

[Ben Hutchings]

On Thu, 2022-07-14 at 10:20 +0100, Edward Betts wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Edward Betts 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
> 
> * Package name: gender-guesser
>   Version : 0.4.0
>   Upstream Author : Israel Saeta Pérez 
> * URL : https://github.com/lead-ratings/gender-guesser
> * License : GPL-3 & GFDL-1.2+
>   Programming Lang: Python
>   Description : Guess the gender from first name
[...]

This is a horribly bad idea, what do you need it for?

Ben.


-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


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

Bug#1014851: Missing SLS mitigation (-mharden-sls) for x86

[Ben Hutchings]

Package: gcc-10
Version: 10.2.1-6
Severity: normal
Tags: patch bullseye
X-Debbugs-Cc: debian-ker...@lists.debian.org

In an upcoming kernel update I would like to add mitigation of
Straight Line Speculation (SLS) for amd64.  This depends partly on
compiler support, enabled with the -mharden-sls option, which is
currently only available in gcc 11 and 12.

Attached is a debdiff that adds this to gcc-10.  I have:

- Rebuilt the package, with no test regressions
- Built a working kernel package with SLS (and return thunks) enabled

The debdiff is against the bullseye version.  I haven't tested the
latest version since we are using gcc-11 in testing/unstable.

I still have to check whether the kernel really still needs this
option in the compiler, since it also builds with retpolines and
rethunks and can replace those jumps with SLS mitigation instead where
appropriate.

Ben.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-10 depends on:
ii  binutils   2.38.50.20220629-2
ii  cpp-10 10.4.0-1
ii  gcc-10-base10.4.0-1
ii  libc6  2.33-7
ii  libcc1-0   12.1.0-5
ii  libgcc-10-dev  10.4.0-1
ii  libgcc-s1  12.1.0-5
ii  libgmp10   2:6.2.1+dfsg1-1
ii  libisl23   0.24-2
ii  libmpc31.2.1-2
ii  libmpfr6   4.1.0-3
ii  libstdc++6 12.1.0-5
ii  libzstd1   1.5.2+dfsg-1
ii  zlib1g 1:1.2.11.dfsg-4

Versions of packages gcc-10 recommends:
ii  libc6-dev  2.33-7

Versions of packages gcc-10 suggests:
ii  gcc-10-doc   10.3.0-2
pn  gcc-10-locales   
ii  gcc-10-multilib  10.4.0-1

-- debconf-show failed
diff -Nru gcc-10-10.2.1/debian/changelog gcc-10-10.2.1/debian/changelog
--- gcc-10-10.2.1/debian/changelog  2021-01-10 12:35:39.0 +0100
+++ gcc-10-10.2.1/debian/changelog  2022-07-11 15:02:37.0 +0200
@@ -1,3 +1,9 @@
+gcc-10 (10.2.1-6.1) UNRELEASED; urgency=medium
+
+  * Backport support for -mharden-sls for x86
+
+ -- Ben Hutchings   Mon, 11 Jul 2022 15:02:37 +0200
+
 gcc-10 (10.2.1-6) unstable; urgency=medium
 
   * Update to git 20210110 from the gcc-10 branch.
diff -Nru 
gcc-10-10.2.1/debian/patches/x86-add-mharden-sls-none-all-return-indirect-branch.diff
 
gcc-10-10.2.1/debian/patches/x86-add-mharden-sls-none-all-return-indirect-branch.diff
--- 
gcc-10-10.2.1/debian/patches/x86-add-mharden-sls-none-all-return-indirect-branch.diff
   1970-01-01 01:00:00.0 +0100
+++ 
gcc-10-10.2.1/debian/patches/x86-add-mharden-sls-none-all-return-indirect-branch.diff
   2022-07-11 15:02:37.0 +0200
@@ -0,0 +1,247 @@
+From: "H.J. Lu" 
+Date: Wed, 27 Oct 2021 07:48:54 -0700
+Subject: [PATCH] x86: Add -mharden-sls=[none|all|return|indirect-branch]
+Origin: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=39d944c4237e5d35e28a2668d3b9a2e0f6f7bd01
+
+Add -mharden-sls= to mitigate against straight line speculation (SLS)
+for function return and indirect branch by adding an INT3 instruction
+after function return and indirect branch.
+
+gcc/
+
+   PR target/102952
+   * config/i386/i386-opts.h (harden_sls): New enum.
+   * config/i386/i386.c (output_indirect_thunk): Mitigate against
+   SLS for function return.
+   (ix86_output_function_return): Likewise.
+   (ix86_output_jmp_thunk_or_indirect): Mitigate against indirect
+   branch.
+   (ix86_output_indirect_jmp): Likewise.
+   (ix86_output_call_insn): Likewise.
+   * config/i386/i386.opt: Add -mharden-sls=.
+   * doc/invoke.texi: Document -mharden-sls=.
+
+gcc/testsuite/
+
+   PR target/102952
+   * gcc.target/i386/harden-sls-1.c: New test.
+   * gcc.target/i386/harden-sls-2.c: Likewise.
+   * gcc.target/i386/harden-sls-3.c: Likewise.
+   * gcc.target/i386/harden-sls-4.c: Likewise.
+   * gcc.target/i386/harden-sls-5.c: Likewise.
+
+(cherry picked from commit 53a643f8568067d7700a9f2facc8ba39974973d3)
+[benh:
+ - Drop changes in gcc/doc/invoke.texi, which is not included in the
+   Debian package
+ - Use NULL instead of nullptr]
+---
+ gcc/config/i386/i386-opts.h  |  7 +++
+ gcc/config/i386/i386.c   | 21 +---
+ gcc/config/i386/i386.opt | 20 +++
+ gcc/doc/invoke.texi  | 10 +-
+ gcc/testsuite/gcc.target/i386/harden-sls-1.c | 14 +
+ gcc/testsuite/gcc.target/i386/harden-sls-2.c | 14 +
+ gcc/testsuite/gcc.target/i386/harden-sls-3.c | 14 +
+ gcc/testsuite/gcc.target/i386/harden-sl

Bug#948712: [Pkg-raspi-maintainers] Bug#948712: Pinebook Pro also uses this chip

[Ben Hutchings]

On Tue, 2022-07-12 at 20:18 +0200, Adam Borowski wrote:
> On Tue, Jul 12, 2022 at 12:45:11PM +0200, Diederik de Haas wrote:
> > On dinsdag 12 juli 2022 01:47:21 CEST Adam Borowski wrote:
> > > Pinebook Pro also wants this firmware, and it's definitely not a raspi,
> > > and it doesn't have /boot/firmware either.
> > 
> > Is this about the /lib/firmware/brcm/brcmfmac434* files?
> > 
> > IMO, that group of files shouldn't be part of this package, but be moved to 
> > another firmware package, perhaps firmware-brcm80211?
> 
> Yeah, that.
> 
> The idea of moving these files to another package seems good; steev proposed
> firmware-linux, firmware-brcm80211 would be a more specific fit.
> Both packages are maintained by debian-kernel@l.d.o, could you folks
> comment please?

So long as those files are in linux-firmware.git, it should be fine to
ship them in firmware-brcm80211.  If they aren't, they should be added
there first.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


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

Bug#1012707: /etc/network/interfaces: only source configuration files using with '*.conf' / use 'source /etc/network/interfaces.d/*.conf' instead of 'source /etc/network/interfaces.d/*'

[Ben Hutchings]

On Tue, 2022-06-14 at 22:52 +0200, Santiago Ruano Rincón wrote:
> El 12/06/22 a las 14:13, Patrick Schleizer escribió:
> > Package: ifupdown
> > Severity: normal
> > 
> > Dear maintainer,
> > 
> > in file /etc/network/interfaces ...
> > 
> > Could you please consider instead of setting the default:
> > 
> > source /etc/network/interfaces.d/*
> > 
> > change suggestion:
> > 
> > source /etc/network/interfaces.d/*.conf
> > 
> > Reason:
> > 
> > When
> > 
> > - text editor (such as kate) create backup files (such as
> > /etc/network/interfaces.d/50_user~ with the tilde at the end)
> > 
> > - local packages by system administrator or Debian derivatives place
> > configuration drop-in snippets in /etc/network/interfaces.d/ folder,
> > 
> > then on upgrades then redundant files might end up in that folder such
> > as those with file extensions '.dpkg-old' or '.dpkg-dist'.
> > 
> > When ifupdown is restarted, an interface is likely to be duplicated
> > leading to ifupdown failure, resulting in a broken network connection.

Is this not what the "source-directory" directive exists for?

It is a bit puzzling that this was added and then not used...

> > 
> > By parsing only configuration files such as with the `*.conf` file
> > extension issues with parsing unexpected files created by editors
> > (backup files) or dpkg are avoided.
> 
> Thanks for your report. I think it makes sens. But for the moment, I am
> pushing it to a separate branch. If I am not wrong, the debian-installer
> installs some files in /etc/network/interfaces.d/, so there must be some
> coordination to avoid issues in future installs.
> 
> Debian Installer Team: it is OK from your side to make the change
> described above?

I grepped the source repositories of d-i packages and found 2 uses of
interfaces.d:

- netboot-assistant has an example command that creates
"/etc/network/interfaces.d/static":
https://salsa.debian.org/installer-team/netboot-assistant/-/blob/master/README.installbox#L62

- netcfg creates /etc/network/interfaces itself, with the wildcard
that's being reported as a bug:
https://salsa.debian.org/installer-team/netcfg/-/blob/master/write_interface.c#L29

So netcfg would probably also have to be changed, whether you decide to
go with *.conf or source-directory.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


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

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Mon, 2022-07-04 at 14:04 +0200, Ansgar wrote:
> On Sun, 19 Jun 2022 12:59:55 +0200 Ben Hutchings wrote:
> > > I'm now looking at whether the missing bytes are recoverable (e.g. are
> > > they always zeroes).
> > [...]
> > 
> > I wrote a script to try all possible byte values for 2 bytes before or
> > after the short signature.  For this particular file, none of them
> > producd a valid signature.  So the short signatures seem to be
> > corrupted in a more complex way.
> 
> The "OCTET STRING" containing the actual signature is shorter for the
> seemingly corrupted signatures:
[...]

Yes I know, and my script uses a library to manipulate the ASN.1
structure when adding bytes.  I'm attaching the script, so you can
check the logic.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.
#!/usr/bin/python3

# Fix broken detached signatures

import os.path
import sys

import asn1crypto.algos
import asn1crypto.cms
import asn1crypto.core

from M2Crypto import BIO, SMIME, X509


# Signature algorithm should be RSA
SIG_ALGO_OID = asn1crypto.core.ObjectIdentifier('1.2.840.113549.1.1.1')


# Signature length should match key length (2048 bits)
SIG_LEN = 2048 // 8


def make_smime_context(cert):
# We don't verify against a CA, just one specific certificate
smime = SMIME.SMIME()
signer_key = X509.X509_Stack()
signer_key.push(X509.load_cert(cert))
smime.set_x509_stack(signer_key)
smime.set_x509_store(X509.X509_Store())
return smime


def verify_payload(smime, sig, data):
smime.verify(
SMIME.load_pkcs7_bio_der(BIO.MemoryBuffer(sig.dump(force=True))),
BIO.MemoryBuffer(data),
flags=(SMIME.PKCS7_BINARY | SMIME.PKCS7_DETACHED
   | SMIME.PKCS7_NOVERIFY))


def brute_force_sig_2bytes(smime, sig, sig_os, data):
orig_raw_sig = bytes(sig_os)
for byte1 in range(256):
for byte2 in range(256):
sig_os.set(bytes((byte1, byte2)) + orig_raw_sig)
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'prepended {byte1}, {byte2} to start of sig')
return True

sig_os.set(bytes((byte1,)) + orig_raw_sig + bytes((byte2,)))
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'added {byte1}, {byte2} at start and end of sig resp.')
return True

sig_os.set(orig_raw_sig + bytes((byte1, byte2)))
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'appended {byte1}, {byte2} to end of sig')
return True

return False


def fix_detached_sig(smime, sig, bin_name):
# The ContentInfo should be a SEQUENCE with signed data at index 1
if len(sig) < 2 or not isinstance(sig[1], asn1crypto.cms.SignedData):
return 'no signed data found', False
sd = sig[1]

# The SignedData should be a SEQUENCE with signer infos at index 5
if len(sd) < 6 or not isinstance(sd[5], asn1crypto.cms.SignerInfos):
return 'no signer infos found', False
infos = sd[5]

# The SignerInfos should be a SET with 1 item
if len(infos) != 1:
return f'found { len(infos) } signer infos; expected 1', False
info = infos[0]

# The SignerInfo should be a SEQUENCE with the signature algorithm
# at index 4 and signature at index 5
if (len(info) < 6
or not isinstance(info[4], asn1crypto.algos.SignedDigestAlgorithm)
or len(info[4]) < 1
or not isinstance(info[5], asn1crypto.core.OctetString)):
return 'expected fields not found in signer info', False

# Check the signature algorithm and length (see bug #1012741)
if info[4][0] != SIG_ALGO_OID:
return f'unexpected signature algorithm { info[4][0].dotted }', False
actual_sig_len = len(bytes(info[5]))

with open(bin_name, 'rb') as f:
data = f.read()

if (actual_sig_len == SIG_LEN - 2
and brute_force_sig_2bytes(smime, sig, info[5], bin_name)):
return (f'signature length is { actual_sig_len } bytes;'
f' expected { SIG_LEN }; filled in missing 2 bytes',
True)

if actual_sig_len != SIG_LEN:
return (f'signature length is { actual_sig_len } bytes;'
f' expected { SIG_LEN }',
False)

verify_payload(smime, sig, data)
return None, False


def load_detached_sig(name):
with open(name, 'rb') as f:
return asn1crypto.cms.ContentInfo.load(f.read())


def save_detached_sig(sig, name):
with open(name, 'wb') as f:
f.write(sig.dump())


def main(sig_dir, bin_dir, cert):
err_count = 0

s

Bug#1014182: closed by Debian FTP Masters (reply to Ben Finney ) (Bug#1014182: fixed in dput 1.1.2)

[Ben Hutchings]

Control: reopen -1
Control: found -1 1.1.2

[...]

>  dput (1.1.2) unstable; urgency=medium
>  .
>* Default to "$HOME/.config" if variable XDG_CONFIG_HOME is not set.
>  Closes: bug#1014181, bug#1014182.
[...]

This is not the same problem as #1014181, that's why it's a separate
bug report.

Run reportbug yourself and you should see that it fails.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
 - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


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

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Sun, 2022-06-26 at 10:30 -0500, Daniel Lewart wrote:
> Ben, et al,
> 
> On Mon, 13 Jun 2022 18:23:18 +0200 Ben Hutchings  wrote:
> 
> > Since the truncated signatures are in the source packages, this is a
> > problem introduced by the code signing service and will need to be
> > fixed there.
> 
> Assuming that the code-signing service uses the kernel's scripts/sign-file
> and calls PKCS7_sign() ...
> 
> Which version of OpenSSL/libssl is used?

I don't know that; you would have to ask the FTP team.

> Are kernel build logs available for download or viewing?

All package build logs are available from <https://buildd.debian.org>,
but the code signing step is separate.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Bug#1013868: nfs-common: Split between Python scripts to separate package

[Ben Hutchings]

Control: severity -1 wishlist

On Sun, 2022-06-26 at 09:47 +0200, Gioele Barabucci wrote:
> Package: nfs-common
> Version: 1:2.6.1-2
> 
> Dear maintainers of nfs-common,
> 
> could you please move the three Python scripts included in nfs-common to 
> a separate -extras package?

No, the postinst may run nfsconvert.py.

> Currently nfs-common Depends on `python3` and, on lean/containerized 
> client systems, it is the only package that requires it. For this 
> reason, in 2019 Fedora moved the scripts `mountstats`, `nfsiostat` and 
> `nfsconvert` to a separate package [1,2], required on servers (for 
> `nfsconver`) but not on clients.

nfsconvert.py is also required on clients.

We can remove nfsconvert.py and revisit this after the bookworm
release.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Bug#1014181: bash-completions and bug script assume $XDG_CONFIG_DIR is set

[Ben Hutchings]

On Fri, 2022-07-01 at 18:10 +0200, Ben Hutchings wrote:
> Package: dput
> Version: 1.1.1
> Severity: normal
> 
> The bash-completion script looks for $XDG_CONFIG_DIR/dput/dput.cf but
> should use ${XDG_CONFIG_DIR:-$HOME/.config}/dput/dput.cf.

s/XDG_CONFIG_DIR/XDG_CONFIG_HOME/g

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Bug#1014182: bug script fails

[Ben Hutchings]

Package: dput
Version: 1.1.1
Severity: important

The last command in the bug script is "dput --print", which no longer
works and exits with return code 64.  This becomes the exit code of
the bug script itself, causing reportbug to suggest cancelling the bug
report:

Gathering additional data, this may take a while...
cat: /dput/dput.cf: No such file or directory
cat: /home/ben/.dput.cf: No such file or directory

-- Configuration parsed by ‘dput’ --
The package bug script /usr/share/bug/dput/script exited with an error 
status (return code = 16384). Do you still want to file a report [y|N|q|?]?

Ben.

-- Package-specific info:

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = ftp
hash= md5
allow_unsigned_uploads  = 0
allow_dcut  = 0
run_lintian = 0
run_dinstall= 0
check_version   = 0
scp_compress= 0
post_upload_command =
pre_upload_command  =
passive_ftp = 1
default_host_main   =
allowed_distributions   = (?!UNRELEASED)

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn= ftp.eu.upload.debian.org
method  = ftp
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login   = *
# login = another_username
fqdn= ssh.upload.debian.org
method  = scp
incoming= /srv/upload.debian.org/UploadQueue/
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command   = /path/to/some/script
# pre_upload_command= /path/to/some/script

[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn= upload.ubuntu.com
method  = ftp
incoming= /
login   = anonymous

[ppa]
fqdn= ppa.launchpad.net
method  = ftp
# replace  with your Launchpad ID
incoming= ~/ubuntu
login   = anonymous

[mentors]
method  = ftp
fqdn= mentors.debian.net
incoming= /pub/UploadQueue
login   = anonymous

[local]
method  = local
incoming= ~/public_html/debian/mini-dinstall/incoming
run_dinstall= 0
post_upload_command = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

-- /dput/dput.cf --

-- /home/ben/.dput.cf --
No package or host has been provided, see dput -h

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of 

Bug#1014181: bash-completions and bug script assume $XDG_CONFIG_DIR is set

[Ben Hutchings]

Package: dput
Version: 1.1.1
Severity: normal

The bash-completion script looks for $XDG_CONFIG_DIR/dput/dput.cf but
should use ${XDG_CONFIG_DIR:-$HOME/.config}/dput/dput.cf.

While making this report, I found that the bug script has the same
bug.

Ben.

-- Package-specific info:

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = ftp
hash= md5
allow_unsigned_uploads  = 0
allow_dcut  = 0
run_lintian = 0
run_dinstall= 0
check_version   = 0
scp_compress= 0
post_upload_command =
pre_upload_command  =
passive_ftp = 1
default_host_main   =
allowed_distributions   = (?!UNRELEASED)

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn= ftp.eu.upload.debian.org
method  = ftp
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login   = *
# login = another_username
fqdn= ssh.upload.debian.org
method  = scp
incoming= /srv/upload.debian.org/UploadQueue/
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command   = /path/to/some/script
# pre_upload_command= /path/to/some/script

[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn= upload.ubuntu.com
method  = ftp
incoming= /
login   = anonymous

[ppa]
fqdn= ppa.launchpad.net
method  = ftp
# replace  with your Launchpad ID
incoming= ~/ubuntu
login   = anonymous

[mentors]
method  = ftp
fqdn= mentors.debian.net
incoming= /pub/UploadQueue
login   = anonymous

[local]
method  = local
incoming= ~/public_html/debian/mini-dinstall/incoming
run_dinstall= 0
post_upload_command = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

-- /dput/dput.cf --

-- /home/ben/.dput.cf --
No package or host has been provided, see dput -h

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dput depends on:
ii  python33.10.4-1+b1
ii  python3-debian 0.1.44
ii  python3-gpg1.17.1-4
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-xdg0.27-2

dput recommends no packages.

Versions of packages dput suggests:
ii  lintian 2.115.2
pn  mini-dinstall   
ii  openssh-client  1:9.0p1-1+b1
ii  rsync