CachyOS Making Use Of Plymouth For Better Boot Experience, Mitigates For XZ Fiasco

[ptr1337]

I've been trying the cachyOS kernels on arch and I have to say, I think somethings wrong, particularly the linux-cachyos-sched-ext and it's been really stuttery. it was fine when I compiled it against arch's main kernel with the patches applied so I think something is funky with the kernel, plan on testing their eevdf kernels soon but has anyone else experience similar issues? Maybe it's just one of those things were I need to test it on cachy itself?

The sched-ext kernel basically does nothing, then just providing the sched-ext interface and our patchset.
If you don't start explicitly the scx schedulers (you can find them in the scx-scheds package), then it basically just uses EEVDF as scheduler.

There was shortly a issue in 6.8.1-cachyos, which did not apply the frequency limits corrrectly on Zen2/Zen3, but this was fixed from our side quite fast.
Was a issue from the upstream amd-cpb boost patchset, which we have reverted then to the old version. Besides that, im not sure what you mean with stuttery.

[Quackdoc]

The sched-ext kernel basically does nothing, then just providing the sched-ext interface and our patchset.
If you don't start explicitly the scx schedulers (you can find them in the scx-scheds package), then it basically just uses EEVDF as scheduler.

There was shortly a issue in 6.8.1-cachyos, which did not apply the frequency limits corrrectly on Zen2/Zen3, but this was fixed from our side quite fast.
Was a issue from the upstream amd-cpb boost patchset, which we have reverted then to the old version. Besides that, im not sure what you mean with stuttery.

I run cosmic-comp and this kernel specifically, even when not scx schedulers were loaded, caused cosmic to stutter, and sway just had generally worse preformance. the linux-sched-ext kernel that cachy builds didn't have an issue, though those kernels have an issue with bcachefs. I was testing linux-cachyos-sched-ext 6.8.1-2 and it has the same issues. Ryzen 2600 so Im not sure it's that. I can go back and test it however.

[ptr1337]

I run cosmic-comp and this kernel specifically, even when not scx schedulers were loaded, caused cosmic to stutter, and sway just had generally worse preformance. the linux-sched-ext kernel that cachy builds didn't have an issue, though those kernels have an issue with bcachefs. I was testing linux-cachyos-sched-ext 6.8.1-2 and it has the same issues. Ryzen 2600 so Im not sure it's that. I can go back and test it however.

> linux-sched-ext kernel that cachy builds didn't have an issue

We are building in a clean chroot and only against -march=x86-64-v3 and -v4. That would be the only difference, if you didnt change anything on the PKGBUILD

> though those kernels have an issue with bcachefs

We are not changing anything on bcachefs

But please add a github issue at github.com/cachyos/linux-cachyos with the details of building, general logs (dmesg, journalctl), your hardware info

[Quackdoc]

> linux-sched-ext kernel that cachy builds didn't have an issue

We are building in a clean chroot and only against -march=x86-64-v3 and -v4. That would be the only difference, if you didnt change anything on the PKGBUILD

> though those kernels have an issue with bcachefs

We are not changing anything on bcachefs

But please add a github issue at github.com/cachyos/linux-cachyos with the details of building, general logs (dmesg, journalctl), your hardware info

the issue is a bcachefs one, not a cachyos one, it was fixed in later kernels. Ill make the ticket when I can.

[patrakov]

Did you check that they actually have the exploit code? There are claims out that the build scripts check for rpm or deb environments before creating the exploit.

I have checked the claim that the build scripts check for rpm or deb build environments. In addition, in a bubblewrap sandbox on Arch Linux, I have checked the following:

* xz-5.6.1-1 PKGBUILD, when given the source files matching the recorded checksums, builds the liblzma.so.5.6.1 library reproducibly (i.e., building it twice yields a byte-for-byte identical result - however, not matching the official one, presumably because some part of the toolchain has been updated)
* Adding a "mkdir debian ; touch debian/rules" line before "./configure" changes the result (by adding the backdoor), and the resulting library becomes ~39 KB larger.
* Building xz-5.6.1-2 in this environment results in the liblzma.so.5.6.1 library nearly identical to the one built from the unmodified xz-5.6.1-1 PKGBUILD - the only differences are in .note.gnu.build-id and .gnu_debuglink sections.

