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

61–70 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#61

Post by pizlonator »

rcthompson wrote: post #52
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…

Doesn't Rust do all its type checking at compile time, not run-time? (Not to say that a correctly-written Rust program wouldn't be vulnerable to Spectre for other reasons, of course.)

Rust has algebraic types, so Spectre could be used to train the branch predictor to take one type case of your match statement, and then have that case taken when the enum is actually in a different shape. That's a violation of the type system.

Re: What Spectre and Meltdown Mean for WebKit

#62

Post by pizlonator »

FreeFull wrote: post #56
rcthompson wrote: post #52

Earlier quoted context omitted.

Doesn't Rust do all its type checking at compile time, not run-time? (Not to say that a correctly-written Rust program wouldn't be vulnerable to Spectre for other reasons, of course.)

If I'm reading this correctly, the issue isn't with the types of the language you wrote the Javascript engine in, but with Javascript's types. All major Javascript engines are written in C++, which also does all its type checking at compile-time.

Not quite. Our C++ code often does static_cast as a downcast based on testing some condition. That's a run-time type check. This isn't solely about those type checks that were implemented using some built-into-the-language type checking mechanism. Also, C++ does have a dynamic type check primitive (dynamic_cast).

We are mitigating these branch-based type checks with pointer poisoning, and I don't think that those changes are biased in favor of C++ or JS, since both are vulnerable.

Re: What Spectre and Meltdown Mean for WebKit

#63

Post by pizlonator »

80x25 wrote: post #44

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

Maybe more than half. ;-)

I think that the branch aspect of Spectre is the thing that WebKit is most affected by.

Re: What Spectre and Meltdown Mean for WebKit

#64

Post by megablast »

6nf wrote: post #43
josephg wrote: post #42

Earlier quoted context omitted.

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?

With a shared cache.

Re: What Spectre and Meltdown Mean for WebKit

#65

Post by abecedarius »

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?

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.

Re: What Spectre and Meltdown Mean for WebKit

#66

Post by politician »

6nf wrote: post #43
josephg wrote: post #42

Earlier quoted context omitted.

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?

Yes, well, close.

> Since the 2010 Westmere microarchitecture Intel 64 processors also support 12-bit "process-context identifiers" (PCIDs), which allow retaining TLB entries for multiple linear-address spaces, with only those that match the current PCID being used for address translation.[19][20]

https://en.wikipedia.org/wiki/Translation_lookaside_buffer#P...

HN discussion: https://news.ycombinator.com/item?id=16094349

Re: What Spectre and Meltdown Mean for WebKit

#67

Post by pizlonator »

kibwen wrote: post #57
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…

I'm actually not sure what that passage is trying to imply at all, I've not seen any prior remarks that Spectre has that sort of implication. AIUI, Spectre lets you read arbitrary memory, not write it, so I'm not sure what they mean by "bypass the type check" and "craft arbitrary pointer". Here's another quote later on: > But Spectre could theoretically involve any branch that enforces security properties, like the b…

It's common for C++ code to do type checking dynamically. In WebKit we do this by rolling the type checks ourselves. With RTTI, you can do dynamic type checks using the build-in dynamic_cast primitive. Our changes, particularly the ones having to do with pointer poisoning, are meant to protect C++ code that does dynamic type checks in addition to JIT'd JS code that does dynamic type checks.

Rust's `match` statement is a dynamic type check just like C++'s `dynamic_cast`. I bet you it's implemented using branches.

Re: What Spectre and Meltdown Mean for WebKit

#68

Post by EgoIncarnate »

80x25 wrote: post #44

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

I don't think anyone is claiming this is solved. Mitigations are by definition a half measure. "Mitigate (verb): make less severe, serious, or painful."

Re: What Spectre and Meltdown Mean for WebKit

#69

Post by estebank »

abecedarius wrote: post #65
josephg wrote: post #42

Earlier quoted context omitted.

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?

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)

Re: What Spectre and Meltdown Mean for WebKit

#70

Post by vardump »

politician wrote: post #66
6nf wrote: post #43

Earlier quoted context omitted.

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?

Yes, well, close. > Since the 2010 Westmere microarchitecture Intel 64 processors also support 12-bit "process-context identifiers" (PCIDs), which allow retaining TLB entries for multiple linear-address spaces, with only those that match the current PCID being used for address translation.[19][20] https://en.wikipedia.org/wiki/Translation_lookaside_buffer#P... HN discussion: https://news.ycombinator.com/item?id=16094…

That's just Meltdown workaround.

Spectre was more relevant to context.

Post reply on HN