Updated XZ Code Lands In Linux 6.12

[phoronix]

Phoronix: Updated XZ Code Lands In Linux 6.12

The kernel patches collected by Andrew Morton were upstreamed today for the Linux 6.12 kernel. Among those changes are pulling in the updated XZ Embedded code...

https://www.phoronix.com/news/Linux-6.12-Updated-Embedded

[emansom]

With or without state sponsored backdoors?

[Daktyl198]

Is there any particular reason that XZ code needs to be inside of the kernel at all? It's just a compression tool, it should live entirely in userspace right?

[V1tol]

After the XZ fallout I expected this to be dropped from the kernel entirely. We have lots of other better alternatives in kernel for everyone's taste, why bother with this one.

[aviallon]

Is there any particular reason that XZ code needs to be inside of the kernel at all? It's just a compression tool, it should live entirely in userspace right?

The kernel still needs to decompress itself. Hence why it is needed in the kernel.

[MicroNerd]

After the XZ fallout I expected this to be dropped from the kernel entirely. We have lots of other better alternatives in kernel for everyone's taste, why bother with this one.

According to the kernel docs the kernel only uses only XZ Embedded and not the affected userspace xz-utils that was from a certain (very new) version too. The xz code in the kernel is not updated that often (that's why it's news here). That being said: yes the code in kernel could also get a sneaky backdoor in theory, so I still understand your concerns.

[ahrs]

Is there any particular reason that XZ code needs to be inside of the kernel at all? It's just a compression tool, it should live entirely in userspace right?

Strictly speaking, no, you can use a different compressor or no compressor.

The kernel still needs to decompress itself. Hence why it is needed in the kernel.

Only if you compress the kernel in the first place. Almost every distro is going to do this though because it saves a lot of disk space. In my custom kernels I use lz4 instead of xz because it's the fastest to decompress (the system in theory boots a bit quicker). If I wanted something that can compress a bit better I'd probably use Zstd instead which can compress to quality similar to that of Xz but still with faster decompression speeds.

[User29]

it's really surpising that it wasn't carved out of the kernel immediately when the backdoor was found.

the only reasoning i can imagine to keep it in the kernel is, that now it's kinda "audited" (no, not really, but kinda) and including something else would raise the risk of introducing still unknown, exciting new vulnerabilities.

[ahrs]

it's really surpising that it wasn't carved out of the kernel immediately when the backdoor was found.

the only reasoning i can imagine to keep it in the kernel is, that now it's kinda "audited" (no, not really, but kinda) and including something else would raise the risk of introducing still unknown, exciting new vulnerabilities.

The business with the backdoor doesn't really apply to the kernel because the code is different and it has to adhere to the kernels development practices. There's no way to hide a backdoor in plain sight when every commit has to make it past at least one human reviewer and then it has to make it past Linus himself.

There's also likely more lucrative targets in the kernel if somebody were to try to do this. I'm not sure how much use an exploit in the Xz de-compressor would be because an attacker has no control over what it decompresses. If you can modify the compressed kernel image or make the kernel load a compressed module then clearly you are already in a very privileged position.

[User29]

The business with the backdoor doesn't really apply to the kernel because the code is different and it has to adhere to the kernels development practices. There's no way to hide a backdoor in plain sight when every commit has to make it past at least one human reviewer and then it has to make it past Linus himself.

Ok, I didn't know this, I thought the code is the same.

Code review: this was true ~20 years ago, but now? The code is just enormous. Just check the recent large folio issue (affected XFS and probably more). The commits were reviewed, weren't they? And a logical bug slipped in which was later fixed accidentally by another commit. Noone noticed it until someone reported it and volunteered for testing.