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

191–200 of 248 posts

Re: LLVM patch to fix half of Spectre attack

#191

Post by Pelam »

pwg wrote: post #154
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…

I thought about that too... AFAIK currently paging system is not generally accessible to userland programs like browsers. They would need some way to setup different contexts for untrusted javascript code and the internal services that the javascript can call.

Also maybe the context switching would need to be made faster, because you would need to do that whenever eg javascript calls browser interfaces.

Re: LLVM patch to fix half of Spectre attack

#192

Post by Dylan16807 »

Klathmon wrote: post #47
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?

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…

> I think the only real fully-encompassing solution to this is a redesign in how we use computers.

You can do a lot by separating these speedup mechanisms across security boundaries. The biggest factor that makes this hard to mitigate is in-process security boundaries. Total isolation between processes is neither necessary nor sufficient.

Re: LLVM patch to fix half of Spectre attack

#193

Post by dtparr »

XR0CSWV3h3kZWg wrote: post #190
meepmorp wrote: post #162

Earlier quoted context omitted.

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.

If it can read the right data (private keys, etc.), then it can write whatever it wants.

Re: LLVM patch to fix half of Spectre attack

#194

Post by eridius »

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…

AIUI the fundamental difference between Meltdown and Spectre is Meltdown involves speculating execution that loads memory across privilege domains and Spectre doesn't. If both AMD and ARM won't speculate memory loads across privilege domains, then it sounds like they're strictly immune to Meltdown.

Re: LLVM patch to fix half of Spectre attack

#195

Post by mappu »

Paul-ish wrote: post #103
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.

Will linux distributions automatically use this compilation option (or its analog in GCC) for packages from now until forever, even if a faster mitigation is added to CPUs?

I use a binary distro and definitely don't want to be running massively slowed-down software mitigations on a corrected CPU.

Although actually, we already are - binary distros already don't take into account per-microarchitecture scheduling, nor any ISA extensions above a common baseline (e.g. just SSE2, no autovectorising to AVX2 etc).

This might provide enough impetus to restructure how binary distros work and get the whole distro compiled with some newer CPU flags (march={first corrected architecture}?) but in the short term i assume every package will take the hit.

Great time to learn about source-based distros!

Re: LLVM patch to fix half of Spectre attack

#196

Post by cookiecaper »

Splines wrote: post #166
ant6n wrote: post #41

Earlier quoted context omitted.

Sounds like it could be great for processor manufacturers. In the age where CPUs don't get faster, there's finally a reason for customers to buy new CPUs again!

Makes me wonder if that's Intel's PR plan (hence their spin on the story). Assuage the general consumer and mainstream media, point the finger at the OS vendors if necessary, and fix the bug in their next-gen chips. When this all shakes out, the general story is going to be "upgrade sooner, current-gen Intel chips are x% faster", where x is going to be a larger number than it was a week ago. It's more-or-less the App…

Here's another potential PR spin: the major cloud vendors got out ahead of this so that they could point the finger at Intel, making customers not ask "Why did you sell me this fundamentally insecure server for so many years?"

Because this isn't really that new nor is it really a bug. Meltdown could be a bug because the asynchronous access of memory in other protection rings is unsafe, but the rest of it is just a normal side-channel attack, an abuse of otherwise-innocent data.

How much moral culpability should rest on the proprietors of software virtualization technologies that don't really safely encapsulate anything due to hardware incongruencies with the modern "sandboxed computing" model?

Surely there have been engineers over the years who've questioned the propriety of misleading users into seeing VMs as fully-encapsulated systems when the hardware just fundamentally doesn't support that type of native encapsulation. Such persons have probably spent the last several years being shunned for being old fogies overly attached to their rust buckets. It'd be interesting to hear some of their stories.

Re: LLVM patch to fix half of Spectre attack

#197

Post by lower »

gmueckl wrote: post #140
CmdDot wrote: post #54

Earlier quoted context omitted.

Not really, once a program is compiled with -retpoline, new hardware won't bring back reliable branch prediction. I'd hope maybe, just maybe, this would be enough to put a focus on compilers producing code that ends up using processor-optimized paths chosen at runtime, to avoid "overheads ranging from 10% to 50%". Though, in this case, that would essentially mean making the entire executable region writable for some…

I'd rather have linkers go down a similar road that the Linux kernel went on a over a decade ago: provide binary patches in a table (essentially alternative machine code) and have the linker patch the correct alternative depending on the CPU and it's bugs. The Linux kernel already contains an "alternatives" segment which is exactly this kind of list of patches. It would be trivial to add such a table to ELF and PE fo…

Something like this exists with function multi-versioning: https://lwn.net/Articles/691932/

For example, glibc chooses optimised machine code for memcpy depending on the CPU it runs on.

Re: LLVM patch to fix half of Spectre attack

#198

Post by ychen306 »

userbinator wrote: post #148

This is horrible, really really horrible. And I'm not talking about the bug itself, but the mitigation --- which is basically "stop using indirect jump and call instructions and recompile all your software". The latter is beyond unrealistic. It also sets a very bad precedent: I understand people want to mitigate/fix as much as possible, but this is basically giving an implicit message to the hardware designers: "it d…

Go ahead, smash your computer, wait a few months, and buy a new one.

Re: LLVM patch to fix half of Spectre attack

#199

Post by Pelam »

jacobolus wrote: post #88
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.

https://millcomputing.com/docs/ e.g. the most recent talk https://millcomputing.com/docs/threading/

Something like the portal calls and "turfs" described in there could help.

Re: LLVM patch to fix half of Spectre attack

#200

Post by the8472 »

Splines wrote: post #166
ant6n wrote: post #41

Earlier quoted context omitted.

Sounds like it could be great for processor manufacturers. In the age where CPUs don't get faster, there's finally a reason for customers to buy new CPUs again!

Makes me wonder if that's Intel's PR plan (hence their spin on the story). Assuage the general consumer and mainstream media, point the finger at the OS vendors if necessary, and fix the bug in their next-gen chips. When this all shakes out, the general story is going to be "upgrade sooner, current-gen Intel chips are x% faster", where x is going to be a larger number than it was a week ago. It's more-or-less the App…

> Even if you know the why and the how, you're still in the same place as everybody else

If you know then you at least have the option to turn off PTI and compile your performance-critical binaries without retpoline.

And maybe disable microcode updates if intel's updates eat another few percent.

Post reply on HN