3 ms·

> Just look at the HN frontpage yesterday - Google Pixel phone pwned because all android applications have unfettered access to the GPU driver, which itself had

> Just look at the HN frontpage yesterday - Google Pixel phone pwned because all android applications have unfettered access to the GPU driver, which itself had a vulnerability. In a Fuchsia world, only apps requiring 3D rendering would have access to the 3D bits of the GPU driver. I think that's a common misconception. I'll freely admit I don't know how Fuchsia handles this, but in the realm of conventional OSes,[0] all modern apps require what twenty years ago would be considered “3D”. The GPU isn't just there for games, it's used to render the UI of all applications, and it's done via APIs you might associate with 3D. Actually, if we define GPU strictly[1] and ignore GPU compute for a moment, there are no “non-3D bits” of the driver. [0] At least macOS, iOS, Windows and Android. Not sure what GNOME etc do. [1] A modern graphics card combines display output, 3D rendering/GPU compute, and video encoding/decoding. If you were to build an SoC with those capabilities, you would want to licence three different IPs: a display processor, graphics processing unit and video processing unit respectively.

londons_explore 4y ago
Thats the current model, yes. But it needn't be that way. The application could simply say "I want a textbox here, and that animation there", and then another UI-drawing-process does the actual rendering. That 2nd process can have the special '3D drawing permission'. Then, if you find a flaw in the GPU driver, you also need to find a flaw in the special UI-drawing-process to allow you to exploit it.
raggi 4y ago
Fuchsia was (when I left) strictly Vulkan in the core OS interfaces for the rendering stack. Picking one technology rather than pulling over several reduces the overall cost of solving for sandboxing that technology. There is still plenty to do in the Vulkan space though - where Chrome solved for webgl we don't yet have a full equivalent for Vulkan, and in some ways Vulkans design has things that make this extra painful (ICDs). At the time when I left the ICD loader is in fact a special case in the OS where it's one of the few mechanisms by which regular components ever get executable memory that does not come directly from their own package (which is a normal and significant design encouraged and policy enforced constraint for most product builds on top of the OS, excepting JITs which are rare). The ICD loader provides a special path for the ICD and some associated data to be loaded from a peer component at runtime. An ideal eventual outcome for secure systems would be to find ways to avoid this vendor runtime mixing, instead for mechanisms to efficiently push command queues through stages of processing. The Vulkan folks have performance related cases to make as to why they took the route they did - I suspect a middle ground is possible eventually but would need new specs and new drivers. Not everything needs this capability, and not everything gets it. Product builds out of the OS can effectively apply policy as to what components get this capability and arrange for other solutions to rendering as best fits the product. The system design makes these choices explicit, rather than implicit, and can be tuned for a particular balance of security, performance and other properties. There was an RFC recently formalizing some of these details, I've not gone over it to see if it also introduced significant new changes. https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0205_vulkan_loader?hl=en https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...
- TazeTSchnitzel 4y ago
  Thanks for the insight, this is pretty interesting. I'm not surprised that Vulkan is a special case considering Fuchsia is using more-or-less off-the-shelf drivers if I understood correctly.
  - raggi 4y ago
    Drivers vary. The intel driver that Fuchsia has was written early on entirely by the team. (This was when I left the only OSS Vulkan driver in the system)

londons_explore 4y ago

Thats the current model, yes. But it needn't be that way. The application could simply say "I want a textbox here, and that animation there", and then another UI-drawing-process does the actual rendering. That 2nd process can have the special '3D drawing permission'. Then, if you find a flaw in the GPU driver, you also need to find a flaw in the special UI-drawing-process to allow you to exploit it.

raggi 4y ago

Fuchsia was (when I left) strictly Vulkan in the core OS interfaces for the rendering stack. Picking one technology rather than pulling over several reduces the overall cost of solving for sandboxing that technology. There is still plenty to do in the Vulkan space though - where Chrome solved for webgl we don't yet have a full equivalent for Vulkan, and in some ways Vulkans design has things that make this extra painful (ICDs). At the time when I left the ICD loader is in fact a special case in the OS where it's one of the few mechanisms by which regular components ever get executable memory that does not come directly from their own package (which is a normal and significant design encouraged and policy enforced constraint for most product builds on top of the OS, excepting JITs which are rare). The ICD loader provides a special path for the ICD and some associated data to be loaded from a peer component at runtime. An ideal eventual outcome for secure systems would be to find ways to avoid this vendor runtime mixing, instead for mechanisms to efficiently push command queues through stages of processing. The Vulkan folks have performance related cases to make as to why they took the route they did - I suspect a middle ground is possible eventually but would need new specs and new drivers. Not everything needs this capability, and not everything gets it. Product builds out of the OS can effectively apply policy as to what components get this capability and arrange for other solutions to rendering as best fits the product. The system design makes these choices explicit, rather than implicit, and can be tuned for a particular balance of security, performance and other properties. There was an RFC recently formalizing some of these details, I've not gone over it to see if it also introduced significant new changes. https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0205_vulkan_loader?hl=en https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

TazeTSchnitzel 4y ago
Thanks for the insight, this is pretty interesting. I'm not surprised that Vulkan is a special case considering Fuchsia is using more-or-less off-the-shelf drivers if I understood correctly.
- raggi 4y ago
  Drivers vary. The intel driver that Fuchsia has was written early on entirely by the team. (This was when I left the only OSS Vulkan driver in the system)