What Spectre and Meltdown Mean for WebKit • Hacker News Board

Re: What Spectre and Meltdown Mean for WebKit

#101

Post by dingo_bat » Tue, Jan 09, 2018, 8:49 AM UTC

WillReplyfFood wrote: post #99

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…

Translated this basically means- for real security to exist, the chip has to be open source down to the layout. This will not happen. So basically, the interest of the one outweighing the interests of the many, results in the many suffering for what exactly?

> open source down to the layout.

I don't see what open source has got to do with any of this.

Re: What Spectre and Meltdown Mean for WebKit

#102

Post by cm2187 » Tue, Jan 09, 2018, 8:49 AM UTC

epenance wrote: post #98

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

Websites are only bloated because of the MB of javascript to make them applications (images do not count as they need to be rendered either way and can be cached). Most of the websites I visit every day don’t display that much content. Once gzipped it's a tiny file.

Re: What Spectre and Meltdown Mean for WebKit

#103

Post by petascale » Tue, Jan 09, 2018, 8:50 AM UTC

kibwen wrote: post #79

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…

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

Hypothetical example pseudocode:

    if is_pointer(pt):
        // do pointer-based stuff
    else:
        raise error

If you train the branch predictor to expect a pointer, it will speculatively treat arbitrary values as pointers until it can determine that they are not. So you can pass in any value and get it treated like a pointer for the duration of the window of speculative execution.

Any conditional branch is potentially vulnerable, an attacker just needs some sort of side effect from speculative execution that persists after rollback.

Re: What Spectre and Meltdown Mean for WebKit

#104

Post by EgoIncarnate » Tue, Jan 09, 2018, 8:51 AM UTC

jpttsn wrote: post #93

EgoIncarnate wrote: post #24

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

Not sure it’s a genie situation. Look at Java applets, Flash player.

The situation is apples and oranges.

Dumping Flash and Java took years, and was driven by rapid adoption of mobile devices that either didn't support them at all (Apple) or very well (everyone else). There was an already deployed alternative (Javascript).

Javascript is buried much deeper in modern websites and would be much more difficult to replace than either Flash or Java Applets were for most sites. For most sites Flash was just to play videos or display ads. Many sites only had to replace an object tag with a video tag. Java Applets were fairly niche in the first place, so aren't really comparable.

In addition there isn't currently a viable alternative for Javascript. Maybe WebAssembly someday, but currently it's designed to supplement Javascript not replace it.

Re: What Spectre and Meltdown Mean for WebKit

#105

Post by iovrthoughtthis » Tue, Jan 09, 2018, 8:51 AM UTC

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…

running untrusted code is a fundamental part of our daily experience.

If you kill the webs ability to do that, people will build something else.

The we have to go through the rigmarole of securing this whole new platform with the same bugs but in different ways.

Instead of neutering the web, let's build secure cpus.

Re: What Spectre and Meltdown Mean for WebKit

#106

Post by gpderetta » Tue, Jan 09, 2018, 8:52 AM UTC

earenndil wrote: post #87

techdragon wrote: post #80

Earlier quoted context omitted.

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…

Consider something like this: 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(uint…

That's basically a jump table. Still vulnerable to spectre (variant 2) without mitigations, btw.

Re: What Spectre and Meltdown Mean for WebKit

#107

Post by stesch » Tue, Jan 09, 2018, 8:53 AM UTC

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…

It's too late.

For many years (decades?) I got downvoted (here and on Reddit) for mentioning that I used NoScript. I even disabled JavaScript completely on Netscape Navigator.

It was in the context of sites that were unusable without JavaScript or security problems that only affected JavaScript in browsers.

Re: What Spectre and Meltdown Mean for WebKit

#108

Post by gpderetta » Tue, Jan 09, 2018, 8:54 AM UTC

megablast wrote: post #64

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?

With a shared cache.

Some of the newer Intel server CPUs allow statically partitioning the shared L3 cache between cores. It might (or not) work as a way to reduce side channel communications between cores.

Re: What Spectre and Meltdown Mean for WebKit

#109

Post by JohnStrange » Tue, Jan 09, 2018, 8:55 AM UTC

epenance wrote: post #98

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

You mean those eternally scrolling pages whose main purpose is to hide content that belongs to the user in the first place? These sites are a pest.

Re: What Spectre and Meltdown Mean for WebKit

#110

Post by gpderetta » Tue, Jan 09, 2018, 8:57 AM UTC

abritinthebay wrote: post #76

estebank wrote: post #69

Earlier quoted context omitted.

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.

Actually multiple CPUs are not normally hidden in mainstream programming languages [1]: i.e. threads are visible. The fiction that it is maintained by the programming languages and hardware is that of a single, coherent address space, which Cell very much did not have.

[1] outside of parallel iteration/folding constructs.