OpenBSD chief de Raadt says no easy fix for new Intel CPU bug
itwire.com
itwire.com
"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.
Not happening in my lifetime I think.
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.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.
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)?
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.
.. 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).
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.
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
* https://www.mail-archive.com/source-changes@openbsd.org/msg9... (https://news.ycombinator.com/item?id=17350278)
It is time to rethinking the engineering methodologies we use in the electronics/informatics field.
http://3.bp.blogspot.com/-OyjQUpLowmg/Udz1_NxqNLI/AAAAAAAABV...
XP, specially after SP2 was as safe as NT, if users bother to actually make use of administrator/user separation roles.
* 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.
Does that mean you don't visit websites with scripting enabled?
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.
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.