CPUsNews

Intel Responds to Micro-Op Security Flaw: Existing Mitigations Still Hold, No New Guidance Needed [Update]

Intel has responded to the micro-op vulnerability discovered by researchers at the University of Virginia, stating that there’s no need for new mitigations as the methods explained in the paper were already covered in previous releases. The chipmaker explains that the existing mitigations for Spectre and related side-channel vulnerabilities were not bypassed by these methods and as such, no new mitigations or guidance are required.

However, it is important to note that this is only applicable for applications that follow Intel’s secure coding guidance which includes measures to protect the user from incidental channels, including micro-op cache incidental channel attacks.

Update: We’ve received an update from the lead researcher at UVA, Professor Ashish Venkat who explains that while writing secure code for your software is important, this particular vulnerability is present in the hardware. Furthermore, the suggestions in Intel’s secure coding guide primarily point towards constant-time programming which is not only quite difficult for the average programmer but also comes with a significant performance overhead:

We’re aware of these guidelines from Intel suggesting software developers write code in a way that is not vulnerable to side-channel attacks. Here’s an excerpt from the Intel article –’Developers who wish to protect secret data against timing side-channel methods should ensure that their code runtime, data access patterns, and code access patterns are identical independent of secret values.

Certainly, we agree that software needs to be more secure, and we agree as a community that constant-time programming is an effective means to writing code that is invulnerable to side-channel attacks.  However, the vulnerability we uncover is in hardware, and it is important to also design processors that are secure and resilient against these attacks.

Certainly, we agree that software needs to be more secure, and we agree as a community that constant-time programming is an effective means to writing code that is invulnerable to side-channel attacks.  However, the vulnerability we uncover is in hardware, and it is important to also design processors that are secure and resilient against these attacks.

In addition, constant-time programming is not only hard in terms of the actual programmer effort, but also entails high-performance overhead and significant deployment challenges related to patching all sensitive software.  The percentage of code that is written using Constant Time principles is in fact quite small.  Relying on this would be dangerous. That is why we still need to secure the hardware.

Ashish Venkat, Assistant Professor of Computer Science at the University of Virginia School of Engineering

Intel’s response:

Intel reviewed the report and informed researchers that existing mitigations were not being bypassed and that this scenario is addressed in our secure coding guidance. Software following our guidance already have protections against incidental channels including the uop cache incidental channel. No new mitigations or guidance are needed.

Intel Statement

As per Intel’s secure coding guiding, most traditional side channels—regardless of technique—can be mitigated by applying all three of the following general “constant time” principles:

  1. Ensure runtime is independent of secret values.
  2. Ensure code access patterns are independent of secret values.
  3. Ensure data access patterns are independent of secret values.

Although these principles are conceptually simple, they can be difficult to implement in practice, depending on the complexity of your algorithms. Luckily, most developers won’t need to work on the most complex situations. Intel hasn’t specified if the micro-op vulnerabilities require the most basic measures or the more complex ones.

Earlier, a research paper from the University of Virginia described three new attacks that leveraged the micro-op cache to steal sensitive information bypassing the existing Spectre mitigations:

  • A same thread cross-domain attack that leaks secrets across the user-kernel boundary
  • A cross-SMT thread attack that transmits secrets across two SMT threads via the micro-op cache,
  • Transient execution attacks that have the ability to leak an unauthorized secret accessed along a mis-speculated path, even before the transient instruction is dispatched to execution, breaking several existing invisible speculation and fencing-based solutions that mitigate Spectre.
  • Read more here.

Areej

Computer Engineering dropout (3 years), writer, journalist, and amateur poet. I started my first technology blog, Techquila while in college to address my hardware passion. Although largely successful, it was a classic example of too many people trying out multiple different things but getting nothing done. Left in late 2019 and been working on Hardware Times ever since.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to top button