New Kernel

The place to discuss Linux and Unix Operating Systems
Forum rules
Behave
User avatar
Grogan
Your Host
Posts: 480
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: New Kernel

Post 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.
User avatar
Grogan
Your Host
Posts: 480
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: New Kernel

Post 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)
User avatar
Zema Bus
Your Co-Host
Posts: 240
Joined: Sun Feb 04, 2024 1:25 am

Re: New Kernel

Post by Zema Bus »

I hadn't thought of that, guess that's one of the upsides to UEFI :)
User avatar
Grogan
Your Host
Posts: 480
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: New Kernel

Post 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.
User avatar
Zema Bus
Your Co-Host
Posts: 240
Joined: Sun Feb 04, 2024 1:25 am

Re: New Kernel

Post by Zema Bus »

I'm on it :)
User avatar
Grogan
Your Host
Posts: 480
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: New Kernel

Post by Grogan »

I got mine done, all 1:26 of it, for both OSes :-)
User avatar
Grogan
Your Host
Posts: 480
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: New Kernel

Post 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
User avatar
Zema Bus
Your Co-Host
Posts: 240
Joined: Sun Feb 04, 2024 1:25 am

Re: New Kernel

Post by Zema Bus »

6.8.8 :)
User avatar
Grogan
Your Host
Posts: 480
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: New Kernel

Post 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.
Post Reply