Announcement

Collapse
No announcement yet.

Updated XZ Code Lands In Linux 6.12

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by aviallon View Post

    The kernel still needs to decompress itself. Hence why it is needed in the kernel.
    Also its modules and the initrd.

    Comment


    • #12
      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.
      Stop TCPA, stupid software patents and corrupt politicians!

      Comment


      • #13
        Originally posted by Adarion View Post
        Aww, people. The xz in kernel was very likely from before the evil additions.
        Noone said otherwise.


        Originally posted by Adarion View Post
        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.

        Originally posted by Adarion View Post
        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.

        Comment


        • #14
          Originally posted by User29 View Post
          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.

          Comment


          • #15
            Originally posted by User29 View Post

            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.

            Comment


            • #16
              Originally posted by Adarion View Post
              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.

              Comment


              • #17
                Originally posted by nanonyme View Post
                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.

                Comment


                • #18
                  Originally posted by emansom View Post
                  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.

                  Comment


                  • #19
                    Originally posted by User29 View Post

                    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!

                    Comment

                    Working...
                    X