Wednesday, August 15th 2018

New "L1 Terminal Fault" Security Vulnerability Affects Intel Processors, Mitigation Out

by
btarunr
 Discuss (48 Comments)
A new series of CPU vulnerabilities affecting Intel processors emerged from the company's security bounty-hunter program, which are an exploitation of the L1 terminal fault. The vulnerability affects Intel processors that support SGX (Software Guard Extensions). A multinational group of researchers from KU Leuven University, Technion - Israel Institute of Technology, University of Michigan, University of Adelaide and Data61 chronicled the vulnerability. The exploit involves interpreting and deriving data from timing the L1 cache. You'll recall that NetSpectre was a similar timing-based bit derivation exploit, what's being measured here instead, is how the L1 cache SRAM refreshes itself to different patterns of bits, and transcribing them to bits and bytes on the other end. We imagine a mitigation to this bug would be to randomize the L1$ timers.

Intel these days is releasing CPU microcode updates faster than King updates Candy Crush with new offline banner ads. The company was sure to have a mitigation for this vulnerability ready before disclosing it to the public. The company, in a statement, said that it's working tireless to get customers to install the updates. The three variants of the L1 Timing Fault vulnerability are chronicled in CVE-2018-3615, CVE-2018-3620, and CVE-2018-3646.
Intel's briefs for each of the three vulnerabilities follows:
  • L1 Terminal Fault-SGX (CVE-2018-3615)-Systems with microprocessors utilizing speculative execution and Intel SGX may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via side-channel analysis.
  • L1 Terminal Fault-OS/ SMM (CVE-2018-3620)-Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access via a terminal page fault and side-channel analysis.
  • L1 Terminal Fault-VMM (CVE-2018-3646)-Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access with guest OS privilege via a terminal page fault and side-channel analysis
Intel setup a micro-site dedicated to this class of vulnerabilities, which not only gives you technical information, but also mitigation.Image courtesy Byte Notes

Related News

Add your own comment

48 Comments on New "L1 Terminal Fault" Security Vulnerability Affects Intel Processors, Mitigation Out

#26
Steevo
How is Intel faster at IPC?

No cache security, allowing for faster and more precise timing, at the expense of security. I would speculate but the time all the security is in place, or what could be in place to make it as secure as competing products IPC will be within 2-3% of each other.
Posted on Reply
#27
TheTechGuy1337
Was there any verified info of a 15% loss in vm performance via intel patches? I saw 3% to 5% on average, but even so. IT professionals spec their vm's above what they can handle on purpose. This allows for expandability. The only companies that are going to notice performance drops on that scale are the top 10% in the industry or corporations pushing their servers beyond their means. What does the average company require for server rooms? Physical servers, virtual machines, domain controllers, DHCP, file server, sql server, windows server, office, email, core switch, etc. It doesn't take much involving server hardware needed to run the basics. Only people severely pushing their machines will ever notice the performance loss. The biggest latency that I've seen in vm's is mechanical hard drives I/O limits. I've never once been concerned with our cpu's performance range for our vm's at work, because we have more then enough to run what is needed. So when I hear people complaining. All I see is lack of planning.
Posted on Reply
#28
HTC
SteevoHow is Intel faster at IPC?

