Re:Re: Another question about L4 system call

Thank you, Raphael. 
Under you clearly guide. I think i have got it. 
My problem is caused because I just think KIP contains only the struct kernel_interface_page_t 
not including the system call trampolines.

Then, because PGSIZE_KIP is (pgent_t :: size_4k), so the trampolines' (eg..the user_ipc() funtion) total size
must be limited to size_4k(exactly less than size_4k).

Thank  you very much!
Best regards,
Bob
 
 


在2008-09-08，"Raphael Neider" <[email protected]> 写道：
>Hi Bob,
>
>> In addition, do your "trampolines in the KIP" means the
>> user_syscall(eg..user_Ipc()) in file /kernel/src/glue/v4-ia32/user.cc
>> ?
>
>Yes.
>
>> From the page table's view, the code in that file is protected . Only
>> in system level can be accessed.
>
>No.
>api/v4/user.h places the user_XXX functions in an ELF section called
>.user.syscall.ipc, which is then combined with other parts of the KIP
>via linker magic in api/v4/kip.ldi and glue/v4-x86/x32/linker-pc99.lds
>
>> Because it's a part of the kernel.
>
>This "copy" of the KIP as part of the kernel binary resides at runtime
>in the kernel memory area, yes, and would not be accessible to the user.
>
>> when funtion user_ipc() is called from user space (the __L4_Ipc() ).
>> The CPU is still in user mode.
>
>Yes.
>
>> Not enter system mode yet, so it can't access the address protected
>> by the page table, such as the user_ipc()'s address.   I am puzzleed
>> about these.
>
>Here you are wrong: You do not need to access the KIP at its kernel
>address. Each address space has a private, user-accessible
>mapping to the KIP: each address space can *read* from the KIP, it is
>mapped into the user address space on creation of the address space!
>The KIP includes the trampolines (the code from user_ipc() et al.) plus
>relative offsets from the start of the KIP to the start of the
>trampolines (the kip->syscall fields).
>
>ASCII art:
>
>+-------------+ 4 GB
>|             |
>+-------------+
>| KIP (1)     | KKIP
>+-------------+
>|             |
>+============== ca. 3 GB
>|             |
>+-------------+
>| KIP (2)     | UKIP
>+-------------+
>|             |
>| application |
>| data and    |
>| code        |
>|             |
>+-------------+ 0
>
>KIP (1) is the KIP as provided in the kernel binary. At the virtual
>address KKIP (0xf011c000 for me), the page is inaccessible from user
>mode as you correctly pointed out (kernel may read/write it here).
>
>But the KIP is also mapped into the user addres space at UKIP (wherever
>space_control was instructed to map it). Via this virtual address, the
>user can access both the kip->syscall offsets and the trampoline code
>(this virtual page is readable and executable, though not writable in
>user mode).
>
>You can jump in user mode from application code (the l4 library) into
>the KIP at address UKIP (as returned via L4_KernelInterface ()), execute
>the trampoline code there and thus enter the kernel.
>
>The virtual pages at addresses KKIP and UKIP map to the same physical
>memory, but grant different access rights to the kernel
>(read/write/execute) and user (read/execute only).
>
>Hope that helps,
>Raphael