OpenBSD Chief De Raadt Says No Easy Fix For New Intel CPU Bug 'TLBleed' (itwire.com)

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. iTWire reports: 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."

He said that Williams was lacking all the details and not thinking it through. "They actually have sufficient detail to think it through: the article says the TLB is shared between hyperthreading CPUs, and it is unsafe to share between two different contexts. Basically you can measure evictions against your own mappings, which indicates the other process is touching memory (you can determine the aliasing factors)." De Raadt said he was still not prepared to say more, saying: "Please wait for the paper [which is due in August]."

Comments

I am an old nobody

[oldgraybeard]

but the fact that the vendors put a secret OS with an api within the cpu below the bois/command set? Who thought that was a good idea. And who did not see the problems and issues.
I know, I know nothing, I wrote z80 assembly as an intro. I am missing the entire point of what the wise individuals are doing..

Just my 2 cents ;)

Re:I am an old nobody

[grep -v '.*' *]

I know, I know nothing, I wrote z80 assembly as an intro.

I learned on an MITS Altair-8800 computer that my roommate had in college. We played one dimensional, straight-line Pong, and had to flip the front-panel switches to reload the program after shutting it off. (5.1 Audio? Mouse? CRT? Printer? Floppy? Keyboard? Paper-tape? You must be joking.)

After graduation, I ended up at his computer shop running CDOS, a CP/M improvement from Cromemco with hardware. They eventually upgraded from 8080 to a Z-80. Really neat, with those 2nd set of registers. We wrote COBOL and Fortran accounting software using embeeded software overlays and 8" floppies and 5-10M hard drives. (150K? 5 Meg? Is that right?? We only had 64K of RAM though, MAX) for companies.

Hey, did you ever see that Zilog Z-80 paperback book (6"x8"? Weird size.) describing how all of the operations worked in pseudo-code? It was wonderful.

I still have a Z-80 fold-out instruction card. Also an IBM 360 one, much longer. Not much useful now, but extremely useful at the time.

Also, decades ago now, IBM produced (as an experiment, not a retail product) a mainframe computer-on-a-chip, but supposedly the firmware was changeable to directly run binary code from IBM 360, PDP, Amdahl, and maybe 3 other CPUs. A decade or more later you've got (we had internal Compaq In-Site cards) things which directly control the computer remotely, even when "it's off". I understand the new corporate ones have it all built on the motherboard. Still need power to the PS though, but you could insert floppy images and flash firmware while sitting at your desk. Neat-O!

I used to understand how things worked, down to the bare metal. (Could program PICs and INT handlers and all that. You too, I'm sure. Remember 16550 UART serial chips with 14-byte internal cache? ) I fiddled with AI a bit in college in the late 70s. It was bloomin' math magic then, I could run the simple operations by hand or look at the intermediate data structures. But it was all just random junk -- except it would actually come out with working answers. I can't imagine and don't understand what they're doing now -- and really, I don't actually think they do either.

Re:Illusion of speparation in VM

[Anonymous Coward]

If we'd be willing to deal with choppy timeslicing where you give the whole processing (all cores & GPU) away for a longer timeslice and fully scrub cache state between and swap for a whole new RAM bank, you could probably start to think about making some guarantees.

But damn that throws away so much performance and response speed.

Of course the world will settle somewhere between that extreme and the current state (probably much closer to the current state for a while).

Re:The problem is the douchebag humans

[BlueStrat]

[The problem is the douchebag humans]

who waste their life coming up with ways to fuck up other peoples' day by hacking their computer.

Pondscum basically. Or pathogenic bacteria. Take your pick. But such is life I guess.

There will always be a criminal element in any free and open society. That's really just human nature.

No, the real problem here are governments that insist people not be *too* secure in their data, communications, and with whom they associate (there is no freedom of association if all your associations are tracked, stored, and analyzed).

Strat

Re:Illusion of speparation in VM

[Pseudonym]

Take a cue from the C++ people. VM separation protects you from Murphy, not Machiavelli.