8 ms·

Seriously, we are having immense trouble with securing CPU virtualization and now we are talking about GPU virtualization for unreviewed, unaccounted, automatic

by madez 9y ago

Seriously, we are having immense trouble with securing CPU virtualization and now we are talking about GPU virtualization for unreviewed, unaccounted, automatically downloaded and executed code? Stop this madness. Use native code and native APIs like OpenGL or Vulkan.

dtf 9y ago
How do I run that in my web page?
- madez 9y ago
  You don't.
  - dtf 9y ago
    How do I run it on my computer?
    - madez 9y ago
      Best case is you get the source or binary package from your trusted package manager and run/compile that. If that is not available, and you still really need the result of that piece of code, fetch the code, compile it and run it. Code distribution has inherent dangers and cannot be safely made extremely effortless and comfortable. Accounting can be bothersome, but is necessary for code.
      - teraflop 9y ago
        Why don't we just put a trusted package manager into the web browser?
        madez 9y ago
        We already have one in the system, why duplicate the effort? Also, It is important to keep the number of authorized sources of code to a system small. If you insist on using that horrible language, you can deliver a webapp that runs in a JavaScript runtime through the OS package manager. That ensures proper accounting for the users.
        Klathmon 9y ago
        So how will I do all that in seconds on any platform with only a URL that is end-to-end encrypted and gives me multiple runtime options? What happens when the "authorized code source" doesn't agree with my program?
        madez 9y ago
        In most distros you don't even need the URL but just the name and get the program in seconds, including signed code that is vetted for by maintainers. Usually you also have many runtime options in the config file, if not in the program itself, but that are details. When your authorized source of code doesn't agree with a program then there is a problem, either with your source or with the program. There are too many parameters to describe all scenarios. For example, if distros refuse to provide a certain program, then you most likely are better off without it, if Apple doesn't let you install a program on your iphone, then you picked the wrong gatekeeper. Apple is a tyrant and puts its interests above yours. If you enter their garden you are on your own and I care very little for the problems there. I'm not saying that code delivery is optimal like it is in the most popular distributions. But the Web is not the solution. Speed is not the only metric.
        Klathmon 9y ago
        Maybe for you, but I don't want any gatekeeper. I want to decide what is "good for me", I want things fast and on any platform from my phone to laptop to car to TV. Luckily we have choices, and I choose to use the web. You can use a browser that disabled all of this, as long as your gatekeeper allows you to.
roblabla 9y ago
Care to explain how GPU virtualization is somehow worse/harder than CPU virtualization ?
- madez 9y ago
  I didn't say that. It's more oil to the fire.
  - albertgoeswoof 9y ago
    Brb, turning off all my cpus and gpus, can’t be adding more fuel!
    - madez 9y ago
      You seem to misunderstand. It's not about not using CPUs or GPUs, but about what code runs on them, and how that code is accounted for. Who vetted for it and who is responsible for it?
- saltcured 9y ago
  Considering that GPU architecture and low-level programming is still treated largely as trade secrets and the domain of proprietary blobs, it's hard to argue how virtualization should be trustworthy. When the OS designers get a good spec about the GPU instruction sets, memory architecture, MMU, and IO-MMU, and the OS designers can be the ones in charge of programming these to be consistent with existing OS protections, then we might start to approach an equivalence with CPUs. Then and only then, we can start worrying about subtle, modern risks like errata where the GPU hardware deviates from the idealized spec or where side-channel attacks take the wind out of our sails. Right now, we have something much closer to the GPU being another computer with an opaque and proprietary OS and a higher-level "managed code" runtime that accepts jobs defined in a mystery ISA by a proprietary compiler suite embedded inside the "graphics driver" in our own computer. We have to have blind faith that there is any data protection as well as that there aren't any code-injection flaws that would allow malicious data and "shader" code to hijack the GPU and its bus interface to compromise the host computer.
verletx64 9y ago
Let's not go too far - Meltdown and Spectre is not an excuse to shut everything down. They existed for years before and I'm sure issues will exist for years after.
- madez 9y ago
  > They existed for years before and I'm sure issues will exist for years after. How is that an argument for more lenient rather than more extreme measures?
  - verletx64 9y ago
    I wasn't arguing for making anything for lenient, I just meant that WebGL is not necessarily suddenly a bad thing just because of Meltdown/Spectre.
    - madez 9y ago
      We need everything but more attack surface. Do you really think the WebGL runtimes are safe and don't leak data through a side channel, possibly combined with the running JavaScript code? To make matters worse, the hardware is opague, running unknown firmware.
pcwalton 9y ago
GPUs are not vulnerable to Meltdown or Spectre, because they don't do speculation, to my knowledge.
- madez 9y ago
  First, at least the driver of Nvidia is affected in an unspecified manner. [0] Second, the hardware is opague and runs unknown firmware. What lies sill in there? What will in future lie in there? Third, how do these hardware components interact? Do they create vulnerabilities in connection with each other? Maybe side leaks that wouldn't be there otherwise? Fourth, there are arguments for rejecting these Web technologies that are orthogonal to their security. These Web technologies lead to an ecosystem of unreviewed code that is outside of the direct and indirect control of the user, shifting power to the developers, ultimately leading to centralization. [0] http://nvidia.custhelp.com/app/answers/detail/a_id/4611 http://nvidia.custhelp.com/app/answers/detail/a_id/4611
DiThi 9y ago
A side channel attack in WebGL similar to Spectre/Meltdown is probably not possible, simply because you don't know when stuff is going to be rendered and how long it takes. You tell the GPU "do this computation" and if it took too long vsync will take 32 ms instead of 16. Maybe you can get a bit more precision with gl.readPixels but I seriously doubt it. I tried to micro benchmark features and changes and I always get too much noise.
dang 9y ago
Please don't take HN threads on generic tangents. Unexpected tangents can be excellent, but generic ones are predictable, and the predictable is the enemy of the curious. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- madez 9y ago
  I get your point.

