Hi all,

I have some questions in x86 protection Mechanism.

We have RPL for data segment selectors.
From where is the RPL loaded into the segment selector?. Is it stored in the process descriptor or the Segment Descriptor of that Data segment?

The x86 processor instruction manuals from Intel explain all about it . . .

I tried going through the manual. I was not able to precisely find out from where is it loaded. Can you please help me through this question.

Pardon me, but when I look at http://en.wikipedia.org/wiki/X86_memory_segmentation, after having done a search for x86 "rpl", I see the answer almost immediately.
There are several different types of segments on the x86 and this protection mechanism applies to each one. The segment reference is either express or implied, as the case may be, but each segment-register's content and the information that it points to specifies the protection that is to apply when the processor uses that segment (register), for that purpose.

There is also a good description (my second Google hit), in http://stackoverflow.com/questions/1...n-x86-machines.
... and there were several comments made by others in response to this.

Hello sundialsvcs,

Thanks for replying. Actually I had gone through the stackoverflow post. So one question on it.
When we say that , its the user code priviledge level, the processor has to somehow find out what was the user's priviledge level. So on x86 how can he find out.
And one more thing,

Kernel can access user data segment -> iilegally
-> Legally - Using get_user_pages. So in either of the cases how is the RPL set so that access to kernel are prohibited/allowed? I mean logically , for each data segment their should be something permission info stored somewhere like process descriptor or some location , from where it is picked and set as the RPL so access by kernel are monitored.

I am somehow missing the connecting links in my understanding. Can you please help me out. Thanks in Advance!!

Read the quoted text again: all the information that you are looking for is right there.

The kernel usually operates at "ring 0," which in less-enlightened processor designs would mean that "it has access to everything" and therefore would constantly have to check, in kernel software, whether a particular chunk of memory should be accessible to the user or not. Instead of this, the x86 architecture can perform the test ... and will throw a general profection fault (GPF), even to the kernel, which the kernel must be prepared to catch.

(When it doesn't, you get things like "unable to handle kernel paging request ...".)

The processor defines, on a segment level and a segment-register level, three privilege-level numbers:

1. CPL: The privilege level of the CPU at the time.
2. [b]RPL:{/b] The privilege level requested by the software.
3. DPL: The privilege-level of the segment being accessed.

Now, notice how max(CPL, RPL) makes the whole thing very efficient:

• The user, operating (say) at "ring 3" (CPL=3), can never "get too big for its britches." This much is just ordinary protectiveness.
• The kernel, operating at "ring 0" (CPL=0), now has the ability to make memory requests on behalf of the user, knowing that a GPF will occur (in kernel mode ...) if the user is not privileged to access that data. Instead of being forced to constantly check, it too can rely upon the interrupt mechanism to treat invalid references as what they are ... "the exception, rather than the rule."

Within the kernel, there is literally a list of places where a GPF is allowed to occur within kernel-space, with information to tell the kernel what to do about it.

Memory access by the kernel is still complicated by the fact that page-faults could occur if the user-requested data is not in memory at the time, and by the possibility that there are more CPUs/cores involved, and by the special dispatching rules that apply to kernel code (and kernel-task vs. not).