It is interesting to see the same pattern that we've watched play out in financial markets repeated in such a different area. High performance from unstated changes in risk. Now that it has been exposed we know who has been swimming naked and over the next couple of years we will learn just how naked they were. Luckily I only run software that I trust on boxes where security is an issue.
The curious thing I'm learning about investors reacting to revealed disasters (caused by poor risk management) is, they don't seem to care as long as the long term story is there . A couple of examples:
* The INTC bugs came out around the beginning of the year, but if you zoom out you can barely tell. It was 34 a year ago and it's 52 today.
* FB fell around 6pct for the CA privacy news, to 152, and then a little for the EU hearings, but it's back in spades to over 200 now.
As long as you provide a plausible hole in the sand, it seems the market will gladly stick its head there and ignore whatever us nerds are FUDDing about.
To be fair, prior Intel issues were mitigated, and even if they couldn't be there might be limited reasons to think that prior issues will impact future sales without sufficient competition in the market. If it turns out that these older Intel chips can't be used for cloud computing anymore then it might just mean that cloud providers like Amazon take a hit but Intel makes a gain in selling them new chips.
And Facebook privacy issues are frequently panic'd about briefly and then forgotten. Markets doing that pretty much mirrors the people who "delete facebook" every time there's a panic and then come back minutes later.
An Intel chip having a flaw will actually help sell more Intel chips in the future as people upgrade their computers and equipment to the "fixed versions".
They are different area but are they not the same strategy and manifestations of the common root cause.
They are both variations of martingale strategy. Increase profits or market share in the short term by increasing the risk of massive losses in the long term. You can play the same game with financial risk and technical debt.
People in Intel face pressure from shareholders to perform better relative to markets and from customers to beat the competition now. Financial industry has similar time horizons.
Is the solution to this and previous side channel bugs to simply not run untrusted and trusted code on the same machine?
Basically a revert to the security model of Windows XP. We should assume access to execute any code means the same security level as having physical access to a machine (I.e. full machine ownership)?
No, as he points out in the article even a kernel call can change the virtual address space so even two threads of the same program may leak data. There's basically no known fix except to disable hyperthreading entirely.
If you give two threads on one core to one VM, the VM could attack the hypervisor. It could have one thread run the TLB probe loop while the other does something that's handled by the hypervisor.
> not run untrusted and trusted code on the same machine?
That would be an incredible disaster, especially if you count "inside a VM" as "on the same machine". Even more so if you count Javascript as "code". And I think it's an overreaction.
I think it is too. Perhaps a better question is: should we really be using the same kind of threat models and mitigation strategies for my gaming machine where I'm alone, and another extreme: A machine running virtual machines for a cloud provider?
For the latter case, issuing microcode/OS fixes or recompiling apps to be more secure but losing 10% performance is probably a worthwhile thing. For the single user machine it's absolutely unacceptable. A gamer would much rather have the XP security model than lose 10% performance in even some rare scenarios due to (for example) extra cache flushes designed to mitigate timing attacks! I'd at least want the option.
So while I don't think that everything we held to be true about computer security is about to go out the window, I almost hope that the future will hold different security for different scenarios. Just because I run the same OS on the same CPU doesn't mean I necessarily need the same security.
It is doable if the hardware supports it well. Especially with virtual machines. However it is expensive to implement and thus even high end consumer mainboards have problems today. (try passing
through a GPU)
And unless you have multiple CPUs or can ensure the cores do not interact in unexpected ways, you essentially have to accept the cost, remain vulnerable (and eat the worms) or replace the hardware with something fixed.
> A gamer would much rather have the XP security model
.. but you probably still don't want your machine to be remotely exploitable by other players. And gaming has the interesting security issue of "anti-cheat", where it's useful if players can prove they're not leaking information from the game process on their own machine. And lots of people will use the same machine to play games and do online banking.
Perhaps the way out is more than one "computer" on the same board with different security models. There's already bits of this with TPMs and ILO systems, but the manufacturers care more about keeping them proprietary than making them usable.
> .. but you probably still don't want your machine to be remotely exploitable by other players
Right. These kind of vulnerabilities are more along the lines of IF an attacker is able to do arbitrary code execution in my first person shooter, by giving it some crafted netcode packages in a multiplayer game - could he then also read my credit card data from my web browser process through a side channel?
And I'm willing to say that - yes - I accept that he can, or at least I'd rather that be possible than sacrifice performance. I realize that any process I run in windows is vulnerable to spying by any other process. Seen that way, the defense has to be against remote code execution, not against cross-process memory reads.
One example of this cross process weakness in windows: once he runs arbitrary code he can just take a screenshot of any other program anyway, including the window with my credit card details in it!
> Seen that way, the defense has to be against remote code execution, not against cross-process memory reads.
This doesn't always look like what it is. You have games that allow e.g. custom levels with map editors, and then the users download the level from the other users and execute whatever code is part of making the level work. This could be exploitable for timing even if it's in a game-specific language. Or isn't even intentionally "code" but still an attacker can use it as a Weird Machine to the same effect.
Putting it on the game developers to make sure none of that is possible is never going to work.
What might work without needing physically separate hardware is to assign dedicated cores to highly performance sensitive programs, with the mitigations disabled on those cores because they're no longer shared. The cost is you would have to leave at least one core for everything else, but that feels like a good trade off. It may even be possible to use the shared core(s) for the game (with lower scheduling priority) even though the mitigations are still turned on for shared core(s).
Also a lot of games actually run a web browser within the game itself these days. So then what do you want to happen if the website the game loads suddenly becomes compromised? (Through DNS poisoning, stealing the domain, etc)
You must pin them to specific cpu cores. But then you lose a big part of the convenience offered by VMs. It is like using gpu passthrough vs virtual 3d card.
Not that big part at all, you can change these settings at will. Sharing the CPUs (overcommiting) is probably out of the question though.
Just most VM management UIs lack the functionality.
GPU passthrough is special because they have weird initialization and shutdown handling. Plus are chunky (all our nothing) until SR-IOV variants become commonplace.
CPU cores don't have these problems.
That's why WebGL is dead (apart copyright/patent issues, IIRC from Apple), there will be no new version. Instead an alternative standard is being development.
Not GP, but I think the ossification of WebGL has little to do with security concerns and a lot to do with the fact that the GL model is a poor fit to the direction hardware has taken over the past couple of decades. Realistically, any successor is going to be benchmarked to within an inch of its life too, so the same worry would apply.
The shape of that successor is still very vague, but it'll probably be closer to the Vulkan/Metal/DX12 generation. Various interested parties have been putting together exploratory proposals (see e.g. Mozilla's Obsidian), and Khronos appears to be accepting that "Vulkan everywhere" ain't going to happen and working on a "3D portability" initiative that's pretty much lowest-common-denominator. That would almost certainly have a web binding if it pans out.
Disclaimer: I don't work in this area, I just follow it out of morbid curiosity.
> Khronos appears to be accepting that "Vulkan everywhere" ain't going to happen and working on a "3D portability" initiative that's pretty much lowest-common-denominator. That would almost certainly have a web binding if it pans out.
this isn't actually such a bad idea. Right now, WebGL isn't OpenGL everywhere either. It's "OpenGL where possible but Direct3D on Windows because OpenGL drivers used to be terrible". Likewise, it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux
> Likewise, it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux
So, a higher-level graphics API. Like WebGL?
I'm not just being facetious - if we're ruling out a low-level API like Vulkan, aren't we back to square one?
What's wrong with WebGL that could be fixed with an API like you describe?
WebGL is modelled after the worst part of OpenGL: hardware state is presented as something that can be altered by the application software at any time in any way, no matter how brain dead the change actually is. Instead of preventing the user to from writing slow rendering code on top of that interface, it actively encourages that.
The new generation of interfaces are based on the tenet that most of the state information is known in advance anyway and can be precompiled into static opaque handles which represent precomputed and sanity-checked hardware register values that the driver just needs to push when required instead of having to run the heavy checking again each time the user calls some glEnable/glDisable or other state altering shenanigans.
I think that a new JavaScript interface that is modelled like this, but is sufficently high level, might be faster, easier to use and safer to implement than what we currently have.
I don't understand what you mean here. You definitely can't expose Vulkan to untrusted code because it is designed to have a very high level of trust between driver and application - the driver is quite likely to crash the whole system on bad input. And there are countless possibilities for bad input in this interface.
So what you need for browsers is an interface that keeps the general ideas of flexible buffer usage and immutable state objects, but puts the user in a rubber cell with heavily padded levers. It can be done, but it likely can't have the full flexibility of DX12/Vulkan/... with memory aliasing etc.
I'm not talking about directly wrapping Vulkan, I was referring to skocznymroczny's comment: "it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux"
The goal would be to maximally retain the advantages of the new generation of graphics APIs, while accommodating all three as backends to the system. (Comparable to the way ANGLE maps WebGL onto Direct3D, but without 'picking favourites'.)
You sound ambivalent on the practicality of this. WebGL itself has been more successful at doing this (wrapping a highly 'trusting' graphics API to give a secure and portable API) than I thought it would be (though we did have the very alarming security issue I mentioned before).
According to this post the future lies in WebVulkan - which is both computing and graphics. On the other hand people from the big companies including Google and Apple are working on WebGPU.
That said, and having worked on a complex WebGL project myself where my colleagues were complaining all the time how bad WebGL is (sorry, won't search the references for that though :P), I wonder how there can possibly be any future for it.
Ah yes, WebCL. A web standard too far. I recall Mozilla saying they wouldn't bother implementing it as people could just use compute shaders in WebGL, but my understanding is that this isn't really practical even now, years later.
From a quick google, I don't think there's really any such thing as 'WebVulkan'. Following the discussion above, I don't see that it would really be a good idea anyway. Wrong level of abstraction.
Someone above linked to this article on 'GPU for the Web' (which I presume is what 'WebGPU' refers to), which as you say looks like it might be the successor to WebGL - https://www.w3.org/community/gpu/
From my testing it looks like WebGL 1 (corresponding to ES 2) is widely available on both mobile and desktop and performs pretty well. I assume WebGL 2 will reach a similar level of support in a couple of years.
For 95% of use cases that’s exactly what we want. I don’t want or need a new 3D standard, I just want the existing standard to work well.
Is there any risk that WebGL 1 availability is going to regress? I hope not!
WebGL is definitely not yet suitable for AAA games, and I’m sure there must be disagreement over the best way to get there. Is that what you’re referring to?
WebGL is still pretty much hit-and-miss, you might have hardware that runs perfectly fine OpenGL ES 3.x native games and then for whatever reason browser vendors blacklist the GPU/OS combination thus running as if software rendering was being used.
And as 3D creator it is not possible to check for this, so people get to the page and dismiss as not being worthy their time.
ES 3 / WebGL 2 is patchy, yes, but I've found ES 2 / WebGL 1 to be reasonably reliable these days. (Edit to add: mainly thinking about iOS, Android and macOS. I haven't experimented much with Windows and Linux.)
Makes me wonder that Matt Dillon, Theo De Raadt, Linus Torvalds, John Carmack and Bryan Cantrill would have been able to make if they were founders of a company together.
Many of these people found success by focusing on engineering solutions instead of founding companies. Makes me instead question what we'd lose if they made that choice years ago.
WebGL as a proxy API is implemented by the browser, yes, but the thing it's proxying (the graphics driver) is well outside the sandbox and is arguably too complex to be secured by parameter validation and the like. If the driver has an exploitable bug in its shader compiler, for example, the WebGL layer is unlikely to be able to guard against it.
I'll be curious to see the details of the exploit. The TLB should only hold metadata about the address spaces involved (e.g. virtual-to-physical mapping, how many times the entry has been used recently), whereas to extract a private key as claimed, one needs the side channel to have a dependency on the data.
71 comments
[ 2.0 ms ] story [ 148 ms ] threadDoes that mean you don't visit websites with scripting enabled?
* The INTC bugs came out around the beginning of the year, but if you zoom out you can barely tell. It was 34 a year ago and it's 52 today.
* FB fell around 6pct for the CA privacy news, to 152, and then a little for the EU hearings, but it's back in spades to over 200 now.
As long as you provide a plausible hole in the sand, it seems the market will gladly stick its head there and ignore whatever us nerds are FUDDing about.
And Facebook privacy issues are frequently panic'd about briefly and then forgotten. Markets doing that pretty much mirrors the people who "delete facebook" every time there's a panic and then come back minutes later.
They are both variations of martingale strategy. Increase profits or market share in the short term by increasing the risk of massive losses in the long term. You can play the same game with financial risk and technical debt.
People in Intel face pressure from shareholders to perform better relative to markets and from customers to beat the competition now. Financial industry has similar time horizons.
Basically a revert to the security model of Windows XP. We should assume access to execute any code means the same security level as having physical access to a machine (I.e. full machine ownership)?
It seems they are complex enough that the answer may be "never", at least for some high risk scenarios.
on kabylake & skylake this has been the recommendation anyway https://lists.debian.org/debian-devel/2017/06/msg00308.html
It is time to rethinking the engineering methodologies we use in the electronics/informatics field.
http://3.bp.blogspot.com/-OyjQUpLowmg/Udz1_NxqNLI/AAAAAAAABV...
* https://www.mail-archive.com/source-changes@openbsd.org/msg9... (https://news.ycombinator.com/item?id=17350278)
That would be an incredible disaster, especially if you count "inside a VM" as "on the same machine". Even more so if you count Javascript as "code". And I think it's an overreaction.
I think it is too. Perhaps a better question is: should we really be using the same kind of threat models and mitigation strategies for my gaming machine where I'm alone, and another extreme: A machine running virtual machines for a cloud provider?
For the latter case, issuing microcode/OS fixes or recompiling apps to be more secure but losing 10% performance is probably a worthwhile thing. For the single user machine it's absolutely unacceptable. A gamer would much rather have the XP security model than lose 10% performance in even some rare scenarios due to (for example) extra cache flushes designed to mitigate timing attacks! I'd at least want the option.
So while I don't think that everything we held to be true about computer security is about to go out the window, I almost hope that the future will hold different security for different scenarios. Just because I run the same OS on the same CPU doesn't mean I necessarily need the same security.
And unless you have multiple CPUs or can ensure the cores do not interact in unexpected ways, you essentially have to accept the cost, remain vulnerable (and eat the worms) or replace the hardware with something fixed.
.. but you probably still don't want your machine to be remotely exploitable by other players. And gaming has the interesting security issue of "anti-cheat", where it's useful if players can prove they're not leaking information from the game process on their own machine. And lots of people will use the same machine to play games and do online banking.
Perhaps the way out is more than one "computer" on the same board with different security models. There's already bits of this with TPMs and ILO systems, but the manufacturers care more about keeping them proprietary than making them usable.
Right. These kind of vulnerabilities are more along the lines of IF an attacker is able to do arbitrary code execution in my first person shooter, by giving it some crafted netcode packages in a multiplayer game - could he then also read my credit card data from my web browser process through a side channel?
And I'm willing to say that - yes - I accept that he can, or at least I'd rather that be possible than sacrifice performance. I realize that any process I run in windows is vulnerable to spying by any other process. Seen that way, the defense has to be against remote code execution, not against cross-process memory reads.
One example of this cross process weakness in windows: once he runs arbitrary code he can just take a screenshot of any other program anyway, including the window with my credit card details in it!
This doesn't always look like what it is. You have games that allow e.g. custom levels with map editors, and then the users download the level from the other users and execute whatever code is part of making the level work. This could be exploitable for timing even if it's in a game-specific language. Or isn't even intentionally "code" but still an attacker can use it as a Weird Machine to the same effect.
Putting it on the game developers to make sure none of that is possible is never going to work.
What might work without needing physically separate hardware is to assign dedicated cores to highly performance sensitive programs, with the mitigations disabled on those cores because they're no longer shared. The cost is you would have to leave at least one core for everything else, but that feels like a good trade off. It may even be possible to use the shared core(s) for the game (with lower scheduling priority) even though the mitigations are still turned on for shared core(s).
XP, specially after SP2 was as safe as NT, if users bother to actually make use of administrator/user separation roles.
Just most VM management UIs lack the functionality.
GPU passthrough is special because they have weird initialization and shutdown handling. Plus are chunky (all our nothing) until SR-IOV variants become commonplace. CPU cores don't have these problems.
"Putting anything that gets benchmarked in a position of security responsibility is very, very dangerous."
https://twitter.com/ID_AA_Carmack/status/395927588108918785
I think the original context was WebGL, but it applies everywhere.
Related reading: remember that time a bug in Firefox's WebGL let an attacker grab a screenshot of your whole monitor?
https://blog.mozilla.org/security/2011/06/16/webgl-graphics-... , https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/blog/webgl-a-new-dimension-for-bro... , https://www.contextis.com/blog/webgl-more-webgl-security-fla...
The shape of that successor is still very vague, but it'll probably be closer to the Vulkan/Metal/DX12 generation. Various interested parties have been putting together exploratory proposals (see e.g. Mozilla's Obsidian), and Khronos appears to be accepting that "Vulkan everywhere" ain't going to happen and working on a "3D portability" initiative that's pretty much lowest-common-denominator. That would almost certainly have a web binding if it pans out.
Disclaimer: I don't work in this area, I just follow it out of morbid curiosity.
A few links:
https://www.khronos.org/api/3dportability/
http://floooh.github.io/2016/08/13/webgl-next.html
https://www.phoronix.com/scan.php?page=news_item&px=Mozilla-...
this isn't actually such a bad idea. Right now, WebGL isn't OpenGL everywhere either. It's "OpenGL where possible but Direct3D on Windows because OpenGL drivers used to be terrible". Likewise, it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux
So, a higher-level graphics API. Like WebGL?
I'm not just being facetious - if we're ruling out a low-level API like Vulkan, aren't we back to square one?
What's wrong with WebGL that could be fixed with an API like you describe?
The new generation of interfaces are based on the tenet that most of the state information is known in advance anyway and can be precompiled into static opaque handles which represent precomputed and sanity-checked hardware register values that the driver just needs to push when required instead of having to run the heavy checking again each time the user calls some glEnable/glDisable or other state altering shenanigans.
I think that a new JavaScript interface that is modelled like this, but is sufficently high level, might be faster, easier to use and safer to implement than what we currently have.
Could an indirection layer really be practical?
(Vaguely related: Zed Shaw's blog post on Indirection Is Not Abstraction, https://zedshaw.com/archive/indirection-is-not-abstraction/ )
So what you need for browsers is an interface that keeps the general ideas of flexible buffer usage and immutable state objects, but puts the user in a rubber cell with heavily padded levers. It can be done, but it likely can't have the full flexibility of DX12/Vulkan/... with memory aliasing etc.
The goal would be to maximally retain the advantages of the new generation of graphics APIs, while accommodating all three as backends to the system. (Comparable to the way ANGLE maps WebGL onto Direct3D, but without 'picking favourites'.)
You sound ambivalent on the practicality of this. WebGL itself has been more successful at doing this (wrapping a highly 'trusting' graphics API to give a secure and portable API) than I thought it would be (though we did have the very alarming security issue I mentioned before).
"Vulnerability analysis of GPU computing"
https://lib.dr.iastate.edu/cgi/viewcontent.cgi?referer=&http...
"Grand Pwning Unit: Accelerating Microarchitectural Attacks with the GPU"
https://www.vusec.net/wp-content/uploads/2018/05/glitch.pdf
Just two random papers, there are quite a few others.
Ah, and as usual when discussing 3D APIs, games console also use their own flavours, XBox is not the exception.
https://www.w3.org/community/gpu/
https://www.khronos.org/webcl/public-mailing-list/archives/1...
According to this post the future lies in WebVulkan - which is both computing and graphics. On the other hand people from the big companies including Google and Apple are working on WebGPU.
That said, and having worked on a complex WebGL project myself where my colleagues were complaining all the time how bad WebGL is (sorry, won't search the references for that though :P), I wonder how there can possibly be any future for it.
From a quick google, I don't think there's really any such thing as 'WebVulkan'. Following the discussion above, I don't see that it would really be a good idea anyway. Wrong level of abstraction.
Someone above linked to this article on 'GPU for the Web' (which I presume is what 'WebGPU' refers to), which as you say looks like it might be the successor to WebGL - https://www.w3.org/community/gpu/
From my testing it looks like WebGL 1 (corresponding to ES 2) is widely available on both mobile and desktop and performs pretty well. I assume WebGL 2 will reach a similar level of support in a couple of years.
For 95% of use cases that’s exactly what we want. I don’t want or need a new 3D standard, I just want the existing standard to work well.
Is there any risk that WebGL 1 availability is going to regress? I hope not!
WebGL is definitely not yet suitable for AAA games, and I’m sure there must be disagreement over the best way to get there. Is that what you’re referring to?
And as 3D creator it is not possible to check for this, so people get to the page and dismiss as not being worthy their time.
Not happening in my lifetime I think.