Why is INVLPG a privileged instrucion (x86)?

[jlledom]

Hello!

Not sure whether this is the proper place to ask this, but I've got a doubt about the x86 architecture.

My doubt is, why is INVLPG a privileged instruction? What could happen if a user program was able to execute it? It would be able to invalidate only the TLB entries of its own pages, isn't it?

Thanks!

[alexfru]

This instruction does not distinguish between user and kernel pages. So, a misbehaving app would cause unnecessary memory reads (to refill the TLB) and introduce delays, which may be especially bad in the kernel and device drivers. And if some page tables that are needed to refill the TLB happen to be swapped out, this will incur additional disk reads and further increase delays. I'm not sure if there are other side effects.

[Octocontrabass]

User mode programs can't modify page tables, so there's no reason to let them use INVLPG.

[jlledom]

This instruction does not distinguish between user and kernel pages. So, a misbehaving app would cause unnecessary memory reads (to refill the TLB) and introduce delays, which may be especially bad in the kernel and device drivers. And if some page tables that are needed to refill the TLB happen to be swapped out, this will incur additional disk reads and further increase delays. I'm not sure if there are other side effects.

Oh yes, I understand now. Thank you!

[rdos]

User mode programs can't modify page tables, so there's no reason to let them use INVLPG.

That's only a convention and not something that is enforced by the processor. It's perfectly possibly to map the page tables so user mode programs can access and modify them.

[rdos]

This instruction does not distinguish between user and kernel pages. So, a misbehaving app would cause unnecessary memory reads (to refill the TLB) and introduce delays, which may be especially bad in the kernel and device drivers. And if some page tables that are needed to refill the TLB happen to be swapped out, this will incur additional disk reads and further increase delays. I'm not sure if there are other side effects.

I'd say that's a minor issue. It will only invalidate the cache, not the page tables themselves. Which entries are in the TLB is not really deterministic for the OS anyway. Any task switch might completely flush the TLB by changing CR3, and those are not really deterministic for a typical OS either. I'd say an OS that relies on certain TLB entries being cached is severely broken.

Still, I see no legitimate use for invlpg for a user program, but I cannot see how it can do much if any harm by using it either.

[simeonz]

I will speculate that by using INVLPG and measuring the execution times of specific system calls with rdtsc (to detect TLB misses), unprivileged attacker will be able to discover important kernel locations. A following attack vector on a buggy driver (say, stack smashing) will be precisely targeted, counteracting kernel ASLR and the entropy of the dynamic allocator. An ordinary user-space "mov" should also be able to roughly sieve the address space, since it will cause conflict TLB misses eventually. INVLPG can be used as a second step to refine the search.

I am not deep into security, but it is conventional to assume some arbitrary compromise to begin with - trojan, exploit, counterfeit payload, etc. The goal is to limit the security ramifications. Some kind of mitigation is usually present, like ASLR, safe unlinking, W^X. The hardware must, as in this case, protect the effectiveness of the mitigation from heuristics.