by madez 9y ago

dtf 9y ago

How do I run that in my web page?

madez 9y ago
You don't.
- dtf 9y ago
  How do I run it on my computer?
  - madez 9y ago
    Best case is you get the source or binary package from your trusted package manager and run/compile that. If that is not available, and you still really need the result of that piece of code, fetch the code, compile it and run it. Code distribution has inherent dangers and cannot be safely made extremely effortless and comfortable. Accounting can be bothersome, but is necessary for code.
    - teraflop 9y ago
      Why don't we just put a trusted package manager into the web browser?
      - madez 9y ago
        We already have one in the system, why duplicate the effort? Also, It is important to keep the number of authorized sources of code to a system small. If you insist on using that horrible language, you can deliver a webapp that runs in a JavaScript runtime through the OS package manager. That ensures proper accounting for the users.
        Klathmon 9y ago
        So how will I do all that in seconds on any platform with only a URL that is end-to-end encrypted and gives me multiple runtime options? What happens when the "authorized code source" doesn't agree with my program?
        madez 9y ago
        In most distros you don't even need the URL but just the name and get the program in seconds, including signed code that is vetted for by maintainers. Usually you also have many runtime options in the config file, if not in the program itself, but that are details. When your authorized source of code doesn't agree with a program then there is a problem, either with your source or with the program. There are too many parameters to describe all scenarios. For example, if distros refuse to provide a certain program, then you most likely are better off without it, if Apple doesn't let you install a program on your iphone, then you picked the wrong gatekeeper. Apple is a tyrant and puts its interests above yours. If you enter their garden you are on your own and I care very little for the problems there. I'm not saying that code delivery is optimal like it is in the most popular distributions. But the Web is not the solution. Speed is not the only metric.
        Klathmon 9y ago
        Maybe for you, but I don't want any gatekeeper. I want to decide what is "good for me", I want things fast and on any platform from my phone to laptop to car to TV. Luckily we have choices, and I choose to use the web. You can use a browser that disabled all of this, as long as your gatekeeper allows you to.

roblabla 9y ago

Care to explain how GPU virtualization is somehow worse/harder than CPU virtualization ?

madez 9y ago
I didn't say that. It's more oil to the fire.
- albertgoeswoof 9y ago
  Brb, turning off all my cpus and gpus, can’t be adding more fuel!
  - madez 9y ago
    You seem to misunderstand. It's not about not using CPUs or GPUs, but about what code runs on them, and how that code is accounted for. Who vetted for it and who is responsible for it?
saltcured 9y ago
Considering that GPU architecture and low-level programming is still treated largely as trade secrets and the domain of proprietary blobs, it's hard to argue how virtualization should be trustworthy. When the OS designers get a good spec about the GPU instruction sets, memory architecture, MMU, and IO-MMU, and the OS designers can be the ones in charge of programming these to be consistent with existing OS protections, then we might start to approach an equivalence with CPUs. Then and only then, we can start worrying about subtle, modern risks like errata where the GPU hardware deviates from the idealized spec or where side-channel attacks take the wind out of our sails. Right now, we have something much closer to the GPU being another computer with an opaque and proprietary OS and a higher-level "managed code" runtime that accepts jobs defined in a mystery ISA by a proprietary compiler suite embedded inside the "graphics driver" in our own computer. We have to have blind faith that there is any data protection as well as that there aren't any code-injection flaws that would allow malicious data and "shader" code to hijack the GPU and its bus interface to compromise the host computer.

verletx64 9y ago

Let's not go too far - Meltdown and Spectre is not an excuse to shut everything down. They existed for years before and I'm sure issues will exist for years after.

madez 9y ago
> They existed for years before and I'm sure issues will exist for years after. How is that an argument for more lenient rather than more extreme measures?
- verletx64 9y ago
  I wasn't arguing for making anything for lenient, I just meant that WebGL is not necessarily suddenly a bad thing just because of Meltdown/Spectre.
  - madez 9y ago
    We need everything but more attack surface. Do you really think the WebGL runtimes are safe and don't leak data through a side channel, possibly combined with the running JavaScript code? To make matters worse, the hardware is opague, running unknown firmware.

pcwalton 9y ago

GPUs are not vulnerable to Meltdown or Spectre, because they don't do speculation, to my knowledge.

madez 9y ago
First, at least the driver of Nvidia is affected in an unspecified manner. [0] Second, the hardware is opague and runs unknown firmware. What lies sill in there? What will in future lie in there? Third, how do these hardware components interact? Do they create vulnerabilities in connection with each other? Maybe side leaks that wouldn't be there otherwise? Fourth, there are arguments for rejecting these Web technologies that are orthogonal to their security. These Web technologies lead to an ecosystem of unreviewed code that is outside of the direct and indirect control of the user, shifting power to the developers, ultimately leading to centralization. [0] http://nvidia.custhelp.com/app/answers/detail/a_id/4611 http://nvidia.custhelp.com/app/answers/detail/a_id/4611

DiThi 9y ago

A side channel attack in WebGL similar to Spectre/Meltdown is probably not possible, simply because you don't know when stuff is going to be rendered and how long it takes. You tell the GPU "do this computation" and if it took too long vsync will take 32 ms instead of 16. Maybe you can get a bit more precision with gl.readPixels but I seriously doubt it. I tried to micro benchmark features and changes and I always get too much noise.

dang 9y ago

Please don't take HN threads on generic tangents. Unexpected tangents can be excellent, but generic ones are predictable, and the predictable is the enemy of the curious. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

madez 9y ago
I get your point.