Updated XZ Code Lands In Linux 6.12

[chriswyatt]

Noone said otherwise.

And they didn't state that anyone was saying the opposite. Pretty sure they were just explaining why that code could never have got in the kernel!

[yoshi314]

With or without state sponsored backdoors?

without your understanding of the exploit. it requires an entire chain of userspace components via symbol resolver override, which is something kernel itself never does.

[caligula]

Right, it does little merit to try to security shame xz out of kernel based on the incident in userbase. What is a relevant topic is whether xz overall still makes sense as a compression now with zstd being present as well.

There are other compression algos as well. For example bzip2 isn't any good these days.

[nanonyme]

So I'd say that xz de/compression code is fine for the kernel and one should rather support upstream than simply blaring around that xz would be all evil and obsolete.

Right, it does little merit to try to security shame xz out of kernel based on the incident in userbase. What is a relevant topic is whether xz overall still makes sense as a compression now with zstd being present as well.

[F.Ultra]

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.

Even if the code had been the same it wouldn't have mattered, the backdoor was not in the code, it was in a test file.

[Weasel]

I'm totally unfamiliar with compression methods, that's why I'm asking: why xz? Is it so good at compression ratio and at decompression time? Because these are the most important metrics. Compression time doensn't really matter, because it happens once.

It matters in some cases when you do live compression like in zram. Though in general I agree. And xz seems to offer best compression out of the ones supported by the kernel.

But yeah you guys completely forget the kernel also needs to be able to decompress squashfs xz compressed images since they can be mounted.

[User29]

Aww, people. The xz in kernel was very likely from before the evil additions.

Noone said otherwise.

and this is now double- and triple-reviewed stuff that enters the kernel.

Maybe. For a while. Then it will be forgotten and reviews and carefulness reduces back to normal. This is how things work.

So I'd say that xz de/compression code is fine for the kernel and one should rather support upstream than simply blaring around that xz would be all evil and obsolete.

It's very noce that you'd say it's fine now.

I'm totally unfamiliar with compression methods, that's why I'm asking: why xz? Is it so good at compression ratio and at decompression time? Because these are the most important metrics. Compression time doensn't really matter, because it happens once.

[Adarion]

Aww, people. The xz in kernel was very likely from before the evil additions. Moreover, it the very backdoor relied also on other funcitonality iirc. Besides, the hole is closed upstream and this is now double- and triple-reviewed stuff that enters the kernel. It is one of multiple methods to compress kernel image or modules. Feel free to use a different one.
And one should take into account that the mess happened because a developer (who did a good job) was so overworked, that he was just happy that someone stepped up and offered help, which was - sadly - a nicely tailored social engineering attack.

So I'd say that xz de/compression code is fine for the kernel and one should rather support upstream than simply blaring around that xz would be all evil and obsolete.

[archkde]

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

Also its modules and the initrd.

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