More Intel speculative execution vulnerabilities(mdsattacks.com)
mdsattacks.com
More Intel speculative execution vulnerabilities
https://mdsattacks.com/#ridl-ng
258 comments
Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything, just two or three additional unpatched PoCs with full source code would be enough.
However, unlike buffer overflow exploits, most researches on CPUs are conducted within academic institutions, doing this certainly breaches the code of conduct. Also, CPUs are the most critical components of all computers and their vulnerabilities are difficult to fix, doing this would put a lot of users under immediate risks, unlike a root exploit, which is less risky and can be fixed within a week. Doing Full Disclosure of hardware exploits that users can not fix is much more ethically problematic than software exploits.
But leaving the users in the dark and allowing Intel to delay its fixes by not to exert pressure is obviously irresponsible, which is the original argument for full disclosure.
So I'm not sure. Perhaps Google's Project Zero is a good model and a good compromise between resposible/full disclosure - embargo for 90 days, full disclosure later, all information becomes public after 90 days and no extension is allowed, period. For CPUs, perhaps we can use 180 days.
However, unlike buffer overflow exploits, most researches on CPUs are conducted within academic institutions, doing this certainly breaches the code of conduct. Also, CPUs are the most critical components of all computers and their vulnerabilities are difficult to fix, doing this would put a lot of users under immediate risks, unlike a root exploit, which is less risky and can be fixed within a week. Doing Full Disclosure of hardware exploits that users can not fix is much more ethically problematic than software exploits.
But leaving the users in the dark and allowing Intel to delay its fixes by not to exert pressure is obviously irresponsible, which is the original argument for full disclosure.
So I'm not sure. Perhaps Google's Project Zero is a good model and a good compromise between resposible/full disclosure - embargo for 90 days, full disclosure later, all information becomes public after 90 days and no extension is allowed, period. For CPUs, perhaps we can use 180 days.
Somewhat tangential point: having a single technological leader is a significant risk. Thankfully AMD is hitting its stride again and seems to be at least somewhat immune or less susceptible to this class of attack. Apples arm processors are approaching x64 performance in some cases.
Imagine if Intel had squashed the competition only to find their architecture is a security risk. As it is now, it really sucks to know that yet another cpu power robbing patch is coming. As a processor monolith they could set back most operations 10 years plugging security flaws. At least I feel like I have a few replacement options. However the skeptic in me feels like it’s only a matter of time that other platforms are researched with equal scrutiny.
Imagine if Intel had squashed the competition only to find their architecture is a security risk. As it is now, it really sucks to know that yet another cpu power robbing patch is coming. As a processor monolith they could set back most operations 10 years plugging security flaws. At least I feel like I have a few replacement options. However the skeptic in me feels like it’s only a matter of time that other platforms are researched with equal scrutiny.
If the vulnerability pipeline is a few years deep and AMD wasn't considered a worthwhile target a few years ago, we might not want to interpret a lack of AMD vulnerabilities as evidence that they are immune.
AMD was always a worthy target because they sold a lot of cost-effective mid and low range CPUs to Dell and friends. They have been absent from the peak performance market for a while but that's a small fraction of computers. After all, AMD didn't go out of business, and they had to be selling a lot of CPUs.
But isn't that not where the worry is? Isn't it cloud computing and server spaces where the real damage can be done here?
No, these vulnerabilities potentially let userspace code escalate privileges, which could lead to ransomware or credential exfiltration. Stealing bank account passwords clearly does damage, and various governments have paid ransoms on the order of $100,000 to recover encrypted files.
I’d argue that side-channel attacks are less of a problem in the server space because servers generally don’t download untrusted code from the internet and execute that code blindly (assuming you aren’t running other peoples’ VMs).
I’d argue that side-channel attacks are less of a problem in the server space because servers generally don’t download untrusted code from the internet and execute that code blindly (assuming you aren’t running other peoples’ VMs).
> assuming you aren’t running other peoples’ VMs
That's the problem right there: the vast majority of workloads in the cloud runs on shared hosts.
AWS/GC dedicated host pricing is not actually that crazy of a markup (around 50% last time I investigated), but that's still very noticeable at scale, and billing granularity is by the hour.
That's the problem right there: the vast majority of workloads in the cloud runs on shared hosts.
AWS/GC dedicated host pricing is not actually that crazy of a markup (around 50% last time I investigated), but that's still very noticeable at scale, and billing granularity is by the hour.
I agree public cloud needs mitigations to be secure. But a significant number of workloads (~50%?) run on-prem or in private clouds. Those generally host "more trusted" code.
True, but only if you trust all your services equally, or restrict each host to a single one.
Otherwise you lose a security boundary.
Otherwise you lose a security boundary.
> assuming you aren’t running other peoples’ VMs
But that’s exactly what cloud does.
But that’s exactly what cloud does.
My second thought - Perhaps embargo with limited length can help, but it only solves the problem of endless embargo. But the following remains unaddressed...
> Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis
Being PoC-oriented means that even if there is full disclosure, Intel is still going to patch PoCs in an ad-hoc manner, rather than a full fix.
Also, if you have full disclosure of a potential problem without PoC, it doesn't solve the problem - Intel can choose to ignore it by not doing a careful root-cause analysis, and fix the problem if there is any.
> Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis
Being PoC-oriented means that even if there is full disclosure, Intel is still going to patch PoCs in an ad-hoc manner, rather than a full fix.
Also, if you have full disclosure of a potential problem without PoC, it doesn't solve the problem - Intel can choose to ignore it by not doing a careful root-cause analysis, and fix the problem if there is any.
> Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything
At the risk of sounding pedantic, that's not 'full disclosure', that's 'responsible disclosure' - https://en.wikipedia.org/wiki/Responsible_disclosure
At the risk of sounding pedantic, that's not 'full disclosure', that's 'responsible disclosure' - https://en.wikipedia.org/wiki/Responsible_disclosure
Is it?
I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero is responsible disclosure because the information is released after the problem is patched. I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".
I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero is responsible disclosure because the information is released after the problem is patched. I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".
> I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero
Good point.
> I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".
If you aren't disclosing everything you have, it's not full disclosure, it's some other disclosure model.
I think we're just arguing semantics though, as I fully agree with your earlier paragraph, that hardware vulnerabilities are trickier than software vulnerabilities regarding disclosure, and that Project Zero is doing roughly the right thing.
Good point.
> I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".
If you aren't disclosing everything you have, it's not full disclosure, it's some other disclosure model.
I think we're just arguing semantics though, as I fully agree with your earlier paragraph, that hardware vulnerabilities are trickier than software vulnerabilities regarding disclosure, and that Project Zero is doing roughly the right thing.
I wish FPGAs were fast enough because I don’t see how else this problem can be solved. Easy to issue a patch that fixes logic implemented in FOGA. Impossible to fix hardware rooted issues unless they work around it at a huge performance cost, if at all possible.
Not an EE so I’m just dumping my thoughts.
Not an EE so I’m just dumping my thoughts.
One problem of FPGAs is that the absolute dependence on proprietary tools from the vendor, the hardware industry is much more closed in comparison. By using those tools, you have to agree the terms and conditions such as the following (this one is from Xilinx),
> By using this software, you agree not to: [...] display the object code of the Software on any computer screen.
From a security perspective, it doesn't inspire confidence, there's no ability to do an independent verification, something like doing a reproducible build with an compiler which source code is open to audit. There's no equivalence of GCC or LLVM for FPGA.
Fortunately, there are some people working on it, just saw it on the homepage, although it's a long way to go... https://news.ycombinator.com/item?id=21522522
I'm not an EE, just my 0.02 USD.
> By using this software, you agree not to: [...] display the object code of the Software on any computer screen.
From a security perspective, it doesn't inspire confidence, there's no ability to do an independent verification, something like doing a reproducible build with an compiler which source code is open to audit. There's no equivalence of GCC or LLVM for FPGA.
Fortunately, there are some people working on it, just saw it on the homepage, although it's a long way to go... https://news.ycombinator.com/item?id=21522522
I'm not an EE, just my 0.02 USD.
> By using this software, you agree not to: [...] display the object code of the Software on any computer screen.
I.e. ... I can print it? Good.
I.e. ... I can print it? Good.
FPGAs are significantly slower and significantly more expensive than dedicated hardware.
The FPGAs used for data-center usage don't even use LUTs primarily anymore, because fully configurable LUTs are too slow and too expensive to manufacture at scale. Instead, data-center sized FPGAs use "DSP Slices" primarily (yeah, LUTS exist but its mostly DSP Slices). They're very expensive (https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-...) and require a very specific set of skills to work with.
The FPGAs used for data-center usage don't even use LUTs primarily anymore, because fully configurable LUTs are too slow and too expensive to manufacture at scale. Instead, data-center sized FPGAs use "DSP Slices" primarily (yeah, LUTS exist but its mostly DSP Slices). They're very expensive (https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-...) and require a very specific set of skills to work with.
DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. There's nothing about LUTs that are harder to make at scale than DSP slices. LUTs are just a little bank of SRAM, and SRAM is generally the most mature cells on a process node.
> DSP slices aren't being made at the exclusion of LUTs on modern FPGAs.
Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers.
> There's nothing about LUTs that are harder to make at scale than DSP slices.
Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a DSP Slice.
Synthesize a 32-bit wallace-tree multiplier for instance, and you'll use thousands of LUTs (maybe 2000ish). However, reserve a DSP-slice for a 32-bit multiply routine, and you'll only use ONE slice.
However, those multipliers on the DSP-slice could be "wasted" if you didn't need that many multipliers. Maybe your arithmetic is primarily addition and subtraction. In any case, when most people talk about "Reconfigurable FPGAs", they're talking about the LUTs which can be the building block of any logic. They aren't talking about DSP-slices, which are effectively prebuilt ALUs connected in a mesh.
Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers.
> There's nothing about LUTs that are harder to make at scale than DSP slices.
Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a DSP Slice.
Synthesize a 32-bit wallace-tree multiplier for instance, and you'll use thousands of LUTs (maybe 2000ish). However, reserve a DSP-slice for a 32-bit multiply routine, and you'll only use ONE slice.
However, those multipliers on the DSP-slice could be "wasted" if you didn't need that many multipliers. Maybe your arithmetic is primarily addition and subtraction. In any case, when most people talk about "Reconfigurable FPGAs", they're talking about the LUTs which can be the building block of any logic. They aren't talking about DSP-slices, which are effectively prebuilt ALUs connected in a mesh.
Your original post is making it sound like FPGAs are switching from LUTs to DSP slices in the general case, which is blatantly not true. Yeah, it uses less resources to use a DSP slice instead of synthesizing a multiplier, bit that's because a DSP slice is just an 18x18 MAC. It's not replacing LUTs for general logic.
It wasn't my intent to say that FPGAs were switching away from LUTs in general. But I expect that FPGAs of the datacenter to be more-and-more DSP-based into the future.
Think of today's supercomputer problems: Deep Learning, 3d Rendering, Finite Element Analysis, Weather Modeling, nuclear research, protein folding, even high-frequency trading. What do they all have in common?
They're all giant matrix-multiplication problems at their core... fundamentally built up from the multiply-and-accumulate primitive.
EDIT: The only real exception is maybe EDA. I don't know too much about those algorithms involved, but IIRC it involves binary decision diagrams (https://en.wikipedia.org/wiki/Binary_decision_diagram). So some problems aren't matrix-multiplication based... but I dare say the majority of today's supercomputer problems involve matrix-multiplication.
Think of today's supercomputer problems: Deep Learning, 3d Rendering, Finite Element Analysis, Weather Modeling, nuclear research, protein folding, even high-frequency trading. What do they all have in common?
They're all giant matrix-multiplication problems at their core... fundamentally built up from the multiply-and-accumulate primitive.
EDIT: The only real exception is maybe EDA. I don't know too much about those algorithms involved, but IIRC it involves binary decision diagrams (https://en.wikipedia.org/wiki/Binary_decision_diagram). So some problems aren't matrix-multiplication based... but I dare say the majority of today's supercomputer problems involve matrix-multiplication.
Super computers and data centers are two different things with markedly different requirements.
Also, deep learning isn't a great fit for FPGAs anyway. There's dedicated silicon that does a better job if you're looking for matrix multiplies per watt.
Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in to get a reply out.
Also, deep learning isn't a great fit for FPGAs anyway. There's dedicated silicon that does a better job if you're looking for matrix multiplies per watt.
Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in to get a reply out.
https://www.xilinx.com/support/documentation/white_papers/wp...
Xilinx absolutely markets these Alveo U200 FPGAs as deep-learning accelerators.
> Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in to get a reply out.
I'm not a HFT-user, but I've always assumed that simulating Monte-carlo Black Scholes was roughly what HFT-traders were doing. Maybe not Black-scholes itself, but maybe some other differential equation that requires a lot of Monte-carlo runs of.
Either way, Black-scholes (and other models) are partial differential equations, which are best simulated as a sequence of matrix multiplications. That's my understanding anyway.
Xilinx absolutely markets these Alveo U200 FPGAs as deep-learning accelerators.
> Additionally, high frequency trading isn't doing much in the way of matrix multiplies, as they don't have enough time. They've got few hundred clock cycles per packet in to get a reply out.
I'm not a HFT-user, but I've always assumed that simulating Monte-carlo Black Scholes was roughly what HFT-traders were doing. Maybe not Black-scholes itself, but maybe some other differential equation that requires a lot of Monte-carlo runs of.
Either way, Black-scholes (and other models) are partial differential equations, which are best simulated as a sequence of matrix multiplications. That's my understanding anyway.
They're marketing towards that, but I can't think of any serious deep learning shops that are using them. Modern GPUs have them beat, to say nothing of dedicated ASICs. The one niche they might have I could see would be infernce on Zync-likes for non power constrained applications, but that's quite a tiny niche.
And there's cute tricks to avoid matrix multiplies in the critical path for HFT.
And there's cute tricks to avoid matrix multiplies in the critical path for HFT.
[deleted]
A lot of the inefficiency of FPGAs is signal routing. If you are very likely to implement X, Y, or Z, then it may just be more economical to put those into the FPGA as discrete circuits. At best maybe you can break them apart into common elements and provide those.
There really isn't much need for LUTs any more, barring some fundamental change in data processing.
There really isn't much need for LUTs any more, barring some fundamental change in data processing.
That doesn't really follow given that LUT count has been increasing with Moore's law.
I see your point, but I think that is because of a lack of commitment to higher integration functional blocks. A lot of work done on a FPGA is very regular.
I suppose LUTs could be the best way to do create the glue logic that basically amounts to signal routing and synchronization, but it seems unlikely.
I suppose LUTs could be the best way to do create the glue logic that basically amounts to signal routing and synchronization, but it seems unlikely.
I'm not going to be surprised if FPGAs of the future start building in on-chip non-blocking CLOS-networks to more efficiently route messages across the chip.
https://en.wikipedia.org/wiki/Clos_network
Dedicated-hardware that serves a purpose. Sure, you can build a CLOS-network out of LUTs, but it'd be more efficient if you made dedicated hardware for it instead.
https://en.wikipedia.org/wiki/Clos_network
Dedicated-hardware that serves a purpose. Sure, you can build a CLOS-network out of LUTs, but it'd be more efficient if you made dedicated hardware for it instead.
I wouldn't be surprised if some do that under the hood already. The cadence hardware emulators for sure do, but they're not quite FPGAs.
If you can get by with higher level functional blocks sitting off of a network on chip, you go the direction of a modern SoC. The neat games you can play with routing those NoC packets around are close to what you're talking about.
The cynic in me thinks a good capitalist would try to sell the discovery to the highest bidder. In this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short on Intel stock. I imagine the payoff would be in the millions of dollars in both cases, and I doubt either scenario is even illegal.
> a good capitalist would try to sell the discovery to the highest bidder.
Not all security researchers are doing it for the money, 0day markets always exist. Malicious people who wish to use the vulnerability for profit wouldn't disclose the vulnerability to begin with. So it's not a new problem.
> this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short
But your comment is insightful - Intel's case is unprecedented. Due to the huge impact of the vulnerabilities, the threat is not coming from the blackhat sellers or black market buyers, but Intel. Intel itself can simply pay researchers with an NDA to keep their mouths shut, while still doing nothing. The impact of the vulnerabilities is also high enough to move the stock market, allowing insider trading.
Not all security researchers are doing it for the money, 0day markets always exist. Malicious people who wish to use the vulnerability for profit wouldn't disclose the vulnerability to begin with. So it's not a new problem.
> this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short
But your comment is insightful - Intel's case is unprecedented. Due to the huge impact of the vulnerabilities, the threat is not coming from the blackhat sellers or black market buyers, but Intel. Intel itself can simply pay researchers with an NDA to keep their mouths shut, while still doing nothing. The impact of the vulnerabilities is also high enough to move the stock market, allowing insider trading.
If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading.
Here's an example of Gotham City Research trying this approach and failing: https://www.thedrum.com/news/2017/09/21/criteo-counters-frau...
(Not a lawyer)
Here's an example of Gotham City Research trying this approach and failing: https://www.thedrum.com/news/2017/09/21/criteo-counters-frau...
(Not a lawyer)
Yeah. Someone actually tried this with AMD last year, but the security vulnerability they found was a lot less important than their breathless press release claimed and the markets basically shrugged. There was some funny business there too, with them paying third-party security researchers to confirm the bugs based on a more technical report the rest of us didn't get to see and the actual publicly-announced description they were used to lend credibility to being kept from them.
Sounds like "Markets can stay irrational longer than you can stay solvent" would apply here
The problem in the Gotham case I linked was that markets didn't consider the news to be as significant as Gotham expected them to.
The goal with this strategy is to find serious issues that will rightly cause investors to immediately decrease their estimate of the value of the company.
The goal with this strategy is to find serious issues that will rightly cause investors to immediately decrease their estimate of the value of the company.
>If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading.
Thanks for the information, never thought about that. On the other hand, would purchasing information about a flaw and using the information to bet the stock constitutes insider trading?
Thanks for the information, never thought about that. On the other hand, would purchasing information about a flaw and using the information to bet the stock constitutes insider trading?
It would be insider trading if the person you purchased from had a duty to the company to keep the secret (they worked for the company and learned of the vulnerability in the normal course of their job, say). If they are an independent researcher and you are an independent researcher, trade away. Then it is just like using satellites to find out that a shopping mall's parking lot is empty on a big shopping day- trade all you want.
If they signed a NDA to cash in on the bug bounty and then sold it to you, I think they are vulnerable to breach of contract, but I don't think you are legally vulnerable, however this is not legal advice, I am not a lawyer, and do you want to go through the expense of finding out?
If they signed a NDA to cash in on the bug bounty and then sold it to you, I think they are vulnerable to breach of contract, but I don't think you are legally vulnerable, however this is not legal advice, I am not a lawyer, and do you want to go through the expense of finding out?
So utilizing information discovered or obtained from independent researches from public sources and personal expertise to trade is not inside trading, albeit how your conclusions are asymmetrical, inaccessible to others, or how impactful they are - since it's inherently no difference from any other type of market analysis, and it's literally the job of financial analysts. And it's also the function of the market: take all these trades as inputs, calculate its output - current price.
Makes perfect sense to me now. I now realized I've some serious misunderstanding of insider trading. Thanks for clearing it up for me.
Makes perfect sense to me now. I now realized I've some serious misunderstanding of insider trading. Thanks for clearing it up for me.
Check out Matt Levine's Moneystuff email newsletter- it is what clarified this for me, and is amusing every day. Not even any ads or upsell to a pay-for subscription. I suspect if this is a thing you are curious about you will enjoy it.
Subscribed via RSS! Thanks.
Insider information is not about the information itself, but rather the source of the information. The exact same piece of information could be insider information or not depending on who you heard it from. Think of it like a watermark or stain on the information. When the information is generated within the "insider" circle, it is permanently stained until that information is made public. Legally, this stain remains no matter how many hops it goes through. However, if the same information is generated by an "outsider" that figured it out, that same information is not stained.
Example: Your neighbor Alice is a hotshot executive at BigCorp. If Alice comes over to your BBQ and starts telling you about how bad their upcoming quarter is going to be, that's probably tainted information. However, if your other neighbor Bob comes to your BBQ, and starts talking about how grumpy Alice has been, and she's always grumpy like this when BigCorp is about to have a bad quarter... That's fair game. Same information, different sources.
That said, in the US I think there must be some indication or reasonable expectation that you knew or were willingly blind to the non-public status of the information.
Example: Your neighbor Alice is a hotshot executive at BigCorp. If Alice comes over to your BBQ and starts telling you about how bad their upcoming quarter is going to be, that's probably tainted information. However, if your other neighbor Bob comes to your BBQ, and starts talking about how grumpy Alice has been, and she's always grumpy like this when BigCorp is about to have a bad quarter... That's fair game. Same information, different sources.
That said, in the US I think there must be some indication or reasonable expectation that you knew or were willingly blind to the non-public status of the information.
If the person you bought it from would have been allowed to trade on it, that should be ok.
Security researchers aren’t hedge funds, most aren’t swimming in cash, and can’t borrow millions on a whim. Also, pouring your life savings into a bet like this is probably dumb.
A security researcher could partner with an investment fund, however. I agree this is too risky to be a good idea for most individual researchers to use directly.
Delaying the fixes is probably making them more money, if they lose a few more percent of performance they lose the number one position on all possible use cases/workflows , the PR hit will be huge, people could demand refunds or compensation (I mean you just sold them an expensive product without disclosing it is insecure and it will lose it's performance)
I wonder if it might not come to bite them though. Doing it this way means that the media will constantly keep talking about yet another vulnerability in Intel CPUs for years. There's a chance that Intel might and up picking a reputation like Flash did for being insecure.
In this case, the FBI and SEC may need to investigate precisely what is going on. If Intel is doing partial fixes it knows of other things that aren’t being disclosed there could be criminal activity occurring.
Additionally, this had big implications for cloud providers. If additional liabilities of data leaks are foisted on companies, insurance companies and corporate counsel may just say no more using amazon, google cloud, azure, etc.
Additionally, this had big implications for cloud providers. If additional liabilities of data leaks are foisted on companies, insurance companies and corporate counsel may just say no more using amazon, google cloud, azure, etc.
> here could be criminal activity occurring.
More likely some agencies don't want their exploits to stop working.
More likely some agencies don't want their exploits to stop working.
Which is sad... It wouldn't bug me nearly as much if they (NSA etc) had a sunset/disclosure policy of a reasonably short timeframe (say 60 days or so) for disclosure to the org that makes the software/hardware.
I can understand a state agency keeping a security flaw a secret to exploit in the near term... but stockpiling for years only to let stuff leak eventually is just irresponsible.
Note: I'm not saying that I like state sponsored hacking, only that I understand it being a reality and pragmatically wish they struck a better balance.
I can understand a state agency keeping a security flaw a secret to exploit in the near term... but stockpiling for years only to let stuff leak eventually is just irresponsible.
Note: I'm not saying that I like state sponsored hacking, only that I understand it being a reality and pragmatically wish they struck a better balance.
Or like java applet. Oracle has killed java applet by not handling security issues in a responsible manner.
Java applets died primarily due to the terrible user experience and inconsistent browser support. Security issues were less of a factor.
To be fair the entire approach was flawed and should have been abandoned in favour of SELinux plus something like seccomp years before.
Selinux, apparmor, etc. are not viable security solutions for pretty much anything, because they are too coarse grained. Seccomp that blocks everything, but leaves just a couple of syscalls to interact with an external proxy process is closer to what could have worked, which is basically a sandbox.
How do you feel about openbsd's pledge()? I would really like something as simple as that on linux...
seccomp actually has that ability to allow only small portion of selective operations.
Block everything except io is just one of its blocking mode.
And the list is even configurable. Docker do use such ability to filter out sys-calls that shouldn't be used in the container.
Block everything except io is just one of its blocking mode.
And the list is even configurable. Docker do use such ability to filter out sys-calls that shouldn't be used in the container.
Sun...
[deleted]
It certainly is, and that much was obvious as Intel "committed" to fixing Spectre V1 in software as opposed to hardware. Worse yet, it doesn't think a hardware solution is necessary. Except, that pretty much all recent Spectre-related bugs are variants of Spectre V1.
They are not. They are based on leaking microarchitectural state such as the contents of the store buffer, while spectrev1 is based on leaks from the branch predictor.
The difference is that the contents of e.g. the store buffer are short-lived, while branch prediction is by design learning behavior of the program for long term use.
It's not a coincidence that Spectre v1 affected all processors and not just Intel x86. Also Spectre v1 still has no widely-deployed hardware mitigation, while for all other vulnerabilities the processor could be patched to add a "flush the leaked state" instruction with a microcode update.
The difference is that the contents of e.g. the store buffer are short-lived, while branch prediction is by design learning behavior of the program for long term use.
It's not a coincidence that Spectre v1 affected all processors and not just Intel x86. Also Spectre v1 still has no widely-deployed hardware mitigation, while for all other vulnerabilities the processor could be patched to add a "flush the leaked state" instruction with a microcode update.
> This is troubling.
Only for people who for whatever reason still continue to buy Intel-based systems.
Only for people who for whatever reason still continue to buy Intel-based systems.
So Intel failed to mitigate the vulnerability when it was first reported. Then they extended the embargo from May until November.
And they still didn't fix it.
What's going on with Intel? Like they're going all in with lying in benchmarks against AMD and straight up forgetting what has been reported as security issues.
And they still didn't fix it.
What's going on with Intel? Like they're going all in with lying in benchmarks against AMD and straight up forgetting what has been reported as security issues.
https://www.glassdoor.com/Reviews/Employee-Review-Intel-Corp...
>Company is dying and has no way to turn itself around.
>Culture is a "go along to get along" / don't rock the boat. Most workers are very passive. Inclusive culture focused on internal "networking" rather than winning. A lot of make work going on, probably 25% extra headcount
>Middle and upper management are in direct revolt against CEO and his plans. During my orientation (2nd quarter 2013) my orientation meeting was about how the CEO is wrong on his plans.
>Advice to Management
>Not much you can do. These problems are the result of near monopoly on PC CPUs for 20 years. This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it.
>Company is dying and has no way to turn itself around.
>Culture is a "go along to get along" / don't rock the boat. Most workers are very passive. Inclusive culture focused on internal "networking" rather than winning. A lot of make work going on, probably 25% extra headcount
>Middle and upper management are in direct revolt against CEO and his plans. During my orientation (2nd quarter 2013) my orientation meeting was about how the CEO is wrong on his plans.
>Advice to Management
>Not much you can do. These problems are the result of near monopoly on PC CPUs for 20 years. This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it.
> This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it.
Interestingly, that printer monopoly seems to be doing fine today, given how I have to go to hp.com to get drivers for my Samsung printer.
Interestingly, that printer monopoly seems to be doing fine today, given how I have to go to hp.com to get drivers for my Samsung printer.
Hewlett-Packard was an electronic engineering, semiconductor, and computing company from the beginning (the first product they sold was an audio distortion analyzer, it used a creative circuit to achieve high performance at minimum cost), they used to do serious and innovative R&D. There were the glorious days when Hewlett-Packard makes state-of-art test equipment and semiconductor devices, developed in-house enterprise computer systems like HP-UX system and PA-RISC CPUs, first-generation of scientific and programmable handheld calculators, etc., not just today's customer printers and laptops.
e.g. I recently found a datasheet of an IC in an amateur radio gear, it were really the glorious days. Those chips with an HP logo (or a Motorola logo) are really cool.
> The INA series of MMICs is fabricated using HP’s 25 GHz f_max, ISOSAT™-I silicon bipolar process which uses nitride self-alignment, submicrometer lithography, trench isolation, ion implantation, gold metallization and polyimide intermetal dielectric and scratch protection to achieve excellent performance, uniformity and reliability.
Around 2000s, the EE & semiconductor department became an independent company, Agillent, and later Keysight.
I think the last major innovation at HP was probably memristor that was supposed to be the next evolution of digital logic and storage, and HP claimed that it was developing a memristor computer system. Unfortunately, it failed to materialize.
e.g. I recently found a datasheet of an IC in an amateur radio gear, it were really the glorious days. Those chips with an HP logo (or a Motorola logo) are really cool.
> The INA series of MMICs is fabricated using HP’s 25 GHz f_max, ISOSAT™-I silicon bipolar process which uses nitride self-alignment, submicrometer lithography, trench isolation, ion implantation, gold metallization and polyimide intermetal dielectric and scratch protection to achieve excellent performance, uniformity and reliability.
Around 2000s, the EE & semiconductor department became an independent company, Agillent, and later Keysight.
I think the last major innovation at HP was probably memristor that was supposed to be the next evolution of digital logic and storage, and HP claimed that it was developing a memristor computer system. Unfortunately, it failed to materialize.
HP was the Google of its day when H & P were in charge. People either retire or die eventually. What happens to Google when time claims Larry and/or Sergei?
Not trying to besmirch or minimize early HP by comparing to Google -- probably better to use Musk/SpaceX or something -- but IMO this is the key takeaway that doesn't seem widely discussed. Innovative companies have innovative leaders with expert-level knowledge in their technical specialties. At some point, the MBAs take over, attempt to put it on autopilot, and it's all downhill from there.
Not trying to besmirch or minimize early HP by comparing to Google -- probably better to use Musk/SpaceX or something -- but IMO this is the key takeaway that doesn't seem widely discussed. Innovative companies have innovative leaders with expert-level knowledge in their technical specialties. At some point, the MBAs take over, attempt to put it on autopilot, and it's all downhill from there.
This is one reason why the current high stock market valuations for large, profitable tech companies are crazy. Eventually the corporate culture rots from the inside and they're overtaken by a disruptive competitor. Unfortunately there's no practical way for retail investors to take a short position on those stocks for 30 years in the future; regular options only go out about 3 years.
True, but if you can identify both the winner and the loser, say AMD and/or TSMC vs INTC, you could sell puts/spreads on the loser and sell calls/spreads on the winner in similar at-risk dollar amounts. If the market itself booms or busts through your strikes, gains on one side will cancel the losses on the other. While you're right, you make double money by winning on both sides. But you lose double if you're betting the wrong way.
My friend, whether you're trading naked or spreads doesn't matter on timescales of corporate rot are ~30 years; the contracts available to retail traders are like ~2 years out.
> Unfortunately there's no practical way for retail investors to take a short position on those stocks for 30 years in the future; regular options only go out about 3 years.
You don't, not if you're a small investor. You go index and hedge your bets that they're not all going to rot at the same time.
You don't, not if you're a small investor. You go index and hedge your bets that they're not all going to rot at the same time.
TL;DR: The market can stay irrational longer than you can stay solvent.
I would say H & P had a serious edge over the Google guys in the ethics department.
What about companies like IBM? The company was originally foundered in 1911, but you could say their heyday wasn't until half a century later (or even more), after the original founder had left.
It was the unusual case of a competent son of the founder.
https://en.wikipedia.org/wiki/Thomas_Watson_Jr.
>Although the initiative, and as such much of the credit for the birth of the information revolution, must go to Tom Jr., considerable courage was also displayed by his then aging father who, despite his long commitment to internal funding, backed his son to the hilt; reportedly with the words "It is harder to keep a business great than it is to build it."
https://en.wikipedia.org/wiki/Thomas_Watson_Jr.
>Although the initiative, and as such much of the credit for the birth of the information revolution, must go to Tom Jr., considerable courage was also displayed by his then aging father who, despite his long commitment to internal funding, backed his son to the hilt; reportedly with the words "It is harder to keep a business great than it is to build it."
Not saying this happened at IBM, but sometimes correct people can be promoted into correct positions, in which case the company keeps going just fine.
However, at some point any company is probably bound to promote wrong people, who will end up promoting/hiring the wrong people under them, eventually completely changing the course of the business.
It seems like the death of a company is inevitable.
However, at some point any company is probably bound to promote wrong people, who will end up promoting/hiring the wrong people under them, eventually completely changing the course of the business.
It seems like the death of a company is inevitable.
It also happens that the circumstances that allowed a company to dominate come to an end. It would require heroic measures to move to a new form of dominance. Why should lightning strike again in the same place?
Lightning will strike a place many times if the capital is expended to erect a lightning rod.
I nominate your comment for the Hacker News comment of the day.
> It feels like the death of a company is inevitable.
Which, from a higher perspective, is good. As it breaks down monopolies and give way to more innovative new companies.
Which, from a higher perspective, is good. As it breaks down monopolies and give way to more innovative new companies.
It's good when we allow them to fail gracefully. I would hate to see what unscrupulous stuff a failing Google could do with all our info being held hostage.
No need to wait or wonder. Google Equifax.
One of the last innovations at HP was the work on Explicitly Parallel Instruction Computing and Very Long Instruction Word architectures that led to the Itanium IA-64 processors produced by Intel.
By putting the burden of scheduling parallelism on the compiler, does the EPIC design avoid speculative execution vulnerabilities, or did Intel implement Itanium with the same flaws?
By putting the burden of scheduling parallelism on the compiler, does the EPIC design avoid speculative execution vulnerabilities, or did Intel implement Itanium with the same flaws?
I'm well aware of the impressive achievements of the old HP. But I'm also aware that that era was already clearly over in the year 2000, and they were already a very different company from what their older reputation suggested. In 2000, there was no "collapse coming" for HP from anything like mismanagement or complacency; they weathered industry-wide troubles as well as any other company and didn't experience any personal catastrophes. If the next 20 years for Intel end up like the last 20 years for HP, then long-term investors will be quite satisfied.
HP? You mean Agilent-Keysight-HP? :p
They’ve split up into companies that are widely successful in each of their individual fields.
They’ve split up into companies that are widely successful in each of their individual fields.
The multiple splits and name changes didn't help brand recognition, at least on my end. I remember HP lab equipment being highly impressive and warranting its price. But I consistently fail to make the connection that Agilent amd Keysight products are the successors to that.
I agree. The rebrand to Keysight is the worst. Agilent was a good name by the time they split. Agilent still exists in medical but I know much less about that. I think everyone who works in test & measurement knows the big brands and knows keysight. All of the reps, culture, and products stayed the same.
The rebranding I’ll never understand is Fujitsu -> Socionext.
The rebranding I’ll never understand is Fujitsu -> Socionext.
> The rebranding I’ll never understand is Fujitsu -> Socionext.
I have to look it up... This is stupid. If I see a Fujitsu chip on a board, I know the brand and may find it interesting. But if I see a Socionext chip, I'll think it's some random U.S. startup from California.
I think there's a reason - Wikipedia says it's a joint venture of Fujitsu and Panasonic, so it makes sense for them to give it a new name, and it's common for these Japanese companies to choose a English name for global business (in the same way that NEC becomes Renesas due to the two reasons).
But what a terrible name!
I have to look it up... This is stupid. If I see a Fujitsu chip on a board, I know the brand and may find it interesting. But if I see a Socionext chip, I'll think it's some random U.S. startup from California.
I think there's a reason - Wikipedia says it's a joint venture of Fujitsu and Panasonic, so it makes sense for them to give it a new name, and it's common for these Japanese companies to choose a English name for global business (in the same way that NEC becomes Renesas due to the two reasons).
But what a terrible name!
HP used to be much more. It was a real innovative company.
But the interesting parts have been spun out like: Agillent and Keysight.
HP Enterprise was also spun out.
But the interesting parts have been spun out like: Agillent and Keysight.
HP Enterprise was also spun out.
Other than splitting off HPE, the HP of 2000 was pretty much the HP of today. As far as I'm aware, they're still major players today in all the markets that they were major players in back then, and none of those HP or HPE business units had to go through a collapse and start over.
Upvoted. Why downvote this comment? It does not have controversial political content nor personal attacks, it's just an OP's personal observation of HP's business performance. If someone disagrees, I'd like to hear you comment (I'm not the OP), rather than letting the comment sink to the bottom.
One of the problems with Intel culture - especially under BK was that the philosophy was "Focus on our key goals to the exclusion of everything else". It was meant to keep focus and ensure we moved quickly. The problem with that is it meant we were entirely unresponsive. It doesn't matter if something important has come up because you've already agreed what the priority is, you've already committed to what you're going to do. So even if something does come up, communicating that problem to the team that needs to fix it is impossible because you'll get ZBB'd (if we do this, we will drop that). Then once you've got engineering to commit, the bureaucracy won't let you just release anything so you need to line up into a release process.
I'm sure no one intended to mislead, but organisationally Intel just isn't designed to fix bugs. It doesn't have a process to respond to issues.
I'm sure no one intended to mislead, but organisationally Intel just isn't designed to fix bugs. It doesn't have a process to respond to issues.
Dumb question: Can you clarify what ZBB'd means in this context? I've never seen it before. There's a wiki page [0] with various meanings for the abbreviation, but nothing seemed to fit. Maybe Zero-based budgeting?
[0] https://en.m.wikipedia.org/wiki/ZBB
[0] https://en.m.wikipedia.org/wiki/ZBB
Zero-based budgeting. It effectively means that a project is no longer getting funded or staffed and is therefore dead.
I have to wonder how many bitter Pyrrhic victory jokes get made by victims of poor implementation based on the creator's last name - Pyrrh. I've seen too many companies destroyed by superficially attractive budgeting schemes, even with how much tech has started to acknowledge perverse incentives they seem to get overlooked. The worst I had direct experience with was a company where they moved to all income being credited to marketing & bizdev and all other parts of the company being treated as losses to be minimized. We were both advertising supported (and thus needed content to sell anything) and had professional products that required analysts, but they when the market started looking rougher they kept the sales & ad people and concentrated layoffs on people who produced things or ran the infrastructure.
Ultra-simplified bookkeeping interpreted through the lens of too much coke nearly destroyed them. The dotcom bubble was a very strange time.
Ultra-simplified bookkeeping interpreted through the lens of too much coke nearly destroyed them. The dotcom bubble was a very strange time.
That company culture and structure needs to change, and fast. Giants do fall.
Instead of focusing on a PR war and scrambling to salvage one fire after another, Intel needs to produce a strategy that will keep them in the game by actually providing value -- not by twisting the hands of big corps for lucrative long-term contracts.
Instead of focusing on a PR war and scrambling to salvage one fire after another, Intel needs to produce a strategy that will keep them in the game by actually providing value -- not by twisting the hands of big corps for lucrative long-term contracts.
>BK was that the philosophy was "Focus on our key goals to the exclusion of everything else".
The Key Goals for the past 4 years if not longer were to ship 10nm with respectable yield. Which as closing of 2019 still didn't happen.
So I am not even sure what they were focused on.
The Key Goals for the past 4 years if not longer were to ship 10nm with respectable yield. Which as closing of 2019 still didn't happen.
So I am not even sure what they were focused on.
Zen and Zen+ may have been strong competitors that Intel was unprepared for, but at least they were still competing, notably in per core performance. Now Zen 2 is out and Intel is taking a beating in every category, from price to power usage to multi core performance to single core performance and everything in between.
Meanwhile it became clear that a decent part of Intel's per core advantage was because of massive shortcuts they took, notably security wise, and so fixing those security holes takes away the performance.
In that situation, I doubt management at Intel is eager to take out yet another one of their shortcut. Intel needs a win, but they are not at all in the state of mind necessary to achieve one...
Meanwhile it became clear that a decent part of Intel's per core advantage was because of massive shortcuts they took, notably security wise, and so fixing those security holes takes away the performance.
In that situation, I doubt management at Intel is eager to take out yet another one of their shortcut. Intel needs a win, but they are not at all in the state of mind necessary to achieve one...
>So Intel failed to mitigate the vulnerability when it was first reported. Then they extended the embargo from May until November. And they still didn't fix it.
The assumption being that they could in the time given, but are sitting on their hands?
The assumption being that they could in the time given, but are sitting on their hands?
No. This timeline shows incompetence, not sitting on their hands: https://mdsattacks.com/#ng-full-story
Incompetence as in "they're incompetent engineers", and if so, compared to what baseline?
Or incompetence in as "they weren't capable of doing it"?
The latter is very probable. The former could underestimate the difficulty of such fixes...
Or incompetence in as "they weren't capable of doing it"?
The latter is very probable. The former could underestimate the difficulty of such fixes...
The two statements are identical, competence is always within a given context.
It's precisely because "competence is always within a given context" that the two statements are not identical.
Incompetent can mean "as to the particular project context" (i.e. they could be great engineers that din't manage to deliver the fixes for this issue), or "as to their general professional capacity" (i.e. they are lesser engineers).
Incompetent can mean "as to the particular project context" (i.e. they could be great engineers that din't manage to deliver the fixes for this issue), or "as to their general professional capacity" (i.e. they are lesser engineers).
Fair point. I read both statements in the context of the particular hardware bugs Intel's trying to fix, but I can see how my comment is quite vague.
No, the second is "incapable" and suggests that even a "great" engineer could not have done it.
The first one says that a "competent" engineer could have.
Big difference.
Big difference.
A great engineer can still be incompetent in the face of a difficult (or poorly specced) task.
[deleted]
> going all in with lying in benchmarks against AMD
I'm assuming this is referencing the "intentionally misleading benchmarks" piece in servethehome. It's worth reading the follow up, in which the author discovers their biggest complaint (older version doesn't have avx2 enabled by default on zen2) was not an issue because Intel manually enabled avx2.
https://www.servethehome.com/update-to-the-intel-xeon-platin...
I'm assuming this is referencing the "intentionally misleading benchmarks" piece in servethehome. It's worth reading the follow up, in which the author discovers their biggest complaint (older version doesn't have avx2 enabled by default on zen2) was not an issue because Intel manually enabled avx2.
https://www.servethehome.com/update-to-the-intel-xeon-platin...
They request all benchmark done with SMT off, they insist on doing their bench without the security fixes for Spectres/Meltdown applied, they use dubious TDP counting, ...
AMD has its fair share of issue in their own self published benchmarks, but at least when third party publish they're not forced to cripple other companies' chips.
AMD has its fair share of issue in their own self published benchmarks, but at least when third party publish they're not forced to cripple other companies' chips.
As addressed, the benchmarks in question were for HPC, where turning off SMT and running without mitigations is standard.
Intel has become big and rich and has stopped (or perhaps never was) being very responsible. Given their fairly entrenched position in the industry, it's doubtful this strategy will impact their profit all that much and therefore we can expect to see more of this behaviour in the future.
Thankfully AMD is making serious headway and will continue to take market share from Intel. It will take time but Intel should begin to feel the sting soon.
I'm nearly 20 years in mid to large companies, I've never seen an AMD cpu on a desktop, laptop or server. Its almost like nobody ever gets fired for buying Intel.
I'm 30+ years in. AMD shipped huge numbers of 8086/8088s as a second-source; you might have had one and not known it. But I'm guessing that's not what you mean. :-)
There was a good bit of time where Opterons where everywhere on servers, including things like the whole Sun x86 line. At one gig we had datacenters full of IBM blade servers stuffed with dual Opteron boards; they were a big success in the market. I know at one point another gig's non-US folks had significant installed base of AMD-based Fujitsu servers.
Didn't see as much on the desktop/laptop side, though I did carry a AMD-based Thinkpad for a short while. Apparently HP sold a successful, low-end, AMD-based business desktop.
YMMV...I think it's a matter of 'I haven't seen any tigers in my back yard, therefore I doubt they exist'.
There was a good bit of time where Opterons where everywhere on servers, including things like the whole Sun x86 line. At one gig we had datacenters full of IBM blade servers stuffed with dual Opteron boards; they were a big success in the market. I know at one point another gig's non-US folks had significant installed base of AMD-based Fujitsu servers.
Didn't see as much on the desktop/laptop side, though I did carry a AMD-based Thinkpad for a short while. Apparently HP sold a successful, low-end, AMD-based business desktop.
YMMV...I think it's a matter of 'I haven't seen any tigers in my back yard, therefore I doubt they exist'.
I've heard that AMD suddenly pulling out of the server market was very damaging for the relationship with vendors, hence (in part) their trouble of getting back in the door .
But it does seem that adoption is growing again, with recent performance figures and the attractive price point.
But it does seem that adoption is growing again, with recent performance figures and the attractive price point.
That's an interesting insight. Was it "pulled out" or "we screwed up the next gen product" though? Quite a gap between Opteron and Threadripper, so you're probably on to something.
So far there was no reason to fire for that.
The only bad period was where AMD Opteron gained a big market share in servers while Intel was doing Pentium 4 Netburst crap.
The only bad period was where AMD Opteron gained a big market share in servers while Intel was doing Pentium 4 Netburst crap.
A focus on managing by spreadsheet instead of focusing on good solid engineering, maybe?
That seems to be the new corporate PR move.
To reiterate the written words from the authors: Intel prevented this particular problem gets to the public and than they flat out lied to the customer.
> On July 3, 2019, we finally learned that, to our surprise, the Intel PSIRT team had missed the PoCs from our Sep 29 submission, despite having awarded a bounty for it, explaining why Intel had failed to address - or even publicly acknowledge - many RIDL-class vulnerabilities on May 14, 2019.
What does this usage of the word 'missed' mean in this context? That they lost it / failed to deliver the PoC to the relevant team? Or that they released a "fix" knowing that it didn't defeat the PoC?
What does this usage of the word 'missed' mean in this context? That they lost it / failed to deliver the PoC to the relevant team? Or that they released a "fix" knowing that it didn't defeat the PoC?
From the way the phrase is turned, I believe they released a fix that covered all previously known PoCs but not those from that submission.
Generally speaking, that really illustrate the dumb way Intel is going about it, fixing on a PoC basis rather than going after the strong underlying problem. It basically screams "there will always be issues, the question is can you find them !".
Generally speaking, that really illustrate the dumb way Intel is going about it, fixing on a PoC basis rather than going after the strong underlying problem. It basically screams "there will always be issues, the question is can you find them !".
AMD is suffering much less from these flaws. Seems they didn't ignore as many security boundaries with their implementation.
AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only.
AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
AMD processors were also vulnerable to spectre v2. I don't know the status of the mitigations or whether it was fixed in zen 2.
EDIT:
I found the list I made a few months back. no guarantees, but i think it is mostly accurate.
Meltdown: Intel, IBM, some ARM
Spectre v1: Intel, ARM, IBM, AMD
Spectre v2: Intel, ARM, IBM, AMD
Spectre v3a: Intel, ARM
Spectre v4: Intel, ARM, IBM, AMD
L1TF: Intel, IBM
Meltdown-PK: Intel
Spectre-PHT: Intel, ARM, AMD
Meltdown-BND: Intel, AMD
MDS: Intel
RIDL: Intel
EDIT:
I found the list I made a few months back. no guarantees, but i think it is mostly accurate.
Meltdown: Intel, IBM, some ARM
Spectre v1: Intel, ARM, IBM, AMD
Spectre v2: Intel, ARM, IBM, AMD
Spectre v3a: Intel, ARM
Spectre v4: Intel, ARM, IBM, AMD
L1TF: Intel, IBM
Meltdown-PK: Intel
Spectre-PHT: Intel, ARM, AMD
Meltdown-BND: Intel, AMD
MDS: Intel
RIDL: Intel
spectre v2, like v1, isn't one that is "fixable." The mitigations (retpoline & microcode updates) are essentially additions that are added in places where security checks are done to just disable speculation for that particular check. But you still have to choose when & where to use those or even if you opt to use them at all.
There are no sweeping fixes for either v1 or v2, and there probably won't be for a long time at best.
But the positive news is that v1 & v2 only matter at all if you do in-process sandboxing of untrusted code. Which most things don't do, so most things are not at any risk from it.
There are no sweeping fixes for either v1 or v2, and there probably won't be for a long time at best.
But the positive news is that v1 & v2 only matter at all if you do in-process sandboxing of untrusted code. Which most things don't do, so most things are not at any risk from it.
> But the positive news is that v1 & v2 only matter at all if you do in-process sandboxing of untrusted code.
I don't think this is accurate. It seems to be a widespread misunderstanding that started because the original proof of concept was within a single process. Spectre, before mitigations, allowed userspace to read kernel memory if appropriate gadgets in the kernel could be identified and exploited.
My understanding is the impact is only intra-process after mitigations.
I don't think this is accurate. It seems to be a widespread misunderstanding that started because the original proof of concept was within a single process. Spectre, before mitigations, allowed userspace to read kernel memory if appropriate gadgets in the kernel could be identified and exploited.
My understanding is the impact is only intra-process after mitigations.
L1TF was an incredibly stupid bug in Intel's L1 cache implementation. I very much doubt IBM's POWER chips had the same issue. Do you have any source for this?
Quoting from https://www.ibm.com/blogs/psirt/potential-impact-processors-...
"On August 15, 2018, security vulnerabilities codenamed Foreshadow/L1TF (CVE-2018-3620, CVE-2018-3646 and CVE-2018-3615) were announced. Two of the vulnerabilities (CVE-2018-3620 and CVE-2018-3646) could potentially impact Power Systems. The Firmware and OS patches released by IBM in February and March 2018 to address the original Meltdown vulnerability (CVE-2017-5754) also address the L1TF/Foreshadow vulnerability, except for Power 9 Systems running with KVM Hypervisor. OS patch for Power 9 KVM Systems will be made available soon. The Firmware and OS patches for all other Power Systems are available in this blog below.
The third L1TF/Foreshadow vulnerability (CVE-2018-3615) relates to SGX implementation and does not impact the Power Systems."
"On August 15, 2018, security vulnerabilities codenamed Foreshadow/L1TF (CVE-2018-3620, CVE-2018-3646 and CVE-2018-3615) were announced. Two of the vulnerabilities (CVE-2018-3620 and CVE-2018-3646) could potentially impact Power Systems. The Firmware and OS patches released by IBM in February and March 2018 to address the original Meltdown vulnerability (CVE-2017-5754) also address the L1TF/Foreshadow vulnerability, except for Power 9 Systems running with KVM Hypervisor. OS patch for Power 9 KVM Systems will be made available soon. The Firmware and OS patches for all other Power Systems are available in this blog below.
The third L1TF/Foreshadow vulnerability (CVE-2018-3615) relates to SGX implementation and does not impact the Power Systems."
Thank you!
L1TF is this: https://software.intel.com/security-software-guidance/insigh...
I'm surprised IBM did this. I thought better of them.
L1TF is this: https://software.intel.com/security-software-guidance/insigh...
I'm surprised IBM did this. I thought better of them.
AFAIK Spectre variant 1 only applies to a single address space; i.e. per process.
Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.
Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.
There used to be a time when people thought relying on if statements for security was enough and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs. Now we know better.
1 - https://en.wikipedia.org/wiki/Singularity_(operating_system)
1 - https://en.wikipedia.org/wiki/Singularity_(operating_system)
> and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs
WebAssembly doubles down on it today.
Technically, though, software isolated lightweight processes within the same address space is still a very real possibility, it's just that isolation is up to the compilers now that have to emit spectre-proof code, so no native blobs. Which, let's get real, has to happen sooner or later for all userspace code, because hardware can't be trusted.
WebAssembly doubles down on it today.
Technically, though, software isolated lightweight processes within the same address space is still a very real possibility, it's just that isolation is up to the compilers now that have to emit spectre-proof code, so no native blobs. Which, let's get real, has to happen sooner or later for all userspace code, because hardware can't be trusted.
You can't trust any computation on hardware that cannot be trusted. There is no way to check that. Any software implemented check to detect that can be thwarted by hardware that misbehaves in malicious ways. Imagine an address based instruction replacement table that is used to convert some key consitional branches into unconditional ones.
> hardware can't be trusted
"Spectre-proof" code are specific workarounds for hardware bugs, not protection against all hardware security issues.
"Spectre-proof" code are specific workarounds for hardware bugs, not protection against all hardware security issues.
Obviously. Hardware can't be trusted to do secure isolation, this is the context here.
Web browsers didn't (still don't AFAIK) use one process per website visited..
> AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only.
> AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
Putting memory permissions check in retirement stage of the pipeline couldn't be accidental, I say...
Sounds like a great "efficiency hack". Till it fucks up.
> AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
Putting memory permissions check in retirement stage of the pipeline couldn't be accidental, I say...
Sounds like a great "efficiency hack". Till it fucks up.
[deleted]
There are some architectural differences that help amd with this specific issues, but I’m pretty sure main reason is just scale - amd is still niche nowadays and receives much less scrutiny and attention from security researchers
Another nail in the casket lake. Is the solution just to throw everything out and start again? Do we just abandon speculative execution?
The problem for most of these is not speculative, it's not doing proper acl during speculation. Just because the cpu is speculating doesn't mean it shouldn't check if you are allowed to access this or that, but that's what Intel did, and they only did the security check at the end before giving back the result, except at this point its too late you've already accessed it.
Other manufacturers AMD included didn't get affected by those variants.
Other manufacturers AMD included didn't get affected by those variants.
I wonder what the performance costs of those ACL checks are.
A single one might not be that big, but they add up (if there are several suchs checks to do in your speculated branch, instead of doing them when they appear during speculation intel chips pooled them up all at the end), and they disappear if the speculation was wrong (speculated the wrong branch ? Didn't lose any time on permission check).
They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations.
They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations.
> They're the >~10% of cpu perf intel chips have lost in the last few years with all the mitigations.
Given AMD's Zen 2 has comparable IPC to Intel at this point without doing the ACL check late it's not evident that the difference in when the ACL is done was a key efficiency gain.
Given AMD's Zen 2 has comparable IPC to Intel at this point without doing the ACL check late it's not evident that the difference in when the ACL is done was a key efficiency gain.
I was not talking about intel's 10% lead over AMD, I was talking about chips from 3-4 years ago, when tested again now with mitigations, perform 10% worse or more in affected workload (see https://www.phoronix.com/scan.php?page=article&item=intel-ic... for exemple)
Surely the mitigations are not the same as "doing proper acl during speculation" in the first place and have a worse performance hit?
They get that IPC on a better process. Shorter gate delays let you pack more into each cycle. IPC can't be divorced from process when comparing architectures.
IPC is from design not from transistor density. Clock speed is what can't be divorced from process. IPC can be. More transistors could enable new designs not previously feasible, but we've loooong since past that point (hence why most new transistors are just being dumped into L3 cache)
Part of the driver of IPC is how many layers of logic you can fit between each pipeline register. We’re not talking density we’re talking logic gate delay.
Each process has different delay, setup, and hold times. On one process I might be able to fit 15 layers of logic before I have to add a pipeline stage. On another I might be able to fit 20 at the same frequency. Pipeline stages are also not free with each adding additional overhead.
This determines how advanced I can make things like my branch predictor or cache pre-fetcher while still meeting timing requirements. For example I might want a larger lookback buffer but I can’t use a larger memory - not because of how much area it takes but because it simply takes too long to do the look up now.
Each process has different delay, setup, and hold times. On one process I might be able to fit 15 layers of logic before I have to add a pipeline stage. On another I might be able to fit 20 at the same frequency. Pipeline stages are also not free with each adding additional overhead.
This determines how advanced I can make things like my branch predictor or cache pre-fetcher while still meeting timing requirements. For example I might want a larger lookback buffer but I can’t use a larger memory - not because of how much area it takes but because it simply takes too long to do the look up now.
AMD and others are fine. Just have security people on the team during microarchitecture design.
Spectre variant 1 is probably unavoidable so security inside a single virtual address space is kinda dead. Use separate processes and mmu.
Spectre variant 1 is probably unavoidable so security inside a single virtual address space is kinda dead. Use separate processes and mmu.
Or we abandon sharing the same hardware for trusted and untrusted code. (Yes, that includes things like whitelisting JS.)
Abandoning speculation entirely is too much. If you just go to in order with a reasonable pipeline length nobody has yet figured a way to smuggle out speculative state on something like an ARM A53. That means giving up performance but only a factor of 4 or so. Giving up speculation entirely would mean an order of magnitude larger performance loss.
I worked at Intel in 1998 as a young engineer a few years out of college. Back then they were riding high on their CPU monopoly.
I left in about a year and a half and moved to a startup company. My issue with Intel was that, as a monopoly, they had grown fat and complacent.
I am not exaggerating when I say that in 1998-99, engineers were working maybe 4-5 productive hours in a week. Political savvy and alliance-building were the most important things for promotions and influence.
Those who actually produced good work had credit for their work diluted through many layers of management. You could do something amazing and your manager's manager might present it in a powerpoint to the company without mentioning your name at all, and acting like the idea was his all along.
I'm surprised the company has lasted this long. Its a place where mediocre people gather.
I left in about a year and a half and moved to a startup company. My issue with Intel was that, as a monopoly, they had grown fat and complacent.
I am not exaggerating when I say that in 1998-99, engineers were working maybe 4-5 productive hours in a week. Political savvy and alliance-building were the most important things for promotions and influence.
Those who actually produced good work had credit for their work diluted through many layers of management. You could do something amazing and your manager's manager might present it in a powerpoint to the company without mentioning your name at all, and acting like the idea was his all along.
I'm surprised the company has lasted this long. Its a place where mediocre people gather.
another 0-4% performance hit for skylake
The really damning part is that it applies even for processors that are supposedly fixed in silicon because Intel dropped the ball by playing wack-a-mole with proof of concept exploits instead of thoroughly building their chips with security in mind.
If the history of Microsoft and Windows security is any indication, it'll take Intel many many years to turn that ship around.
There's a question of whether AMD has been mostly unaffected only because their chips haven't received as much scrutiny, but for the time being it does seem that if you care about security, you'd better go with Epyc.
If the history of Microsoft and Windows security is any indication, it'll take Intel many many years to turn that ship around.
There's a question of whether AMD has been mostly unaffected only because their chips haven't received as much scrutiny, but for the time being it does seem that if you care about security, you'd better go with Epyc.
I don't think anyone seriously expected Intel to be able to thoroughly harden their chips against Spectre-style attacks given just a year to tweak their existing microarchitecture. They were able to move some permissions checks ahead of some speculative actions, but they simply haven't had enough time to design an architecture that can unwind all observable side-effects of mispredictions. It was obvious that all the near-term fixes in silicon would be equivalent to or only slightly better than the microcode or OS-based mitigations.
AMD’s speculative execution design is more risk aversive and it isn’t prone to many of the bugs identified so far. Of course this may change but I think it’s more than just scrutiny: AMD speculates less.
Plus, with better IPCs on Ryzen and much greater performance per dollar, why Intel?!
Plus, with better IPCs on Ryzen and much greater performance per dollar, why Intel?!
> If the history of Microsoft and Windows security is any indication, it'll take Intel many many years to turn that ship around.
AMD's Bulldozer debacle may be a better example, because in some ways it's a better example than Windows.
By that, I mean two things.
1) Silicon typically has a pretty long up-front design phase. Meaning there's probably at least 2 upcoming generations in development at any given time.
2) Intel's marketing is somewhat coy about 'architecture' changes, but the sources I found (admittedly just an SO post and Wikipedia) indicate that the number of pipeline stages in the Core series has not changed much over the last few years. IOW it's probably not a full architecture revamp in their 3-step cycle.
P6 as an Arch lasted around 15 years, when you think about it (including the original 'Core' i.e. Core 2 Duo/Solo here, as while heavily optimized and revamped, it was still P6). K7/K8 lasted about the same longer (15-ish). Netburst was a bit of an outlier, only lasting around 7 years. Same for Bulldozer.
Big assumption here, but based on the pattern I'd assume that Intel originally wasn't even considering a full revamp (or, depending on how they do their iterations, it wouldn't be fully revamped) to be ready until around 2023.
Because of the time involved (back to the first point,) I doubt they would be able to have the problem mitigated in silicon until 2021 at the earliest. (As a bonus, they'd probably want/have to qualify it extra well, lest they accidentally introduce a whole new class of vulnerabilities.)
AMD's Bulldozer debacle may be a better example, because in some ways it's a better example than Windows.
By that, I mean two things.
1) Silicon typically has a pretty long up-front design phase. Meaning there's probably at least 2 upcoming generations in development at any given time.
2) Intel's marketing is somewhat coy about 'architecture' changes, but the sources I found (admittedly just an SO post and Wikipedia) indicate that the number of pipeline stages in the Core series has not changed much over the last few years. IOW it's probably not a full architecture revamp in their 3-step cycle.
P6 as an Arch lasted around 15 years, when you think about it (including the original 'Core' i.e. Core 2 Duo/Solo here, as while heavily optimized and revamped, it was still P6). K7/K8 lasted about the same longer (15-ish). Netburst was a bit of an outlier, only lasting around 7 years. Same for Bulldozer.
Big assumption here, but based on the pattern I'd assume that Intel originally wasn't even considering a full revamp (or, depending on how they do their iterations, it wouldn't be fully revamped) to be ready until around 2023.
Because of the time involved (back to the first point,) I doubt they would be able to have the problem mitigated in silicon until 2021 at the earliest. (As a bonus, they'd probably want/have to qualify it extra well, lest they accidentally introduce a whole new class of vulnerabilities.)
What are we down to now? 70%? 80%? of original performance with all the mitigations added up by now?
If a car was advertised as emitting 20% less pollution than it actually did, people would be pissed[1]!
[1]: https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal
If a car was advertised as emitting 20% less pollution than it actually did, people would be pissed[1]!
[1]: https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal
I'm glad I started off not overclocking my 6700k with the intent of cranking up the clock over time in order to maintain the same performance with regard to software bloat and mitigations like these. I got lucky and can hit 5Ghz safely, with a base of 4Ghz.
Definitely jumping to AMD next time around though. My next upgrade was originally going to be dual Xeons but those Ryzen Pro 3000s are looking nice.
Definitely jumping to AMD next time around though. My next upgrade was originally going to be dual Xeons but those Ryzen Pro 3000s are looking nice.
Yeah I'm looking into upgrading my 6500 to a Ryzen 3 3600. It's a shame there's no B550 boards yet.
From what we've seen so far B550 is pretty much just x470 (no PCIE4). And B450, B350 boards will do fine running a 3600. I don't really see a point waiting for B550.
It's mostly just that I'm afraid I'll order a board that isn't on the latest bios, which will be a headache.
And an excuse to postpone.
And an excuse to postpone.
Some MSI motherboards (and maybe others?) have a "Flashback" feature to flash BIOS from a USB storage device without needing a CPU.
I was completely unaware of this feature, and blissfully saved by it when building a computer for a family member. It's a killer feature.
Oh nice, I had no idea. I might pull the trigger on black friday then.
Can confirm, mine supports this.
I recall a Google security blog that spoke more generally that with so many layers of code that you don't know what they're doing the result is that effectively they consider any speculative execution that exists at the time of writing the blog may be a potential vulnerability.
Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will
have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels.
- name: Disable CPU-sapping security mitigations
become: yes
lineinfile:
path: /etc/default/grub
line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off"
- name: Update grub
become: yes
command: /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.
There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes.
It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't be running JS anyway.
It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't be running JS anyway.
What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0]
Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution.
Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably the most stupid thing you can do to disable these mitigations because they're not just theoretical, they're real, they're here and everyone knows about them.
This is like anti-vaxx philosophy. "the risk is low"; well, maybe the risk is low because of herd immunity, it's not feasible to run these attacks as they'll be obvious to those who have the mitigations in place (100% CPU), but if there's a 0.00000001% return then it becomes profitable to exploit, just like mail spam.
Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. Unless you can work without javascript and I doubt you can because the web today is basically unusable without it.
If you have a database which is only accessible internally, you can disable the mitigations, because those things are hit hardest by the mitigations and do not run untrusted code.
But really, your desktop is running untrusted code _a lot_. Please do not do this, not only for your own sake but for everyones sake. Don't make it profitable for malicious agents to run these attacks.
[0]: https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_...
Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution.
Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably the most stupid thing you can do to disable these mitigations because they're not just theoretical, they're real, they're here and everyone knows about them.
This is like anti-vaxx philosophy. "the risk is low"; well, maybe the risk is low because of herd immunity, it's not feasible to run these attacks as they'll be obvious to those who have the mitigations in place (100% CPU), but if there's a 0.00000001% return then it becomes profitable to exploit, just like mail spam.
Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. Unless you can work without javascript and I doubt you can because the web today is basically unusable without it.
If you have a database which is only accessible internally, you can disable the mitigations, because those things are hit hardest by the mitigations and do not run untrusted code.
But really, your desktop is running untrusted code _a lot_. Please do not do this, not only for your own sake but for everyones sake. Don't make it profitable for malicious agents to run these attacks.
[0]: https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_...
Can you please not post in the flamewar style to HN, regardless of how right you are or feel you are? It degrades the site and provokes worse from others, and we need better than that here. Also, it poisons any good information in your comment.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
From the comment in your link:
> It's missing the entire actual implementation of the Spectre attack, which requires analysis of read times to see if you're hitting the processor cache or not.
"analysis of read times" is what the browsers "fixed" to mitigate the attacks (and site isolation later). Again, there has been no working attacks on updated browsers.
Please feel free to link an example of one though, I will gladly admit I'm wrong. You just seem to frankly have no idea how the exploits actually work though (did you actually read the code in the reddit post?), so I suspect that this conversation will be a waste of time.
> It's missing the entire actual implementation of the Spectre attack, which requires analysis of read times to see if you're hitting the processor cache or not.
"analysis of read times" is what the browsers "fixed" to mitigate the attacks (and site isolation later). Again, there has been no working attacks on updated browsers.
Please feel free to link an example of one though, I will gladly admit I'm wrong. You just seem to frankly have no idea how the exploits actually work though (did you actually read the code in the reddit post?), so I suspect that this conversation will be a waste of time.
The browser mitigation’s only work with the kernel mitigation’s. Neither is working well without the other. And yes. I’m very well versed on this topic.
>The browser mitigation’s only work with the kernel mitigation’s.
That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.
That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.
The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time.
The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers.
But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand.
You just make these attacks more likely; I'm not going to be impacted except for a few trillion CPU cycles of idiots trying to exploit me.
You're the one who puts their entire digital life on the line by eking out 5% performance.
The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers.
But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand.
You just make these attacks more likely; I'm not going to be impacted except for a few trillion CPU cycles of idiots trying to exploit me.
You're the one who puts their entire digital life on the line by eking out 5% performance.
>The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time.
Oh, so it just takes more time, so you have knowledge of an exploit? Fine, show me any PoC or similar bypassing the lower accuracy and site isolation.
You are such a big part of the problem with how this whole class of exploits have been handled. No technical knowledge, just spewing stuff like "You're the one who puts their entire digital life on the line", when we there is no indication that anything like that can transpire.
Please stop spreading misinformation.
Oh, so it just takes more time, so you have knowledge of an exploit? Fine, show me any PoC or similar bypassing the lower accuracy and site isolation.
You are such a big part of the problem with how this whole class of exploits have been handled. No technical knowledge, just spewing stuff like "You're the one who puts their entire digital life on the line", when we there is no indication that anything like that can transpire.
Please stop spreading misinformation.
Personal attacks are not ok on HN and we ban accounts that do that, so please don't do that—regardless of how wrong another comment is or you feel it is.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement.
This is not misinformation, _you_ are spreading "certainty" of safety surrounding a dangerous idea.
https://spectreattack.com/spectre.pdf
Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
This is not misinformation, _you_ are spreading "certainty" of safety surrounding a dangerous idea.
https://spectreattack.com/spectre.pdf
Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
>Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement.
Yeah, which was why SharedArrayBuffer was disabled when spectrev1 was released. It is still disabled in Chrome if site-isolation is disabled and it's still disabled in firefox.
You should really know all this if you are so very well versed in the subject.
>Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
I don't run without migrations. I commented on the original parent comments threat model and that I think it's perfectly logical. And I maintain this, if your threat model is so strict, that you are afraid of speculative execution vulnerabilities hitting you through javascript, you should not run JS at all, as regular js 0days have hit while no actual speculative execution browser exploits have hit.
Yeah, which was why SharedArrayBuffer was disabled when spectrev1 was released. It is still disabled in Chrome if site-isolation is disabled and it's still disabled in firefox.
You should really know all this if you are so very well versed in the subject.
>Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.
I don't run without migrations. I commented on the original parent comments threat model and that I think it's perfectly logical. And I maintain this, if your threat model is so strict, that you are afraid of speculative execution vulnerabilities hitting you through javascript, you should not run JS at all, as regular js 0days have hit while no actual speculative execution browser exploits have hit.
“Threat model is so strict” is weird to say when any ad network can access any and all memory on your desktop potentially.
That’s a very wide attack scope.
That’s a very wide attack scope.
Ha, I had the same thought, comparing this to antivaxxers.
The downsides are of course, infinitely lower (stolen password vs disability or death), but yeah the similarity is there.
We've yet to see a real world attack using any of these, however.
The downsides are of course, infinitely lower (stolen password vs disability or death), but yeah the similarity is there.
We've yet to see a real world attack using any of these, however.
Browser 0-days still often run on user priviledges. The moment you get code-execution on a vulnerable Intel CPU that turns into hardware level access.
And like the other commenter said, there are also JS implementations.
And like the other commenter said, there are also JS implementations.
[deleted]
> There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0).
sure dude, sure
sure dude, sure
Chrome: CVE-2019-13720, CVE-2019-5786
Firefox: CVE-2019-11707/CVE-2019-11708
Your turn. Link the speculative execution 0days.
Your turn. Link the speculative execution 0days.
Here's an example of post-mitigation reading of protected memory using Javascript and Spectre https://alephsecurity.com/2018/06/26/spectre-browser-query-c...
I think it's just silly that you would rely on browser mitigations like disabling high precision timers when that's obviously just a hack.
I think it's just silly that you would rely on browser mitigations like disabling high precision timers when that's obviously just a hack.
As is said in the PoC, it does not bypass index masking and site-isolation. They read data already available to the code they are executing. They did show that the timer resolution mitigation is not 100% effective, which is well known and why it is not the only mitigation.
That's not a speculative execution browser 0day, as it doesn't work in updated browsers and it never has (or I guess it works if you want to leak data you could just console.log). Could you post an actual 0day instead?
That's not a speculative execution browser 0day, as it doesn't work in updated browsers and it never has (or I guess it works if you want to leak data you could just console.log). Could you post an actual 0day instead?
Not every computer runs a web browser. Of the hundreds of high performance cores I have, only a couple run a web browser. ... thought increasingly more of them are non-intel.
What about a network stack? Are they running one of those exposed to adversaries? http://www.misc0110.net/web/files/netspectre.pdf
Very interesting link! but indeed, I have a lot of cores that are just on a private network.
FYI, you can do the same thing with drop-in config files and avoid the annoying dpkg-conffile prompt whenever you upgrade grub2-common:
$ cat /etc/default/grub.d/mitigations.cfg
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT mitigations=auto,nosmt">No I don't give a fuck about the 'risk' this introduces
Well, let's hope you're not powned because of this and get dragged into giving some fucks, for a 5-10% of performance hit you wouldn't notice anyway...
Well, let's hope you're not powned because of this and get dragged into giving some fucks, for a 5-10% of performance hit you wouldn't notice anyway...
Anecdotally, the performance hit from the security mitigations since the Spectre/Meltdown publication has been very noticeable.
More anecdata: On my workloads, which involves moving large discrete image frames as part of a video inference ML pipeline through a message broker and other processing pipelines, de-mitigating decreased system loads ~25% on average. Some workloads up to 30% depending on inference model. So yes noticeable.
Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ? And they are not particularly unique.
Do you understand my risk and load requirements better than I do ?
Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ?
But thanks for your concern and all.
Do you understand my risk and load requirements better than I do ?
Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ?
But thanks for your concern and all.
>Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ?
You'd be surprised what people would do. Could be just out of some spite ("fuck Intel"). Could not even include any measurable workloads ("I want my machine to go ultra fast").
>Do you understand my risk and load requirements better than I do ?
For you particularly probably not, but you'd be surprised how many times a third party can "understand the risk and load requirements" of someone else (even a business) better than they do.
E.g. the "No, you don't need a Hadoop cluster for doing "ML" on a 1GB file", phenomenon.
>Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ?
Only briefly, cause the tone of the comment made it sound more of a knee jerk reaction ("No I don't give a fuck about the 'risk' this introduces", "until everything is swapped to AMD") doesn't sound like the fruits of rational analysis...
You'd be surprised what people would do. Could be just out of some spite ("fuck Intel"). Could not even include any measurable workloads ("I want my machine to go ultra fast").
>Do you understand my risk and load requirements better than I do ?
For you particularly probably not, but you'd be surprised how many times a third party can "understand the risk and load requirements" of someone else (even a business) better than they do.
E.g. the "No, you don't need a Hadoop cluster for doing "ML" on a 1GB file", phenomenon.
>Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ?
Only briefly, cause the tone of the comment made it sound more of a knee jerk reaction ("No I don't give a fuck about the 'risk' this introduces", "until everything is swapped to AMD") doesn't sound like the fruits of rational analysis...
> Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ?
What do you mean by `resource management modeling` in this context? Do you mean `capacity planning` or `system scaling planning` or something else altogether?
What do you mean by `resource management modeling` in this context? Do you mean `capacity planning` or `system scaling planning` or something else altogether?
You can do the same thing on Windows by using InSpectre: https://www.grc.com/inspectre.htm
And yet, despite all of its security problems and issues with Intel, server vendors are buying more Intel than ever. On one hand they complain about Intel's pricing, threatening about making their CPU with POWER or ARM, on the other hand they happily use AMD as a tool to get better pricing.
The sales number dont lie, AMD doesn't even account for 10% of Server CPU shipment, and may not even happen in 2020 given Intel's new price cut.
The sales number dont lie, AMD doesn't even account for 10% of Server CPU shipment, and may not even happen in 2020 given Intel's new price cut.
Is it possible to apply the mitigations on an per-application level in Windows? IMHO it'd be pretty useful to be able have them on by default, but disable them for specific applications where you care about maximum performance and know that you won't be running untrusted code.
Surely if you emulate a processor without speculative execution with good fidelity (Such as a good NES emulator) then the program running ON that emulator can't deduce anything from speculative execution?
Is the answer (for home users) to just sandbox some processes under an emulator layer? I'd be happy to just sandbox some sensitive processes like my browser even if it took a huge performance hit, so long as some other apps like games did not take the same hit.
Is the answer (for home users) to just sandbox some processes under an emulator layer? I'd be happy to just sandbox some sensitive processes like my browser even if it took a huge performance hit, so long as some other apps like games did not take the same hit.
Not very likely: the attacker is outside the emulated vulnerability-free sandbox, and the state of the emulator is exposed like the state of any other program.
Accessing the emulator's memory means accessing the emulated program's memory, it's just slightly obfuscated.
Accessing the emulator's memory means accessing the emulated program's memory, it's just slightly obfuscated.
How is the attacker outside, assuming it's a process running on the emulator (I.e. the attacker surface here in the emulator example would be only the NES game, so he has to work with NES cpu opcodes, NES memory locations etc)?
Spectre was exploitable from javascript, so all of your same questions apply there. The answer is that a virtual env like that doesn't really stop an attacker, they just have to sort of meta program what they want the emulator to do rather than writing native machine code themselves. A little harder, but still doable.
The attacker is not a process running on the emulator, not even if you assume it is. Security is about the worst case, not about hit or miss partial solutions.
I’m talking about a hypothetical future where there are mitigations in place such as running each app sandboxed in an emulator. Obviously if a malicious process can sidestep any such mitigation and run any way it wants, then presumably it can read the memory of any process too? Why would an app even need to rely on vulnerabilities then?
If this is your scenario, the attacker runs in its own emulator. A fairly thick pair of gloves, but not enough to prevent exploiting speculative execution vulnerabilities and reaching outside the emulator to poke into other processes.
As another comment points out, attacks from Javascript code that escape the browser sandbox have been demonstrated, which is exactly your sandboxing scenario minus the easy part of targeting what an emulator is emulating.
As another comment points out, attacks from Javascript code that escape the browser sandbox have been demonstrated, which is exactly your sandboxing scenario minus the easy part of targeting what an emulator is emulating.
> attacks from Javascript code that escape the browser sandbox have been demonstrated
As far as I understand you still need to be able to have some kind of timing information or cpu state available in the sandboxed program, which is possible if the emulator/sandbox runs close enough to the metal (Such as a js program in a modern browsee, because they need to be fast). Remove ALL timing info and it should be possible to make it impossible to exploit speculative execution. It might run 1000x or 10000x slower than a modern JS engine however.
As far as I understand you still need to be able to have some kind of timing information or cpu state available in the sandboxed program, which is possible if the emulator/sandbox runs close enough to the metal (Such as a js program in a modern browsee, because they need to be fast). Remove ALL timing info and it should be possible to make it impossible to exploit speculative execution. It might run 1000x or 10000x slower than a modern JS engine however.
I need to reiterate that optimism ("remove all timing info...") has no place in information security.
If you think you have removed all timing information sources you are aware of, many remain: those you aren't aware of at all, those you failed to recognize as exploitable, those you didn't actually remove by mistake, those that are degraded but still present... The attacker should be assumed to be clever and knowledgeable; as the saying goes, creating a system that you don't know how to crack is easy.
If you think you have removed all timing information sources you are aware of, many remain: those you aren't aware of at all, those you failed to recognize as exploitable, those you didn't actually remove by mistake, those that are degraded but still present... The attacker should be assumed to be clever and knowledgeable; as the saying goes, creating a system that you don't know how to crack is easy.
I suppose you could run your trusted applications in the top-most Windows instance without mitigations, and run untrusted applications in a virtualized Windows instance with mitigations enabled. Wouldn't be pretty or very practical, but I suppose it might work?
Tagging on with a similar query. I am on Windows 10. If I were to run Firefox in sandboxie, would be the attacker have to deal with an extra layer of security or does it offer no help?
It will offer no help;
for context, imagine that the attacker has access to all memory on the system. It's not -exactly- like that for a bunch of reasons but realistically it's very similar.
for context, imagine that the attacker has access to all memory on the system. It's not -exactly- like that for a bunch of reasons but realistically it's very similar.
Ok this has been bugging me for a while. How does speculative execution roll back side effect like write to disk or send a packet on the network, when the speculation is wrong. At a guess there are safe instructions that can be run when doing branch prediction?
Nothing like that happens. Writes to dram or pcie devices or data bus cannot be rolled back. You have a misunderstanding of what speculative execution entails. The things that get rolled back are writes to general purpose registers.
I/O takes seven eternities in microcode-ville. It doesn't hurt too much to wait for the speculation to be resolved before changing state visible outside the microarchitecture of the CPU.
Accesses to memory that is configured for device I/O (UnCacheable in x86 terms) are never speculated, so there’s nothing to roll back.
Can we please have an architectural MSR to disable TSX?
The good news: There's a new MSR which lets you do this:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
The less good news: as far as I can tell, Intel did not commit to how architectural this will be going forward. Considering the role TSX has played in speculation-based attacks, it appears to me to be a generic mitigation that would be great to accompany TSX wherever it is available in the future. Now that MSR_IA32_TSX_CTRL is defined, it should be easier to implement going forward.
Disclaimer: I work on Linux at Intel.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
The less good news: as far as I can tell, Intel did not commit to how architectural this will be going forward. Considering the role TSX has played in speculation-based attacks, it appears to me to be a generic mitigation that would be great to accompany TSX wherever it is available in the future. Now that MSR_IA32_TSX_CTRL is defined, it should be easier to implement going forward.
Disclaimer: I work on Linux at Intel.
...speculation attacks, and outright bugs in TSX, and the fact that even when everything is working it's a timing mechanism that VMX can't intercept. I really hope it becomes architectural (and gains a bit for HLE)!
Ah, but TSX is also used to block attacks (on SGX enclaves). So just disabling it entirely seems over simple.
What would the performance impact be if they simply took away speculative execution (but not cashing)?
Is disabling hyper-threading a via work-around for these vulnerabilities?
My understanding is that this works for many (but not all) of the vulnerabilities. Interestingly, in the past few years Intel has dramatically increased the number of non-SMT processors on their product list.
If that is going to be your personal way of mitigating the issue, you've got a choice of 4, 6, and 8 core parts at a significant discount compared to their HyperThreaded variants.
If that is going to be your personal way of mitigating the issue, you've got a choice of 4, 6, and 8 core parts at a significant discount compared to their HyperThreaded variants.
Lord Theo was right again!
[deleted]
One question- do these vulnerabilities , including spectre and meltdown only help in stealing information or can they also hijack your computer to do arbitrary things?
depends on the information you steal.
If you steal passwords, then you can use said password to hijack whatever the passwords are protecting.
If you steal private keys, you may be able to use said keys to impersonate the victim (like via ssh into their remote machines).
But if you're asking if speculative vulns could directly lead to remote code execution, then no (since you already have given the attacker a measure of control, as they are able to execute code already).
If you steal passwords, then you can use said password to hijack whatever the passwords are protecting.
If you steal private keys, you may be able to use said keys to impersonate the victim (like via ssh into their remote machines).
But if you're asking if speculative vulns could directly lead to remote code execution, then no (since you already have given the attacker a measure of control, as they are able to execute code already).
It can be used to defeat ASLR, which is a way to make exploiting code harder. However, defeating ASLR just makes it easier to deploy an exploit against a program, but you still need the exploit.
It doesn't immediately give code exec, but generally it wouldn't be very hard to turn arbitrary memory read capabilities into privilege escalation. As long as you know what the system is running.
It doesn't immediately give code exec, but generally it wouldn't be very hard to turn arbitrary memory read capabilities into privilege escalation. As long as you know what the system is running.
So the sense I'm making is- that most of thesr attacks need to be supervised and need you to be a target in particular?
The attacker needs some way to execute code on your machine. The code doesn't need any special permissions, although attacks are more difficult (but not impossible) if it doesn't have access to high resolution timing information. You can be a target by visiting a webpage with JavaScript enabled.
[deleted]
To exploit these vulnerabilities, you already need (unprivileged, sandboxed) RCE.
These vulnerabilities "only" steal information; however that information could of course be leveraged into privilege escalation or anything else.
These vulnerabilities "only" steal information; however that information could of course be leveraged into privilege escalation or anything else.
This isn't true unfortunately.
Being able to cause manipulate the control flow of code that already exists on the computer can be sufficient. See netspectre for an example that worked on real google cloud vms and local wired networks.
http://www.misc0110.net/web/files/netspectre.pdf
Being able to cause manipulate the control flow of code that already exists on the computer can be sufficient. See netspectre for an example that worked on real google cloud vms and local wired networks.
http://www.misc0110.net/web/files/netspectre.pdf
Wow, that is impressive.
Yes in theory you could do that, but to actually exploit in practice I would have guessed couldn't be done.
Yes in theory you could do that, but to actually exploit in practice I would have guessed couldn't be done.
Don't get too excited. From the paper: "In the Google cloud, we leak around 3 bits per hour from another virtual machine." This is, of course, under ideal conditions.
They estimated that with some dedicated hardware they could improve that by 2-10x.
Still not very useful for an attacker.
But still fascinating and impressive they could do it at all.
Still not very useful for an attacker.
But still fascinating and impressive they could do it at all.
> To exploit these vulnerabilities, you already need (unprivileged, sandboxed) RCE.
Such as running JavaScript code served by an ad network.
Such as running JavaScript code served by an ad network.
Correct.
Point being, running arbitary (unprivileged, sandboxed) code is a prerequisite; an attacker can already max your CPU, mine crypto, etc.
Point being, running arbitary (unprivileged, sandboxed) code is a prerequisite; an attacker can already max your CPU, mine crypto, etc.
[deleted]
This is troubling.