Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 14, 2018 19:16 UTC (Tue) by smoogen (subscriber, #97)
Parent article: Meltdown strikes back: the L1 terminal fault vulnerability

> Systems running container workloads will be only lightly affected by L1TF, while those running virtualization will pay a heavy cost.

This may be obvious, but are you talking about containers in any environment or only if they are running on baremetal? Many of the container systems I have seen run them inside a virtualized environment sitting on top of baremetal to allow for one thing to do what its best at, and the other to do something else.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 14, 2018 20:31 UTC (Tue) by ssl (guest, #98177) [Link] (5 responses)

The ownership is crucial here. If you own both the virtual infrastructure (=hypervisor) and the container hosting VM's (and all the other guests) then it's not as big problem for you.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 15, 2018 11:48 UTC (Wed) by danpb (subscriber, #4831) [Link] (4 responses)

Even if the same person/organization owns the guest VM and host, the "trusted" guest VM can become "untrustworthy" if some software component in it gets compromised (through one of the countless bugs all complex software has). So if they're relying on use of VMs to isolate their applications from each other, the risk is still notable even in the single owner case.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 16, 2018 3:08 UTC (Thu) by Rearden (subscriber, #35172) [Link] (3 responses)

But, there would be no reason for a "friendly" VM to run the unpatched kernel in the virtualized environment. The issue for hostile hosts only manifests when the "attacker" can run an un-patched kernel in the VM. As long as the VM's kernel is patched to invert the PFN, then it doesn't matter if someone attempts the attack against the VM kernel, it won't be affected.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 16, 2018 18:42 UTC (Thu) by jcm (subscriber, #18262) [Link] (2 responses)

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...

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.