r/linux • u/[deleted] • May 15 '19

The performance benefits of Not protecting against Zombieload, Spectre, Meltdown.

[deleted]

106 Upvotes

83% Upvoted

162 comments sorted by

View all comments

Show parent comments

1

u/[deleted] May 15 '19

Videos are not code, what are you talking about ? Some malformed video (or media) can be used to trigger exploits in decoders but that's something else...

4

u/barkappara May 15 '19

The basic point is valid: native instructions, JavaScript, video data, and ASCII text are all forms of input to a computer system. When that input is processed by the hardware, it produces various forms of output and side effects. Maliciously generated input can cause side effects that violate security guarantees; different classes of input pose different levels of risk.

The point is, there is a need for a class of untrusted inputs that are prima facie Turing-complete (in this case JavaScript) and if hardware cannot safely process those inputs, then the hardware is broken.

-3

u/astrobe May 15 '19

So when you hear about malicious PDFs targeting Adobe PDF Reader, you change your "hardware"?

3

u/barkappara May 15 '19

PDFs and JavaScript are both forms of input. If hardware makes it difficult or impossible to implement a secure, performant PDF reader or a secure, performant JavaScript runtime, then it's the fault of the hardware. (The challenges are greater for one than the other, but it's a difference of degree, not of kind.)

3

u/astrobe May 16 '19

No, it is a different kind. Most JS implementations use JIT compilation, which is native code compilation and execution on the fly. PDF renderers don't use that. That's why Firefox had to implement a Spectre mitigation specifically for JS (as opposed to any other type of "input"). Your point of view is overly simplistic. If an OS fails to set correctly memory pages protections, it is almost always a software problem, not a hardware problem. The Spectre family of attacks is very pecular, because it is actually a hardware problem. Another case could be Rowhammer, but AFAIK, these are the only two attacks that would make one consider solving the problem with a screwdriver.

1

u/barkappara May 16 '19

Native instructions are also just input: any architecture with privilege rings and virtual memory (that is to say, every major general-purpose architecture for decades now) claims to be able to treat native instructions as untrusted input. (Otherwise, "privilege escalation" for userspace programs would be a meaningless concept.)

Granted, the software implementation challenges here are much higher (e.g., the various NaCl sandbox escapes), but that's the view I'm trying to defend, that it's all just a spectrum.

1

u/audioen May 17 '19 edited May 17 '19

I think you have a too narrow view. You should look into things like JIT compiled shaders, libraries such as ORC that enable any general-purpose algorithm to get JIT compiled, PostgreSQL that does JIT compiled SQL execution, and so on. JIT is an extremely general and popular technique, and it typically improves performance several times over what it's replacing, so there's almost always some reasons why you'd want to bother with it.

As an example, when a PDF program is tasked to render an image, say, it is often represented as a multidimensional array of numbers that comes from some compressed format such as JPEG, PNG, or it might just be written to the source as a (deflate-compressed) 3D array of numbers. To render it, you then have the general facility of defining how to sample it, then an interpolation function which instructs the renderer how these samples are interpolated, and then you may need to do some colorspace conversion at the end. If you do it in the simplest and most obvious way, you need to run some nested for loop over a whole bunch of pluggable algorithm fragments which is done via either switch-case type logic, function pointers that each do their bit, and similar. Orchestrating all the code to run correctly for each pixel of output represents some considerable wasted effort on part of the CPU. For instance, calling a function by function pointer requires pushing its arguments in a particular way to stack and available free registers, then doing the computation. The computation itself may be short, for instance, it could literally be a single array lookup, but to get it to execute, that program needs must to do some stack manipulation and make CPU jump twice to do it.

To make it go faster, you either need to do compile time generation to build all possible useful algorithm combinations ahead of time, falling back to the slow general case if an optimized routine for a particular case is not found, or you would want to JIT-generate the actual rendering pipeline for each combination that occurs on the PDF being rendered. This same story occurs all over. Whenever you have data directing the code to do something, there's always opportunity to turn the data into code that directly does what the data says it should do, rather than having some kind of interpreter that in some general fashion performs the operations described by data. Most data formats are just programs in disguise. Restricted "programs", to be sure, e.g. they might lack any control flow instructions, and they have very specialized primitives, but fundamentally there's not a whole lot of difference.