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

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 14, 2018 21:46 UTC (Tue) by Sesse (subscriber, #53779)
Parent article: Meltdown strikes back: the L1 terminal fault vulnerability

Is there a way to enable SMT but only schedule threads from the same user/VM on the hyperthread pair? That would seem to keep security, while still keeping most of the performance advantages.

to post comments

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 14, 2018 22:35 UTC (Tue) by nilsmeyer (guest, #122604) [Link] (3 responses)

You will also need to take care that nothing outside the VM is scheduled there (kernel threads, interrupts etc.).

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 14, 2018 22:37 UTC (Tue) by Sesse (subscriber, #53779) [Link] (2 responses)

Yes—one would think this would be a good feature for a scheduler to have in general. (Think side-channel attacks in general.)

OpenBSD “solves” this by simply not supporting hyperthreading, but that seems too heavy-handed to me.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 15, 2018 18:32 UTC (Wed) by jcm (subscriber, #18262) [Link] (1 responses)

It would be nice if we could guarantee no secrets were loaded, track, and flush them, but this isn't something most general purpose OS stacks running a full environment on a host do today. It is something some hypervisors are doing to mitigate against L1TF, and obviously is going to be investigated over time to improve the state of available mitigations on Linux, but it's very non-trivial.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 15, 2018 18:34 UTC (Wed) by Sesse (subscriber, #53779) [Link]

FWIW, my request was for just “not at the same time” (to make timing attacks much harder), not flushing L1 on every context switch. That's too heavy-handed for most userspace.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 15, 2018 8:00 UTC (Wed) by vbabka (subscriber, #91706) [Link] (4 responses)

Looks like Microsoft went with this approach for Hyper-V: https://blogs.technet.microsoft.com/virtualization/2018/0...

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 15, 2018 14:02 UTC (Wed) by nilsmeyer (guest, #122604) [Link] (3 responses)

Which also goes to show that they had advance knowledge of the vulnerability.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 15, 2018 14:17 UTC (Wed) by JoelWilliamson (guest, #105956) [Link] (2 responses)

It looks like the Core Scheduler for Hyper-V was introduced in 2016. I'm sure Microsoft had some advance knowledge, but I doubt they knew about this before Project Zero discovered Meltdown/Spectre. More likely, Microsoft introduced this as a general mitigation against any leaking between threads sharing a core, or simply to give guests a bit more control of their own scheduling.

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 15, 2018 18:46 UTC (Wed) by jcm (subscriber, #18262) [Link]

We should give kudos to Microsoft here. They thought about the potential risks from tight resource sharing some time ago and obviously were able to invest significantly ahead of any one vulnerability such as this one in secret scrubbing/address space isolation/core scheduling/etc. This is something that we'll need to look at in Linux and other OSes over time if we want to make HT totally safe as well. It's a great example of what's possible, but a big lift. We do need to also get over the mindset that SMT threads are "cores". Especially in projects like OpenStack. An SMT thread is not a core, and we should never treat it as such, but it's easy to think in those terms when looking at /proc/cpuinfo output and just counting "cpus".

Meltdown strikes back: the L1 terminal fault vulnerability

Posted Aug 23, 2018 22:56 UTC (Thu) by ssmith32 (subscriber, #72404) [Link]

You are correct. Reading the article makes that clear. The default in server 2016 is the classic scheduler, which does not bind LP to VP 1:1. The core scheduler was introduced as an option in Server 2016, both for security & performance SLA reasons.