Jika heap diinisialisasi nol untuk keamanan, lalu mengapa stack hanya diinisialisasi?

Di sistem Debian GNU / Linux 9 saya, ketika biner dijalankan,

• stack belum diinisialisasi tetapi
• heap diinisialisasi nol.

Mengapa?

Saya berasumsi bahwa inisialisasi nol mempromosikan keamanan tetapi, jika untuk heap, lalu mengapa tidak juga untuk stack? Apakah tumpukan juga tidak membutuhkan keamanan?

Pertanyaan saya tidak spesifik untuk Debian sejauh yang saya tahu.

Contoh kode C:

#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>

const size_t n = 8;

// --------------------------------------------------------------------
// UNINTERESTING CODE
// --------------------------------------------------------------------
static void print_array(
  const int *const p, const size_t size, const char *const name
)
{
    printf("%s at %p: ", name, p);
    for (size_t i = 0; i < size; ++i) printf("%d ", p[i]);
    printf("\n");
}

// --------------------------------------------------------------------
// INTERESTING CODE
// --------------------------------------------------------------------
int main()
{
    int a[n];
    int *const b = malloc(n*sizeof(int));
    print_array(a, n, "a");
    print_array(b, n, "b");
    free(b);
    return 0;
}

Keluaran:

a at 0x7ffe118997e0: 194 0 294230047 32766 294230046 32766 -550453275 32713 
b at 0x561d4bbfe010: 0 0 0 0 0 0 0 0 

Standar C tidak meminta malloc()untuk menghapus memori sebelum mengalokasikannya, tentu saja, tetapi program C saya hanya untuk ilustrasi. Pertanyaannya bukan pertanyaan tentang C atau tentang perpustakaan standar C. Sebaliknya, pertanyaannya adalah pertanyaan tentang mengapa kernel dan / atau run-time loader memusatkan perhatian pada tumpukan tetapi bukan tumpukan.

EKSPERIMEN LAIN

Pertanyaan saya mengenai perilaku GNU / Linux yang dapat diamati daripada persyaratan dokumen standar. Jika tidak yakin apa yang saya maksud, maka coba kode ini, yang memanggil perilaku tidak terdefinisi lebih lanjut ( tidak terdefinisi, yaitu sejauh menyangkut standar C) untuk menggambarkan poin:

#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>

const size_t n = 4;

int main()
{
    for (size_t i = n; i; --i) {
        int *const p = malloc(sizeof(int));
        printf("%p %d ", p, *p);
        ++*p;
        printf("%d\n", *p);
        free(p);
    }
    return 0;
}

Output dari mesin saya:

0x555e86696010 0 1
0x555e86696010 0 1
0x555e86696010 0 1
0x555e86696010 0 1

Sejauh menyangkut standar C, perilaku tidak terdefinisi, jadi pertanyaan saya tidak mempertimbangkan standar C. Panggilan untuk malloc()tidak perlu mengembalikan alamat yang sama setiap kali tetapi, karena panggilan untuk malloc()ini memang benar-benar mengembalikan alamat yang sama setiap kali, menarik untuk memperhatikan bahwa memori, yang ada di heap, adalah nol setiap kali.

Tumpukan itu, sebaliknya, tampaknya tidak memusatkan perhatian.

Saya tidak tahu apa yang akan dilakukan kode terakhir pada mesin Anda, karena saya tidak tahu lapisan mana dari sistem GNU / Linux yang menyebabkan perilaku yang diamati. Anda bisa mencobanya.

MEMPERBARUI

@ Kusalananda telah mengamati dalam komentar:

Untuk apa nilainya, kode terbaru Anda mengembalikan alamat yang berbeda dan (sesekali) data yang tidak diinisialisasi (bukan nol) ketika dijalankan di OpenBSD. Ini jelas tidak mengatakan apa-apa tentang perilaku yang Anda saksikan di Linux.

Bahwa hasil saya berbeda dengan hasil di OpenBSD memang menarik. Rupanya, percobaan saya bukan menemukan protokol keamanan kernel (atau linker), seperti yang saya pikirkan, tetapi hanya artefak implementasi.

Dalam terang ini, saya percaya bahwa, bersama-sama, jawaban di bawah @mosvy, @StephenKitt dan @AndreasGrapentin menyelesaikan pertanyaan saya.

Lihat juga di Stack Overflow: Mengapa malloc menginisialisasi nilai ke 0 dalam gcc? (kredit: @bta).

Penyimpanan dikembalikan oleh malloc () tidak diinisialisasi nol. Jangan pernah berasumsi itu.

Dalam program pengujian Anda, itu hanya kebetulan: Saya kira malloc()baru saja mendapat blok baru mmap(), tetapi jangan mengandalkan itu juga.

Sebagai contoh, jika saya menjalankan program Anda di komputer saya dengan cara ini:

$ echo 'void __attribute__((constructor)) p(void){
    void *b = malloc(4444); memset(b, 4, 4444); free(b);
}' | cc -include stdlib.h -include string.h -xc - -shared -o pollute.so

$ LD_PRELOAD=./pollute.so ./your_program
a at 0x7ffd40d3aa60: 1256994848 21891 1256994464 21891 1087613792 32765 0 0
b at 0x55834c75d010: 67372036 67372036 67372036 67372036 67372036 67372036 67372036 67372036

