Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLVM patch to fix half of Spectre attack

reviews.llvm.org

Post reply on HN
Print view View original

121–130 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#121

Post by jopsen »

leeoniya wrote: post #82
tptacek wrote: post #17

Page was down when I tried to read it, but it's archived here: http://archive.is/s831k . Its hard to get your head around how big a deal this is. This vulnerability is so bad they killed x86 indirect jump instructions. It's so bad compilers --- all of them --- have to know about this bug, and use an incantation that hacks ret like an exploit developer would. It's so bad that to restore the original performance of a p…

i know this came out as a leak, but makes one wonder how "responsible" even a Jan 9 official announcement would have been. the scope is absolutely terrifying. this bug will be exploitable for a very long time.

They had like 6 months or so... how is more time going to make things less painful?

Re: LLVM patch to fix half of Spectre attack

#122

Post by tptacek »

gpm wrote: post #89
tlrobinson wrote: post #79

Earlier quoted context omitted.

Isn't that a bit like a firefighter saying your house burning down is "glorious"?

To the extent that he exploits computers for a living (e.g. pentesting) and not stops exploits for a living, it seems more like a (presumably law-abiding) arsonist calling houses burning glorious.

Arsonists set fires. Vendors create vulnerabilities, not pentesters.

Re: LLVM patch to fix half of Spectre attack

#123

Post by tptacek »

bouk wrote: post #48
rayiner wrote: post #36

Earlier quoted context omitted.

Is glorious the right word for it? We’re going back to the stone ages where processors couldn’t predict the targets of indirect jumps. More generally, this seems to me like an attempt to patch out of what is really a class of attacks leveraging fundamental assumptions about high-performance CPU design. Before, OOO just had to preserve correctness and (some of) the order of exceptions and memory operations. Now, it ha…

tptacek exploits computers for a living, so it's glorious for him :)

It's not that it makes the practice of breaking into computers that much more interesting so much as it makes the underlying field much more interesting to work in. The engineering problems just got a lot more complex. We're all taking an attack vector seriously --- microarchitectural side channels --- that we weren't taking as seriously before, except as an abstract threat to crypto and a way of defeating a mitigation --- KASLR --- that nobody believed in anyways.

What's glorious is that serious software security people now have to start being literate about what it means to reverse engineer and dump the branch history buffers on different CPUs. Getting dragged through this kind of minutiae is the reason I'm still in this field after 22 years.

And I'm just a bystander here. Imagine what it must have been like for Jann Horn over the last several months!

This subsection describes how we reverse-engineered the internals of the Haswell branch predictor. Some of this is written down from memory, since we didn't keep a detailed record of what we were doing.

... because shit was so crazy while they were working this out that they didn't have the cycles to write everything down!

Re: LLVM patch to fix half of Spectre attack

#124

Post by smt88 »

dingo_bat wrote: post #96
Klathmon wrote: post #47

Earlier quoted context omitted.

I'm not more knowledgeable than you, but I think I agree. side channels have always been some of the most insidious exploits. Many are basically un-solvable (timing attacks are always going to leak some information, and compression is basically completely at odds with secure information storage), many more are easily enough overlooked that it would be easy to maliciously include them without raising any eyebrows, and…

How about not running untrusted code? That seems to be much easier to do and won't kill performance. Kill js on the web. Run only apps signed by Microsoft. Develop ML based malware fingerprinting that can recognise timing attack patterns. Throwing OO execution away shouldn't be an option in the long term.

"Kill JS on the web" is easy and only mildly inconvenient using NoScript, but that doesn't mean most laypeople are going to do it.

Chrome and FF need "execute JS" to be an explicit per-site permission, similar to the permissions model of native smartphone apps.

Google will never do this because they're an ad company and care more about targeting ads than protecting Chrome users.

Re: LLVM patch to fix half of Spectre attack

#125

Post by acdha »

gmueckl wrote: post #120
panarky wrote: post #106

Earlier quoted context omitted.

> on any non-shared non-virtualized system is there any reason to enable these workarounds Does the non-shared non-virtualized system have any encryption keys in memory that you want to protect? Do you use full-disk encryption or ssh to other machines or use a cryptocurrency wallet?

