kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: baoquan.he@gmail.com (Baoquan He)
To: kernelnewbies@lists.kernelnewbies.org
Subject: linux segment
Date: Thu, 20 Jun 2013 17:02:36 +0800	[thread overview]
Message-ID: <51C2C52C.7030800@gmail.com> (raw)
In-Reply-To: <CAPihQtuvz_zvftgNn-AybnTgOMHMQ2QaHTV7tccYnmdC2W0SDg@mail.gmail.com>

On 10/24/2012 08:04 PM, Fan Yang wrote:

> Hi all: I print the cs ds and ss register in the user space, and it 
> is same as the __USER_CS and __USER_DS which defined in kernel as 73 
> and 7b. In the kernel __KERNEL_CS and __KERNEL_DS defined as 60 and 
> 68, but when I print this two value in my kernel module, I get 60
> and 7b. Why ? It should be 60 and 68, shouldn't it?
> 




Hi Fan,

I just talked to you and very impressed. By checking source code, I
found what you mentioned is normal.

You can check arch/x86/kernel/entry_32.S, and go to the page_fault
definition, in error_code, you can
see the CS and DS assignment.

error_code:
        /* the function address is in %gs's slot on the stack */
        pushl_cfi %fs
        /*CFI_REL_OFFSET fs, 0*/
        pushl_cfi %es
        /*CFI_REL_OFFSET es, 0*/
        pushl_cfi %ds
        /*CFI_REL_OFFSET ds, 0*/
        pushl_cfi %eax
        CFI_REL_OFFSET eax, 0
        pushl_cfi %ebp
        CFI_REL_OFFSET ebp, 0
        pushl_cfi %edi
        CFI_REL_OFFSET edi, 0
        pushl_cfi %esi
        CFI_REL_OFFSET esi, 0
        pushl_cfi %edx
        CFI_REL_OFFSET edx, 0
        pushl_cfi %ecx
        CFI_REL_OFFSET ecx, 0
        pushl_cfi %ebx
        CFI_REL_OFFSET ebx, 0
        cld
        movl $(__KERNEL_PERCPU), %ecx
        movl %ecx, %fs
        UNWIND_ESPFIX_STACK
        GS_TO_REG %ecx
        movl PT_GS(%esp), %edi          # get the function address
        movl PT_ORIG_EAX(%esp), %edx    # get the error code
        movl $-1, PT_ORIG_EAX(%esp)     # no syscall to restart
        REG_TO_PTGS %ecx
        SET_KERNEL_GS %ecx

Below is the assignment. This is changed in 2.6, the reason is that in
kernel the CPL is 0 and it's
safe to operate __USER_DS with DPL is 3. Here if use __KERNEL_DS, even
though they have the
same content, it need change back when return to user space.

So in your original post, you mentioned the cs:ds is 60, 7b, it's normal
and correct value. Hope
this can help.

        movl $(__USER_DS), %ecx
        movl %ecx, %ds
        movl %ecx, %es
        TRACE_IRQS_OFF
        movl %esp,%eax                  # pt_regs pointer
        call *%edi

  parent reply	other threads:[~2013-06-20  9:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-24 12:04 linux segment Fan Yang
2012-10-26 23:53 ` Mulyadi Santosa
2012-10-27  7:49 ` Jun Hu
2012-10-28 14:02   ` Fan Yang
2012-10-28 14:20     ` Fan Yang
2012-10-29  7:32     ` Mulyadi Santosa
2012-10-30  0:44       ` Fan Yang
2012-10-30  6:04         ` Mulyadi Santosa
2012-11-02  9:32         ` Tobias Boege
2013-06-20  9:02 ` Baoquan He [this message]
2013-06-20 10:01   ` Fan Yang
2013-06-20 13:40     ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51C2C52C.7030800@gmail.com \
    --to=baoquan.he@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).