OpenBSD, a BSD Unix devoted to security first and foremost, Kroah-Hartman freely admits was the first to come up with what’s currently the best answer for this class of security holes: Turn Intel’s simultaneous multithreading (SMT) off and deal with the performance hit. Linux has adopted this method. But it’s not enough. You must secure the operating system as each new way to exploit hyper-threading appears. For Linux, that means flushing the CPU buffers every time there’s a context switch (e.g. when the CPU stops running one VM and starts another). You can probably guess what the trouble is. Each buffer flush takes a lot of time, and the more VMs, containers, whatever, you’re running, the more time you lose. “The bad part of this is that you now must choose: Performance or security. And that is not a good option,” Kroah-Hartman said. He added: “If you are not using a supported Linux distribution kernel or a stable/long term kernel, you have an insecure system.”
Reading Time: 2 minutes
During his Open Source Summit Europe keynote speech, Greg Kroah-Hartman, the stable Linux kernel maintainer, said Intel CPU’s security problems “are going to be with us for a very long time” and are “not going away.” He added: “They’re all CPU bugs, in some ways they’re all the same problem,” but each has to be solved in its own way. “MDS, RDDL, Fallout, Zombieland: They’re all variants of the same basic problem.” ZDNet reports: And they’re all potentially deadly for your security: “RIDL and Zombieload, for example, can steal data across applications, virtual machines, even secure enclaves. The last is really funny, because [Intel Software Guard Extensions (SGX)] is what supposed to be secure inside Intel ships” [but, it turns out it’s] really porous. You can see right through this thing.” To fix each problem as it pops up, you must patch both your Linux kernel and your CPU’s BIOS and microcode. This is not a Linux problem; any operating system faces the same problem.