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

221–230 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#221

Post by hnonlyforu »

alien_at_work wrote: post #208
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…

>Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages, That's not remotely a valid comparison. If I run a native app, I had to get that app somehow and install it. I know it can modify my computer (and probably have to give it persmission to do so). A web page can automatically load other pages, even in the background and do who knows what.…

Same thing could happen to apps. There was a Baidu app in China that secretly downloaded random videos just to eat up the users' data plan, so they will buy more data.

Re: What Spectre and Meltdown Mean for WebKit

#222

Post by iainmerrick »

pizlonator wrote: post #41
ams6110 wrote: post #34

> All type checks are also vulnerable. For example, if some type contains an integer at offset 8 while another type contains a pointer at offset 8, then an attacker could use Spectre to bypass the type check that is supposed to ensure that you can’t use the integer to craft an arbitrary pointer. So, even if WebKit were entirely written in Rust, we'd still be fucked. I'm really starting to think it's about time for me…

Right, programming-language-based security mechanisms that rely on emitting runtime checks are broken and you need something like index masking or pointer poisoning to fix them. Rust could use those fixes as well.

Why does Rust need those? Those are things you need when running untrusted code in a sandbox. Is there a scenario where Rust is used that way?

There's WASM, but in that case the extra checks need to be applied at the WASM level, not the Rust level.

Re: What Spectre and Meltdown Mean for WebKit

#223

Post by tetromino_ »

br1 wrote: post #175
om2 wrote: post #9

Earlier quoted context omitted.

The fence instruction that Intel recommends (lfence) is way slower than the techniques described here. We measured a 5x slowdown on Web Assembly trying to use it. Also we have been working on these mitigations since well before Intel made their suggestion.

Have you considered arr[max(i, arr.len)] instead of AND?

Max() is not a CPU instruction. It's an abstraction, a function that could be implemented either using a branch (which defeats the whole purpose) or, on some architectures, with something like cmovXX.

Perhaps they wanted a solution that works on Arm, which I think doesn't have cmovXX. Or maybe Intel does speculation with cmovXX used on array index.

Re: What Spectre and Meltdown Mean for WebKit

#224

Post by alien_at_work »

hnonlyforu wrote: post #221
alien_at_work wrote: post #208

Earlier quoted context omitted.

>Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages, That's not remotely a valid comparison. If I run a native app, I had to get that app somehow and install it. I know it can modify my computer (and probably have to give it persmission to do so). A web page can automatically load other pages, even in the background and do who knows what.…

Same thing could happen to apps. There was a Baidu app in China that secretly downloaded random videos just to eat up the users' data plan, so they will buy more data.

Again: we've always known that desktop apps were risky and could do anything to our computer (and for years, a lot of "free" windows software installed malware and viruses). We were always told that JavaScript is "sandboxed".

Re: What Spectre and Meltdown Mean for WebKit

#225

Post by Nursie »

krapp wrote: post #167
cm2187 wrote: post #92

I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of…

> 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…

>> Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages

This is not in any way equivalent to browsing an informational site and having arbitrary code execute.

>> Yet the web ... is the only one on which people - erstwhile hackers - say that code should be a considered a privilege and not a right,

Hell no, code execution is a privilege in all situations! I don't just download scores of random executables and run them. Do you?

>> But pretending javascript is a second-class citizen on the web isn't the answer.

Making it one might be an improvement though. There's no way in hell I should be (to give a recent example) browsing a keyboard review and notice that my laptop now sounds like an aircraft about to take off because the site is running something unidentified as fast as it can (likely a coin miner).

Re: What Spectre and Meltdown Mean for WebKit

#226

Post by tn_ »

LaGrange wrote: post #164
epenance wrote: post #98

Earlier quoted context omitted.

This is false. Many websites are using Javascript to render the websites in full to give the users a better experience, such as rendered a SPA (Single-Page-Application) to prevent unneeded amounts of data loaded on each page request and only load exactly what you need, to give a faster, smoother and higher quality experience for the user. Sure the mom down the street who wants to blog about the her kitchen recipes wo…

If you took away JS from Facebook and Twitter, they'd literally be a better experience. They'd be forced to give up much of what makes them painful to use. At least Twitter had a character counter, that was a useful JS feature, but they broke even that. And if you need a diagraming tool, maybe a website isn't the best solution.

It's that simple, huh? Why not save everyone the trouble and replace GUI's with terminals while we are at it.

Re: What Spectre and Meltdown Mean for WebKit

#227

Post by ambulancechaser »

alien_at_work wrote: post #218
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 h…

but removing branch prediction would be to restore those stalls and inefficiencies as the way things are when you don't use those strange data structures, right?

The effect of this seems to be "I wish everything was slower and then the naive implementation would be the best implementation".

Re: What Spectre and Meltdown Mean for WebKit

#228

Post by htk »

cm2187 wrote: post #92

I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of…

This whole thread became a big "throw the baby out with the bathwater". Of course there is a long way to a secure web (if that is ever achievable), but disabling javascript is just a lazy alternative, creating a lot more nuisance than whatever damage is being done via javascript lately.

OTOH the "chain of trust" idea looks promising. And increases the responsibility on the visited website, because if it wants third party content to run javascript it'll have to host it itself.

Re: What Spectre and Meltdown Mean for WebKit

#229

Post by alien_at_work »

ambulancechaser wrote: post #227
alien_at_work wrote: post #218

Earlier quoted context omitted.

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 h…

but removing branch prediction would be to restore those stalls and inefficiencies as the way things are when you don't use those strange data structures, right? The effect of this seems to be "I wish everything was slower and then the naive implementation would be the best implementation".

>restore those stalls and inefficiencies as the way things are when you don't use those strange data structures, right

No, a stall is only a thing because branch prediction exists. Get rid of it and I can go back to not caring about the deep underlying architecture of the hardware I may potentially be running on. And not doing branch prediction isn't inefficient... that's a bizare statement. Branch prediction and speculative execution are themselves inefficiencies (i.e. spending power to do things that will turn out to not be needed fairly often).

>the naive implementation would be the best implementation

Not the naive implementation. A well thought out, developed implementation that is defeated by deep hardware details. The promise of high level languages was always to avoid having to know these sorts of details. In designing an algorithm I should be worried about things like how often I access data (e.g. can I cut down on how many accesses with some clever structure?) and the like. Now that's all trumped by deeply knowing the low level implementation.

Re: What Spectre and Meltdown Mean for WebKit

#230

Post by UncleEntity »

estebank wrote: post #69
abecedarius wrote: post #65

Earlier quoted context omitted.

I always liked the https://en.wikipedia.org/wiki/J%E2%80%93Machine idea: gobs of processors each with a small private memory (nothing shared), in a fast mesh network. It fits with physics: accessing local memory can be fast, while distant memory physically just can't. But even if it's really all that, it's just so different from the architectures we've put so much work into or on top of.

That sounds like a more extreme version of what the Cell[1] was supposed to be. Developers seemed to think that developing for that architecture was really painful, specially compared to other contemporary console platforms. I'd love it if the progress being made in the industry got us to actually being able to exploit the full potential of such architectures. [1]: https://en.wikipedia.org/wiki/Cell_(microprocessor)

> I'd love it if the progress being made in the industry got us to actually being able to exploit the full potential of such architectures.

If they had ever released it as a general purpose computer instead of a locked down game console people could've experimented with it enough to unlock its full potential.

If they were smart they'd dust off the old chips, throw them on a RasberryPi type system and laugh all the way to the bank.

Post reply on HN