These questions are only relevant if you're not controlling and trusting all the code you're running that system. For a consumer system this is true if (and basically only if) you're running a web browser on that system. If you're confident in the software you're running on a non-shared hardware, both Meltdown and Spectre are non-issues requiring no mitigation. This is a narrow class of systems, but it exists.

> For a consumer system this is true if (and basically only if) you're running a web browser on that system.

… which is pretty close to universally true, especially when you consider how many people use apps which are based on something like Electron. If those apps load code or, especially, display ads there's JavaScript running in places people aren't used to thinking about.

Re: LLVM patch to fix half of Spectre attack

#126

Post by leeoniya »

Piskvorrr wrote: post #115
leeoniya wrote: post #82

Earlier quoted context omitted.

i know this came out as a leak, but makes one wonder how "responsible" even a Jan 9 official announcement would have been. the scope is absolutely terrifying. this bug will be exploitable for a very long time.

Jan 9, 2019? 2050? How much longer is long _enough_?

i guess at minimum it's worth asking how many major hosting providers have been fully patched at the time of disclosure. in addition to browsers and OSes.

Re: LLVM patch to fix half of Spectre attack

#127

Post by nikanj »

TheCycoONE wrote: post #110
ikeyany wrote: post #80

Earlier quoted context omitted.

Is this a 5% to 50% performance hit on all workloads or specific workloads?

The 50% was for a microbenchmark of C++ code making heavy use of virtual. V-tables and jump tables get much more expensive. Any execution path that is known at compile time is not affected.

I wonder where that leaves Java, C#, Node.js etc. Do the VMs generate code that suffers from this?

Re: LLVM patch to fix half of Spectre attack

#128

Post by FractalNerve »

sandworm101 wrote: post #90
tcoppi wrote: post #45

Earlier quoted context omitted.

Seems like the ultimate end-game here is to have mini-vms for every process using CPU-level ring protection. If you can't speculate across privilege levels, only inside them, it isn't a security problem anymore.

Or time to have Kernel live on dedicated cache not ever accessed/shared with anything else. Let the CPU speculate all it wants, just not when playing in the kernel's cache. It may even be time for dedicated kernel cpus/cores.

> It may even be time for dedicated kernel cpus/cores.

Oh yes, I agree! One needs to be able to phycically (un)lock the "kernel fpga" like a door without remote capabilities, except for server cpu's. Or whatever chip designers believe is a good "physical kernel embodiment" other than fpga.

EDIT: I know it's not really clever, but I would really enjoy hearing any solutions that doesn't try to fix it at the hardware level.

Re: LLVM patch to fix half of Spectre attack

#129

Post by crb002 »

jzl wrote: post #95

A new thing that's going to become a standard part of systems engineering: deciding whether any given system needs to run with or without these kinds of protections. Do you want the speed of speculative execution or do you want Meltdown/Spectre protection? In some cases lack of protection is fine. But figuring out the answer for any given system is often going to take expert-level security knowledge. Security is all…

CPUs should have a single instruction that wipes branch prediction caches. I would have it off by default, and add to the C/C++ spec this as a standard library macro or pragma. Easy peasy.

You only need to wipe between syscalls that have side effects. Number crunching AVX heavy subroutines should never have to deal with safety once entered.

Re: LLVM patch to fix half of Spectre attack

#130

Post by ghaff »

timeu wrote: post #114
ghaff wrote: post #104

Earlier quoted context omitted.

This document has performance impact estimates from Red Hat Performance Engineering: https://access.redhat.com/node/3307751

As far as I can tell this only measures the impact of the Meltdown bugifx/kernel patch for Intel CPUs. Would be interesting to see the accumulated impact of the mitigation of Meltdown (KPTI) and Spectre (using Retpolines)

"The Red Hat Performance Engineering team characterized application workloads to help guide partners and customers on the potential impact of the fixes supplied to correct CVE-2017-5754, CVE-2017-5753 and CVE-2017-5715, including OEM microcode, Red Hat Enterprise Linux kernel, and virtualization patches."

The numbers seem to be for patches on several Intel CPUs for all three of the disclosed vulnerabilities. [reworded]

Post reply on HN