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

41–50 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#41

Post by pizlonator »

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.

Re: What Spectre and Meltdown Mean for WebKit

#42

Post by josephg »

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…

Something I keep coming back to in all this is that maybe we should be surprised that it’s even possible to share a CPU between mutually untrusted programs, let alone do it in so many contexts.

How do we stop his entire class of bugs? What is the Rust for CPU design?

Re: What Spectre and Meltdown Mean for WebKit

#43

Post by 6nf »

josephg wrote: post #42
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…

Something I keep coming back to in all this is that maybe we should be surprised that it’s even possible to share a CPU between mutually untrusted programs, let alone do it in so many contexts. How do we stop his entire class of bugs? What is the Rust for CPU design?

CPUs tend to have multiple cores these days, would it be possible to assign (in software) all kernal space work to one or more dedicated cores to mitigate some of the risks?

Re: What Spectre and Meltdown Mean for WebKit

#44

Post by 80x25 »

These mitigations feel like a half measure. To quote the Spectre paper:

"Even code that contains no conditional branches can potentially be at risk."

"long-term solutions will require that instruction set architectures be updated to include clear guidance about the security properties of the processor, and CPU implementations will need to be updated to conform."

It seems too early to declare Spectre class attacks mitigated by the mechanisms presented in the OP.

Re: What Spectre and Meltdown Mean for WebKit

#45

Post by lower »

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…

Note that the article talks about type checks for the JavaScript code that is being executed by WebKit, not type checks in the implementation of WebKit itself. So there are two different kinds of type checks involved here.

Re: What Spectre and Meltdown Mean for WebKit

#46

Post by pizlonator »

lower wrote: post #45
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…

Note that the article talks about type checks for the JavaScript code that is being executed by WebKit, not type checks in the implementation of WebKit itself. So there are two different kinds of type checks involved here.

We are using pointer poisoning to protect type checks in WebKit itself as well as type checks in the JavaScript code we execute.

We are using index masking in WTF::Vector and WTF::StringImpl, which are used both for JavaScript execution and for lots of other things in WebKit that want a vector or a string.

Re: What Spectre and Meltdown Mean for WebKit

#47

Post by madez »

EgoIncarnate wrote: post #38
madez wrote: post #29

Earlier quoted context omitted.

> Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change. This fatalist stance is childish, and dangerous. As long as there are people working to make things better, things do improve. Sure, if you make sure that one small website works without JavaScript then that doesn't change the world. I hear a similiar argument when I explain why I don't eat…

>> Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change. >This fatalist stance is childish, and dangerous. As long as there are people working to make things better, things do improve. How is it any more of a fatalist stance than the idea that javascript or running untrusted code in a sandbox is fundamentally broken? Personally I think it's easi…

> Personally I think it's easier and more likely that we attempt to fix a few web browsers than expect a millions of websites to change.

This is the same argument I criticized before. The world doesn't change completely over night because one changes their own actions, and that is fine. These million websites maybe never change, and that's what we'd have to live with.

Re: What Spectre and Meltdown Mean for WebKit

#49

Post by indexerror »

eridius wrote: post #48

I'm really curious how SharedArrayBuffer can be used to create high-precision timers. I'm also wondering what's now broken due to SharedArrayBuffer being removed.

From page 10-11 of [1]:

> A shared resource provides a way to build a real counting thread with a negligible overhead compared to a message passing approach. This already raised concerns with respect to the creation of a high-resolution clock [19]. In this method, one worker continuously increments the value of the buffer without checking for any events on the event queue. The main thread simply reads the current value from the shared buffer and uses it as a high-resolution timestamp.

[1] https://gruss.cc/files/fantastictimers.pdf

Post reply on HN