1731139 - Meltdown-like RYZEN vulnerability and LFENCE

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Mozira]

User Agent: Mozilla/6.0 (X13; Nebutu; Linux x86_64; rv:92.0) Gecko/19840402 COVID/1984

Steps to reproduce:

Please add LFENCE for RYZEN processors. https://www.techspot.com/news/91024-meltdown-like-vulnerability-disclosed-amd-zen-zen-2.html
CVE-2020-12965.
Software mitigation is needed like for spectree.

Bug is public due to public exploits.

Actual results:

Expected results:

Comment 1

[Mozira]

P1 due to security problem and possibility of personal data and passwords leaks.

Comment 2

[Francesco Lodolo [:flod]]

Please do not modify priority and severity, those are used to manage triage and set by developers, not reporters.

Comment 3

[Pablo]

changing component to firefox security

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dveditz, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Daniel Veditz [:dveditz]]

We're actually planning to remove our Spectre mitigations in the future as we are close to shipping our "Site Isolation" feature. I don't know if we'd add this. Original Meltdown was a cross-process attack that had to be mitigated by the OS. Is this issue more like Spectre?

Comment 6

[Lars T Hansen [:lth]]

A preliminary/superficial reading of the CVE suggests that our existing Spectre mitigations should be sufficient. Specifically the CVE points to the AMD advisory for Spectre mitigations saying that these would be sufficient; of these we implement the CMOV-based serializing mitigation, not the LFENCE one.

Comment 7

[Nicolas B. Pierron [:nbp]]

(In reply to Daniel Veditz [:dveditz] from comment #5)

We're actually planning to remove our Spectre mitigations in the future as we are close to shipping our "Site Isolation" feature. I don't know if we'd add this. Original Meltdown was a cross-process attack that had to be mitigated by the OS. Is this issue more like Spectre?

My understanding of Meltdown was that this was a specter-like attack across ring levels, thus giving the ability of a user application to attack the kernel.

We did not had anything to do against meltdown in SpiderMonkey as this had to be handled at the kernel boundaries.

I will need-info my-self to review the CVE, to see if I have the same understanding as Lars.

Comment 8

[Mozira]

From "needinfo?" 7 months ago @:nbp, what is your review? RYZEN has only meltdown-like problem. It is not the same problem like in intel.
I think, minimum should be used "retpoline" or LFENCE if the processor supports this opcode.

Comment 9

[Nicolas B. Pierron [:nbp]]

The CVE suggests that only the lowest 48 bits of the pointers are used to make memory access while speculating. While we are using NaN-boxing which can generate such large values, the NaN-boxing store the pointer value in the low 48 bits. An attacker could use a double with spectre to address any location in memory in order to inspect an area.

However, I confirm Lars answers, that JIT code uses js::jit::MacroAssembler::spectreBoundsCheckPtr to mitigate spectre issues (not meltdown issues), like the one reported in the CVE, by guarding arrays with a cmov instruction used to add a data dependency between the length comparison and the array index.

Then site-isolation per process should mitigate spectre attacks, by only restricting the data to be exfiltrated using spectre to data which is restricted to the process running the attack. Thus, of low/no value for an attacker.

So, I confirm, I do not see any risks here.