Page 2 of 6
Re: New Kernel
Posted: Wed Apr 10, 2024 5:16 pm
by Grogan
Linux 6.8.5
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.8.5
This one revolves around another CPU mitigation, BHI (Branch History Injection). Another one to make sure to disable
x86/bhi: Add support for clearing branch history at syscall entry
commit 7390db8aea0d64e9deb28b8e1ce716f5020c7ee5 upstream.
Branch History Injection (BHI) attacks may allow a malicious application to
influence indirect branch prediction in kernel by poisoning the branch
history. eIBRS isolates indirect branch targets in ring0. The BHB can
still influence the choice of indirect branch predictor entry, and although
branch predictor entries are isolated between modes when eIBRS is enabled,
the BHB itself is not isolated between modes.
Alder Lake and new processors supports a hardware control BHI_DIS_S to
mitigate BHI. For older processors Intel has released a software sequence
to clear the branch history on parts that don't support BHI_DIS_S. Add
support to execute the software sequence at syscall entry and VMexit to
overwrite the branch history.
For now, branch history is not cleared at interrupt entry, as malicious
applications are not believed to have sufficient control over the
registers, since previous register state is cleared at interrupt
entry. Researchers continue to poke at this area and it may become
necessary to clear at interrupt entry as well in the future.
This mitigation is only defined here. It is enabled later.
There's lots more, but BHI seems to be the main attraction here.
Re: New Kernel
Posted: Wed Apr 10, 2024 10:54 pm
by Grogan
Bloody Hell... know what just occurred to me? With both kernels going to the same EFI "/boot" directory now, and me mounting it in Arch anyway, I don't need to build two separate kernels at all anymore, or even keep two trees. The only difference now between the two configs on the new rig was that I had cgroup support completely disabled on my LFS kernels. On Arch, I have to fake it by just enabling cgroup support itself (so systemd can mount /sys/fs/cgroup or it refuses to init anything) and not the drivers. On my LFS, there's nothing in the boot scripts that would even try to initialize that (I'd have to config it to) so it only matters for a bit of unused overhead in the kernel image so it can stay enabled.
Same kernel image in the EFI partition
Code: Select all
cp arch/x86/boot/bzImage /boot/vmlinuz-6.8.5
The only thing I have to do is run make modules_install twice as both OSes are going to need their own modules dir on their filesystems. Once for Arch and once for Bollux. Obviously I have to mount the other fs too (/mnt/lfs). That just takes a sec, and is easier than manually copying them.
Code: Select all
make modules_install
make INSTALL_MOD_PATH=/mnt/lfs modules_install
That will run depmod in each case for you too. The symlinks in the modules dir will point to the correct source dir in both cases too (only matters for building out of tree modules etc. which I don't do at all now anyway)
So now, there's no more need to have separate kernel build directories, the configs are the same, I only have to build once... never mind messing with EXTRAVERSION.
I just edit both grub stanzas at once now, too
Code: Select all
menuentry 'Arch Linux' {
insmod gzio
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root 69A1-4857
linux /vmlinuz-6.8.5 root=/dev/nvme1n1p2 ro mitigations=off split_lock_detect=off loglevel=3 quiet
}
menuentry 'Bollux' {
insmod gzio
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root 69A1-4857
linux /vmlinuz-6.8.5 root=/dev/nvme1n1p4 ro mitigations=off split_lock_detect=off ipv6.disable=1
}
I use different command line parameters for the two, but that matters nought.
The LFS system won't need to mount the EFI partition at all (I wasn't planning on adding it to fstab there, just manually mount and install kernel etc. but this is even better)
Re: New Kernel
Posted: Thu Apr 11, 2024 7:20 am
by Zema Bus
I hadn't thought of that, guess that's one of the upsides to UEFI

Re: New Kernel
Posted: Sat Apr 13, 2024 6:45 pm
by Grogan
Linux 6.8.6
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.8.6
Oops, I noticed a bit too late to do it now (have to leave) but we've got a new kernel. There's some stuff in there (e.g. amdgpu) that should be had.
Re: New Kernel
Posted: Sat Apr 13, 2024 10:18 pm
by Zema Bus
I'm on it

Re: New Kernel
Posted: Sun Apr 14, 2024 2:25 am
by Grogan
I got mine done, all 1:26 of it, for both OSes

Re: New Kernel
Posted: Wed Apr 17, 2024 3:09 pm
by Grogan
Linux 6.8.7
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.8.7
There are only 7 shit tonnes of fixes for drm/amdgpu/display
Re: New Kernel
Posted: Sun Apr 28, 2024 1:36 am
by Zema Bus
6.8.8

Re: New Kernel
Posted: Sun Apr 28, 2024 3:40 am
by Grogan
Yeah, great, now. Now that I don't need to do a rebuild for anything and have other shit to do. Arch has just gone and upgraded to Python 3.12 which is going to break all the relationships (/usr/lib/python3.11 is disconnected. I have to redo gcc, LLVM, anything with python modules. Nice thing to have to deal with on a Saturday night.
Re: New Kernel
Posted: Thu May 02, 2024 9:52 pm
by Grogan
It's Linux 6.8.9 time
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.8.9
Bluetooth fixes
network PHI fixes
dmaengine fixes
graphics fixes
etc.
I was going to skip it until I got to:
drm/amdgpu: Fix leak when GPU memory allocation fails
Re: New Kernel
Posted: Fri May 03, 2024 8:05 am
by Zema Bus
I'll do it this weekend, it'll take my mind off of things for a few mins

Re: New Kernel
Posted: Sun May 12, 2024 10:56 pm
by Grogan
Linux 6.9 is out now, though not on the main kernel.org site yet
I want to get this done before supper, so I grabbed the tarball snapshot from here:
https://git.kernel.org/pub/scm/linux/ke ... linux.git/
Re: New Kernel
Posted: Sun May 12, 2024 11:06 pm
by Grogan
Look at this new option... this bugs me, because whenever you get some security option like that, some asshole distributor is going to enable it in their kernels and make people jump through hoops to use their USB devices.
Code: Select all
CONFIG_USB_DEFAULT_AUTHORIZATION_MODE:
Select the default USB device authorization mode. Can be overridden
with usbcore.authorized_default command line or module parameter.
This option allows you to choose whether USB devices that are
connected to the system can be used by default, or if they are
locked down.
With value 0 all connected USB devices with the exception of root
hub require user space authorization before they can be used.
With value 1 (default) no user space authorization is required to
use connected USB devices.
With value 2 all connected USB devices with exception of internal
USB devices require user space authorization before they can be
used. Note that in this mode the differentiation between internal
and external USB devices relies on ACPI, and on systems without
ACPI selecting value 2 is analogous to selecting value 0.
If unsure, keep the default value.
It's a good thing I configure my own kernels.
Re: New Kernel
Posted: Mon May 13, 2024 7:17 am
by Zema Bus
I see it's up on the main page now.
Re: New Kernel
Posted: Fri May 17, 2024 11:28 pm
by Grogan
Short changelog for Linux 6.9.1
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.9.1
wifi: mt76: mt7915: add missing chanctx ops
keys: Fix overwrite of key expiration on instantiation
The expiry time of a key is unconditionally overwritten during
instantiation, defaulting to turn it permanent. This causes a problem
for DNS resolution as the expiration set by user-space is overwritten to
TIME64_MAX, disabling further DNS updates. Fix this by restoring the
condition that key_set_expiry is only called when the pre-parser sets a
specific expiry.
However, the rest of it has to do with blacklisting some dmaengine devices on certain SoC's
dmaengine: idxd: add a new security check to deal with a hardware erratum
On Sapphire Rapids and related platforms, the DSA and IAA devices have an
erratum that causes direct access (for example, by using the ENQCMD or
MOVDIR64 instructions) from untrusted applications to be a security problem.
VFIO: Add the SPR_DSA and SPR_IAX devices to the denylist
commit 95feb3160eef0caa6018e175a5560b816aee8e79 upstream.
Due to an erratum with the SPR_DSA and SPR_IAX devices, it is not secure to assign
these devices to virtual machines. Add the PCI IDs of these devices to the VFIO
denylist to ensure that this is handled appropriately by the VFIO subsystem.
The SPR_DSA and SPR_IAX devices are on-SOC devices for the Sapphire Rapids
(and related) family of products that perform data movement and compression.
I don't think there's anything in there that would affect us (maybe the key expiration issue, but probably not and we're not running DNS servers as in the specific example) but since it only takes me 1:29 and I'm just waiting for that musical sounding "Michael!" when it's dinner time anyway

Re: New Kernel
Posted: Sat May 18, 2024 7:09 am
by Zema Bus
lol! I miss those days when my mom & dad would let me know dinner was ready, and then we'd gather in the living room to watch TV and sometimes a movie while having dinner

Re: New Kernel
Posted: Sat May 25, 2024 7:11 pm
by Grogan
Today, for your CPU warming pleasure, is Linux 6.9.2
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.9.2
Code: Select all
block: add a partscan sysfs attribute for disks
commit a4217c6740dc64a3eb6815868a9260825e8c68c6 upstream.
Userspace had been unknowingly relying on a non-stable interface of
kernel internals to determine if partition scanning is enabled for a
given disk. Provide a stable interface for this purpose instead.
block: add a disk_has_partscan helper
commit 140ce28dd3bee8e53acc27f123ae474d69ef66f0 upstream.
Add a helper to check if partition scanning is enabled instead of
open coding the check in a few places. This now always checks for
the hidden flag even if all but one of the callers are never reachable
for hidden gendisks.
That's not something that would come into play for us in normal use, but is more for multipath type shit (e.g. more than one path to a SCSI device/LUN), or, say, loop mounting a partition in a disk image that has a partition table.
There are documentation updates. You all read the kernel docs, RIGHT?
Some USB type-c fixes. I've seen so much bollocks related to that, I don't even enable that in my kernel (though I do actually have one usb c port at the back i/o ports that I cannot foresee ever using)
You definitely don't want lawn brownies like this in your kernel (though you wouldn't likely hit it):
Code: Select all
drm/amd/display: Fix division by zero in setup_dsc_config
commit 130afc8a886183a94cf6eab7d24f300014ff87ba upstream.
When slice_height is 0, the division by slice_height in the calculation
of the number of slices will cause a division by zero driver crash. This
leaves the kernel in a state that requires a reboot. This patch adds a
check to avoid the division by zero.
The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on
a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor
connected via Thunderbolt. The amdgpu driver crashed with this exception
when I rebooted the system with the monitor connected.
kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)
kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu
After applying this patch, the driver no longer crashes when the monitor
is connected and the system is rebooted. I believe this is the same
issue reported for 3113.
Re: New Kernel
Posted: Sat May 25, 2024 7:46 pm
by Zema Bus
I looked last night and thought there would probably be a new one this weekend after seeing how long it had been.
Re: New Kernel
Posted: Fri May 31, 2024 4:56 am
by Grogan
Linux 6.9.3
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.9.3
Scheduler fixes, a bunch of networking fixes, a few minor looking ext4 fixes.
and this:
drm/amd/display: Fix potential index out of bounds in color transformation function
[ Upstream commit 63ae548f1054a0b71678d0349c7dc9628ddd42ca ]
Fixes index out of bounds issue in the color transformation function.
The issue could occur when the index 'i' exceeds the number of transfer
function points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds, an error message is
logged and the function returns false to indicate an error.
Re: New Kernel
Posted: Wed Jun 12, 2024 7:13 pm
by Grogan
It's been a long time between point releases this time, but Linux 6.9.4 is out today:
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.9.4
It's a decently long changelog, I could spend 100x the time going over it, than it would take to just do it (~1m30s) lol
There seem to be a lot of CPU topology fixes from Intel.
Typical networking fixes
Always seem to be some amdgpu and/or amd/display fixes.
One that was interesting to read:
Code: Select all
Revert "drm: Make drivers depends on DRM_DW_HDMI"
commit 8f7f115596d3dccedc06f5813e0269734f5cc534 upstream.
This reverts commit c0e0f139354c01e0213204e4a96e7076e5a3e396, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.
The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in. Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.
Now that's not something that would have bothered us, it's more a matter of semantics in the kernel build system. It's not appropriate for the DRM
layer to enable that dependency, but individual DRM drivers that need the code built in. That last paragraph is not even applicable to the specific situation, it's more the rationale. Neither would result in the user having to enable it as this isn't a user facing config option. There are lots of settings in the kernel config (since the beginning of time) that just get enabled based on your platform and other configuration choices. Unless the user goes and manually edits them to =NO in the .config file (and likely breaking their build, never mind their kernel) they are invisible to you.
Off to build it I go..
Re: New Kernel
Posted: Sun Jun 16, 2024 4:59 pm
by Grogan
Linux 6.9.5 now
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.9.5
It's a lot of filesystem stuff like nilfs2 and btrfs fixes, but plenty of other misc. fixes that might be relevant.
Re: New Kernel
Posted: Mon Jun 17, 2024 5:02 am
by Zema Bus
I just got it done. I've been distracted lately and was a few point releases behind.
Re: New Kernel
Posted: Sat Jun 22, 2024 7:30 am
by Grogan
Re: New Kernel
Posted: Thu Jun 27, 2024 7:23 pm
by Grogan
Linux 6.9.7 today
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.9.7
On skimming, it looks like there are several regressions fixed from wrong approaches to things etc.
Re: New Kernel
Posted: Sat Jul 06, 2024 4:19 am
by Grogan
It's kernel time again... Linux 6.9.8
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.9.8
Some double-free and null pointer type bugs in libata (I don't use that anymore) but nothing else really jumps out at me. Lots of little bugs that would affect somebody. Maybe somebody like me...

Re: New Kernel
Posted: Thu Jul 11, 2024 8:08 pm
by Grogan
Looks like we're getting another before 6.10 is released
Linux 6.9.9
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.9.9
Re: New Kernel
Posted: Mon Jul 15, 2024 2:13 am
by Grogan
It looks like we do have Linux 6.10 right now. It's not on the kernel.org page, but it's tagged and bagged:
https://git.kernel.org/pub/scm/linux/ke ... linux.git/
I might as well get on it.
Re: New Kernel
Posted: Mon Jul 15, 2024 4:41 am
by Zema Bus
I probably won't be doing it for at least a few days, my Slackware install is upstairs where it's too hot to do anything.
Re: New Kernel
Posted: Wed Jul 24, 2024 4:42 pm
by Grogan
It has been 10 days with Linux 6.10, and now it's time for 6.10.1
Not very much actually
https://cdn.kernel.org/pub/linux/kernel ... Log-6.10.1
thermal: core: Allow thermal zones to tell the core to ignore them
The iwlwifi wireless driver registers a thermal zone that is only needed
when the network interface handled by it is up and it wants that thermal
zone to be effectively ignored by the core otherwise.....
That's about the only entry that was interesting to read. Other than that, some CIFS filesystem fixes, a minor ext4 fix, an io_uring fix... that's about it.
Re: New Kernel
Posted: Sun Jul 28, 2024 8:04 pm
by Grogan
Linux 6.10.2
https://cdn.kernel.org/pub/linux/kernel ... Log-6.10.2
I'll be building the kernel on Arch and using the same results, so I might not get to that before the next one.
Actually there's something that needs fixing (can corrupt frames):
tap: add missing verification for short frame
tun: add missing verification for short frame