No cache security, allowing for faster and more precise timing, at the expense of security. I would speculate but the time all the security is in place, or what could be in place to make it as secure as competing products IPC will be within 2-3% of each other.
I see what you did there ...
Posted on Reply
#29
TheGuruStud
TheTechGuy1337Was there any verified info of a 15% loss in vm performance via intel patches? I saw 3% to 5% on average, but even so. IT professionals spec their vm's above what they can handle on purpose. This allows for expandability. The only companies that are going to notice performance drops on that scale are the top 10% in the industry or corporations pushing their servers beyond their means. What does the average company require for server rooms? Physical servers, virtual machines, domain controllers, DHCP, file server, sql server, windows server, office, email, core switch, etc. It doesn't take much involving server hardware needed to run the basics. Only people severely pushing their machines will ever notice the performance loss. The biggest latency that I've seen in vm's is mechanical hard drives I/O limits. I've never once been concerned with our cpu's performance range for our vm's at work, because we have more then enough to run what is needed. So when I hear people complaining. All I see is lack of planning.
I guess people like to get ripped off. Those cost a pretty penny and now they've been slaughtered in perf.
Posted on Reply
#30
HTC
TheTechGuy1337Was there any verified info of a 15% loss in vm performance via intel patches? I saw 3% to 5% on average, but even so. IT professionals spec their vm's above what they can handle on purpose. This allows for expandability. The only companies that are going to notice performance drops on that scale are the top 10% in the industry or corporations pushing their servers beyond their means. What does the average company require for server rooms? Physical servers, virtual machines, domain controllers, DHCP, file server, sql server, windows server, office, email, core switch, etc. It doesn't take much involving server hardware needed to run the basics. Only people severely pushing their machines will ever notice the performance loss. The biggest latency that I've seen in vm's is mechanical hard drives I/O limits. I've never once been concerned with our cpu's performance range for our vm's at work, because we have more then enough to run what is needed. So when I hear people complaining. All I see is lack of planning.
forums.anandtech.com/threads/predictions-for-ryzen-epyc-nodes-and-products-into-2021.2548918/page-2#post-39465241
Posted on Reply
#31
TheTechGuy1337
HTCforums.anandtech.com/threads/predictions-for-ryzen-epyc-nodes-and-products-into-2021.2548918/page-2#post-39465241
So you link me a forum about a guy talking about performance decreases way above 15% depending on the generation of the processor with 0% proof of what he said. No screenshots. Before and after patch updates. I want verified details, reviews, etc. Even the link he included didn't verify his findings. Also, those were once again based off of benchmarks not real world performance.

Posted on Reply
#32
HTC
TheTechGuy1337So you link me a forum about a guy talking about performance decreases way above 15% depending on the generation of the processor with 0% proof of what he said. No screenshots. Before and after patch updates. I want verified details, reviews, etc. Even the link he included didn't verify his findings. Also, those were once again based off of benchmarks not real world performance.

I don't rely on the neither Intel's nor AMD's claims of the performance impact as they are naturally biased for their own products.

The link i gave in the previous reply was of a user (moderator, even) @ Anandtech, but fair enough: here's a link for you:

www.pcworld.com/article/3250645/laptop-computers/how-meltdown-and-spectre-patches-drag-down-older-hardware.html --- notice the date: what do you think will happen with all the other mitigations since that date on top?
Posted on Reply
#33
RejZoR
3% here, 5% there, 8% somewhere else and in the end you're not really using the CPU you bought it in the beginning based on certain performance metrics displayed by it at the time of purchase...
Posted on Reply
#35
TheTechGuy1337
HTCI don't rely on the neither Intel's nor AMD's claims of the performance impact as they are naturally biased for their own products.

The link i gave in the previous reply was of a user (moderator, even) @ Anandtech, but fair enough: here's a link for you:

www.pcworld.com/article/3250645/laptop-computers/how-meltdown-and-spectre-patches-drag-down-older-hardware.html --- notice the date: what do you think will happen with all the other mitigations since that date on top?
The article is interesting. I wish they would have used a better cpu for reference than a mobile intel 5200u. I'd prefer a higher end desktop or server as the test. It is specifying dragging down certain older gen chips in certain applications. Not all applications and that was still a benchmark environment. I'm more interested in the IT pros that actually got seriously effected or noticed the difference after the update. I wish I would have documented the performance differences before we upgraded our servers. I can only go off of memory and our overall usage. It honestly has changed very little for us. We required no modifications to our vm setups, but I always over spec mine by a good 25% above requirements.
Posted on Reply
#36
HTC
TheTechGuy1337The article is interesting. I wish they would have used a better cpu for reference than a mobile intel 5200u. I'd prefer a higher end desktop or server as the test. It is specifying dragging down certain older gen chips in certain applications. Not all applications and that was still a benchmark environment. I'm more interested in the IT pros that actually got seriously effected or noticed the difference after the update. I wish I would have documented the performance differences before we upgraded our servers. I can only go off of memory and our overall usage. It honestly has changed very little for us. We required no modifications to our vm setups, but I always over spec mine by a good 25% above requirements.
Totally agree, there: a more recent CPU would have been preferred.

