New Kernel

[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.

[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)

[Zema Bus]

I hadn't thought of that, guess that's one of the upsides to UEFI

[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.

[Zema Bus]

I'm on it

[Grogan]

I got mine done, all 1:26 of it, for both OSes

[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

[Zema Bus]

6.8.8

[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.

[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

[Zema Bus]

I'll do it this weekend, it'll take my mind off of things for a few mins

[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/

[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.

[Zema Bus]

I see it's up on the main page now.

[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

[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

[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.

[Zema Bus]

I looked last night and thought there would probably be a new one this weekend after seeing how long it had been.

[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.

[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..

[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.

[Zema Bus]

I just got it done. I've been distracted lately and was a few point releases behind.

[Grogan]

Linux 6.9.6
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.9.6

Bunch of boring stuff

[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.

[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...

[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

[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.

[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.

[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.

[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