Announcement

Collapse
No announcement yet.

The Linux Kernel Has Been Forcing Different Behavior For Processes Starting With "X"

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

  • The Linux Kernel Has Been Forcing Different Behavior For Processes Starting With "X"

    Phoronix: The Linux Kernel Has Been Forcing Different Behavior For Processes Starting With "X"

    An ugly hack within the Linux kernel that has been in mainline for over three years has been called out. Due to a buggy X.Org Server / xf86-video-modesetting DDX, the Linux kernel has been imposing different behavior on whether a process starts with "X" and in turn disable the atomic mode-setting support...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Xorg is fine they say. No need for Wayland they say...

    Comment


    • #3
      OMG, rebuilding my kernel now

      Comment


      • #4
        I'm not a C dev, but doesn't
        Code:
         && req->value == 1
        mean that only a process named "X" would enter in this condition?

        I'm not saying it's not a questionable solution, but if it's true then maybe it didn't affect as many processes as they thought.​

        Comment


        • #5
          Classic example of Linux-quality code.

          I'd say the usual stuff about crap running in supervisor mode and microkernel multiserver systems being the way forward, but effort.

          Comment


          • #6
            Originally posted by ayumu View Post
            Classic example of Linux-quality code.

            I'd say the usual stuff about crap running in supervisor mode and microkernel multiserver systems being the way forward, but effort.
            Classic example of Xorg quality, but morons praising microkernel brain dead design have no clue as usual. Tell me why there's no single use case for your broken by design piece of shit microkernel? Just don't come with 'layers between OS and hardware' examples. I want examples of real world usage and performance of this broken by design POS. Oh, and why even OpenBSD doesn't give a shit about your crap?
            Last edited by Volta; 07 November 2022, 08:18 AM.

            Comment


            • #7
              I hope that Linus accepts it.

              Comment


              • #8
                Seriously that's trash....

                Comment


                • #9
                  Not breaking userspace is going to be tricky with this one...

                  http://www.dirtcellar.net

                  Comment


                  • #10
                    Originally posted by Volta View Post
                    Classic example of Xorg quality, but morons praising microkernel brain dead design have no clue as usual. Tell me why there's no single use case for your broken by design piece of shit microkernel? Just don't come with 'layers between OS and hardware' examples. I want examples of real world usage and performance of this broken by design POS. Oh, and why even OpenBSD doesn't give a shit about your crap?
                    While I don't buy on the microkernel shenanigans, there's a point to be made about migration efforts. Why do we still have bufferbloat everywhere? Why it took so long to start using IPv6? Why are we still mostly using TCP for the web? Changing infra is not just about the quality of the replacement, but about the cost of implementation. Microkernels DEFINITELY were not a reasonable option at the time Linux gained dominance. They may be today, but migration costs will always hold them back, just as they hold back many other designs and new kernels and what not.
                    While this IS about X.org being shit*, a microkernel could still contain this hack without doing it under kernel level privileges, so that's something. I don't see the security issue tho, but I'm no security expert. The way I see it it just breaks atomic modesetting for drivers whose name starts with X rather than give privilege escalation to a random process or stuff like that.

                    *In this case for a driver that, AFAIK, is specific to Linux's interfaces, so kinda gray anyway.

                    Comment

                    Working...
                    X