the closest I can think of was the famous floating point error that caused Intel to recall lots of parts[1]. Even that didn't render the CPUs useless for most users, only some scientific and business use cases really had problems.
And as I recall Linux had a kernel patch that would bypass the affected hardware and run all floating point operations in software (splitting floats into two integers, etc), so you could bypass the flaw at the cost of performance.
I remember Linux having floating-point emulation for 486 processors without a floating point unit. But at least according to this early message from Torvalds, Linux didn't implement this for FDIV:
> It wouldn't be impossible, but it's not something I will do: this isn't a problem to be solved by the OS, but by Intel or the user. The fdiv bug isn't a problem for most people, and for those that it is, it's more efficient to make the compiler do the bug work-around instead.
> Note that doing it in the kernel would mean trapping for every fp operation, and that's not good for a fp-intensive program: and the main programs which /would/ care about the fdiv bug are the fp-intensive ones.
Googling around it seems the typical solution, other than just doing nothing, was to recompile, as GCC had a patch to detect the FDIV bug and emulate division much more efficiently.
I only had a 486SX (no FPU) at the time so it was never really on my radar. Non-scientific software didn't really do floating-point arithmetic precisely because FPUs weren't very common on consumer hardware. Most of the people burnt by the FDIV bug were already well positioned to either recompile their software or receive patches from their vendors.
>Thomas Nicely, a professor of mathematics at Lynchburg College, had written code to enumerate primes, twin primes, prime triplets, and prime quadruplets. Nicely noticed some inconsistencies in the calculations on June 13, 1994, shortly after adding a Pentium system to his group of computers, but was unable to eliminate other factors (such as programming errors, motherboard chipsets, etc.) until October 19, 1994. On October 24, 1994, he reported the issue to Intel.
Can you imagine debugging this for that many months only to find out there was nothing on your end to fix.
My memory is hazy but I'm sure I recall the problem during summer 94, but I stand corrected. Was there any normal way for the information to reach us? That was the year intel took down Vlsd Pentkovskis profile page.. I loved to tease everyone that Pentium was named tribute to him...
I had a similar experience when doing my first serious work in a compiled language. I found and reported a compiler bug in double-precision division (in a commercial C compiler). It took me years to stop blaming the compiler for my bugs.
I had the same, an embedded system with GCC 3.something. Managed to get a toolchain together with 4.something and suddenly our uptime and random corruption issues disappeared.
I spent an entire summer as an intern, constantly on the phone with IBM support trying to get DB2 Connect to work in a Windows cluster only to be told "this is not a supported configuration" despite it being clearly supported in the documentation. Gave up. Years later, ran into my former boss randomly (at a liquor store of all places) and he mentioned they were finally able to get it to work.
Another confounding one was where I was trying to bulk copy some data to Sybase using Python. Started getting some really strange DB errors. Couldn't figure it out for a while. Turns out, it was a bug in the DB module and it was using uninitialized memory in certain conditions. Was a 1-line fix, but took about 6 weeks to find.
Yet another one was when I was working on porting my C++ services from 32 to 64-bit. Sockets were timing out immediately sometimes. Couldn't reproduce in the debugger. Was a bug in a 3rd party framework. It was improperly using the rtdsc instruction in some inline ASM. Worked fine on 32-bit, but the register layout was different on 64-bit. So, it was effectively reading a garbage upper 32-bits for the high-res timer. Only found that one because I noticed in my logs that my timers were reporting that some operations had taken >200 years. I forget how long it took to track that one down, but it was months of off and on hunting.
I've also hit internal compiler errors. The one I remember was that an anonymous namespace at global scope would cause an ICE. I was about to file a bug report once I'd a minimal reproduction, but it'd already been reported and fixed.
Intel has already had so many flaws and vulnerabilities that I think nothing will change. People would prefer to ignore the problem and do nothing because they don't want their businesses to implode.
I wish the updates for Spectre/Meltdown were optional on my Windows machine. They posed no real risk to my single-user gaming machine and the fixes had an unacceptable performance burden IMHO.
Are you sure they are not optional? I remember disabling various security updates at the time, but unfortunately I wasn't testing whether performance in games was affected positively after removing them. I can only say that it felt as it had been faster, but I hadn't measured FPS.
Same on my Chromebook Pixel LS too.
They were optional but now they added all kinds of additional mitigations and are also adding linux throttling and in the last 6 months or so I probably have gained ~60% compile time.
There's a performance mode that Google has a support article for. Google exactly "Change your Chromebook’s performance setting", and you should see it.
If lscpu still shows some offline cpus (let's say cpu 1 and 3 are offline), echo 1 >> /sys/devices/system/cpu/cpu<1 or 3>/online. Run lscpu again, and you should see all CPUs online and 2 threads per core.
Seriously this isn't humor, we're running a "abandoned " processor for authentication and a operating system decidedly unattractive unless you want to win capture the flag at deacon. We abandoned the secure operating system version very reluctantly so it was formerly B book.
The driver for recalls is demand from the largest customers. In Intel's case, mostly big cloud operators.
They have a strong vested interest in pretending that sharing compute resources across customers is a safe thing to do, so they're unlikely to rock the boat.
[Ignorant tangent] Is core hardware more exploited these days or are vulnerabilities just more reported in tech news? I'd assume the former, but I'm not a hardware person. If so is this just due to increasing complexity/optimization going on in chip design or better tooling/methods of exploitation?
As far as I know there has never been an enclave attack found in a rootkit in the wild. This is probably because there hasn't been anything publicly obviously worth stealing in an enclave yet.
It’s not obvious to me that credit card tokens are fungible enough (or stored in SGX). They’re also a highly insured asset with manageable counterparty risk.
Edit: So yeah, I'm not sure it's worth all of the complexity of an SGX attack. There are probably easier ways to get the credit cards.
Not really, because if your device is owned, they can read your credit card info from the main OS environment. Secure enclave us really about protecting the device from being stolen and taken over, not protecting important secrets.
An attacker doesn't want to remotely steal your iPhone or laptop. At most they want to unlock it after they steal the physical device.
Injecting a bios worm into a data center is more of a concern.
This is actually not accurate. The payments loop is entirely closed in an SE-based system. There are keys loaded on the enclave in manufacturing that come from the card networks, they encrypt tokens on the way to the SE and they can only be decrypted on the SE itself. Then during an actual transaction there is another encrypted exchange over RFID and again the encrypted blob is generated by an applet on the SE.
Sure, that's the theory, but I'm not sure a "SE-based" system as you describe it is actually used at all, or certainly for any non-trivial volume of transactions, in an Intel-based (desktop/laptop) environment.
I've never used a web store checkout system that wasn't based on browser forms, or any mechanism that felt like asking a secure enclave to sign a transaction. Google Chrome offers to store your credit card numbers for you, but that's just so it can autofill web forms.
Apple Pay or whatever, sure, on their hardware. Macbooks, I'd think it uses the touchbar secure enclave. But nothing really uses SGX on Intel except Netflix DRM.
Credit cards with complete billing info sell for what... 50 cents a piece? If you're rooting a payment processor, maybe a worthwhile target, although you could probably do much better than steal card numbers. A consumer device? Not so much.
Interesting. I haven't looked in a long time, but my vague recollection is of bulk card data being sold much cheaper than that. I could be totally incorrect though!
Is that really the case? If I'm not mistaken, secure enclaves have a different security model than the use cases you're suggesting: They are so a third party can run software on a user's machine without trusting the user. For example, delivering encrypted drm software to a customer that might be trying to crack it.
It's so you can run software without trusting the operating system. And by extension that implies the root user as well, but that's not always the use case (it is for DRM).
E.g. you might want your credit card processing in an enclave even if it's your own card, simply to hide it from any rootkits or malware you may have installed.
For the user, there is no real point to such a separation. If the system is full of rootkits and malware, the credit card can be hijacked through for the browser, for example. You don't need to get at the actual credit card processing if you can control all inputs and outputs.
We're seeing the exploration of a new surface through speculative execution and related hardware techniques. There is basically a backlog of exploring this surface that researchers and security folks in industry are working to process. Eventually will settle into a more steady state, but takes a long while to push through the new territory.
An expanding attack surface in hardware, coupled with increasing complexity inside and outside of chips, is making it far more difficult to secure systems against a variety of new and existing types of attacks https://semiengineering.com/hardware-attack-surface-widening.... Per Paul Kocher “AI will help attackers in a number of ways, where behaviors that used to be unique to humans can now be automated in ways that are lot harder to distinguish from humans"
It's probably a bit of both. Intel started implementing speculative execution decades ago but the first exploits like Specter/Meltdown weren't published until a few years ago so that alone is strong evidence that there might be ancient attack vectors that we haven't even considered yet.
On the other hand, interest in this topic among the public has definitely grown since branding departments started getting their hands on the exploits and Bloomberg published that sensationalist Micro story so it's a self reinforcing cycle.
They've gone from "try to get someone fired to get them to shut up" to "offer millions of dollars of bounties to researchers". It's a completely different attitude.
Right, but side channels in Intel products were known. It is unreasonable to expect the literature to account for every single aspect of your design. Had the side channel threat been taken more seriously at the time, it would presumably have led to more robust designs.
All multicore cpu's are insecure, just like CPU virtualisation is highly exploitable, its just no one has documented how and what to exploit yet, so "legally" it doesnt exist yet, but bit by bit more HW exploits are being discovered. Very few people really really understand how these systems work, and there's plenty of hubris knocking about the IT sector.
"Hardware" runs a lot more complex software nowadays than in the past. So it's more exploitable. Also, tools for probing hardware are more available and affordable.
Whenever I wonder this, I always think back to wargames’ example of phone phreaking. The answer seems obvious: early hardware/software was insanely easy to exploit because hardware/software security was not a thing. It was trivial to use features in a malicious way. We’re currently in an arms race because eventually society decided it wanted computer security.
That’s not to say systems were all insecure in the past. You just didn’t trust computers to be secure.
All of the above. Greater complexity/more features, people dedicated to finding vulnerabilities, more news coverage of vulnerabilities, more money to be made from exploiting vulnerabilities and general complacency from Intel. Given the lack of serious competition in the high performance space until recently, Intel figured they could get away with their rather slow and unimpressive response which basically boiled down to kneecapping recent processors and telling owners of older ones to just buy a new computer.
Compare and contrast their handling of the stream of vulnerabilities in the past few years to the FDIV bug in the 90's. The FDIV bug was the first time I remember a hardware bug making national news. Intel just about shit themselves over this apologizing profusely, offering free processor swaps, billion dollar write down, talking about how this would never happen again etc. A big part of the reason they took it so seriously was that there were still a number of other alternative CPU manufacturers trying to compete with Intel at the time and it was far from certain that x86 would become the undisputed ISA for PCs. (this was pre-Windows 95) All this, and the vast majority of people would never ever experience the FDIV bug even if their processor had it.
Times change, but the lesson remains the same: competition is good.
What happened is that Spectre was the first instance of a new class of vulnerabilities, one which hadn't been considered previously. Side-channel attacks were already well known, but nobody seemed to have considered side channels from speculative execution before (it's hard to overstate how bizarre these vulnerabilities look like, from a software point of view: they're leaking information from a code path which has not been executed, could not execute, and in some cases doesn't even exist; that is, when looking only at the software, the leak appears to come from a parallel universe where an impossible code path actually executed).
Since this vulnerability class was previously unknown, hardware didn't have much protection against it, except by accident (or as a side effect of more conservative design). Being in hardware, they are difficult or impossible to workaround in software. And they were found in common hardware most people have. This all lead to them being widely reported by the tech press.
Almost, but plenty of computer architects speculated about vulnerabilities in speculative execution. It just seemed infeasible. The attack can differ based on the particular architecture (cache hierarchy, associativity, latency per instruction, buffer sizes...), clock speed, microcode, workloads, temperature, and a thousand other variables.
Spectre was more impressive than a new idea: it was a brilliant execution of an idea that every architect eventually had. Rowhammer was similar. Everyone knew that it was possible to get boned by physics, but it can happen at an arbitrary place in an arbitrary way that isn't captured by any model. Rowhammer wasn't impressive because it was an idea, but because it was a simple, obvious in retrospect, way to exploit physics to bypass the models.
>Almost, but plenty of computer architects speculated about
I remember reading papers in the mid to later 90s on just this topic, in regard to processing on top secret systems.
Most of the infeasiblility at the time was of running code on remote systems at the same time. Things like javascript were not everywhere at the time and most computers only had one core.
Part of this is just that eyes are suddenly focussed on it. It's a repeated pattern in the tech industry.
Several years ago it felt like we barely went a week between Flash vulnerabilities.
Then someone found a major vulnerability in the JVM, and that became the centre of attention, and it felt like we were having to patch the JVM every single month.
Then something else came along and all eyes got focussed on that... rinse, repeat.
Right now the CPU is becoming a focus. We've probably got another couple of years of this before it'll settle down.
CPU is interesting because it's a lot harder to exploit, it's much less by way of finding low hanging fruit, unlike Flash and JVM.
It's because normalization of "cloud" brought into clear focus you're running your business critical code on other people's computers, along with other customers' code.
There are more hardware exploits. New classes of exploits using physics and side-channels are circumventing the formal models used to build CPUs.
CPU designers have made complex architectural decisions to speed up execution. In the case of spectre, it's to speed up single-threaded execution. In the case of this, it's to optimize security features. An analogous case is AES256, which was chosen because it's fast. But it's fast because the s-boxes use the private key as an index into an array, so there's caching. But this introduces a side-channel, because based on time to execute you can infer the private key.
Do all these vulnerabilities mean that manufacturers will have to remove those optimizations, rendering the cpu slower?
It seems to me that extracting or injecting data that way is very hard to do, and is likely to return very little information.
Is the tradeoff something like: we should prevent the one in a hundred billion chance that my cpu leaks a critical password to some intruder one day at the cost of rendering all my processes 30% slower?
Can I restate the go question as "is complexity of the machine effectively security by obscurity and effective in practice for reliance upon?"
Really how much unnecessary complexity is traversing boundaries we can shut down or at least gate effectively?
My company has used CICS for this purpose since forever and we're not so much a legacy that you will think about our architecture in this way if we talked about it, but CICS is a very rare interface in this era.
30% slower for what? What workload? What environment?
I can’t even ask what your source on it being “worse than 30%“ because that statement doesn’t mean anything... people keep attaching percentages to these vulnerabilities that really mean nothing for any general use case, to the point you can’t even compare them to each other!
I imagine your answer is going to be “well these mitigations are going to be more slower than the last ones”
Do these vulnerabilities and the last live on the same hot paths?
Are you privy to some information we’re all lacking here that lets you just throw out a statement like this?
The problem isn't limited to SGX; it's just that nobody has tried it against e.g. the kernel. If someone figures that out you're going to be seeing that performance hit come there, too.
the op seemed to be asking if we should remove speculative execution optimizations entirely to avoid these security problems. if we did that, the execution time, if averaged over all the workloads use, would be more than just 30% slower. the slowdown would be so large that i felt comfortable speaking in vague generalities, rather than providing specific benchmarks which pedants on the internet would also reply to in anger stating that it was not a real world workload or whatever. can’t win, so i don’t try.
If anything they’re asking the opposite! “Should we even be limiting the optimizations at all”
They start with the question “are manufacturers are forced to remove specific optimizations” (which replying to with “going to be worse than 30%” doesn't meaningfully answe) and immediately counter it with the above question “why remove any optimizations” (which your reply also doesn’t answer at all)
Calling out your arm wavy non-statement isn’t pedantry, asking that a comment be more than doomsaying noise isn’t either. Sorry if you feel otherwise.
What's probably going to happen is more isolation. SGX is a target for these vulnerabilities because it's a separate mode of the same processor core which runs normal software; were it on a dedicated core, it wouldn't be vulnerable. In the same way, the kernel can be attacked by user processes (and processes can attack each other) only because they share the same core. So I'd expect to see for instance the kernel running on a set of cores separate from user software (probably using a ring buffer interface for most system calls, like io_uring), and the hardware state being totally flushed when switching a core to another process.
that's incredible! first catchy names and websites, next compelling trailers. if the trend continues security researchers will start inking movie deals!
When I click on a Techrunch link, it tries to redirect me to some tracking url on advertising.com. That would probably collect data about me, set cookies and send me back to Techcrunch. Since I do not allow that, I cannot read Techcrunch articles at all.
Lets see what others think. I made an Ask HN from this:
It definitely shouldn't be banned. Techcrunch has many stories where there was something really interesting that they were the first to report. That said, the long tail of TC articles that are rehashes of what's already been written elsewhere do get tiring.
Being first to report something is ultimately worthless, and absolutely not what we want to encourage (rushing to publish in order to be first).
What matters in actual journalism, and what we should encourage, elevate, and credit, is the BEST reporting. That is, the most accurate, most readable, most informative, most honest.
Factors like misleading clickbait, content-free speculation, inflammatory commentary, and poor fact-checking need to disqualify outlets from consideration when determining which news source to promote on a given story.
I don't mean necessarily junking a publisher categorically for past sins, but rather looking at each story individually and determining whether someone else is reporting it BETTER.
It depends on the nature of the article. I've dated a national award winning journalist that was also the senior editor of the most prestigious magazine in my country (our version of The New Yorker, essentially) and there is a balance to being scooped and really nailing the reporting.
Linking to a paywalled source for an audience that you can't guarantee are all subscribers is like telling everyone to just trust you that a story exists.
I would not know how to feel about a community that both hates advertising and paywalls, and that also routinely causes DDoS-like spikes of traffic on smaller sites.
Can we ban Gizmodo and Vox while we're at it? I constantly see Gizmodo peddling the kind of fake news where the headline, the part every journalist knows most readers stop after, is a flat out lie that only becomes defensible because of weasel wording nested midway through the article. And Vox for just being Vox, the only rag I see posted here that abuses histrionics more than them is commondreams.
> The exact technical details (as documented here) of the flaw aren’t anything the average user would understand or be able to fix themselves.
I believe it would be tremendously helpful when discussion threads float up comments that help people understand the problem better and what, if anything, they can do (including waiting for patches or taking other precautions).
The "new" AMD attack depends on lack of already existing spectre mitigations. If I understand correctly, this one is a real new one that works against a correctly patched system.
I think the current outlook on this is "the only reason we're not seeing speculative bugs with AMD is because nobody is looking and they're probably more annoying to find", not that they're not there.
the new AMD attack effectively breaks KASLR (the "metadata" that the attack reveals is page table layouts) and AMD has announced they're not going to patch it.
itself it's not a problem but if you pair it with something else it destroys a major line of defense against that something else.
AMD is still architecturally vulnerable to some variants of SPECTRE, they just consider it "hard to exploit", but they do recommend you run KASLR to harden against it. Well, so much for that.
As far as I understand it, KASLR is a general hardening technique to shuffle the kernel address space so that it's harder for attackers to use vulnerabilities successfully to attack the kernel. I don't think it's specifically for Meltdown.
ASLR is a general technique to try to prevent memory corruption vulnerabilities from being turned into code execution when the attacker can determine the location of already-existing code in memory and use the memory corruption to cause program flow to jump to it.
It works pretty well against remote code execution because it's hard for an attacker who can't already execute arbitrary code on your machine to determine the address space layout. In principle it can also be used to protect the kernel against user processes, but that's much harder because a process that can already execute arbitrary user code on the same machine can use a variety of side channel attacks like this to determine the kernel address space layout.
KPTI was originally proposed to close some of those side channels, but it's kind of expensive. It only got enabled by default (on Intel) because it also mitigates Meltdown, which is a much worse problem. It also doesn't handle all of the side channels:
Meanwhile, if some kernel code is vulnerable to Spectre (i.e. the Spectre mitigations are not implemented properly), it could allow the attacker to read arbitrary kernel memory. That is obviously very bad, but the ability to read arbitrary kernel memory implies that the attacker can already determine the kernel address space layout, so I'm not sure how KASLR would be helpful in mitigating that.
> The "new" AMD attack depends on lack of already existing spectre mitigations.
No, it's a misunderstanding to say that the flaw in the "Take A Way" whitepaper depends on a mechanism already patched.
Attack scenarios which are used in the paper to show the feasibility of the 2 new side channels are patched (except the KASLR entropy reduction), but the side-channels themselves are not patched.
> but the side-channels themselves are not patched.
And might never be patched just like FLUSH+RELOAD never was. And the paper itself even points out that FLUSH+RELOAD is a more applicable attack than Load+Reload is:
> Comparison with Flush+Reload. While Flush+Reload invalidates a
cache line from the entire cache hierarchy, Load+Reload only evicts
the data for the sibling thread from the L1D. Thus, Load+Reload is
limited to cross-thread scenarios, while Flush+Reload is applicable
to cross-core scenarios too.
Collide+Probe is more interesting as it can use virtual address instead of physical address in comparison to Prime+Probe. That may get a microcode update to do a way flush on context switch as part of general Spectre mitigations (just like the branch predictors are), but it can also be handled entirely in software by adjusting how the AES implementation works as the paper also talks about.
But fundamentally what these attacks enable are super old & well known, with multiple existing mechanisms that fulfill similar roles. It's why Spectre/Meltdown never focused on the side-channel part of the attack, because it seems to just be assumed side-channels will always exist. And why the paper used existing, documented vulnerabilities to do the exploit side of their PoC, just changing the side-channel used to ex-filtrate the data.
Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it?
> But fundamentally what these attacks enable are super old & well known, with multiple existing mechanisms that fulfill similar roles.
It still has to be published.
The article doesn't claim to break all the isolation mechanisms of the processor like Spectre/Meltdown.
Why should we compare this paper with Spectre/Meltdown?
> Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it?
Yes, there are at least three things in "Take A Way" which is interesting:
- These side-channels are harder to detect because it doesn't require a very intensive use of the cache (no flush / filling all cache ways / etc.). A single collision is enough to evict a targeted cache line.
- It allows to set up a covert channel that can transfer up to 588.9 kB/s.
- They did a reverse engineering job on a processor mechanism and its undocumented hash function.
> The article doesn't claim to break all the isolation mechanisms of the processor like Spectre/Meltdown. Why should we compare this paper with Spectre/Meltdown?
That was sort of my point, we shouldn't be making that comparison but further up in the comment chain that's exactly what was being done.
The paper itself is great and definitely should exist. But it's not a counter-argument to "yet another Intel attack surfaces" either.
It's a cache-based timing sidechannel attack that leaks the address of memory accesses. In general, you should probably assume that every CPU with caches is susceptible to those (so every one with reasonable performance). As the paper mentions, there have been other cache side channel attacks that broke cryptographic implementations and only had working exploits on Intel - people didn't count those as Intel-specific attacks along with the Meltdowns or L1TFs either then or now, though, because there was no fundamental reason why it shouldn't be possible to exploit other chips the same way. Treating this one differently and somehow comparable to Intel CPUs just outright leaking data across privilege boundaries seems like a false attempt at injecting balance where none exists.
“Fanboyism” needs to stop for AMD and Intel. It’s clouding facts and objectivity. These days people have a hard on for AMD as if it’s some kind of a religious messiah saving them from doom.
It bothers me and I don’t really understand. There are some really vile comments about Intel and unreasonable praise for AMD - simply because it’s the “underdog”. What is this? Some kind of a sport that one is rooting for the “underdog”. It’s a multi billion dollar corporation.
The post you're replying to fairly clearly states that security issues in Intel chips are pushing them to buy AMD, next. It doesn't look at all like "fanboyism".
I’m just talking about the general theme of AMD/Intel discussions on HN. There is a heavy bias for AMD, not just on HN but everywhere on the internet. Just go to Anandtech forums.
I should clarify that my frustration isn’t about what the OP said. It’s a general observation.
Its not a bias it's just true. Intel has chips that are objectively underperformannt and less secure based on everything we know currently. There are no good reasons anyone should pick an Intel chip for their desktop system for the foreseeable future.
What gave you that idea? This thread was clearly about someone building a local PC. There's no reason to assume that'd be a server chip?
But even in the server world go look up any comparison of Epyc Rome vs. Intel Xeon and you'll still struggle to find a reason to go Intel. The Epyc 7742 is in a league of its own at this point.
I’m trying to get a point across for favoritism of AMD beyond objective measures.
This entire post is about Intel security flaw where we just had one discovered for AMD yesterday! But people are not as vile about AMD but become hostile when it comes to Intel. Why? There are some toxic people defending both sides with passion. I’m baffled. If this isn’t “Fanboys”, what is?
Regarding comparisons, I’m yet to see a conclusive source that points at AMD > Intel for server workloads - benchmarking these things is complex. Power, efficiency, workload types, etc matter. So it’s not as simple as saying “Hey, AMD won”.
I’m disappointed at the hostility for pointing out fanboyism on HN. It’s present whether one denies it or not.
Edit: Holyshit. I won’t be responding anymore. This has become an unproductive discussion simply for pointing out the bias in supporting the “underdog”. I have no way to prove this but I stand by my observations and what my eyes see - given Apples and Apples comparison for metric X or security flaw X, people have a deep bias for supporting the “underdog”. I saw this first hand back in 2006 when Intel was the “underdog”. This is a fact and no amount of massaging on HN or the Internet forums will change that. I’m again disappointed in the HN community’s response.
It sounds like I'm trying to debunk you, but I just want to answer your questions.
I work as an HPC administrator and I just want to tell a single thing:
We were unable to buy first generation EPYC processors because almost all of the production run is bought by Google, Amazon and Dropbox. They weren't offered by many vendors as general availability servers because it wasn't possible.
It's a bit late here so, I cannot do much research but I'll leave this Phoronix article [0] about RocksDB performance.
Phoronix Test Suite sounds a bit cheesy but, as far as I can see, it's becoming a reputable benchmark suite. I was troubleshooting a server from a big manufacturer and, its official live CD has this thing installed to see how system performs.
Also our fellow HPC centers says that EPYC is not vaporware in terms of performance.
> I’m disappointed at the hostility for pointing out fanboyism on HN
Because it very much comes across as though you've got an axe to grind. OP was "maybe sort of" going to build an AMD box, for which there are a lot of good reasons irrespective of the bug on topic, and this set him over the top.
His post doesn't really exude fanboy behavior, and your comment - while possibly appropriate for some other post - isn't really appropriate to OP.
I don't know if I have an axe to grind - I've said time and again my response had nothing to do with the OP. It was a general observation. I should have actually put it up at the root level instead of responding to OP. Did you see my messages about "general observation"?
> where we just had one discovered for AMD yesterday
AMD's was a new side channel that doesn't appear to be that different from existing side channels like flush+reload. Some pros (and cons) over the established ones, but you're not attacking anything with those either. It's how you ex-filtrate data after a successful attack.
This, by comparison, is a new attack vulnerability. They are different severity, and I'd expect here of all places to recognize & acknowledge that. I'm baffled as to why you seem to be expecting something different?
> Regarding comparisons, I’m yet to see a conclusive source that points at AMD > Intel for server workloads - benchmarking these things is complex. Power, efficiency, workload types, etc matter. So it’s not as simple as saying “Hey, AMD won”.
Did you look? Yes benchmarking these is complex, but when one CPU wins the overwhelming majority of every comparison on every metric it reeks of fanboyism to then claim it's "not conclusive." There's no shortage of server CPU benchmarks done in this space. If you have a specific comparison that's missing then say it. Otherwise you're just accusing people of the fanboy behavior that you're exhibiting.
"For those with little time: at the high end with socketed x86 CPUs, AMD offers you up to 50 to 100% higher performance while offering a 40% lower price. Unless you go for the low end server CPUs, there is no contest: AMD offers much better performance for a much lower price than Intel, with more memory channels and over 2x the number of PCIe lanes. These are also PCIe 4.0 lanes. What if you want more than 2 TB of RAM in your dual socket server? The discount in favor of AMD just became 50%.
So has AMD done the unthinkable? Beaten Intel by such a large margin that there is no contest? For now, based on our preliminary testing, that is the case. The launch of AMD's second generation EPYC processors is nothing short of historic, beating the competition by a large margin in almost every metric: performance, performance per watt and performance per dollar."
Like every review of Rome is like this. AMD released an incredible product. Credit where credit is due is not fanboyism.
There are certain things that get consistently hammered on HN.
Referring to people as "fanboys" is one of them. There's a reason for this: it's an insult, for starters. Furthermore, it leads to unproductive discussions. More heat than light.
There's almost always a way to express yourself that doesn't involve being dismissive and insulting. You may not realize that's what you're doing by saying "fanboy". But it is what you're doing.
If you'd pulled a highfalutin' word like "partisanship" you would probably find a productive conversation. Just avoid fanboy, circlejerk, and other obvious flamebait, and you'll be fine.
No, it's not. The paper chooses SGX because it's easy to write a PoC against, but there's nothing in it limiting it to SGX. (It's a general technique against any kind of memory load in a privileged context.)
Yea but you do realize that it’s a legislative issue? We need better controls for anti-competitive behavior.
You can just flip the sides, if AMD controlled 85% market share, the shareholders would demand the same unless we have laws preventing anti-competitive behavior.
That said, I do acknowledge the business leadership at Intel and their toxic attempts to prevent competition.
Legislation has nothing to do with "underdog" or marketshare. It has to do with anti-competitive practices regardless of the party. The same laws would apply to Intel or AMD regardless of their market share.
You’re a hundred percent right and I’ve noted it before, but this is exactly what happens if you call it out (your post gets buried) because there’s a nice mix of people who are emotionally attached to AMD and see AMD as their best bud who's showing Intel what’s what and not a profit driven company that would squeeze them exactly as much as they could afford if they were in a better position...
and people who bought AMD stock, but none of Intel or anything much else, because they see the CPU market as a 0 sum game. AMD was a darling of first time investors on a certain platform and they don't diversify. It’s not that their constant wall of pro-AMD stock noise is going to affect the stock price, but it also becomes a bit of an emotional thing for them.
All the AMD posts here end up looking a lot more like Reddit than Hacker News
HN is not exactly the source of truth for anything technical, but generally people are either in the ballpark on technical comments, or (more likely) get corrected by someone who is.
On AMD posts that doesn’t happen and it just becomes a low quality cesspool of “I just bought a gaming PC and chose AMD”, “Intel is on life support right now omg”, and a few poorly supported rationalizations of the post's topic.
And when you call it out these people assume you’re defending Intel (because to them it’s a holy war)
Mine is not about "Fanboyism". I'm going to upgrade my system after 7 years and will go for a multi-core performance system for parallel software development.
I consider AMD for its new Infinity Fabric and multi-core performance. I also use performance counters a lot to optimize my code and improve my understanding of modern processors even further.
This will be my 5th build and I've built 2 AMD and 3 Intel systems for long-term use in a span of ~20 years. I think it's logical to go for a high-performance system with lower attack count/surface to reduce the chance of getting performance-crippling uCode or Kernel patches in the future.
I was probably a fanboy while overclocking my 1433MHz 1700+ to 2.2GHz with ABIT ultra mother boards. These days and mindset has long gone, at least for me.
OTOH, I have more than enough cutting edge hardware from major vendors to manage and play with. So, I'm not hungry for anything really.
No problem. We're discussing stuff here. I also didn't want to sound angry or aggressive. I'm sorry if I did (English is not my native language).
I also did root for AMD when I was younger however, in a more down-to-earth fashion. AMD was providing 90% of the performance of a comparable Intel system and, Intel was so dominating that AMD was at the brink of collapse.
I rooted for AMD because I wanted them to survive. I wanted competition. I wanted to see more interesting ideas from more vendors. I also reacted to that infamous "AMD's thermal management doesn't work" video from Tom's Hardware because my and my friends' AMD systems' thermal management features were working fine.
I rooted for AMD because they were more dynamic when compared to Intel. They allowed overclocking, experimenting. They had more chipset choices and some of these chipsets did interesting things that Intel was not daring to try.
Intel was a company wearing suits even in weekends, while AMD was going to work putting on jeans and, it was exciting for young enthusiasts.
AMD still has this in its gene though. They were kind and open enough to revise their GPU silicon to enable truly open source drivers sans HDCP. Their company culture is different and I root for the underdogs sometimes because, I root for competition.
There are good reasons to go with AMD over Intel CPUs at the moment, the number of published security exploits should not be one. There is nothing fundamentally more insecure in the Skylake CPU architecture than in Zen 2, just one has more marketshare and gets scrutinized more intensely.
> There is nothing fundamentally more insecure in the Skylake CPU architecture than in Zen 2
Except there is. Hence why Skylake suffered from Meltdown while AMD didn't. Skylake's design is to do ACL checks at instruction retirement instead of up front. AMD's is the reverse.
Software workarounds for Meltdown exist, yes, but the Skylake architecture still fundamentally has that insecure design.
Signal already uses SGX for Contact Discovery, and has for many months.
In all cases, Signal only uses SGX to improve cases where data previously was stored in plaintext. The idea is to change the required attack from "compromise signal servers" to "compromise signal servers _and_ compromise SGX".
OK, but if compromising SGX is pretty easy, that just leaves the servers (hosted on AWS) for someone to be able to observe and decrypt all Signal traffic, right?
It is anything but easy. I guess that is why you get downvoted. The fact that only this academic group was able to come up with these attacks shows the amount of knowledge you need to have to carry them out.
OK, but how hard is it for a state-backed intelligence agency to come up with that knowledge? The Vault 7 leaks showed that the CIA has all kinds of very deep capabilities in this area. I'm not thinking of some random script kiddies doing this.
Past news should have shown that pretty much nothing is invulnerable from state-backed intelligence services. I would be more worried about what can realistically be hacked by random people on the internet.
Some people here (and elsewhere) have pointed out this recent tendency of Signal to put a lot of eggs in the same SGX basket. I hope they take a closer look at the risks of this strategy.
Excuse my irrelevant question, but I can't hold myself to ask. Why do they think it's a flaw but not an intentional mistake to open a backdoor to government agencies?
This vulnerability targets SGX enclaves (although I believe it would affect all memory loads?), which run code that is meant to be isolated from the rest of your computer and is probably currently only being used by DRM on your computer. This is a flaw in your processor and at the moment you probably cannot do anything to protect against this, although work is being done to come up with mitigations. Currently, it seems like they’ll be the kind that’ll slow down your computer.
it affects all loads, but for sgx the attacker scenario is that you have compromised the OS, which makes it significantly easier to create the conditions (faults/microcode assists) that cause the LVI than if you were just another userspace program (but it's not impossible there either)
There was a CTF this weekend (UTCTF) featuring a task to exploit a program running in a secure SGX enclave. As part of solving that task I spent some time looking into the design of SGX, and I gotta say it doesn’t sound promising.
The basic idea is to be able to run code on an Intel processor that cannot be tampered with or even examined by any other part of the system, including the OS, hypervisors, etc. The entire code and data segment of this program runs in its own world, the “secure enclave”, in user mode (ring 3). The attack model is that every piece of software executing on the CPU (user code, OS code, hypervisors) and every bit of hardware outside the CPU (network interfaces, hardware buses, memory interfaces) could be compromised and attempting to leak data from your Secure Enclave, and the enclave code/data should still remain tamper proof and unreadable. The SGX implementation even includes an attestation system, using a trusted server operated by Intel, which will attempt to verify that the CPU itself is not compromised.
The entire thing depends on a lot of cryptography. Sealing keys to encrypt data that will be persisted to disk from the enclave. Memory protection keys to encrypt everything going to RAM. Page encryption keys to encrypt any memory that the OS tries to page out. Attestation keys to cryptographically verify that the CPU measured itself to be OK. Cryptographic signatures to validate the initial enclave code and data to protect against tampering of the initial state. Session keys to protect the enclave’s communication with whatever application server is providing the code/data for the enclave’s computation. The OS and even the ring 3 application hosting the enclave have a MITM position on absolutely everything the enclave does, so the disclosure of just one of these keys breaks the security of the whole system.
I am not surprised at all that SGX wound up being vulnerable to a low-level CPU attack. The attack surface is way too big and there are too many points of failure.
What is correctly? You have to understand that SGX was built on an existing infrastructure, without rebuilding the chip. Intel architects ignored side channels for years. So the security specification was being met, except it had ignored a crucial threat. Small comfort. My point is that "correctly" for security can only be defined in the context of a threat model. If the model is incomplete, then you are exposed. I am not aware of a complete threat model for TEE design. And the reason is clear. The threats develop over time, springing into existence as an emergent property of complex designs rewarded by a market that is not keen on incentivizing secure design.
The Intel instruction specification details which access control checks are performed when executing instructions. In most of the speculative execution bugs, the Intel implementors decided to skip those checks for performance reasons. Note that this is a implementation correctness issue, not a security issue (which is defined only for a threat model).
The SGX design was created on top of the instruction specification, not on top of specific buggy processors. Hence the vulnerability! The threat model for SGX did not consider incorrect processor implementation.
> The Intel instruction specification details which access control checks are performed when executing instructions. In most of the speculative execution bugs, the Intel implementors decided to skip those checks for performance reasons. Note that this is a implementation correctness issue, not a security issue (which is defined only for a threat model).
Note that the access checks are only bypassed when executing speculatively, because they get reordered to occur before the checks take place. It's not that the checks aren't there; it's that they're too late and this allows for tainting micro-architectural buffers with the side effects of the invalid loads.
I think we are on the same page. I was referring to the specific SGX implementation that relied on existing processor infrastructure, and you are making the argument that no system can be secure that is built on a faulty implementation. No amount of threat modeling will help you if an implementation does not perform its function. All threat models are built under the implicit assumption that the implementation they will help derive will be correct. The threat model helps to answer the question of which function should be realized. Whether that function is in fact realized or not is a different matter. With the speculative execution bugs, the function being realized unintentionally deviated from the specified access checks.
> The attack surface is way too big and there are too many points of failure.
First impression, but is it a ridiculous notion to assume that loading code into the secure area wouldn’t be used by malware? Like if you were trying to avoid detection for the rest of the system that doesn’t seem like a great place to do it?
I think very few mortals out there use SGX, Intel apparently dropping public tooling support for it just shows for it.
Biggest scare is coming to DRM users, but even they I think are not much impressed as insecure trustlets for 845 in the wild already made then to give up few years ago.
Yes I just don't understand, most big vulnerabilities that make the headlines, even if they involves a lot of people, the vuln scenario looks it's still crumbs.
Of course the crumbs of many users can add up to a lot, so it's a still a concern, it's not really nothing.
Of course what matters is the PR involved, not the actual vuln. Hardware vulns are pretty bad since they can't be fixed. But still, it still sounds like worse than it really is.
I understand how they turn incorrect store forwarding into an attack, but can somebody summarize what causes the store forwarding to be wrong in the first place?
short version: only the lower bits of an address are compared at first, because the rest might take a while to resolve
so the cpu can speculate that the rest is gonna match as well and start to work with the data, and then either keep it or throw it away once the rest of the address is known
An 11 month embargo for a widespread security flaw like this is unacceptable. Researchers need to refuse to comply with this. 90 days by default and an extra 90 on request is more than enough. If they can't get their shit together in six months they won't be able to in 12.
I'd prefer 90 days and then unconditional publishing. I grant that making companies' desire for silence actually affect the bottom line has appeal, but 1. some companies have deep pockets, and 2. I'm not ethically comfortable with anything of the form "pay me to not disclose this bad thing".
The headline and a lot of the writeup is very confusing. This attack does not let you modify architectural state, only speculative state. The headlines sound like you can corrupt the values that the program actually ends up using, but you can't. You can only modify speculative state and use those changes to get more control over what data is leaked through side channels.
I'm not a technical expert, but check out the guy who made the fake movie trailer's channel. He has written parody songs for almost all of the Intel execution attacks there are, which is quite hilarious.
Would buffered connectivity mitigate what is becoming a Swiss cheese infrastructure of hardware (security holes in everything)?
Direct connectivity (on Internet 1.0) seems to be playing with fire nowadays.
Security admins probably love the fact that they are guarding their assets from unknown threats/vulnerabilities that major manufactures have included in their products.
Honestly, I think they need to create new categories for the protocols used for the traditional Internet and divide it into Local Area Protocals (LAPs) and Wide Area Protocols (TCP/IP is the defacto WAP) as well as adding a gateway (like AppleTalk to IP gateways of yore) so that there is more than an airgap (its a different language/protocol as well) separating your network from from the worlds biggest venerable network.
Or, as compute power, storage and hardware get less expensive, running two cryptoledgers for inbound and outbound communications would make it easier to sanitize every bit that enters a network.
I like squid and other products, but I think dropping TCP/IP from the LAN or tranfering all packets in amber (bitledger) would correct a lot of the present shortcomings with security, privacy and unfixable manufacturer defects.
The bitledger-as-a-router/gateway/firewall was more of a joke, but replacing TCP/IP on the LAN only changes how we interface with the network without changing any of the building blocks in place.
This is a good thing when the secure enclave is user-hostile and the attacker is the user.
Although it is unlikely, I remain wishful that this continued barrage of side-channel attacks will usher in the return of the era where people actually own their hardware 100%, rely on processor protections as defense against mistakes and not malice --- as was the original intent of 286 protected mode --- and understand that attempting to isolate trusted and untrusted code on the same hardware is ultimately futile.
Cloud providers already offer full blades, though they're quite expensive. I could imagine vendors commissioning custom hardware that electrically isolates CPU cores and caches, like a sort of hyper MMU. The challenge lies in combining these "nodelets" together dynamically to make larger VM skus when needed without compromising security when they're supposed to be isolated. Plus you'd have to design a ton of new hardware which isn't cheap.
Clouds will probably stick with traditional server blades until transient attacks are found which simply can't be defeated, even with new silicon. Even replacing entire DCs worth of blades would be cheaper than reworking the fundamental hardware.
(I have no inside knowledge, my opinions are my own.)
Intel continues to get beaten up by their decision to defer access checks in speculation. Meltdown, L1TF, and now LVI-stale-data are all rooted in one mistake. Fortunately, the silicon fix for Meltdown appears to mitigate these issues ("RDCL_NO"). But it also introduces LVI-NULL (which is admittedly more restricted, but still problematic).
The Intel deep dive [0] is a pretty solid addition to the original paper [1].
It looks like Ice Lake processors are going to be the first ones that are not affected [2]. Based on the deep dive, it sounds like these still aren't perfect (they don't completely avoid forwarding values to dependent instructions from faulting loads). They instead exhibit some behavior they call "zero-at-ret", which Intel says is not expoitable in practice.
Intel does not explicitly say Ice Lake is zero-at-ret, but reading between the lines this seems to be the case ("parts generally exhibiting Zero-at-ret behavior... will be documented as 'not affected'.") Only Ice Lake is listed as not affected, so they likely would not put this caveat in there if this did not apply to Ice Lake.
This is a bit of a naive question, but do the Ice Lake mitigations address any of the performance impact from the software updates that address earlier issues?
1) You can disable kPTI without opening the door to Meltdown (which let you directly read kernel memory as usermode).
2) You can re-enable hyperthreading while allowing virtualization (VMs) without obvious issues (l1tf used to allow users to read kernel memory through VMs). I don't know which, if any, distros do this, but it's the prudent thing to do if you care deeply about security. (Linux may have the scheduling fixes by now that also fix this, but I honestly haven't followed them, and they didn't have them in like November when I last checked.)
Others:
1) I'm honestly unsure if you can recompile kernels without "retpoline", but it's not a super big perf impact anyway, at least not compared to those two mitigations.
2) I'm not super familiar with the "MDS" vulnerabilities, so I don't know how bad the perf impact of their mitigations are, or how bad their impact is.
3) There's some TSX issues, which I'm also unfamiliar with, also probably don't matter much perf wise.
If you are paranoid, or have a multi-tenant machine, I'd still leave these on (and I'd particularly leave hyper-threading off, even on AMD), since we haven't stopped seeing new side channels. Hyper-threading is basically asking for problems on multi-tenant machines.
Honestly, if your machine is not multi-tenant, and you can tolerate some risk (e.g. you don't care if anyone sitting at your machine can read all of RAM, including potential malware), I'd just disable all this stuff. Unless you've run into particular hiccups (you compile linux kernels all day and you need the extra cores), I wouldn't do it.
regarding 2): latest betas of ChromeOS disable hyperthreading if one enables builtin Linux VM. Seems overzealous to me, as the OS is not multi-tenant usually
By default on my ChromeOS 81 beta HyperThreading is getting disabled only after you start the linux vm. HT stays disabled until you reboot. There is scheduler flag in chrome://flags, but IME it does nothing
206 comments
[ 5.8 ms ] story [ 347 ms ] thread[1] https://en.wikipedia.org/wiki/Pentium_FDIV_bug
> It wouldn't be impossible, but it's not something I will do: this isn't a problem to be solved by the OS, but by Intel or the user. The fdiv bug isn't a problem for most people, and for those that it is, it's more efficient to make the compiler do the bug work-around instead.
> Note that doing it in the kernel would mean trapping for every fp operation, and that's not good for a fp-intensive program: and the main programs which /would/ care about the fdiv bug are the fp-intensive ones.
https://groups.google.com/d/msg/comp.os.linux.development/4o...
Googling around it seems the typical solution, other than just doing nothing, was to recompile, as GCC had a patch to detect the FDIV bug and emulate division much more efficiently.
I only had a 486SX (no FPU) at the time so it was never really on my radar. Non-scientific software didn't really do floating-point arithmetic precisely because FPUs weren't very common on consumer hardware. Most of the people burnt by the FDIV bug were already well positioned to either recompile their software or receive patches from their vendors.
https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unsc...
https://en.wikipedia.org/wiki/Pentium_F00F_bug
OS vendors worked around it in software.
Can you imagine debugging this for that many months only to find out there was nothing on your end to fix.
Edit:typo fixed for pentium
Another confounding one was where I was trying to bulk copy some data to Sybase using Python. Started getting some really strange DB errors. Couldn't figure it out for a while. Turns out, it was a bug in the DB module and it was using uninitialized memory in certain conditions. Was a 1-line fix, but took about 6 weeks to find.
Yet another one was when I was working on porting my C++ services from 32 to 64-bit. Sockets were timing out immediately sometimes. Couldn't reproduce in the debugger. Was a bug in a 3rd party framework. It was improperly using the rtdsc instruction in some inline ASM. Worked fine on 32-bit, but the register layout was different on 64-bit. So, it was effectively reading a garbage upper 32-bits for the high-res timer. Only found that one because I noticed in my logs that my timers were reporting that some operations had taken >200 years. I forget how long it took to track that one down, but it was months of off and on hunting.
I've also hit internal compiler errors. The one I remember was that an anonymous namespace at global scope would cause an ICE. I was about to file a bug report once I'd a minimal reproduction, but it'd already been reported and fixed.
If lscpu still shows some offline cpus (let's say cpu 1 and 3 are offline), echo 1 >> /sys/devices/system/cpu/cpu<1 or 3>/online. Run lscpu again, and you should see all CPUs online and 2 threads per core.
Where are you seeing a performance burden? The spectre/meltdown patches had no impact to game performance: https://www.tomshardware.com/reviews/gaming-performance-melt...
Maybe it doesn't quite fit your criteria completely, since there is also a microcode workaround. Still...
They have a strong vested interest in pretending that sharing compute resources across customers is a safe thing to do, so they're unlikely to rock the boat.
These secure enclaves are routinely used for extremely sensitive data, surely it's more worth stealing than someone's WiFi credentials.
Edit: So yeah, I'm not sure it's worth all of the complexity of an SGX attack. There are probably easier ways to get the credit cards.
An attacker doesn't want to remotely steal your iPhone or laptop. At most they want to unlock it after they steal the physical device.
Injecting a bios worm into a data center is more of a concern.
I've never used a web store checkout system that wasn't based on browser forms, or any mechanism that felt like asking a secure enclave to sign a transaction. Google Chrome offers to store your credit card numbers for you, but that's just so it can autofill web forms.
Apple Pay or whatever, sure, on their hardware. Macbooks, I'd think it uses the touchbar secure enclave. But nothing really uses SGX on Intel except Netflix DRM.
E.g. you might want your credit card processing in an enclave even if it's your own card, simply to hide it from any rootkits or malware you may have installed.
On the other hand, interest in this topic among the public has definitely grown since branding departments started getting their hands on the exploits and Bloomberg published that sensationalist Micro story so it's a self reinforcing cycle.
Considering it was published with the intent to "move markets" I would consider it a fraudulent Micro story.
That’s not to say systems were all insecure in the past. You just didn’t trust computers to be secure.
Compare and contrast their handling of the stream of vulnerabilities in the past few years to the FDIV bug in the 90's. The FDIV bug was the first time I remember a hardware bug making national news. Intel just about shit themselves over this apologizing profusely, offering free processor swaps, billion dollar write down, talking about how this would never happen again etc. A big part of the reason they took it so seriously was that there were still a number of other alternative CPU manufacturers trying to compete with Intel at the time and it was far from certain that x86 would become the undisputed ISA for PCs. (this was pre-Windows 95) All this, and the vast majority of people would never ever experience the FDIV bug even if their processor had it.
Times change, but the lesson remains the same: competition is good.
Since this vulnerability class was previously unknown, hardware didn't have much protection against it, except by accident (or as a side effect of more conservative design). Being in hardware, they are difficult or impossible to workaround in software. And they were found in common hardware most people have. This all lead to them being widely reported by the tech press.
Spectre was more impressive than a new idea: it was a brilliant execution of an idea that every architect eventually had. Rowhammer was similar. Everyone knew that it was possible to get boned by physics, but it can happen at an arbitrary place in an arbitrary way that isn't captured by any model. Rowhammer wasn't impressive because it was an idea, but because it was a simple, obvious in retrospect, way to exploit physics to bypass the models.
I remember reading papers in the mid to later 90s on just this topic, in regard to processing on top secret systems.
Most of the infeasiblility at the time was of running code on remote systems at the same time. Things like javascript were not everywhere at the time and most computers only had one core.
Several years ago it felt like we barely went a week between Flash vulnerabilities.
Then someone found a major vulnerability in the JVM, and that became the centre of attention, and it felt like we were having to patch the JVM every single month.
Then something else came along and all eyes got focussed on that... rinse, repeat.
Right now the CPU is becoming a focus. We've probably got another couple of years of this before it'll settle down.
CPU is interesting because it's a lot harder to exploit, it's much less by way of finding low hanging fruit, unlike Flash and JVM.
And now that code can adversarial effect you?
That's why it became such a hot topic.
CPU designers have made complex architectural decisions to speed up execution. In the case of spectre, it's to speed up single-threaded execution. In the case of this, it's to optimize security features. An analogous case is AES256, which was chosen because it's fast. But it's fast because the s-boxes use the private key as an index into an array, so there's caching. But this introduces a side-channel, because based on time to execute you can infer the private key.
It seems to me that extracting or injecting data that way is very hard to do, and is likely to return very little information.
Is the tradeoff something like: we should prevent the one in a hundred billion chance that my cpu leaks a critical password to some intruder one day at the cost of rendering all my processes 30% slower?
1) https://venturebeat.com/2019/05/14/intel-zombieload-flaw-for...
2) https://zombieloadattack.com/
Really how much unnecessary complexity is traversing boundaries we can shut down or at least gate effectively?
My company has used CICS for this purpose since forever and we're not so much a legacy that you will think about our architecture in this way if we talked about it, but CICS is a very rare interface in this era.
30% slower for what? What workload? What environment?
I can’t even ask what your source on it being “worse than 30%“ because that statement doesn’t mean anything... people keep attaching percentages to these vulnerabilities that really mean nothing for any general use case, to the point you can’t even compare them to each other!
I imagine your answer is going to be “well these mitigations are going to be more slower than the last ones”
Do these vulnerabilities and the last live on the same hot paths?
Are you privy to some information we’re all lacking here that lets you just throw out a statement like this?
some more technical info here https://software.intel.com/security-software-guidance/insigh...
The tone of the original comment replied to definitely came from personal computing slant...
unless someone publishes a very practical attack from userspace, I don't think this will affect personal computing atm
If anything they’re asking the opposite! “Should we even be limiting the optimizations at all”
They start with the question “are manufacturers are forced to remove specific optimizations” (which replying to with “going to be worse than 30%” doesn't meaningfully answe) and immediately counter it with the above question “why remove any optimizations” (which your reply also doesn’t answer at all)
Calling out your arm wavy non-statement isn’t pedantry, asking that a comment be more than doomsaying noise isn’t either. Sorry if you feel otherwise.
I made a blog post trying to explain the Intel ME hardware bug.
Understanding the Intel CSME Vulnerability for Mere Mortals - https://news.ycombinator.com/item?id=22534259
https://lviattack.eu
It has a good explanation, videos and FAQ.
(the Techcrunch post is just horrible)
https://lviattack.eu/lvi.pdf
https://github.com/jovanbulck/sgx-step
When I click on a Techrunch link, it tries to redirect me to some tracking url on advertising.com. That would probably collect data about me, set cookies and send me back to Techcrunch. Since I do not allow that, I cannot read Techcrunch articles at all.
Lets see what others think. I made an Ask HN from this:
https://news.ycombinator.com/item?id=22539255
What matters in actual journalism, and what we should encourage, elevate, and credit, is the BEST reporting. That is, the most accurate, most readable, most informative, most honest.
Factors like misleading clickbait, content-free speculation, inflammatory commentary, and poor fact-checking need to disqualify outlets from consideration when determining which news source to promote on a given story.
I don't mean necessarily junking a publisher categorically for past sins, but rather looking at each story individually and determining whether someone else is reporting it BETTER.
Fools rush in.
Linking to a paywalled source for an audience that you can't guarantee are all subscribers is like telling everyone to just trust you that a story exists.
I believe it would be tremendously helpful when discussion threads float up comments that help people understand the problem better and what, if anything, they can do (including waiting for patches or taking other precautions).
- Maybe I should buy an Intel system again because of the performance counters and other nice things.
Another Intel attack surfaces
- Yep, I shall go AMD this time...
From 2 days ago, in case you weren't aware.
itself it's not a problem but if you pair it with something else it destroys a major line of defense against that something else.
AMD is still architecturally vulnerable to some variants of SPECTRE, they just consider it "hard to exploit", but they do recommend you run KASLR to harden against it. Well, so much for that.
It works pretty well against remote code execution because it's hard for an attacker who can't already execute arbitrary code on your machine to determine the address space layout. In principle it can also be used to protect the kernel against user processes, but that's much harder because a process that can already execute arbitrary user code on the same machine can use a variety of side channel attacks like this to determine the kernel address space layout.
KPTI was originally proposed to close some of those side channels, but it's kind of expensive. It only got enabled by default (on Intel) because it also mitigates Meltdown, which is a much worse problem. It also doesn't handle all of the side channels:
http://www.cs.ucr.edu/~nael/pubs/micro16.pdf
Meanwhile, if some kernel code is vulnerable to Spectre (i.e. the Spectre mitigations are not implemented properly), it could allow the attacker to read arbitrary kernel memory. That is obviously very bad, but the ability to read arbitrary kernel memory implies that the attacker can already determine the kernel address space layout, so I'm not sure how KASLR would be helpful in mitigating that.
No, it's a misunderstanding to say that the flaw in the "Take A Way" whitepaper depends on a mechanism already patched. Attack scenarios which are used in the paper to show the feasibility of the 2 new side channels are patched (except the KASLR entropy reduction), but the side-channels themselves are not patched.
And might never be patched just like FLUSH+RELOAD never was. And the paper itself even points out that FLUSH+RELOAD is a more applicable attack than Load+Reload is:
> Comparison with Flush+Reload. While Flush+Reload invalidates a cache line from the entire cache hierarchy, Load+Reload only evicts the data for the sibling thread from the L1D. Thus, Load+Reload is limited to cross-thread scenarios, while Flush+Reload is applicable to cross-core scenarios too.
Collide+Probe is more interesting as it can use virtual address instead of physical address in comparison to Prime+Probe. That may get a microcode update to do a way flush on context switch as part of general Spectre mitigations (just like the branch predictors are), but it can also be handled entirely in software by adjusting how the AES implementation works as the paper also talks about.
But fundamentally what these attacks enable are super old & well known, with multiple existing mechanisms that fulfill similar roles. It's why Spectre/Meltdown never focused on the side-channel part of the attack, because it seems to just be assumed side-channels will always exist. And why the paper used existing, documented vulnerabilities to do the exploit side of their PoC, just changing the side-channel used to ex-filtrate the data.
Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it?
It still has to be published. The article doesn't claim to break all the isolation mechanisms of the processor like Spectre/Meltdown. Why should we compare this paper with Spectre/Meltdown?
> Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it?
Yes, there are at least three things in "Take A Way" which is interesting:
- These side-channels are harder to detect because it doesn't require a very intensive use of the cache (no flush / filling all cache ways / etc.). A single collision is enough to evict a targeted cache line.
- It allows to set up a covert channel that can transfer up to 588.9 kB/s.
- They did a reverse engineering job on a processor mechanism and its undocumented hash function.
That was sort of my point, we shouldn't be making that comparison but further up in the comment chain that's exactly what was being done.
The paper itself is great and definitely should exist. But it's not a counter-argument to "yet another Intel attack surfaces" either.
It bothers me and I don’t really understand. There are some really vile comments about Intel and unreasonable praise for AMD - simply because it’s the “underdog”. What is this? Some kind of a sport that one is rooting for the “underdog”. It’s a multi billion dollar corporation.
I should clarify that my frustration isn’t about what the OP said. It’s a general observation.
What gave you that idea? This thread was clearly about someone building a local PC. There's no reason to assume that'd be a server chip?
But even in the server world go look up any comparison of Epyc Rome vs. Intel Xeon and you'll still struggle to find a reason to go Intel. The Epyc 7742 is in a league of its own at this point.
This entire post is about Intel security flaw where we just had one discovered for AMD yesterday! But people are not as vile about AMD but become hostile when it comes to Intel. Why? There are some toxic people defending both sides with passion. I’m baffled. If this isn’t “Fanboys”, what is?
Regarding comparisons, I’m yet to see a conclusive source that points at AMD > Intel for server workloads - benchmarking these things is complex. Power, efficiency, workload types, etc matter. So it’s not as simple as saying “Hey, AMD won”.
I’m disappointed at the hostility for pointing out fanboyism on HN. It’s present whether one denies it or not.
Edit: Holyshit. I won’t be responding anymore. This has become an unproductive discussion simply for pointing out the bias in supporting the “underdog”. I have no way to prove this but I stand by my observations and what my eyes see - given Apples and Apples comparison for metric X or security flaw X, people have a deep bias for supporting the “underdog”. I saw this first hand back in 2006 when Intel was the “underdog”. This is a fact and no amount of massaging on HN or the Internet forums will change that. I’m again disappointed in the HN community’s response.
I work as an HPC administrator and I just want to tell a single thing:
We were unable to buy first generation EPYC processors because almost all of the production run is bought by Google, Amazon and Dropbox. They weren't offered by many vendors as general availability servers because it wasn't possible.
It's a bit late here so, I cannot do much research but I'll leave this Phoronix article [0] about RocksDB performance.
Phoronix Test Suite sounds a bit cheesy but, as far as I can see, it's becoming a reputable benchmark suite. I was troubleshooting a server from a big manufacturer and, its official live CD has this thing installed to see how system performs.
Also our fellow HPC centers says that EPYC is not vaporware in terms of performance.
[0]: https://www.phoronix.com/scan.php?page=article&item=intel-am...
Because it very much comes across as though you've got an axe to grind. OP was "maybe sort of" going to build an AMD box, for which there are a lot of good reasons irrespective of the bug on topic, and this set him over the top.
His post doesn't really exude fanboy behavior, and your comment - while possibly appropriate for some other post - isn't really appropriate to OP.
AMD's was a new side channel that doesn't appear to be that different from existing side channels like flush+reload. Some pros (and cons) over the established ones, but you're not attacking anything with those either. It's how you ex-filtrate data after a successful attack.
This, by comparison, is a new attack vulnerability. They are different severity, and I'd expect here of all places to recognize & acknowledge that. I'm baffled as to why you seem to be expecting something different?
> Regarding comparisons, I’m yet to see a conclusive source that points at AMD > Intel for server workloads - benchmarking these things is complex. Power, efficiency, workload types, etc matter. So it’s not as simple as saying “Hey, AMD won”.
Did you look? Yes benchmarking these is complex, but when one CPU wins the overwhelming majority of every comparison on every metric it reeks of fanboyism to then claim it's "not conclusive." There's no shortage of server CPU benchmarks done in this space. If you have a specific comparison that's missing then say it. Otherwise you're just accusing people of the fanboy behavior that you're exhibiting.
But here: https://www.anandtech.com/show/14694/amd-rome-epyc-2nd-gen/1...
"For those with little time: at the high end with socketed x86 CPUs, AMD offers you up to 50 to 100% higher performance while offering a 40% lower price. Unless you go for the low end server CPUs, there is no contest: AMD offers much better performance for a much lower price than Intel, with more memory channels and over 2x the number of PCIe lanes. These are also PCIe 4.0 lanes. What if you want more than 2 TB of RAM in your dual socket server? The discount in favor of AMD just became 50%.
So has AMD done the unthinkable? Beaten Intel by such a large margin that there is no contest? For now, based on our preliminary testing, that is the case. The launch of AMD's second generation EPYC processors is nothing short of historic, beating the competition by a large margin in almost every metric: performance, performance per watt and performance per dollar."
Like every review of Rome is like this. AMD released an incredible product. Credit where credit is due is not fanboyism.
Referring to people as "fanboys" is one of them. There's a reason for this: it's an insult, for starters. Furthermore, it leads to unproductive discussions. More heat than light.
There's almost always a way to express yourself that doesn't involve being dismissive and insulting. You may not realize that's what you're doing by saying "fanboy". But it is what you're doing.
If you'd pulled a highfalutin' word like "partisanship" you would probably find a productive conversation. Just avoid fanboy, circlejerk, and other obvious flamebait, and you'll be fine.
The schadenfreude isn't coming from nowhere.
You can just flip the sides, if AMD controlled 85% market share, the shareholders would demand the same unless we have laws preventing anti-competitive behavior.
That said, I do acknowledge the business leadership at Intel and their toxic attempts to prevent competition.
Legislation has nothing to do with "underdog" or marketshare. It has to do with anti-competitive practices regardless of the party. The same laws would apply to Intel or AMD regardless of their market share.
and people who bought AMD stock, but none of Intel or anything much else, because they see the CPU market as a 0 sum game. AMD was a darling of first time investors on a certain platform and they don't diversify. It’s not that their constant wall of pro-AMD stock noise is going to affect the stock price, but it also becomes a bit of an emotional thing for them.
All the AMD posts here end up looking a lot more like Reddit than Hacker News
HN is not exactly the source of truth for anything technical, but generally people are either in the ballpark on technical comments, or (more likely) get corrected by someone who is.
On AMD posts that doesn’t happen and it just becomes a low quality cesspool of “I just bought a gaming PC and chose AMD”, “Intel is on life support right now omg”, and a few poorly supported rationalizations of the post's topic.
And when you call it out these people assume you’re defending Intel (because to them it’s a holy war)
I consider AMD for its new Infinity Fabric and multi-core performance. I also use performance counters a lot to optimize my code and improve my understanding of modern processors even further.
This will be my 5th build and I've built 2 AMD and 3 Intel systems for long-term use in a span of ~20 years. I think it's logical to go for a high-performance system with lower attack count/surface to reduce the chance of getting performance-crippling uCode or Kernel patches in the future.
I was probably a fanboy while overclocking my 1433MHz 1700+ to 2.2GHz with ABIT ultra mother boards. These days and mindset has long gone, at least for me.
OTOH, I have more than enough cutting edge hardware from major vendors to manage and play with. So, I'm not hungry for anything really.
I also did root for AMD when I was younger however, in a more down-to-earth fashion. AMD was providing 90% of the performance of a comparable Intel system and, Intel was so dominating that AMD was at the brink of collapse.
I rooted for AMD because I wanted them to survive. I wanted competition. I wanted to see more interesting ideas from more vendors. I also reacted to that infamous "AMD's thermal management doesn't work" video from Tom's Hardware because my and my friends' AMD systems' thermal management features were working fine.
I rooted for AMD because they were more dynamic when compared to Intel. They allowed overclocking, experimenting. They had more chipset choices and some of these chipsets did interesting things that Intel was not daring to try.
Intel was a company wearing suits even in weekends, while AMD was going to work putting on jeans and, it was exciting for young enthusiasts.
AMD still has this in its gene though. They were kind and open enough to revise their GPU silicon to enable truly open source drivers sans HDCP. Their company culture is different and I root for the underdogs sometimes because, I root for competition.
Except there is. Hence why Skylake suffered from Meltdown while AMD didn't. Skylake's design is to do ACL checks at instruction retirement instead of up front. AMD's is the reverse.
Software workarounds for Meltdown exist, yes, but the Skylake architecture still fundamentally has that insecure design.
Not sure how much of a risk this plays in that plan, though.
In all cases, Signal only uses SGX to improve cases where data previously was stored in plaintext. The idea is to change the required attack from "compromise signal servers" to "compromise signal servers _and_ compromise SGX".
which is of course exactly what sgx is supposed to defend against, but at the same time that kind of access is a pretty big problem on its own
Some people here (and elsewhere) have pointed out this recent tendency of Signal to put a lot of eggs in the same SGX basket. I hope they take a closer look at the risks of this strategy.
Anything I should add?
In short, who should be worried, a common Windows user, a *nix system admin or everyone who uses intel chips..
The basic idea is to be able to run code on an Intel processor that cannot be tampered with or even examined by any other part of the system, including the OS, hypervisors, etc. The entire code and data segment of this program runs in its own world, the “secure enclave”, in user mode (ring 3). The attack model is that every piece of software executing on the CPU (user code, OS code, hypervisors) and every bit of hardware outside the CPU (network interfaces, hardware buses, memory interfaces) could be compromised and attempting to leak data from your Secure Enclave, and the enclave code/data should still remain tamper proof and unreadable. The SGX implementation even includes an attestation system, using a trusted server operated by Intel, which will attempt to verify that the CPU itself is not compromised.
The entire thing depends on a lot of cryptography. Sealing keys to encrypt data that will be persisted to disk from the enclave. Memory protection keys to encrypt everything going to RAM. Page encryption keys to encrypt any memory that the OS tries to page out. Attestation keys to cryptographically verify that the CPU measured itself to be OK. Cryptographic signatures to validate the initial enclave code and data to protect against tampering of the initial state. Session keys to protect the enclave’s communication with whatever application server is providing the code/data for the enclave’s computation. The OS and even the ring 3 application hosting the enclave have a MITM position on absolutely everything the enclave does, so the disclosure of just one of these keys breaks the security of the whole system.
I am not surprised at all that SGX wound up being vulnerable to a low-level CPU attack. The attack surface is way too big and there are too many points of failure.
Most secure systems assume that the CPU is functioning correctly. It is not clear that you can do anything securely if the CPU is buggy.
The SGX design was created on top of the instruction specification, not on top of specific buggy processors. Hence the vulnerability! The threat model for SGX did not consider incorrect processor implementation.
Note that the access checks are only bypassed when executing speculatively, because they get reordered to occur before the checks take place. It's not that the checks aren't there; it's that they're too late and this allows for tainting micro-architectural buffers with the side effects of the invalid loads.
https://www.usenix.org/system/files/conference/usenixsecurit...
First impression, but is it a ridiculous notion to assume that loading code into the secure area wouldn’t be used by malware? Like if you were trying to avoid detection for the rest of the system that doesn’t seem like a great place to do it?
I think very few mortals out there use SGX, Intel apparently dropping public tooling support for it just shows for it.
Biggest scare is coming to DRM users, but even they I think are not much impressed as insecure trustlets for 845 in the wild already made then to give up few years ago.
Of course the crumbs of many users can add up to a lot, so it's a still a concern, it's not really nothing.
Of course what matters is the PR involved, not the actual vuln. Hardware vulns are pretty bad since they can't be fixed. But still, it still sounds like worse than it really is.
Direct connectivity (on Internet 1.0) seems to be playing with fire nowadays.
Security admins probably love the fact that they are guarding their assets from unknown threats/vulnerabilities that major manufactures have included in their products.
Or, as compute power, storage and hardware get less expensive, running two cryptoledgers for inbound and outbound communications would make it easier to sanitize every bit that enters a network.
I like squid and other products, but I think dropping TCP/IP from the LAN or tranfering all packets in amber (bitledger) would correct a lot of the present shortcomings with security, privacy and unfixable manufacturer defects.
Needing physical access to compromise a system sounds like a much better way to play whack-a-mole.
If the hardware cannot protect itself, moving the defense to the next layer out sounds plausible to me.
Although it is unlikely, I remain wishful that this continued barrage of side-channel attacks will usher in the return of the era where people actually own their hardware 100%, rely on processor protections as defense against mistakes and not malice --- as was the original intent of 286 protected mode --- and understand that attempting to isolate trusted and untrusted code on the same hardware is ultimately futile.
Clouds will probably stick with traditional server blades until transient attacks are found which simply can't be defeated, even with new silicon. Even replacing entire DCs worth of blades would be cheaper than reworking the fundamental hardware.
(I have no inside knowledge, my opinions are my own.)
I hope you don't like browsing the web…
The Intel deep dive [0] is a pretty solid addition to the original paper [1].
It looks like Ice Lake processors are going to be the first ones that are not affected [2]. Based on the deep dive, it sounds like these still aren't perfect (they don't completely avoid forwarding values to dependent instructions from faulting loads). They instead exhibit some behavior they call "zero-at-ret", which Intel says is not expoitable in practice.
Intel does not explicitly say Ice Lake is zero-at-ret, but reading between the lines this seems to be the case ("parts generally exhibiting Zero-at-ret behavior... will be documented as 'not affected'.") Only Ice Lake is listed as not affected, so they likely would not put this caveat in there if this did not apply to Ice Lake.
[0] https://software.intel.com/security-software-guidance/insigh... [1] https://lviattack.eu/lvi.pdf [2] https://software.intel.com/security-software-guidance/insigh...
1) You can disable kPTI without opening the door to Meltdown (which let you directly read kernel memory as usermode).
2) You can re-enable hyperthreading while allowing virtualization (VMs) without obvious issues (l1tf used to allow users to read kernel memory through VMs). I don't know which, if any, distros do this, but it's the prudent thing to do if you care deeply about security. (Linux may have the scheduling fixes by now that also fix this, but I honestly haven't followed them, and they didn't have them in like November when I last checked.)
Others:
1) I'm honestly unsure if you can recompile kernels without "retpoline", but it's not a super big perf impact anyway, at least not compared to those two mitigations.
2) I'm not super familiar with the "MDS" vulnerabilities, so I don't know how bad the perf impact of their mitigations are, or how bad their impact is.
3) There's some TSX issues, which I'm also unfamiliar with, also probably don't matter much perf wise.
If you are paranoid, or have a multi-tenant machine, I'd still leave these on (and I'd particularly leave hyper-threading off, even on AMD), since we haven't stopped seeing new side channels. Hyper-threading is basically asking for problems on multi-tenant machines.
Honestly, if your machine is not multi-tenant, and you can tolerate some risk (e.g. you don't care if anyone sitting at your machine can read all of RAM, including potential malware), I'd just disable all this stuff. Unless you've run into particular hiccups (you compile linux kernels all day and you need the extra cores), I wouldn't do it.