X86-64 Linux系统为什么调用RCX，该值是什么意思？

Question

我正在尝试使用sys_brk syscall在Linux中分配一些内存。这是我尝试的内容：

BYTES_TO_ALLOCATE equ 0x08

section .text
    global _start

_start:
    mov rax, 12
    mov rdi, BYTES_TO_ALLOCATE
    syscall

    mov rax, 60
    syscall

事实是根据Linux调用惯例，我期望返回值在rax register中（指向分配的内存指针）。 以下寄存器内容，

Syscall之前的

rax            0xc      12
rbx            0x0      0
rcx            0x0      0
rdx            0x0      0
rsi            0x0      0
rdi            0x8      8

我在GDB中运行了此操作，在制作sys_brk syscall之后，我注意到Syscall之后的

rax            0x401000 4198400
rbx            0x0      0
rcx            0x40008c 4194444 ; <---- What does this value mean?
rdx            0x0      0
rsi            0x0      0
rdi            0x8      8

我不太了解RCX在这种情况下登记的值。我分配了sys_brk的8个字节开始的指针？

Answer 1

与往常一样，系统调用返回值在rax中。参见是unix＆amp; Linux系统致电I386和X86-64 。

请注意，sys_brk与brk/sbrk posix functions的接口略有不同；请参阅 c库/内核差异brk（2 ）人页。具体而言， linux sys_brk sets 程序折断; ARG和返回值都是指示。参见 issembly x86 brk（）brk（）该答案需要投票，因为这是该问题上唯一的好问题。

---

您问题的另一个有趣的部分是：

我在这种情况下不太了解RCX寄存器中的值

在这种情况下， “> syscall / 指令旨在允许内核恢复用户空间执行，但仍然很快。

syscall不做任何负载或商店，它仅修改寄存器。它没有使用特殊寄存器保存返回地址，而只是使用常规整数寄存器。

rcx = rip and rflags在内核返回到您的用户空间代码之后，这不是一个巧合。此不是的唯一方法是，如果ptrace系统调用修改了该过程已保存的rcx或r11值在内核内。 （ptrace是系统调用GDB使用）。在这种情况下，Linux将使用IRET而不是sysret返回用户空间，因为较慢的通用案例iret可以做到这一点。 （请参阅如果您在64位代码中使用32位INT 0x80 Linux ABI会发生什么？对于Linux的System-call输入点的某些演练。主要是从32位到32位的入口点 在64位过程中syscall。

---

流程，不是 代码> syscall ：

• 设置rcx = rip，r11 = rflags（因此，在执行syscall之前，内核甚至不可能看到这些regs的原始值）。

• masks rflags带有从配置寄存器（ia32_fmask msr）的预配置掩码。这使内核可以禁用中断（如果）直到完成swapgs和设置rsp指向内核堆栈。即使cli是入口点处的第一个指令，也会有一个脆弱性窗口。您还可以免费获得cld通过掩盖df SO REP MOVS/STOS即使用户空间也向上移动已经使用了std。

  有趣的事实：AMD的第一个提议syscall/swapgs设计没有掩盖rflags，而是他们在AMD64邮件列表上的内核开发人员的反馈（在2000年，第一个硅之前的几年）。

• 跳到配置的syscall输入点（设置CS：RIP = ia32_lstar）。我认为旧的cs值在任何地方都没有保存。

• 它无能为它的价值来自用户空间。

因此，syscall的设计需要一个clobbers注册的系统通话ABI，这就是为什么值是它们的原因。