OSDev.org

The Place to Start for Operating System Developers
It is currently Tue May 23, 2017 9:12 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: Why is INVLPG a privileged instrucion (x86)?
PostPosted: Mon Oct 24, 2016 4:10 am 
Offline

Joined: Sat Jul 25, 2015 4:33 am
Posts: 7
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!


Top
 Profile  
 
 Post subject: Re: Why is INVLPG a privileged instrucion (x86)?
PostPosted: Mon Oct 24, 2016 4:27 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 766
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.


Top
 Profile  
 
 Post subject: Re: Why is INVLPG a privileged instrucion (x86)?
PostPosted: Mon Oct 24, 2016 4:48 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1054
User mode programs can't modify page tables, so there's no reason to let them use INVLPG.


Top
 Profile  
 
 Post subject: Re: Why is INVLPG a privileged instrucion (x86)?
PostPosted: Mon Oct 24, 2016 5:01 am 
Offline

Joined: Sat Jul 25, 2015 4:33 am
Posts: 7
alexfru wrote:
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!


Top
 Profile  
 
 Post subject: Re: Why is INVLPG a privileged instrucion (x86)?
PostPosted: Wed Nov 02, 2016 3:25 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 2178
Octocontrabass wrote:
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.


Top
 Profile  
 
 Post subject: Re: Why is INVLPG a privileged instrucion (x86)?
PostPosted: Wed Nov 02, 2016 3:31 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 2178
alexfru wrote:
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.


Top
 Profile  
 
 Post subject: Re: Why is INVLPG a privileged instrucion (x86)?
PostPosted: Wed Nov 02, 2016 10:51 am 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 43
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group