Contoh kedua Anda hanya mengekspos artefak mallocimplementasi di glibc; jika Anda melakukannya berulang malloc/ freedengan buffer lebih besar dari 8 byte, Anda akan melihat dengan jelas bahwa hanya 8 byte pertama yang di-zeroed, seperti pada kode contoh berikut.

#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>

const size_t n = 4;
const size_t m = 0x10;

int main()
{
    for (size_t i = n; i; --i) {
        int *const p = malloc(m*sizeof(int));
        printf("%p ", p);
        for (size_t j = 0; j < m; ++j) {
            printf("%d:", p[j]);
            ++p[j];
            printf("%d ", p[j]);
        }
        free(p);
        printf("\n");
    }
    return 0;
}

Keluaran:

0x55be12864010 0:1 0:1 0:1 0:1 0:1 0:1 0:1 0:1 0:1 0:1 0:1 0:1 0:1 0:1 0:1 0:1 
0x55be12864010 0:1 0:1 1:2 1:2 1:2 1:2 1:2 1:2 1:2 1:2 1:2 1:2 1:2 1:2 1:2 1:2 
0x55be12864010 0:1 0:1 2:3 2:3 2:3 2:3 2:3 2:3 2:3 2:3 2:3 2:3 2:3 2:3 2:3 2:3 
0x55be12864010 0:1 0:1 3:4 3:4 3:4 3:4 3:4 3:4 3:4 3:4 3:4 3:4 3:4 3:4 3:4 3:4

Terlepas dari bagaimana tumpukan diinisialisasi, Anda tidak melihat tumpukan yang asli, karena perpustakaan C melakukan beberapa hal sebelum memanggil main, dan mereka menyentuh tumpukan.

Dengan pustaka GNU C, pada x86-64, eksekusi dimulai pada titik entri _start , yang memanggil __libc_start_mainuntuk mengatur segalanya, dan yang terakhir akhirnya memanggil main. Tetapi sebelum memanggil main, ia memanggil sejumlah fungsi lain, yang menyebabkan berbagai bagian data ditulis ke stack. Isi tumpukan tidak dihapus di antara panggilan fungsi, jadi ketika Anda masuk main, tumpukan Anda berisi sisa dari panggilan fungsi sebelumnya.

Ini hanya menjelaskan hasil yang Anda dapatkan dari tumpukan, lihat jawaban lain mengenai pendekatan dan asumsi umum Anda.

Dalam kedua kasus, Anda mendapatkan memori yang tidak diinisialisasi , dan Anda tidak dapat membuat asumsi tentang isinya.

Ketika OS harus membagi halaman baru ke proses Anda (apakah itu untuk tumpukan atau untuk arena yang digunakan oleh malloc()), itu menjamin bahwa ia tidak akan mengekspos data dari proses lain; cara biasa untuk memastikan itu adalah mengisinya dengan nol (tetapi sama-sama valid untuk menimpa dengan hal lain, termasuk bahkan nilai halaman /dev/urandom- pada kenyataannya beberapa malloc()implementasi debugging menulis pola non-nol, untuk menangkap asumsi yang salah seperti milik Anda).

Jika malloc()dapat memenuhi permintaan dari memori yang sudah digunakan dan dirilis oleh proses ini, isinya tidak akan dihapus (sebenarnya, kliring tidak ada hubungannya dengan malloc()dan tidak bisa - itu harus terjadi sebelum memori dipetakan ke dalam ruang alamat Anda). Anda mungkin mendapatkan memori yang sebelumnya telah ditulis oleh proses / program Anda (misalnya sebelumnya main()).

Dalam program contoh Anda, Anda melihat malloc()wilayah yang belum ditulis oleh proses ini (yaitu langsung dari halaman baru) dan tumpukan yang telah ditulis ke (dengan main()kode pra -program Anda). Jika Anda memeriksa lebih banyak tumpukan, Anda akan menemukan nol-diisi lebih jauh ke bawah (ke arah pertumbuhan).

Jika Anda benar-benar ingin memahami apa yang terjadi di tingkat OS, saya sarankan Anda melewati lapisan C Library dan berinteraksi menggunakan panggilan sistem seperti brk()dan sebagai mmap()gantinya.

Premis Anda salah.

Apa yang Anda gambarkan sebagai 'keamanan' adalah benar-benar kerahasiaan , artinya tidak ada proses yang dapat membaca memori proses lainnya, kecuali jika memori ini dibagi secara eksplisit di antara proses-proses ini. Dalam sistem operasi, ini adalah salah satu aspek dari isolasi kegiatan bersamaan, atau proses.

Apa yang dilakukan sistem operasi untuk memastikan isolasi ini, adalah setiap kali memori diminta oleh proses untuk alokasi tumpukan atau tumpukan, memori ini berasal dari suatu wilayah dalam memori fisik yang diisi dengan nol, atau yang diisi dengan sampah yang berasal dari proses yang sama .

Hal ini memastikan bahwa Anda hanya pernah melihat nol, atau junk Anda sendiri, sehingga kerahasiaan terjamin, dan kedua tumpukan dan tumpukan adalah 'mengamankan', meskipun tidak selalu (nol) diinisialisasi.

Anda terlalu banyak membaca pengukuran Anda.