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."
Despite the extent of detail in the article, de Raadt said he was still not prepared to say more. Last week, when iTWire asked him about the flaw before the leak to The Register, he said he could not be more specific about the nature of the vulnerability that had led to the disabling of hyper-threading as the researchers are due to present a paper about it only in August/
"Please wait for the paper," de Raadt said on Monday. "But the detail doesn't matter. Any cynic can see the issue based upon the word 'shared'.
"So the proposed rule is to not run two separate virtual address spaces on a HT CPU pair. Only run the same address space."
He said there were problems aplenty that could arise. "The problem with changing the scheduler is, what processes do you run on two hyperthreading CPUs sharing a TLB? They must trust each other. So how about only processes by the same user. But what if one of them uses a security technology like, say pledge? It has a different security profile than the another process. Oh, the rule has just been broken."
De Raadt offered a second scenario. "Let's say you just run threads of the same program, so they have the same address space. One of the threads does a system call, so it is now running in the kernel. In a subtle way, the rule has just been broken."
OpenBSD has an enviable reputation for security and runs some of the public servers with the longest uptimes. De Raadt himself is obsessed with security, and has as his aim the provision of an operating system that has a secure default install. OpenBSD has had only two remote vulnerabilities in its default install since the project forked from NetBSD in 1996.
De Raadt said it was nearly impossible to select processes that one could run on another CPU, "and there are instances where if one process does something, you must immediately bump the other because it is about to observe something it should not".
He laid the blame squarely on Intel. "There are delineations of rights between processes, otherwise we wouldn't go through so much effort separating the rights that processes have. Hyperthreading isn't dumb per se, Intel just took a further shortcut by not creating independent or segmented micro caches and TLBs which hide this."
And de Raadt reiterated what he had said earlier: there were no quick fixes.
"BTW, it looks like the floating point unit fixes to operating systems took every team about two weeks, individually," de Raadt commented, before adding, sarcastically, "This Intel CPU is amazing. They sure are keeping it fresh and new!"
An Intel spokesperson told iTWire in an unsolicited comment: "Protecting our customers and their data continues to be a critical priority for us. We are looking into this feedback and thank the community for their ongoing efforts.” (Intel update is here.)