问题描述
除了 .data 和 .bss 之外，是否可以在NASM程序的其他部分中分配内存?
Is it possible to allocate memory in other sections of a NASM program, besides .data and .bss?
说我想写到 .text 部分中的某个位置并收到 Segmentation Fault
Say I want to write to a location in .text section and receive Segmentation Fault
我对避免这种情况并合法访问内存的方式感兴趣.我正在运行Ubuntu Linux
I'm interested in ways to avoid this and access memory legally. I'm running Ubuntu Linux
推荐答案
如果要在运行时分配内存 ，请使用 sub rsp，4096 之类的.或与libc链接，则从libc运行 mmap 系统调用或调用malloc .
If you want to allocate memory at runtime, reserve some space on the stack with sub rsp, 4096 or something. Or run an mmap system call or call malloc from libc, if you linked against libc.
如果要测试shellcode/自我修改代码，
或出于其他原因而拥有可写的 .text :
与 ld --omagic 或 gcc -Wl，-omagic 链接.从 ld(1)手册页:
Link with ld --omagic or gcc -Wl,--omagic. From the ld(1) man page:
另请参见
或者您可以使用链接描述文件.可能还可以使用NASM部分属性来声明具有读取，写入和exec权限的自定义部分.
Or probably you can use a linker script. It might also be possible to use NASM section attribute stuff to declare a custom section that has read, write, exec permission.
通常(在shellcode测试之外)没有任何理由要做这些，只需将静态存储放入 .data 或 .bss 中，然后将像普通人一样， .rodata 中的静态只读数据.
There's normally (outside of shellcode testing) no reason to do any of this, just put your static storage in .data or .bss, and your static read-only data in .rodata like a normal person.
在代码附近放置读/写数据会严重影响性能:检测自我修改代码的硬件可能会产生管线核干扰，并且如果有页面，则至少会污染数据的iTLB和代码的dTLB.包括两者中的一部分，而不是一个或另一个都充满了.
Putting read/write data near code is actively bad for performance: possible pipeline nukes from the hardware that detects self-modifying-code, and it at least pollutes the iTLB with data and the dTLB with code, if you have a page that includes some of both instead of being full of one or the other.
这篇关于在.text部分分配可写内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！