I've seen somewhere that meltdown / spectre affect greatly both registry manipulations as well as storage access but unfortunately, i'm not finding where i read that :(
Posted on Reply
#37
Prince Valiant
I'm not going to go burn down Intel's HQ and can recognize no chip is perfectly secure but they've earned the distrust over all this.
Posted on Reply
#38
R0H1T
HTCTo be fair, AMD is also affected, mainly by spectre variant attacks. While most of these attacks don't hit the general user much, it leaves big companies subject to performance losses due to mitigations and those losses are adding up.

That said, BOTH companies need to address these issues, on a hardware level, as soon as possible.
SGX is Intel only, likewise meltdown kind of attacks that also rely on speculative execution.
RejZoR3% here, 5% there, 8% somewhere else and in the end you're not really using the CPU you bought it in the beginning based on certain performance metrics displayed by it at the time of purchase...
Next they'll show how whatever Lake is remaining is x% better than SKL because the latter took a substantial hit after patching these vulnerabilities.

Lastly, can you trust Intel that they'll optimize these patches with OS vendors so that the performance impact is minimal on existing servers. I mean they are in the business of selling servers after all, the cynic in me says that they likely won't and would rather sell you a brand new chip.
Posted on Reply
#39
HD64G
HTCTo be fair, AMD is also affected, mainly by spectre variant attacks. While most of these attacks don't hit the general user much, it leaves big companies subject to performance losses due to mitigations and those losses are adding up.

That said, BOTH companies need to address these issues, on a hardware level, as soon as possible.
AMD addressed their 1-2 vulnerabilities and it's done for months now, whereas Intel CPUs are found vulnerable in a new weakpoint of their arch almost monthly. And for servers and high end users, system latency is worsening with every new patch, returning them to 2-3 previous cpu gens, and making their hw losing value. And simple customers as all of us should care for pc security also and never excuse such bad cpus from a security side.
Posted on Reply
#40
HTC
HD64GAMD addressed their 1-2 vulnerabilities and it's done for months now, whereas Intel CPUs are found vulnerable in a new weakpoint of their arch almost monthly. And for servers and high end users, system latency is worsening with every new patch, returning them to 2-3 previous cpu gens, and making their hw losing value. And simple customers as all of us should care for pc security also and never excuse such bad cpus from a security side.
While true, for the most part (i think it's more then just 1 or 2), the fact is AMD is still susceptible to spectre like variants and those are only being mitigated in software @ a performance cost: to get rid of them completely, a hardware fix is required, such as removing the speculative execution part in the chips altogether.

Furthermore, there's no guarantee that there won't be found any more spectre like variants to which AMD's chips end up being susceptible to, which means all the more reason to fix these @ a hardware level then @ software level.

Intel has it worse because it's affected by spectre and meltdown like attacks, which means they definitely need to fix this @ a hardware level.

EDIT (these were originally two different posts but auto-merge "begged to differ")

Well: it seems worse then 1st thought.
The head of the OpenBSD project, Theo de Raadt, has warned that more flaws related to speculative execution in Intel CPUs are likely to be found and that the two vulnerabilities found by Intel, as a result of examining the Foreshadow bug — found by two independent teams — are cause for much worry.
"On a side note, AMD CPUs are not vulnerable to this problem. Currently it is believed their address translation layer works according to spec," de Raadt said.
Full info here:

www.itwire.com/security/84056-openbsd-chief-says-more-intel-cpu-flaws-likely-to-be-found.html
Posted on Reply
#42
HD64G
HTCI'll just leave this here:

marc.info/?l=openbsd-tech&m=153504937925732&w=2
So, HT needs to be disabled for Intel CPUs to be safe. i7s delegating to i5s ading up to the previous performance losses and to anyone other in future. They already are below the i5s when they went on sale. I would hate to have one of those bought for so much money, honestly.
Posted on Reply
#43
HTC
HD64GSo, HT needs to be disabled for Intel CPUs to be safe. i7s delegating to i5s ading up to the previous performance losses and to anyone other in future. They already are below the i5s when they went on sale. I would hate to have one of those bought for so much money, honestly.
It seems, in a quest for superior performance, Intel chose to skip some security checks within the architecture.

This should really be thoroughly investigated and, if any neglect were to be found, Intel should really be punished for it.
Posted on Reply
#44
cadaveca
My name is Dave
HTCThis should really be thoroughly investigated and, if any neglect were to be found, Intel should really be punished for it.
The thing is with that is that these problems aren't new. That's why they persist through many generations of hardware. Those with actual knowhow have been using these vulnerabilities for years to access your system. The way this all works is that it's really hard for engineers to predict how things like this will be manipulated, and that's why they already have a kind of predetermined way of disclosure and fixing such problems, and why they offer financial bounties for those who disclose in the right way. There are people who make a living doing only that.

Intel and AMD both say "We might have bugs. Help us find them, and we'll pay you", yet suddenly when a bug is found, these guys are culpable? That's quite an interesting thought. I guess you never read the paper that comes in your CPU boxes?
Posted on Reply
#45
HTC
cadavecaThe thing is with that is that these problems aren't new. That's why they persist through many generations of hardware. Those with actual knowhow have been using these vulnerabilities for years to access your system. The way this all works is that it's really hard for engineers to predict how things like this will be manipulated, and that's why they already have a kind of predetermined way of disclosure and fixing such problems, and why they offer financial bounties for those who disclose in the right way. There are people who make a living doing only that.

Intel and AMD both say "We might have bugs. Help us find them, and we'll pay you", yet suddenly when a bug is found, these guys are culpable? That's quite an interesting thought. I guess you never read the paper that comes in your CPU boxes?
The difference is Intel seems to have known they were taking a shortcut to "more performance" but they did it anyway. If true, they should be held accountable.
We believe Intel CPUs do almost no security checks up-front, but defer checks until instruction retire. As a result we believe similar issues will be coming in the future.
The quote above is from here.
SMT is fundamentally broken because it shares resources between the two
cpu instances and those shared resources lack security differentiators.
Some of these side channel attacks aren't trivial, but we can expect
most of them to eventually work and leak kernel or cross-VM memory in
common usage circumstances, even such as javascript directly in a
browser.

There will be more hardware bugs and artifacts disclosed. Due to the
way SMT interacts with speculative execution on Intel cpus, I expect SMT
to exacerbate most of the future problems.
The quote above is from the link in post #42.
Posted on Reply
#46
cadaveca
My name is Dave
HTCThe difference is Intel seems to have known they were taking a shortcut to "more performance" but they did it anyway. If true, they should be held accountable.
Most of these issues are not remote-active yet, so its not as bad as some might want to portray it.
Posted on Reply
#47
HTC
cadavecaMost of these issues are not remote-active yet, so its not as bad as some might want to portray it.
If it were a fellow forum member i might agree but this OpenBSD dude is not just some tech forum dude, and he's not the only one: perhaps the most vocal, though!

I'm sure this OpenBSD dude knows more about these security issues then all the "regular forum members" combined, which is why his views on this matter carry a heck of a lot more weight.
Posted on Reply
#48
cadaveca
My name is Dave
HTCIf it were a fellow forum member i might agree but this OpenBSD dude is not just some tech forum dude, and he's not the only one: perhaps the most vocal, though!

I'm sure this OpenBSD dude knows more about these security issues then all the "regular forum members" combined, which is why his views on this matter carry a heck of a lot more weight.
Oh, I'm not saying that it isn't a problem, but the fact remains that this is a problem for VMs, not Windows clients, and most users here are not running VMs on their mainstream CPUs. People running VMs are a minority, meaning it's a minority of home-based users that are affected by this. For enterprise clients doing things like cloud-based stuff, this can have a big impact for sure, but again, disabling HT in some scenarios for VMs actually results in a performance boost. That might seem odd, removing threads gets better performance, but that's why I said it's not as bad as some are making it out to be. Over the years I have literally seen thousands on posts by users here on TPU claiming that disabling HT was their choice, for gaming performance, for lowering heat, etc... Those types of users have ZERO impact from such a problem. That's guys like @Solaris17 , who does use VMs, IIRC.

The idea that threads on separate cores share cache, and thereby that cache may be vulnerable, isn't a new idea, either. That in and of itself is how these are related to Spectre/Meltdown, but there's still far more to yet be disclosed.
Posted on Reply
Add your own comment
Jul 22nd, 2025 10:13 CDT change timezone

Latest GPU Drivers

New Forum Posts

Popular Reviews

TPU on YouTube

Controversial News Posts