What Spectre and Meltdown Mean for WebKit

Post by cerved » Tue, Jan 09, 2018, 7:08 AM UTC

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…

Post by cerved » Tue, Jan 09, 2018, 7:13 AM UTC

techdragon wrote: post #80

pizlonator wrote: post #67

Earlier quoted context omitted.

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

Post by pjmlp » Tue, Jan 09, 2018, 7:20 AM UTC

EgoIncarnate wrote: post #24

username223 wrote: post #5

> WebKit is affected because in order to render modern web sites, any web JavaScript engine must allow untrusted JavaScript code to run on the user’s processor... WebKit is affected by both issues because WebKit allows untrusted code to run on users’ processors. There's the elephant in the room, though this article doesn't go far enough. Trust isn't binary. It's not that the code isn't formally verified, or doesn't t…

Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change anytime soon. So we are stuck with the situation where the defenders (the hardware and software designers) have to be correct 100% of the time on a platform that is constantly changing. The attackers only need to be right once. Maybe someday everything will just be streaming video or something…

Post by earenndil » Tue, Jan 09, 2018, 7:46 AM UTC

techdragon wrote: post #80

pizlonator wrote: post #67

Earlier quoted context omitted.

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

    struct __internal_variable {
        uint64_t type;
        void *data;
    }
    
    uint64_t __last_type = [number of builtin types];
    
    whenever you create a new type: increment __last_type and associate that type with the number;

    uint64_t typeof(__internal_variable var) {
        return var.type;
    }
    
    function[__last_type] typechecks;
    functions[] = void function(uint64_t type) { failure; }
    functions[int] = void function(uint64_t type) { success; }

    functions[typeof(myvar)]()

Post by flohofwoe » Tue, Jan 09, 2018, 7:53 AM UTC

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?