From 71cdacb7718fab5e2cb1a59eb349493481f1f772 Mon Sep 17 00:00:00 2001 From: Georgii Staroselskii Date: Sun, 17 Sep 2017 02:55:20 +0300 Subject: [PATCH] syscall-3.md: fix typos - delete a comma - s/receiving/received - s/Both function/Both functions - s/vsyscal/vsyscall --- SysCall/syscall-3.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/SysCall/syscall-3.md b/SysCall/syscall-3.md index 79474dc..0641856 100644 --- a/SysCall/syscall-3.md +++ b/SysCall/syscall-3.md @@ -36,7 +36,7 @@ static inline void map_vsyscall(void) {} #endif ``` -As we can read in the help text, the `CONFIG_X86_VSYSCALL_EMULATION` configuration option: `Enable vsyscall emulation`. Why emulate `vsyscall`? Actually, the `vsyscall` is a legacy [ABI](https://en.wikipedia.org/wiki/Application_binary_interface) due to security reasons. Virtual system calls have fixed addresses, meaning that `vsyscall` page is still at the same location every time and the location of this page is determined in the `map_vsyscall` function. Let's look on the implementation of this function: +As we can read in the help text, the `CONFIG_X86_VSYSCALL_EMULATION` configuration option: `Enable vsyscall emulation`. Why emulate `vsyscall`? Actually, the `vsyscall` is a legacy [ABI](https://en.wikipedia.org/wiki/Application_binary_interface) due to security reasons. Virtual system calls have fixed addresses, meaning that `vsyscall` page is still at the same location every time and the location of this page is determined in the `map_vsyscall` function. Let's look on the implementation of this function: ```C void __init map_vsyscall(void) @@ -80,7 +80,7 @@ __vsyscall_page: ret ``` -Let's go back to the implementation of the `map_vsyscall` function and return to the implementation of the `__vsyscall_page`, later. After we receiving the physical address of the `__vsyscall_page`, we check the value of the `vsyscall_mode` variable and set the [fix-mapped](https://proninyaroslav.gitbooks.io/linux-insides-ru/content/MM/linux-mm-2.html) address for the `vsyscall` page with the `__set_fixmap` macro: +Let's go back to the implementation of the `map_vsyscall` function and return to the implementation of the `__vsyscall_page` later. After we received the physical address of the `__vsyscall_page`, we check the value of the `vsyscall_mode` variable and set the [fix-mapped](http://0xax.gitbooks.io/linux-insides/content/mm/linux-mm-2.html) address for the `vsyscall` page with the `__set_fixmap` macro: ```C if (vsyscall_mode != NONE) @@ -223,7 +223,7 @@ do_ret: regs->ip = caller; regs->sp += 8; return true; -``` +``` That's all. Now let's look on the modern concept - `vDSO`. @@ -263,10 +263,10 @@ static int __init init_vdso(void) #ifdef CONFIG_X86_X32_ABI init_vdso_image(&vdso_image_x32); -#endif +#endif ``` -Both function initialize the `vdso_image` structure. This structure is defined in the two generated source code files: the [arch/x86/entry/vdso/vdso-image-64.c](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/entry/vdso/vdso-image-64.c) and the [arch/x86/entry/vdso/vdso-image-64.c](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/entry/vdso/vdso-image-64.c). These source code files generated by the [vdso2c](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/entry/vdso/vdso2c.c) program from the different source code files, represent different approaches to call a system call like `int 0x80`, `sysenter` and etc. The full set of the images depends on the kernel configuration. +Both functions initialize the `vdso_image` structure. This structure is defined in the two generated source code files: the [arch/x86/entry/vdso/vdso-image-64.c](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/entry/vdso/vdso-image-64.c) and the [arch/x86/entry/vdso/vdso-image-64.c](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/entry/vdso/vdso-image-64.c). These source code files generated by the [vdso2c](https://github.com/torvalds/linux/blob/16f73eb02d7e1765ccab3d2018e0bd98eb93d973/arch/x86/entry/vdso/vdso2c.c) program from the different source code files, represent different approaches to call a system call like `int 0x80`, `sysenter` and etc. The full set of the images depends on the kernel configuration. For example for the `x86_64` Linux kernel it will contain `vdso_image_64`: @@ -357,7 +357,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp) } ``` -The `map_vdso` function is defined in the same source code file and maps pages for the `vDSO` and for the shared `vDSO` variables. That's all. The main differences between the `vsyscall` and the `vDSO` concepts is that `vsyscal` has a static address of `ffffffffff600000` and implements `3` system calls, whereas the `vDSO` loads dynamically and implements four system calls: +The `map_vdso` function is defined in the same source code file and maps pages for the `vDSO` and for the shared `vDSO` variables. That's all. The main differences between the `vsyscall` and the `vDSO` concepts is that `vsyscall` has a static address of `ffffffffff600000` and implements `3` system calls, whereas the `vDSO` loads dynamically and implements four system calls: * `__vdso_clock_gettime`; * `__vdso_getcpu`;