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

151–160 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#151

Post by chrisper »

dzdt wrote: post #25

When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%. Ouch! This is independent of other performance hurts, like from the kernel syscall overhead that was the hot topic yesterday. This is pretty crazy.

It's ok. The 9th generation of Intel will be 50% faster and the most secure CPU ever made! /s

Re: LLVM patch to fix half of Spectre attack

#152

Post by rsync »

vfaronov wrote: post #31

I have a hunch that the era of side-channel attacks is only now dawning, and that we should expect many more painful exploits and cumbersome mitigations in the coming years. What do people more knowledgeable in the field think about this?

"What do people more knowledgeable in the field think about this?"

https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

(from 2007)

Re: LLVM patch to fix half of Spectre attack

#153

Post by gpderetta »

leoc wrote: post #59
phkahler wrote: post #28

RISC-V impact? With all the reports of these attacks, I have not seen mention of risc-v. Since they are in the process of finalizing a lot of specs including memory model and privileged instructions, I wonder if there will be last minute changes to mitigate these vulnerabilities.

At the risk of being a HN self-parody, I’ve also been wondering what this means for the Mill... https://millcomputing.com/docs/prediction/

The only speculation done on the mill currently is on whether it will ever be released, so I think they'll be safe.

Re: LLVM patch to fix half of Spectre attack

#154

Post by pwg »

Pelam wrote: post #81

Maybe some future architecture will allow software to tell CPU which regions it considers to be secret from the point of view of each other region. Something like that could allow the CPU to speculate agressively while preventing information leak exploits.

The CPU hardware already has that feature. It is the VM paging system and the permissions assigned thereto.

The bug here is that the CPU is not aborting the speculation when fetches occur to addresses marked as "access denied". Instead the fetch happens and a line of normally inaccessible memory is put into cache by code that should not be able to get it read into the cache normally.

One hardware fix would be to plug that hole. Speculative reads get blocked when they encounter permission denied errors from the paging system and do not change the cache state. That blocks the Meltdown attack, but not the Spectre attack.

Re: LLVM patch to fix half of Spectre attack

#155

Post by sigstoat »

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.

> If you're confident in the software you're running on a non-shared hardware...

and that you won't be hit by a remote execution vulnerability.

Re: LLVM patch to fix half of Spectre attack

#156

Post by bobajeff »

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.

There is no chance JavaScript/WebAssembly will get disabled in browsers. However, it is possible things like Zero-rating, Certification Authorities, Google AMP and Facebook Instant Articles could eventually help to lockdown the web to only trusted domains.

However this wouldn't completely solve the issue (see Google Play Store).

Re: LLVM patch to fix half of Spectre attack

#157

Post by JshWright »

tlrobinson wrote: post #79
bouk wrote: post #48

Earlier quoted context omitted.

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

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

How many firefighters do you know? I guarantee you every one of them gets excited at the prospect of a "good" structure fire.

Re: LLVM patch to fix half of Spectre attack

#158

Post by yorwba »

ashleyn wrote: post #75
tzahola wrote: post #73

Earlier quoted context omitted.

- we didn't have browsers compiling JavaScript into machine code - we didn't have hyperconverged cloud infrastructures running arbitrary entities' code next to each other

Sounds like it's time for me to give up on the so-called "modern web" and install noscript.

You can have both "modern web" and block most JavaScript. You just need to keep adding scripts to the whitelist until sites you trust work again. It's a bit arduous at first, but possible to get used to once everything you visit daily has been added.

Re: LLVM patch to fix half of Spectre attack

#159

Post by nindalf »

dzdt wrote: post #25

When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%. Ouch! This is independent of other performance hurts, like from the kernel syscall overhead that was the hot topic yesterday. This is pretty crazy.

The sentence that follows the line you quoted is

> However, real-world workloads exhibit substantially lower performance impact.

I feel like you could have mentioned this.

Re: LLVM patch to fix half of Spectre attack

#160

Post by cws125 »

Just as a FYI, according to:

* https://lkml.org/lkml/2018/1/4/432 * http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a...

It appears that Skylake and later can actually predict retpolines? Some hardware features called IBRS, IBPB, STIBP (not a lot of details on this are out there) are supposedly coming in a microcode update.

Post reply on HN