Bagaimana cara kerja alokasi tumpukan di Linux?

Apakah OS menyimpan jumlah ruang virtual yang valid untuk stack atau sesuatu yang lain? Apakah saya dapat menghasilkan stack overflow hanya dengan menggunakan variabel lokal besar?

Saya telah menulis sebuah Cprogram kecil untuk menguji asumsi saya. Ini berjalan pada X86-64 CentOS 6.5.

#include <string.h>
#include <stdio.h>
int main()
{
    int n = 10240 * 1024;
    char a[n];
    memset(a, 'x', n);
    printf("%x\n%x\n", &a[0], &a[n-1]);
    getchar();
    return 0;
}

Menjalankan program memberi &a[0] = f0ceabe0dan&a[n-1] = f16eabdf

Peta proc menunjukkan tumpukan: 7ffff0cea000-7ffff16ec000. (10248 * 1024B)

Kemudian saya mencoba meningkatkan n = 11240 * 1024

Menjalankan program memberi &a[0] = b6b36690dan&a[n-1] = b763068f

Peta proc menunjukkan tumpukan: 7fffb6b35000-7fffb7633000. (11256 * 1024B)

ulimit -stercetak 10240di PC saya.

Seperti yang Anda lihat, dalam kedua kasus ukuran tumpukan lebih besar dari yang ulimit -sdiberikan. Dan tumpukan tumbuh dengan variabel lokal yang lebih besar. Bagian atas tumpukan entah bagaimana lebih dari 3-5kB &a[0](AFAIK zona merah adalah 128B).

Jadi bagaimana peta tumpukan ini dialokasikan?

Tampaknya batas memori tumpukan tidak dialokasikan (toh, tidak bisa dengan tumpukan tidak terbatas). https://www.kernel.org/doc/Documentation/vm/overcommit-accounting mengatakan:

Pertumbuhan tumpukan bahasa C melakukan mremap implisit. Jika Anda ingin jaminan absolut dan berjalan mendekati tepi Anda HARUS mmap tumpukan Anda untuk ukuran terbesar yang Anda pikir Anda perlukan. Untuk penggunaan stack pada umumnya, ini tidak terlalu menjadi masalah, tetapi ini adalah kasus sudut jika Anda benar-benar peduli

Namun mmapping tumpukan akan menjadi tujuan dari kompiler (jika memiliki opsi untuk itu).

EDIT: Setelah beberapa tes pada mesin Debian x84_64, saya telah menemukan bahwa stack tumbuh tanpa panggilan sistem apa pun (sesuai dengan strace). Jadi, ini berarti bahwa kernel menumbuhkannya secara otomatis (inilah yang dimaksud "implisit" di atas), yaitu tanpa eksplisit mmap/ mremapdari proses.

Cukup sulit untuk menemukan informasi terperinci yang mengonfirmasi hal ini. Saya merekomendasikan Memahami Linux Virtual Memory Manager oleh Mel Gorman. Saya kira jawabannya ada di Bagian 4.6.1 Menangani Kesalahan Halaman , dengan pengecualian "Wilayah tidak valid tetapi di samping wilayah yang dapat diperluas seperti tumpukan" dan tindakan yang sesuai "Perluas wilayah dan alokasikan halaman". Lihat juga D.5.2 Memperluas Tumpukan .

Referensi lain tentang manajemen memori Linux (tetapi hampir tidak ada tentang stack):

• FAQ Memori
• Apa yang harus diketahui setiap programmer tentang memori oleh Ulrich Drepper

EDIT 2: Implementasi ini memiliki kelemahan: dalam kasus sudut, tabrakan tumpukan-tumpukan mungkin tidak terdeteksi, bahkan dalam kasus di mana tumpukan akan lebih besar dari batas! Alasannya adalah bahwa penulisan dalam variabel dalam stack mungkin berakhir pada memori heap yang dialokasikan, dalam hal ini tidak ada kesalahan halaman dan kernel tidak dapat mengetahui bahwa stack perlu diperpanjang. Lihat contoh saya dalam diskusi Tabrakan tumpukan-tumpukan diam di bawah GNU / Linux yang saya mulai di daftar bantuan gcc. Untuk menghindarinya, kompiler perlu menambahkan beberapa kode saat panggilan fungsi; ini dapat dilakukan dengan -fstack-checkuntuk GCC (lihat balasan Ian Lance Taylor dan halaman manual GCC untuk detailnya).

Kernel Linux 4.2

• mm / mmap.c # acct_stack_growth memutuskan apakah akan rusak atau tidak. Menggunakan rlim[RLIMIT_STACK]yang sesuai dengan POSIXgerlimit(RLIMIT_STACK)
• arch / x86 / mm / fault.c # do_page_fault adalah pengendali interupsi yang memulai rantai yang akhirnya memanggilacct_stack_growth
• arch / x86 / entry / entry_64.S mengatur penangan kesalahan halaman. Anda perlu tahu sedikit tentang paging untuk memahami bagian itu: Bagaimana cara kerja paging x86? | Stack Overflow

Program tes minimal

Kami kemudian dapat mengujinya dengan program NASM 64-bit minimal:

global _start
_start:
    sub rsp, 0x7FF000
    mov [rsp], rax
    mov rax, 60
    mov rdi, 0
    syscall

Pastikan Anda mematikan ASLR dan menghapus variabel lingkungan karena itu akan tersimpan di stack dan menghabiskan ruang:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
env -i ./main.out

Batasnya ada di suatu tempat sedikit di bawah saya ulimit -s(8MiB untuk saya). Sepertinya ini karena ekstra data yang ditentukan Sistem V pada awalnya diletakkan di tumpukan di samping lingkungan: Linux 64 parameter baris perintah di Majelis | Stack Overflow

Jika Anda serius tentang ini, TODO membuat gambar initrd minimal yang mulai menulis dari tumpukan atas dan turun, dan kemudian jalankan dengan QEMU + GDB . Letakkan dprintfdi loop mencetak alamat stack, dan breakpoint di acct_stack_growth. Itu akan mulia.

Terkait:

• /software/207386/how-are-the-size-of-the-stack-and-heap-limited-by-the-os
• Di mana memori stack dialokasikan dari untuk proses Linux? | Stack Overflow
• Apa itu Stack Linux? | Stack Overflow
• Berapa kedalaman rekursi maksimum dalam Python, dan bagaimana cara meningkatkannya? pada Stack Overflow

Secara default, ukuran tumpukan maksimal dikonfigurasikan menjadi 8MB per proses,
tetapi dapat diubah menggunakan ulimit:

Menampilkan default di kB:

$ ulimit -s
8192

Setel ke tidak terbatas:

ulimit -s unlimited

mempengaruhi shell saat ini dan subkulit dan proses anak mereka.
( ulimitadalah perintah shell builtin)

Anda dapat menunjukkan kisaran alamat tumpukan aktual yang digunakan dengan:
cat /proc/$PID/maps | grep -F '[stack]'
di Linux.