1. 13
  1.  

  2. 7

    Under the Freon driver model, the Chrome browser talks directly to the kernel’s DRM/KMS APIs

    What could possibly go wrong?

    1. 8

      This is already what happens whenever you do GL with DRI (the Direct Rendering Interface) under X11, for the most part. And this is very much where Wayland is pushing the Linux graphics stack.

      1. 6

        I’m not an expert, but what’s wrong with this, exactly?

        X11 also exposes several raw hardware resources to application code on a regular basis, and has a pretty terrible memory management model, all for the sake of performance. Cutting out the (frankly, pretty outdated) middleman sounds like a good idea. I’m not saying every application should talk directly to the kernel APIs, but in this case, Chrome is the application level of the OS. It’s perfectly sane to have it handle or delegate the rendering directly using the kernel interfaces.

        X11 was designed for a software and hardware model that just no longer applies. The hardware interface and the software that uses it just no longer operate in the way the X11 API was designed, and this has resulted in various holes being punched through X11 to use new hardware features.

        1. 3

          Web browsers - which have a nearly infinitely large attack surface - talking to ring 0 code scares the living daylights out of me.

          That’s not to say that X isn’t nasty in its own way, but at least it’s the devil we know.

          1. 2

            Your points makes a lot of sense, but this is ChromeOS we’re talking about, so I think compromising Chrome (even without ring 0 elevation) would already be total ownage of the system.

            1. 3

              this is ChromeOS we’re talking about, so I think compromising Chrome (even without ring 0 elevation) would already be total ownage of the system.

              The browser is definitely sandboxed and the OS hardened, and a decent amount of thought seems to be put into their approach.

              From their design docs, talking about exposing kernel APIs:

              After the audio/video experience, we’re left with one major exposed surface for plugins which require video card device access. Since we will want to support accelerated 3D and other fast rendering, we’ll be exposing (possibly binary-only) video card drivers via X/DRI. This is a larger problem that will be addressed in a more detailed design document on the issue.

              I’d say calling this a larger problem buries the lede just a bit.

              Before a browser exploit could impact a sandboxed browser. Getting root would mean attacking WebGL because that’s where DRI lives, but I don’t think that was even enabled on ChromeOS (but I could be wrong there).

              Now the web browser talks to the kernel. An attack surface to root went from “WebGL, if the user even has it turned on” to “V8, Blink, VP8, you name it!”

          2. 2

            I’m definitely not an expert but this sounds like an opportunity for a bright spark to generate an image to own your hardware…