Meltdown strikes back: the L1 terminal fault vulnerability [LWN.net]

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 16, 2018 18:42 UTC (Thu) by jcm (subscriber, #18262)
In reply to: Meltdown strikes back: the L1 terminal fault vulnerability by Rearden
Parent article: Meltdown strikes back: the L1 terminal fault vulnerability

A "trusted" VM doesn't exist in reality. There are always going to be new bugs discovered that a determined attacker can use to compromise and perform privilege escalation. Then that "trusted" kernel becomes whatever they want very quickly. This is a nuance that isn't getting the necessary attention because it's a boring detail...

to post comments

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 17, 2018 0:01 UTC (Fri) by Rearden (subscriber, #35172) [Link]

I think that argument is pretty reductive, and goes well past individual mitigation for this particular threat, and the reason why it's not strictly required to take extra steps in the case where both the Host and Guest OS's are "trusted".

Of course some futher privilege escalation vulnerability could expose the VM host OS to this, but a further privilege escalation vulnerability would likely also expose all sorts of other things as well, this vulnerability being just one of many.

Big picture security comes down to risk mitigation through a layered approach, depending on the resources available and the risk associated with a particular breach. Some future, possible "privilege escalation" vulnerability must be planned for outside of the rememdy for this specific vulnerability. What I mean is, if your workflow and risk for a system that you own both the VM and Host OS is high enough that a compromise of one could impact imporant data, you probably need to be taking the steps associated with "untrusted" guest VMs anyway.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Oct 24, 2018 6:48 UTC (Wed) by alejluther (subscriber, #5404) [Link]

Yes, it does exist. You are thinking in a VM with a server role serving client requests, so clients specifically access the system, so vulneravilities can be exploited. But VMs could have other services not directly connected or accessible to clients. For example, telcos have VMs working with packets where those packets do not have the VM as the endpoint.