用于C代码的x86反汇编生成:orq $ 0x0，％(rsp) [英] The x86 disassembly for C code generates: orq $0x0, %(rsp)

问题描述

我编写了以下C代码:

I have written the following C code:

它只是分配一个包含1000000个整数和另一个整数的数组，并将该数组的第一个整数设置为0

It simply allocates an array of 1000000 integers and another integer, and sets the first integer of the array to 0

我使用 gcc -g test.c -o test -fno-stack-protector

它提供了一个非常奇怪的反汇编:

It gives a very weird disassembly:

显然，它继续在循环中在堆栈上分配4096个字节，并且每隔4096个字节或"为0，然后一旦达到3997696个字节，便进一步分配2184个字节.然后，它将第4000000个字节(从未分配过)设置为5.

Apparently it keeps allocating 4096 bytes on the stack in a loop, and "or"s every 4096th byte with 0 and then once it reaches 3997696 bytes, it then further allocates 2184 bytes. It then proceeds to set the 4000000th byte (which was never allocated) to 5.

为什么不分配请求的全部4000004字节?为什么要或"每4096个字节为0的字节，这是无用的指令吗?

Why doesn't it allocate the full 4000004 bytes that were requested? Why does it "or" every 4096th byte with 0, which is a useless instruction?

我在这里理解不对吗?

注意:这是用cc版本9.3编译的.gcc 7.4版不执行循环，并且或"执行gcc版本7.4.每个第4096个字节为0的字节，但它确实只分配了3997696 + 2184 = 3999880字节，但仍将第4000000个字节设置为5

NOTE: This was compiled with gcc version 9.3. gcc version 7.4 does not do the loop and "or" every 4096th byte with 0, but it does allocate only 3997696+2184=3999880 bytes but still sets the 4000000th byte to 5

推荐答案

这是对 Stack Clash 类漏洞的一种缓解，该漏洞自90年代或更早就已知，但仅在2017年得到广泛宣传.参见 stack-clash.txt 和此博客条目.)

This is a mitigation for the Stack Clash class of vulnerabilities, known since the 90s or earlier but only widely publicized in 2017. (See stack-clash.txt and this blog entry.)

如果攻击者可以安排执行具有攻击者控制大小的VLA的功能，或者可以安排当攻击​​者控制其他某些地方已使用的堆栈量时执行具有固定大小的大型数组的功能这样，它们可以使堆栈指针被调整为指向其他内存的中间，从而导致函数破坏该内存，通常导致任意代码执行.

If the attacker can arrange for a function with a VLA of attacker-controlled size to execute, or can arrange for a function with a large fixed-size array to execute when the attacker controls the amount of stack already used in some other way, they can cause the stack pointer to be adjusted to point into the middle of other memory, and thereby cause the function to clobber said memory, usually leading to arbitrary code execution.

此处发出的机器代码GCC是堆栈冲突保护功能的一部分.通过(大约)每当将堆栈指针调整到大于最小页面大小时，一次(一次)以一个最小页面大小的单位递增移动堆栈指针，并在每次调整后访问内存，就可以降低风险.这样可以确保，如果存在至少一个保护页(页面映射的 PROT_NONE )，则访问将出错并在对无关内存进行调整之前生成信号.主线程始终具有保护页面，并且默认情况下，新创建的保护页面也具有保护页面(并且大小可以在pthread线程创建属性中配置).

The machine code GCC has emitted here is part of the Stack Clash Protection feature. It mitigates the risk by (roughly), whenever adjusting the stack pointer by more than the minimum page size, moving it incrementally by one minimum-page-sized unit at a time and accessing memory after each adjustment. This ensures that, if at least one guard page (page mapped PROT_NONE) is present, the access will fault and generate a signal before the adjustment into unrelated memory is made. The main thread always has guard pages, and by default newly created ones do too (and the size can be configured in the pthread thread creation attributes).

这篇关于用于C代码的x86反汇编生成:orq $ 0x0，％(rsp)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！