Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Spectre and Meltdown Mean for WebKit

webkit.org

Post reply on HN
Print view View original

281–290 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#281

Post by andrewmcwatters »

iainmerrick wrote: post #219
flohofwoe wrote: post #89

Earlier quoted context omitted.

1ms is absolutely overkill IMHO and will require rewriting a lot of code which measures frametime this way. This is not an issue for the precision reductions in the other browsers (Chrome's 100us is just about what's still tolerable, Firefox's 20us is fine). It's probably better to round the measured frametime to the next 'vsync frametime' like 16.667ms or 33.333ms anyway, but I expect a lot of WebGL demos and games…

What's an example scenario where you need an ultra-high-resolution timer? For WebGL, don't you just rely on requestAnimationFrame to call you at the right times, and draw your frame as quickly as possible? What's the benefit of being able to measure the frame time to the nearest microsecond, rather than the nearest millisecond?

Timing behavior in literally any game.

Re: What Spectre and Meltdown Mean for WebKit

#282

Post by pizlonator »

bakery2k wrote: post #193

Mitigations for Spectre and Meltdown are also being added to the JavaScript VMs in Chrome [1], Firefox [2] and IE/Edge [3]. Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? What about the JVM and Microsoft's CLR? Or are these other VMs not susceptible to this form of attack? [1] https://www.chromium.org/Home/chromium-security/ssca [2] https://b…

> Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT?

Yes.

> What about the JVM and Microsoft's CLR?

Yes.

Re: What Spectre and Meltdown Mean for WebKit

#283

Post by pizlonator »

roca wrote: post #77

I see how this addresses some examples of Spectre, and it's clever (hi Filip!) and probably worth doing. However, not all possible Spectre-related vulnerabilities involve type confusion. E.g. imagine if we had JS code that does let x = bigArray[iframeElem.contentWindow.someProperty]; Conceivably that could get compiled to some mix of JIT code and C++ that does if (iframeElemOrigin == selfDocumentOrigin) { index = ...…

Hi Robert! It’s been a while! :-)

Oooh that’s a good catch. I agree that pointer poisoning and index masking don’t handle this case. Unless the pointer to the data structure being accessed (bigArray or whatever) is poisoned with a function of origin. Maybe that’s the way to do it.

I am still optimistic about this. It’s going to be a lot of work and there will be surprises but then that’s always true when writing software.

Re: What Spectre and Meltdown Mean for WebKit

#284

Post by pizlonator »

0x7f wrote: post #280
0x7f wrote: post #273

I don't understand why they say Spectre can control branching in WebKit. Spectre is an information leak attack, it doesn't allow to modify memory. I could allow to find x in `is x == valueToCheck`. But if this is possible, even before Spectre it's a security issue, it's only harder to guess, and Javascript code should not be allowed to control `x`.

I think this part is misleading => "Spectre means that an attacker can control branches, so branches alone are no longer adequate for enforcing security properties." I think they meant "Spectre means an that attacker can ABUSE branches", and in that they are right.

This is clarified later: “Spectre means that branches are no longer sufficient for enforcing the security properties of read operations in WebKit.“

It’s totally true that Spectre allows attackers to control reads, but when they do this, they enter a non-destructive execution mode. They can read but anything they write is thrown away. (To our knowledge, lol.)

Re: What Spectre and Meltdown Mean for WebKit

#285

Post by [deleted] »

pizlonator wrote: post #282
bakery2k wrote: post #193

Mitigations for Spectre and Meltdown are also being added to the JavaScript VMs in Chrome [1], Firefox [2] and IE/Edge [3]. Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? What about the JVM and Microsoft's CLR? Or are these other VMs not susceptible to this form of attack? [1] https://www.chromium.org/Home/chromium-security/ssca [2] https://b…

> Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? Yes. > What about the JVM and Microsoft's CLR? Yes.

[deleted]

Re: What Spectre and Meltdown Mean for WebKit

#286

Post by bakery2k »

pizlonator wrote: post #282
bakery2k wrote: post #193

