TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

LLVM patch to fix half of Spectre attack

433 点作者 Kristine1975超过 7 年前

28 条评论

tptacek超过 7 年前
Page was down when I tried to read it, but it&#x27;s archived here: <a href="http:&#x2F;&#x2F;archive.is&#x2F;s831k" rel="nofollow">http:&#x2F;&#x2F;archive.is&#x2F;s831k</a>.<p>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&#x27;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&#x27;s so bad that to restore the original performance of a predictable indirect jump you might have to change the way you write high-level language code.<p>It&#x27;s glorious.
评论 #16070975 未加载
评论 #16070708 未加载
评论 #16070795 未加载
评论 #16070942 未加载
评论 #16071561 未加载
评论 #16070689 未加载
评论 #16073222 未加载
评论 #16071329 未加载
dzdt超过 7 年前
<i>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%.</i><p>Ouch! This is independent of other performance hurts, like from the kernel syscall overhead that was the hot topic yesterday. This is pretty crazy.
评论 #16070754 未加载
评论 #16071484 未加载
评论 #16070790 未加载
评论 #16071995 未加载
评论 #16070805 未加载
评论 #16071771 未加载
评论 #16071870 未加载
AaronFriel超过 7 年前
This is brutal for all interpreted&#x2F;JITed languages and all statically compiled languages with dynamic dispatch. I can hardly imagine worse news for performance oriented engineers. And what&#x27;s worse is that dynamic libraries will probably need to be rebuilt with these mitigations in mind, so nearly everyone will pay the cost even if they don&#x27;t need it.<p>I feel bad for all of the engineers currently working on performance sensitive applications in these languages. There&#x27;s a whole lot of Java, .NET, and JavaScript that&#x27;s about to get slower[1]. Enterprise-y, abstract class heavy (i.e.: vtable using) C++ will get slower. Rust trait objects get slower. Haskell type classes that don&#x27;t optimize out get slower.<p>What a mess.<p>[1] These mitigations will need to be implemented for interpreters, and JITs will want to switch to emitting &quot;retpoline&quot; code for dynamic dispatch. There&#x27;s no world in which I don&#x27;t expect the JVM, V8, and others to switch to these by default soon.
rntz超过 7 年前
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?<p>Maybe I&#x27;m being naive, but would a simple modulo instruction work? Consider the example code from <a href="https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privileged-memory-with-side.html" rel="nofollow">https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privi...</a>:<p><pre><code> unsigned long untrusted_offset_from_caller = ...; if (untrusted_offset_from_caller &lt; arr1-&gt;length) { unsigned char value = arr1-&gt;data[untrusted_offset_from_caller]; ... } </code></pre> If instead we did:<p><pre><code> unsigned char value = arr1-&gt;data[untrusted_offset_from_caller % arr1-&gt;length]; </code></pre> 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 &quot;optimize&quot; out the modulo here.)
jzl超过 7 年前
A new thing that&#x27;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&#x2F;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 about multiple layers of protection, and even a non-public facing machine might benefit from these layers depending on the context.
评论 #16071736 未加载
评论 #16071703 未加载
评论 #16074950 未加载
leni536超过 7 年前
It has an interesting performance impact on calls to dynamic libraries. One alternative approach would be to avoid the indirect calls through not using &#x27;-fPIC --shared&#x27; when building shared libraries but &#x27;-mcmodel=large --shared&#x27;. This causes the relocations to happen at the direct calls and not through a GOT.<p>The obvious drawback that it effectively disables sharing code in memory, it would still allow sharing code on disk though. So it would be a middle ground between the current state in dynamic and static linking.<p><a href="https:&#x2F;&#x2F;www.technovelty.org&#x2F;c&#x2F;position-independent-code-and-x86-64-libraries.html" rel="nofollow">https:&#x2F;&#x2F;www.technovelty.org&#x2F;c&#x2F;position-independent-code-and-...</a>
ealexhudson超过 7 年前
This patch apparently implements this mitigation: <a href="https:&#x2F;&#x2F;support.google.com&#x2F;faqs&#x2F;answer&#x2F;7625886" rel="nofollow">https:&#x2F;&#x2F;support.google.com&#x2F;faqs&#x2F;answer&#x2F;7625886</a>
评论 #16070757 未加载
评论 #16070662 未加载
badrequest超过 7 年前
I, for one, am eternally grateful for the incredibly bright people who take the time to patch this sort of stuff.
评论 #16070847 未加载
评论 #16072334 未加载
vfaronov超过 7 年前
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.<p>What do people more knowledgeable in the field think about this?
评论 #16070929 未加载
评论 #16070911 未加载
评论 #16071883 未加载
phkahler超过 7 年前
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.
评论 #16071097 未加载
评论 #16071031 未加载
评论 #16071070 未加载
评论 #16071088 未加载
评论 #16071123 未加载
评论 #16071458 未加载
coldcode超过 7 年前
I remember doing tricks like this in 6502 assembly and in other early processors. Amazing that to stop these attacks you have to come up with clever tricks again. Back in the 80&#x27;s I would have never imagined this type of attack being something to worry about.
评论 #16070518 未加载
peapicker超过 7 年前
This brings to mind Ken Thompson&#x27;s &quot;Reflections on Trusting Trust&quot;[1] -- after all, all I have to do to write code with the exploit is be able to remove the patch and rebuild the compiler and build some executables.<p>Trusting in a compiler you hope was used to build all the executables on your system isn&#x27;t trustworthy enough to be the final solution.<p>[1] <a href="https:&#x2F;&#x2F;www.win.tue.nl&#x2F;~aeb&#x2F;linux&#x2F;hh&#x2F;thompson&#x2F;trust.html" rel="nofollow">https:&#x2F;&#x2F;www.win.tue.nl&#x2F;~aeb&#x2F;linux&#x2F;hh&#x2F;thompson&#x2F;trust.html</a>
评论 #16071762 未加载
cws125超过 7 年前
Just as a FYI, according to:<p>* <a href="https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2018&#x2F;1&#x2F;4&#x2F;432" rel="nofollow">https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2018&#x2F;1&#x2F;4&#x2F;432</a> * <a href="http:&#x2F;&#x2F;xenbits.xen.org&#x2F;gitweb&#x2F;?p=people&#x2F;andrewcoop&#x2F;xen.git;a=blob;f=xen&#x2F;arch&#x2F;x86&#x2F;spec_ctrl.c;h=79aedf774a390293dfd564ce978500085344e305;hb=refs&#x2F;heads&#x2F;sp2-mitigations-v6.5#l168" rel="nofollow">http:&#x2F;&#x2F;xenbits.xen.org&#x2F;gitweb&#x2F;?p=people&#x2F;andrewcoop&#x2F;xen.git;a...</a><p>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.
jgowdy超过 7 年前
The problem I see with this concept is ROP mitigations like Intel’s control flow enforcement don’t seem compatible with intentionally using tweaked addresses with ret. The address they inject won’t match the shadow stack and the program will be terminated.
评论 #16071739 未加载
teilo超过 7 年前
Isn&#x27;t it the case that the Itanium architecture would not be vulnerable to Spectre because it moves the onus of branch prediction from the CPU to the compiler?
评论 #16071737 未加载
nathell超过 7 年前
I can&#x27;t help thinking of how the early-ITS approach to security (not only was there none, but looking at other users&#x27; work was a deliberate feature) was embraced by its users. I&#x27;m way too young to remember, but it rings a bell somewhere down my heart.<p>There&#x27;s a lot of prominence being given to all kinds of damage malicious users might inflict, and ways to prevent or mitigate, but little to the <i>malice</i> itself. Whence does it arise? What emotions drive those users? What unmet needs?<p>Meanwhile, when these slowing-down patches for Sceptre and Meltdown arrive, I intend to <i>not</i> run them, to the possible extent. I intend to keep aside a VM with patches for critical stuff, like banking or others&#x27; data entrusted to me. But I don&#x27;t want my machine to be slowed down just because someone, sometime, might invest effort in targeting these attacks at it. Given how transparent I want to be with my life, that&#x27;s a risk I&#x27;m willing to take.
评论 #16071503 未加载
fooker超过 7 年前
retpoline seems to be a novel concept. Can anyone ELI5?<p>Also, any insight about performance impact here?
评论 #16071016 未加载
评论 #16070489 未加载
评论 #16070486 未加载
contrarian_超过 7 年前
Note for a true fix to the BTB poisoning attack you would additionally have to disable SMT&#x2F;HT.<p>See here: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16070304" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16070304</a>
Pelam超过 7 年前
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.<p>Something like that could allow the CPU to speculate agressively while preventing information leak exploits.
评论 #16071895 未加载
评论 #16071377 未加载
userbinator超过 7 年前
This is horrible, really <i>really</i> horrible. And I&#x27;m not talking about the bug itself, but the mitigation --- which is basically &quot;stop using indirect jump and call instructions and recompile all your software&quot;. The latter is beyond unrealistic.<p>It also sets a very bad precedent: I understand people want to mitigate&#x2F;fix as much as possible, but this is basically giving an implicit message to the hardware designers: &quot;it doesn&#x27;t matter if our instructions are broken, regardless of how widespread in use they already are --- they&#x27;ll just fix it in the software.&quot;
评论 #16071856 未加载
评论 #16073113 未加载
sempron64超过 7 年前
It&#x27;s noted in the patch that one would have to recompile linked libraries, which seems impractical, unless a distro decides to build everything with this flag.
评论 #16078160 未加载
评论 #16070424 未加载
strongholdmedia超过 7 年前
As Alex Ionescu has put it:<p>&gt; We built multi-tenant cloud computing on top of processors and chipsets that were designed and hyper-optimized for<p>&gt; single-tenant use. We crossed our fingers that it would be OK and it would all turn out great and we would all profit.<p>&gt; In 2018, reality has come back to bite us.<p>This is the root of all the problems.
crb002超过 7 年前
This was the fix I was going to suggest. Especially with AVX leakage.<p>Right now many function calls don&#x27;t safely wipe registers and the new side channel caches found in Spectre. There really needs to be two kinds of function calls. Maybe a C PRAGMA?<p>The complier has parent function call wiping as a flag; the code has pragmas that over-ride the flag.
okneil超过 7 年前
The site is down for me. HN hug of death?
评论 #16070363 未加载
评论 #16070507 未加载
评论 #16070400 未加载
lousken超过 7 年前
what about performance impact after new CPU architecture arrives? how is that going to work?
eptcyka超过 7 年前
Mill can&#x27;t come soon enough.
评论 #16071037 未加载
silimike超过 7 年前
If this were 15 years ago, I&#x27;d say the site was SlashDotted.
andrewmcwatters超过 7 年前
In other news, Intel has found that by not using a computer at all, though performance overheads increase 100%, this counter-measure does secure any previously available attack vectors.