What Spectre and Meltdown Mean for WebKit • Hacker News Board

Re: What Spectre and Meltdown Mean for WebKit

#211

Post by Matt3o12_ » Tue, Jan 09, 2018, 1:41 PM UTC

UncleEntity wrote: post #206

krapp wrote: post #167

Earlier quoted context omitted.

> I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages, or not allow anyone to program a GUI unless they can justify the use of canvas space. Yet the web, arguably the most successful and free (as in both beer and freedom) and access…

> ...say that code should be a considered a privilege and not a right, or that it doesn't really belong on the web at all, despite javascript being on the web for ~20 years now. Same could be said about advertising and I'm infringing on all these innocent corporations' natural rights by running an adblocker. For random code to run on my machine a few (IMHO reasonable) steps need to happen: 1) somehow entice me to cli…

Be aware that Adblock doesn’t block all JavaScript code. It blocks code after people have identified that code X run on website Y does something bad (tracking, ads, etc) and they decided to block it. This works well for visible ads because people see them. For tracking scripts, it still happens because most of them have obvious giveaways (come from a different domain, etc) but chances are that you still run random code because it is better hidden (comes from the same domain and does nothing obvious bad). Just because you use Adblock, malicious code will still be able to run. You are just less likely to notice it because it does nothing obvious so people don’t notice it as quickly and it will not get blocked. If you don’t want to run malicious code at all unless you trust this website, you should probably consider running NoScript.

Re: What Spectre and Meltdown Mean for WebKit

#212

Post by UncleEntity » Tue, Jan 09, 2018, 1:42 PM UTC

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…

> Or are these other VMs not susceptible to this form of attack?

I think the main difference is all the other dynamic languages don't let someone do a driveby attack, you have to download the code and run it as opposed to clicking a link and having who knows what appear.

Re: What Spectre and Meltdown Mean for WebKit

#213

Post by alien_at_work » Tue, Jan 09, 2018, 1:44 PM UTC

send_computers wrote: post #130

xtanx wrote: post #127

Earlier quoted context omitted.

The statement "a better experience" is debatable. I cannot remember how many times I have visited SPA websites that break the browser url history. Also, if a SPA fails to load a request for any reason, try reloading it. Ops you start over. And I am not talking about some people that don't know what they are doing. At times I've had issues with Google's new developer console, gsuite admin, analytics, product hunt and…

These are all examples of bugs or badly designed/coded applications. Don't blame JS for bad coding...

Nonsense. Bad tools are bad tools as evidenced by the fact that literally no one can use properly at scale.

Evangelists of bad technologies always like to trott out the nonsense about "a good carpenter never blames their tools"... well of course they don't: they buy the tools and always buy the appropriate ones. Further, if they did complain the customer would wonder why they bought bad tools in the first place.

A carpenter would never try to build a building with a "JavaScript" equivalent in the first place. They recognize the tool as garbage (perhaps after trying, and failing, to use it) and switch to something more appropriate.

Re: What Spectre and Meltdown Mean for WebKit

#214

Post by krapp » Tue, Jan 09, 2018, 1:45 PM UTC

madez wrote: post #204

krapp wrote: post #200

Earlier quoted context omitted.

What benefit would there be to doing that? If the functionality remains the same, you've just transferred Turing completeness somewhere else. I can see the benefit to having languages other than javascript run in the browser, though, but the only way there seems to be WebAssembly.

The advantage of not supporting programming languages in the browser from content that comes from servers is that one doesn't accidentally fall into that trap. The functionality in my browser is important. The more the browser is scriptable, the better, but not from the website. The code on my machine is reviewed, vetted, accounted, maintained and free. That is the big difference.

So you're advocating site developers add elements to their HTML which browser plugins then execute like a scripting language? I may not entirely understand what you're proposing.

If the end result is the same functionality as was being provided by javascript, then if you didn't trust the javascript, you can't trust the (now Turing complete) HTML. The same trust and verification issues exist, just moved to another level of abstraction.

>The code on my machine is reviewed, vetted, accounted, maintained and free. That is the big difference.

Is it? By whom? Not by you personally, not all of it. Blind trust is unavoidable at some point.

Re: What Spectre and Meltdown Mean for WebKit

#215

Post by iainmerrick » Tue, Jan 09, 2018, 1:45 PM UTC

