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

71–80 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#71

Post by vasili111 »

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 really starting to think it's about time for me to get out of this business.

Maybe it is time to move to IT security business?

Re: What Spectre and Meltdown Mean for WebKit

#72

Post by rickycook »

bradgessler wrote: post #36

One of the most brilliant features in the latest versions of Safari are per-website settings for ad blockers, notifications, location, etc. Between those two vulnerabilities and the general obnoxious useage of JS on websites, I’d love to see the addition of a per-website setting for JS. I would personally turn it off by default and only whitelist a handful of websites.

similar to noscript, there’s “JS Blocker” for Safari. it’s truly an excellent extension; significantly more powerful than noscript because it allows hugely customisable rules for loading only some scripts on some pages (eg https and *.cloudfront.com when loading console.aws.amazon.com), rules about canvas usage, XHR requests and a whole lot of other things. it’s the honestly the only reason i haven’t moved back to firefox, because by comparison noscript is just SO awful!

http://jsblocker.toggleable.com/home

Re: What Spectre and Meltdown Mean for WebKit

#73

Post by jurip »

js2 wrote: post #23
hamandcheese wrote: post #20

Earlier quoted context omitted.

This doesn’t explain why they kept Safari at the same version number.

Oh you're right. Specifically, they kept the CFBundleShortVersionString the same, but updated the CFBundleVersion. My guess is that updating CFBundleShortVersionString is a marketing decision. Maybe Apple is waiting till all the WebKit fixes related to Spectre/Meltdown are available before updating it?

Also various Apple systems define CFBundleShortVersionString to be of the format A.B.C, no fourth element allowed. macOS versioning is still stuck with 10 as the A, B identifies the major release and C is the point release that is effectively also marketing driven. With iOS the first number is used for the major releases so C is available for bug fixes.

Re: What Spectre and Meltdown Mean for WebKit

#74

Post by mkeblx »

bsimpson wrote: post #59
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?

It's surprising to me that there are such various levels of coarseness each browser vendor chose: Gecko [0]: accurate to 20us Edge [1]: accurate to 20us, with an additional 20us of noise Chrome [2]: accurate to 100us (thanks mkeblx for finding this) Safari [OP]: accurate to 1000us [0] https://blog.mozilla.org/security/2018/01/03/mitigations-lan... [1] https://blogs.windows.com/msedgedev/2018/01/03/speculative-e... [2…

Chrome is 100us: https://chromium-review.googlesource.com/c/chromium/src/+/85...

Re: What Spectre and Meltdown Mean for WebKit

#75

Post by roca »

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…

Interestingly you could apply these mitigations in Rust itself --- array index masking where Rust has array bounds checks, and pointer obfuscation where you check the variant tags of algebraic types. Some extra work would be required for unsafe Rust code. That would automatically protect almost all Rust code, whereas most C and C++ code would have to be handled manually.

Re: What Spectre and Meltdown Mean for WebKit

#76

Post by abritinthebay »

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)

It was painful - mostly because we don't have good tools for that sort of thing and most of our programming sort of hides the idea of multiple CPUs and pretends it's all working at once (in terms of us writing the code anyhow).

It's all abstracted in a very linear way.

Changing all that will take a lot of time if we do.

Re: What Spectre and Meltdown Mean for WebKit

#77

Post by roca »

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 = ... get someProperty ...
    x = bigArray[index];
  } else {
    ... error ...
  }
and speculative execution could let the property value leak into the cache.

So I'm not optimistic about the prospects for fully automating defenses against Spectre without hardware fixes :-(.

Re: What Spectre and Meltdown Mean for WebKit

#78

Post by eecc »

frik wrote: post #55
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?

Yes, we need a many-core CPU. Then every program can run on a core. And we can use MPI, CILK, etc to run parallel programs. Each CPU could run its own small operating system, or using a micro kernel OS. Writing algorithms in parallel manner isn't as complicated as make to believe you, a lot can be rewritten based on cookbooks/patterns. Intel developed a many-core CPU (72 CPU cores) called Xeon Phi: https://en.wikiped…

Well, Meltdown mitigation involves unmapping as much Kernel as possible when switching modes. It’s so much overhead that I wonder if uK messaging and process context switching is cheaper and faster.

Re: What Spectre and Meltdown Mean for WebKit

#79

Post by kibwen »

pizlonator wrote: post #67
kibwen wrote: post #57

Earlier quoted context omitted.

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

> Rust's `match` statement is a dynamic type check just like C++'s `dynamic_cast`.

I wonder if this is a case of a difference in terminology, because enum variants (the branches in `match` expressions) aren't considered types in Rust, and have no interaction with Rust's typechecker (Rust always has to assume that every instance of an enum can be any variant, even in cases where we as the programmer know that only one variant is possible).

At the same time I'm still unclear on what the OP is trying to imply. To reiterate, AIUI Spectre can only read, not write, privileged memory, so it's impossible for a Spectre attack to trick the engine into believing that (to use Rust terminology) an instance of an enum is a variant that it isn't. Am I incorrect?

Re: What Spectre and Meltdown Mean for WebKit

#80

Post by techdragon »

pizlonator wrote: post #67
kibwen wrote: post #57

Earlier quoted context omitted.

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

Serious question, is it even possible to have something like ‘match’ or ‘dynamic_cast’ in a programming language without using branches under the hood?

I’m not talking about research/example microprocessors that don’t have equivalent instructions. I mean isn’t branching a fundamental logical construct and we either do it in hardware with branch assembly operations or emulate functional equivalents of them in the software that runs on the microprocessor some other way? Or is there some clever/old logical/mathematical “alternative” to branches?

Post reply on HN