Hacker News Reader

Comment by anyfoo | Hacker News Reader

Because the OS has no say. A running program issues an assembly instruction to the CPU to read or write this register, and the CPU complies.

For the OS to have a say, the CPU would need to provide a way where the OS tells it (usually by setting certain values in other registers) that the CPU should not allow access, at least under certain circumstances.

The article actually does go into certain situations where the access is more restricted (search for "VHE"), but also in how that does not really apply here.

View on HN

The OS can scan the program for instructions that access these bits. If necessary on a per-basic-block basis.

Of course, this only works if you can't introduce new code without the kernel noticing.

Yes, you can introduce new code but the kernel should also watch for that (JIT compilation etc.) and check the resulting code. It's quite involved, and the whole process looks more like a sandbox or emulator, but it's possible.

Doing this performantly is going to be very prohibitive.

Perhaps (depends also on CPU support), but on the other hand: in today's world with untrusted apps, the kernel will have to do some sandboxing anyway.

Could the OS intentionally clear or write dummy data to the register instead?

No. The author explained why not:

> originally I thought the register was per-core. If it were, then you could just wipe it on context switches. But since it's per-cluster, sadly, we're kind of screwed, since you can do cross-core communication without going into the kernel.

You gotta access those bits though some instructions though. What if the command pipeline filters those instructions.

Can you elaborate what you mean? What is the "command pipeline" here?

You are working here with CPU registers. At this point the OS has no say, it’s a hardware bug. Not a particularly serious one though.

I didn't say the OS filters the pipeline. Modern CPUs have a lot of updateable microcode, including how it handles its command pipeline.

Modern x86/x64 CPUs. The M1 might not have updatable microcode.

Apple might consider microcode a vulnerability. Certainly a double-edged knife.

There is no indication that the M1 has updatable microcode, nor any other features that might allow such mitigation. (If it did, Apple would've fixed it; I did give them a 90 day disclosure warning and they're not lazy about fixing actual fixable bugs.)

Aw - that was what I was worried about - without updatable microcode :nuke:.

https://news.ycombinator.com/item?id=27286918

Reply on news.ycombinator.com