What is RIDL and Why Should you Care?

In 2019 researchers from Vrije Universiteit Amsterdam shared details of a new side-channel attack which they coined “Rogue In-Flight Data Load” (RIDL). It was the latest in a long line of hardware side-channel vulnerabilities such as Spectre and Meltdown. RIDL allows an attacker to leak information from other processes running on the same system, regardless of privilege level. As such it shares many similarities with Meltdown but is distinct in that it specifically targets data resident in the Line-fill buffers (LFBs) of Intel CPUs. LFBs are internal buffers used to track outstanding memory requests for use in the event of a cache miss.

A successful RIDL exploit can subvert the memory separation guarantees of modern processors, exposing any data that was recently accessed by another process previously scheduled on the same core.

RIDL attacks are particularly dangerous for web browsers because they routinely fetch and execute untrusted content from the web. Most modern browsers rely on the security-enforcing technologies of the hardware to isolate this content from other web contexts and the rest of the system; a technique known as sandboxing. Researchers proved this capability by performing an attack using a modified Firefox SpiderMonkey JavaScript engine to execute WebAssembly code and read data from other websites and applications, including passwords, cookies, encryption keys, or personal information.

According to researchers, the vulnerability only appears to impact Intel processors with those manufactured by AMD seemingly unaffected (Refer appendix B). In response, Intel has released microcode updates but has been unable to fully resolve the issue. As such, Intel also recommended disabling hyper-threading (HT) to prevent the sharing of process cores. Hyper-threading is a feature that allows running more than one thread on a single core, which dramatically improves processor performance, however it also increases the risk of side-channel attacks, because the threads share Line-Fill Buffers. Due to the impact on performance, this mitigation is not widely deployed.

How can you Mitigate RIDL in Microsoft Edge?

From build 25922, Microsoft Windows shipped a new opt-in scheduling feature that prevents threads within a process from being scheduled to the same core as threads from another security domain, effectively mitigating RIDL attacks. Microsoft Edge introduced a feature flag in version 121.0.2277.128 that allows the enablement of this mitigation policy called RestrictCoreSharing. This policy prevents the renderer process, which is responsible for rendering web pages, from sharing the same core with threads from other security domains.

To enable the mitigation in Microsoft Edge, you need to do launch Microsoft Edge with the feature flag “msRendererRestrictCoreSharing” up to version 128.0.2662.0, and “WinSboxRestrictCoreSharingOnRenderer” from version 128.0.2663.0.

You could see the mitigation policy enabled for the renderer process by navigating to edge://sandbox and observing the values under the Mitigations column of the renderer.

At the time of writing the mitigation was available on the Windows 11 Insider channels. The OS has certain restrictions as mentioned here when applying this mitigation.

What are the Trade-Offs when Enabling RestrictCoreSharing?

RestrictCoreSharing is a mitigation feature that can protect your browser from RIDL attacks, but it also carries some drawbacks that users should be aware of. The primary concern is that it can have a substantial impact the performance of your system when it is under increased processing load (such as when playing games or performing other compute-bound tasks). This is because other processes cannot be scheduled on the core when the renderer is in execution. Our calculations show that this can reduce overall performance of the core by up to 20%, depending on the task.

Therefore, you should consider your own threat model and performance needs before enabling RestrictCoreSharing. If you are a security-conscious user or an individual who frequently visits less trusted websites, you may wish to enable RestrictCoreSharing to protect your data from RIDL attacks. However, if you are a casual user who visits well-known and reputable websites, you may not need to enable RestrictCoreSharing, especially if you do not want to compromise on the systems performance without significant impact on security.

Availability in Chromium

Microsoft also made this feature available to the open-source Chromium project. The mitigation can be applied on Chromium-based browsers by launching with the feature flag “WinSboxRestrictCoreSharingOnRenderer” from version 128.0.6538.0.

We are working with Chromium maintainers to add an enterprise policy and a configuration flag that makes the feature available in chrome://flags.