[Alliancemd]

The question is not whether Arch and CachyOS were affected at all, but whether the purported "fix" does anything at all. And I know for sure that it doesn't: the disassembly of the liblzma.so.5.6.1 library before and after the fix is identical, the only difference is in ELF headers. IMPORTANT EDIT: The previous statement about the identical disassembly applies to Arch Linux only. I have not checked CachyOS, and I know for sure that the backdoor does exist in Debian.

Doing something "just in case" and not issuing official statements debunking the provably-false information in the security advisory given this level of evidence is only fueling conspiracy theories. Due to this, in my past job, auditors (who were previously OK with Arch Linux) could scream "please wipe the disk and install Windows just in case".

"provably-false information" - what are you talking about "PatraKov"? I have looked at the Openwall report, it's 100% a backdoor, without any doubts. I don't know what kind of crap you are reading.

[Alliancemd]

I have checked the claim that the build scripts check for rpm or deb build environments. In addition, in a bubblewrap sandbox on Arch Linux, I have checked the following:

* xz-5.6.1-1 PKGBUILD, when given the source files matching the recorded checksums, builds the liblzma.so.5.6.1 library reproducibly (i.e., building it twice yields a byte-for-byte identical result - however, not matching the official one, presumably because some part of the toolchain has been updated)
* Adding a "mkdir debian ; touch debian/rules" line before "./configure" changes the result (by adding the backdoor), and the resulting library becomes ~39 KB larger.
* Building xz-5.6.1-2 in this environment results in the liblzma.so.5.6.1 library nearly identical to the one built from the unmodified xz-5.6.1-1 PKGBUILD - the only differences are in .note.gnu.build-id and .gnu_debuglink sections.

There you go... Showing zero understanding of what the issue is. CachyOS member just told you that neither CachyOS, nor Arch Linux is affected, only for you to complain that Arch Linux is not affected...
Different distros get their XZ source code through different methods. Some distros download it from Git, where it doesn't have the backdoor(that's why it's NOT affected). Others, like Fedora Rawhide download the tarballs, which were uploaded by Jia Tan and not the original maintainer Lasse Collin, which have the backdoor inserted and obfuscated.

[andyprough]

XZ Fiasco

If XZ's backdoor is a fiasco, what should we call Chrome/chromium's 53 known zero-day exploited vulnerabilities that have been added to cisa.gov's catalog over the past 28 months since November 2021? What word is worse than 'fiasco'? A 'tragedy'?

[Quackdoc]

If XZ's backdoor is a fiasco, what should we call Chrome/chromium's 53 known zero-day exploited vulnerabilities that have been added to cisa.gov's catalog over the past 28 months since November 2021? What word is worse than 'fiasco'? A 'tragedy'?

we call that expected xD

[patrakov]

"provably-false information" - what are you talking about "PatraKov"? I have looked at the Openwall report, it's 100% a backdoor, without any doubts. I don't know what kind of crap you are reading.

Provably false information is "Arch Linux had this backdoor in any version of their xz binary packages". It was in the source tarball that they used, and the build environment did not meet the conditions necessary for the malware object to be linked into liblzma.so.5.6.1. Yet, they say that their xz-5.6.1-1 is affected.

To be fair, they do say that their sshd does not load liblzma, and therefore the trigger that would be used by the malware in other distributions is missing. But a stronger statement, namely, that the malware that the upstream put into xz 5.6.0 and 5.6.1 tarballs did not make it into the Arch Linux binary packages (regardless of the way how openssh was built), is what I would expect.

This stronger statement is needed because the procedures for dealing with a vulnerability and with a backdoor are different.