LLVM patch to fix half of Spectre attack • Hacker News Board

Re: LLVM patch to fix half of Spectre attack

#181

Post by comicjk » Thu, Jan 04, 2018, 6:05 PM UTC

tzahola wrote: post #165

sempron64 wrote: post #109

Earlier quoted context omitted.

This unfortunately also affects almost all mobile apps and modern Windows installations, as they all run Javascript-enabled ads. Maybe this might cause Microsoft to reconsider what it allows to run on Windows but I don't see mobile ads going away any time soon.

>javascript-enabled ads Good opportunity to get rid of them.

Or, as a compromise, no third-party javascript. Google can easily code up the 100 most common javascript ad formats and let advertisers pick from a menu.

Re: LLVM patch to fix half of Spectre attack

#182

Post by acdha » Thu, Jan 04, 2018, 6:08 PM UTC

teilo wrote: post #161

als0 wrote: post #134

Earlier quoted context omitted.

Assuming the compiler knows what it's doing :)

That was always the problem with the Itanium compilers. They were crap because they couldn't benefit from the years of tuning traditional architectures enjoyed.

Also the compiler had to be absolutely brilliant to rewrite the serial branching code most programmers wrote to work with the EPIC model. They had some good results optimized math-heavy code but the general purpose code ended up with too many nops waiting on results.

Re: LLVM patch to fix half of Spectre attack

#183

Post by rntz » Thu, Jan 04, 2018, 6:08 PM UTC

This mitigates spectre variant #2, branch target injection. We also have a mitigation for meltdown, namely KPTI. Is there a known mitigation for spectre variant #1, bounds check bypass?

Maybe I'm being naive, but would a simple modulo instruction work? Consider the example code from https://googleprojectzero.blogspot.com/2018/01/reading-privi...:

    unsigned long untrusted_offset_from_caller = ...;
    if (untrusted_offset_from_caller length) {
     unsigned char value = arr1->data[untrusted_offset_from_caller];
     ...
    }

If instead we did:

    unsigned char value = arr1->data[untrusted_offset_from_caller % arr1->length];

Would this produce a data dependency that prevents speculative execution from reading an out-of-bounds memory address? (Ignore for the moment that a sufficiently smart compiler might "optimize" out the modulo here.)

Re: LLVM patch to fix half of Spectre attack

#184

Post by coldacid » Thu, Jan 04, 2018, 6:18 PM UTC

comicjk wrote: post #181

tzahola wrote: post #165

Earlier quoted context omitted.

>javascript-enabled ads Good opportunity to get rid of them.

Or, as a compromise, no third-party javascript. Google can easily code up the 100 most common javascript ad formats and let advertisers pick from a menu.

I'd rather just be rid of them altogether. No compromise.

Re: LLVM patch to fix half of Spectre attack

#185

Post by bluGill » Thu, Jan 04, 2018, 6:20 PM UTC

alanfalcon wrote: post #167

Kristine1975 wrote: post #112

Earlier quoted context omitted.

Which in some cases might make it cheaper for customers to use their own hardware, resulting in cloud providers losing business.

Maybe. But their own hardware will also be slower, no?

Maybe. When it is your own hardware you can do a different risk analysis. If you control all the code that runs on the system you don't need any mitigation. Most servers don't run arbitrary code form the internet - at least not intentionally. (a security hole that allows remote code execution is a real issue, but that risk can be managed)

My company doesn't need to mitigate the risk of me using these tricks. I'm not going to, but even if I was I have many other ways to get at sensitive data if I tried. If I get caught I'm fired and put in prison which is enough mitigation.

Re: LLVM patch to fix half of Spectre attack

#186

Post by bluGill » Thu, Jan 04, 2018, 6:22 PM UTC

jcranmer wrote: post #101

voidmain wrote: post #27

Earlier quoted context omitted.

And I fear there's little reason to think that the "three variants" from project zero's announcement are the full scope of the problem. They were just the variants that the few people in on this found time to develop exploits for. There can now be security bugs in things your program doesn't do; it seems like there is room for nearly unlimited creativity in finding them. From the spectre paper: "A minor variant of th…

I think the main takeaway should be "speculative execution creates exploitable side-channels, and you should assume your hardware is exploitable until proven otherwise." AMD and ARM are probably still exploitable with unknown exploits, possibly even at Meltdown-levels of exploitability, but people haven't taken the time to reverse-engineer the microarchitecture enough to find the exploits. If I were developing proces…

This needs to find its way into the hands of every manager of companies that make processors.

Re: LLVM patch to fix half of Spectre attack

#187

Post by bluGill » Thu, Jan 04, 2018, 6:35 PM UTC

sandworm101 wrote: post #171

ufo wrote: post #132

Earlier quoted context omitted.

Reading Kernel memory (Meltdown attack) is extra bad but regular user processes being able to read each other's memory (Spectre attack) is also very bad and not solvable by isolating the kernel.

Im less worried about my steam client reading my chat cache than something inside my web browser reading the keys that encrypt my home directory. Short of abandoning all sharing, the least we can do is isolate kernel cache.

That depends on what you are chatting with. My chatlog would be very interesting to our competitors. The key that encrypts my home directory isn't useful because the firewall blocks your access to my home directory (that a different layer of security).

Re: LLVM patch to fix half of Spectre attack

#188

Post by phs2501 » Thu, Jan 04, 2018, 6:37 PM UTC

eptcyka wrote: post #62

mike_hearn wrote: post #60

Earlier quoted context omitted.

What makes you think the Mill would be immune to these issues?

Mill has no speculative execution.

Uh, yes it does. It has no /out of order/ execution but it certainly has speculative execution. They mention quite often in talks how they predict EBB exits and not each branch. They even go so far as to follow that EBB exit chain to speculatively load code from DRAM several calls ahead, which is much more speculation than current CPUs are capable of.

You basically can't make a deeply-pipelined processor fast without speculative execution.

Re: LLVM patch to fix half of Spectre attack

#189

Post by gmueckl » Thu, Jan 04, 2018, 6:37 PM UTC

sigstoat wrote: post #155

gmueckl wrote: post #120

Earlier quoted context omitted.

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.

That's what being confident in the software means.

Re: LLVM patch to fix half of Spectre attack

#190

Post by XR0CSWV3h3kZWg » Thu, Jan 04, 2018, 6:51 PM UTC

meepmorp wrote: post #162

yorwba wrote: post #158

Earlier quoted context omitted.

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.

Unless, of course, the site you trust is hosted in a shared hosting VM which is also vulnerable to spectre or meltdown. In which case, you can’t trust the scripts.

spectre can read, not write.