Mitigations for Spectre and Meltdown are also being added to the JavaScript VMs in Chrome [1], Firefox [2] and IE/Edge [3]. Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? What about the JVM and Microsoft's CLR? Or are these other VMs not susceptible to this form of attack? [1] https://www.chromium.org/Home/chromium-security/ssca [2] https://b…

> Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? Yes. > What about the JVM and Microsoft's CLR? Yes.

Thanks. I suspected as much for LuaJIT because, like a JavaScript engine, it supports JIT compilation of untrusted code. It's interesting to hear that PUC Lua also needs these mitigations even though it's only an interpreter.

As for implementations of Python and Ruby, they might not worry about these attacks - because AFAIK they do not try to support secure execution of untrusted code.

Re: What Spectre and Meltdown Mean for WebKit

#287

Post by flukus »

EgoIncarnate wrote: post #270
madez wrote: post #267

Earlier quoted context omitted.

> Embedding hundreds of iframes into existing pages isn't a viable solution. I know I'm repeating myself, but then let's standardize a better way to solve the problem without executing supplied code. JavaScript is not a magic bullet that solves problems that aren't solveable otherwise.

You'll have to come up with proof of a better alternative before you'll get agreement from people like me. Javascript and sandboxed executable code may not be a magic bullet, but it's the bullet we have. "Lets standardize a better way" doesn't give much to talk about if I don't buy into the issues you have with Javascript and executable code. If you could give a compelling example of a better way that gives the same…

Let's stick with the reddit example. The up/down vote links could be standard anchors with additional tags ^. Inline posting could be similar.

It doesn't take much to do 99% of what we want with javascript and server side rendering, we used hacks to do it before javascript so I'm sure we could design something even better. It doesn't sacrifice anything.

Re: What Spectre and Meltdown Mean for WebKit

#288

Post by username223 »

pjmlp wrote: post #86
username223 wrote: post #28

Earlier quoted context omitted.

> The web by and large requires javascript, and it's not likely to change. While I am mostly a pessimist, this is one place where I harbor a tiny sliver of optimism. Once users recognize that something is awful, and have the means to get rid of it, they eventually do so. Client side Java and Flash are dead, because everyday users figured out that they sucked, and were given the option not to use them. We're getting c…

> Client side Java and Flash are dead Not paying attention to the news? Just wait until WebAssembly gets more mature.

> Not paying attention to the news? Just wait until WebAssembly gets more mature.

Not yet. If "WebAssembly" is anything like actual machine code, then it will be easy to compile a bunch of languages to "WebAssembly," and a huge pain to make them talk to each other. So nothing really changes.

Re: What Spectre and Meltdown Mean for WebKit

#289

Post by vog »

UncleEntity wrote: post #216
vog wrote: post #154

Earlier quoted context omitted.

I'm just saying that in general, the incentive for a scientist to put work into an open system is orders of magnitude higher than to put work into a closed system. To provide a similar example: The crypto experts around Daniel J. Berstein and Tanja Lange stated publicly at 34C3 that they refused to perform crypto analysis on a certain algorithm that was patented. But they (and others) published good crypto analysis r…

> I'm just saying that in general, the incentive for a scientist to put work into an open system is orders of magnitude higher than to put work into a closed system. They already do that, I'm sure you can find a multitude of papers on branch prediction and speculative execution if you simply took the time to look. Probably even some by the very same people who designed the Intel chips causing all the fuss.

Please refrain from strawman arguments.

Nobody said there is no research, just that openness would lead to more research. Even "a multitude of papers" was obviously not enough to catch this earlier.

On top of that, please refrain from personal attacks.

Re: What Spectre and Meltdown Mean for WebKit

#290

Post by iainmerrick »

andrewmcwatters wrote: post #281
iainmerrick wrote: post #219

Earlier quoted context omitted.

What's an example scenario where you need an ultra-high-resolution timer? For WebGL, don't you just rely on requestAnimationFrame to call you at the right times, and draw your frame as quickly as possible? What's the benefit of being able to measure the frame time to the nearest microsecond, rather than the nearest millisecond?

Timing behavior in literally any game.

Does the timer need to be much higher resolution than the frame rate? If so, why?

Maybe you want to measure the frame rate precisely? That is certainly something you can do, but not usually something you need to do.

Post reply on HN