SoylentNews is people
SoylentNews
from the I-predict-another-one-in-six-months-tops dept.
Recompiling is unlikely to be a catch-all solution for a recently unveiled Intel CPU vulnerability known as TLBleed, the details of which were leaked on Friday, the head of the OpenBSD project Theo de Raadt says.
The details of TLBleed, which gets its name from the fact that the flaw targets the translation lookaside buffer, a CPU cache, were leaked to the British tech site, The Register; the side-channel vulnerability can be theoretically exploited to extract encryption keys and private information from programs.
Former NSA hacker Jake Williams said on Twitter that a fix would probably need changes to the core operating system and were likely to involve "a ton of work to mitigate (mostly app recompile)".
But de Raadt was not so sanguine. "There are people saying you can change the kernel's process scheduler," he told iTWire on Monday. "(It's) not so easy."
(Score: 4, Informative) by Anonymous Coward on Tuesday June 26 2018, @01:51AM (1 child)
The obvious fix is gang scheduling, but sadly de Raadt is correct about it being not so easy... well at least if you want to keep performance. On the bright side, you can get back the hyperthreading.
Gang scheduling is when you schedule a group of tasks all together. Traditionally it was a performance idea, for cases such as rapidly communicating processes. It's best to schedule them as a group, letting them have all the processors, then schedule away from them as a group. The entire system is handed to a cooperating group of tasks, rather than handing out 1 processor at a time.
For the security situation, the requirement is that the gang be defined according to security. For example, if a pair of tasks can ptrace (debug) each other, they belong in the same gang.
This nicely deals with future security attacks that we are all expecting. For example, SMP suffers from bus contention. Each CPU can detect that some other CPU is using the memory bus (or crossbridge or whatever) and therefore deduce something about what is going on in the other task. If all tasks are in the same security context, this isn't a concern.
The difficulty is that the kernel is a distinct security context. Unless all tasks enter/leave the kernel at the same time, there is a problem. The kernel is a different security context. Pausing tasks might be possible, but of course then processors sit idle during that time.
We also get a bit more trouble from the proliferation types of security contexts in the modern world. Browser sandbox content is different from the rest of the browser. OpenBSD has the "pledge" system call, causing more trouble. New types of security distinctions keep popping up to further subdivide the system, and all of these distinctions must be taken into account for the gang scheduling.
(Score: 3, Interesting) by Knowledge Troll on Tuesday June 26 2018, @02:20AM
That part where the kernel running is mutually exclusive with any other process running sounds like an absolutely massive issue but it does handle the case that De Raadt points out where a process in one hyperthread can get info from another process on the companion hyperthread executing in the kernel. Thank you for introducing the concept of gang scheduling though.