xtanx wrote: post #196

krapp wrote: post #167

Earlier quoted context omitted.

> I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages, or not allow anyone to program a GUI unless they can justify the use of canvas space. Yet the web, arguably the most successful and free (as in both beer and freedom) and access…

> no one is saying we should deactivate native apps written in unsafe languages No we should definitely not, but we should encourage using something like rust or whatever comes after rust.

The language is a red herring here.

Javascript is a safe language, but it's powerful enough to exploit Spectre and Meltdown. Rust would be the same. It's not badly-written programs we need to worry about in this context, it's well-written malicious programs exploiting badly-designed hardware.

We don't need apps written in safe programming languages to fix this problem, we need secure browsers, OSes and hardware. (And yes, those bits should be written in safe languages.)

Re: What Spectre and Meltdown Mean for WebKit

#216

Post by UncleEntity » Tue, Jan 09, 2018, 1:48 PM UTC

vog wrote: post #154

dingo_bat wrote: post #126

Earlier quoted context omitted.

But these attacks (Meltdown/Spectre) are on a fundamental design approach, which was conceived and developed and researched in the open. People in colleges all over the world study about them. Do you really think this would have been caught much sooner is Intel had released all schematics and layouts to the public?

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.

Re: What Spectre and Meltdown Mean for WebKit

#217

Post by iainmerrick » Tue, Jan 09, 2018, 1:52 PM UTC

pizlonator wrote: post #30

Game_Ender wrote: post #26

Earlier quoted context omitted.

Sorry maybe I missed something but you had some really cool techniques to avoid using branches to do things like array length checks and type checks? So you replaced an if branch with a new, potentially slower, and harder to understand concept. I was not trying to imply you removed all branches. It is a really cool piece of engineering but we can still be sad we have to implement it. (On the hardware side I was assum…

Now we are doing both bounds check branches and index masking. The index masking is purely additive. We didn't replace branches. Similarly, where we use pointer poisoning, it is in addition to some other security check, which is almost always a branch.

Also, security aside, removing (mispredicted) branches is a legitimate way to try to speed up code!

Re: What Spectre and Meltdown Mean for WebKit

#218

Post by alien_at_work » Tue, Jan 09, 2018, 1:54 PM UTC

NelsonMinar wrote: post #2

I really hate to see this rush to "make sure our code doesn't use branch prediction". It may be the best fix we have available now, but it's going to create a legacy of bizarre inefficient machine code that will last forever.

I feel the opposite. I'd like nothing better than this to be the end of branch prediciton. I can think of no other technology that's been so deterimental to high level languages than branch prediction. How many elegant, beutiful algorithms are replaced by bizarre data structures, etc., because avoiding pipeline stalls will trump any other optimization you can make.

For most things the CPU is doing, we can ignore in high level languages because the compiler/optimizer can turn our high level code into the appropriate byte code to take advantage of deep hardwar magic. Not branch prediction, though, no matter how high level my language, I still must consider pipeline size, cache alignment and so on when designing a novel new container or algorithm or risk it being inexplicitly slow.

Branch prediction is, and always was a hack. Let it die.

Re: What Spectre and Meltdown Mean for WebKit

#219

Post by iainmerrick » Tue, Jan 09, 2018, 1:55 PM UTC

flohofwoe wrote: post #89

TheCoreh wrote: post #19

Restricting performance.now()'s resolution to 1ms is really bad news :( Once the other mitigations are in place, will the webkit team consider increasing the resolution again? Can we get a Developer menu or Web Inspector option to temporarily enable the old resolution again?

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?

Re: What Spectre and Meltdown Mean for WebKit

#220

Post by iainmerrick » Tue, Jan 09, 2018, 1:57 PM UTC

_0w8t wrote: post #197

bennofs wrote: post #170

Earlier quoted context omitted.

If you combine index masking with a branch that should still be Ok. For example, if you do `if(idx > arrayLength) return undefined else array[idx & mask]` then the CPU can only predict "return undefined" or "array[idx & mask]", none of which can cause any harm.

Does that imply that WebKit always allocate by power of two and a script cannot read the memory for unrelated allocation between the array length and the nearest 2 n?

No, it means attacks are still possible in the memory region just after the buffer, when it's smaller than the next power of two. Not ideal but it's better than nothing.