共享库的内存写保护

我突然对某事感到好奇。共享库，例如glibc（在Linux中），kernel32.dll（在Windows中）在进程之间物理共享。但是，由于这些库位于（映射）用户虚拟内存地址空间中，因此我认为恶意进程可能会将共享库内存区域的访问属性更改为启用写，并弄乱每个内容，以使共享它们的所有其他进程崩溃。

我在Linux上进行了以下实验，并且系统没有崩溃。下面是我的测试源代码。

meltdown@ubuntu:/tmp$ cat a.c
#include <stdio.h>
#include <sys/mman.h>
#include <stdlib.h>
int g=0;
int main(int argc, char* argv[]){
    int* a = (int*)strtoul(argv[1], 0, 16);
    printf("globals : %p\n", &g);
    printf("a : %p\n", a);
    mprotect( a, 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC);

int i=0;
for(i=0; i<0x3f0; i++){
    *(a+i)=0;
}

printf("done?\n");

while(1);
return 0;
}
meltdown@ubuntu:/tmp$ 

在我运行该程序之前。我找到了libc.so.6的虚拟地址（我将内核设置为不使用ASLR）

meltdown@ubuntu:/tmp$ ldd a
linux-gate.so.1 =>  (0xb7fff000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e37000)
/lib/ld-linux.so.2 (0x80000000)

确认libc的地址后，我尝试用NULL覆盖其中的一部分

meltdown@ubuntu:/tmp$ ./a 0xb7e37000
globals : 0x804a030
a : 0xb7e37000
done?
^C
meltdown@ubuntu:/tmp$ 

由于libc在物理内存中共享，因此我假设如果成功覆盖libc的内存，系统将崩溃。但是，该系统很好。我认为这里发生了一些事情，阻止了我的意图。

有人可以向我解释为什么系统没有崩溃吗？先感谢您。

ps。我不是在谈论NX或DEP。请不要混淆。我正在谈论以完全访问权限覆盖共享库内存区域（例如，根进程使用mprotect（...，...，PROT_READ | PROT_WRITE | PROT_EXEC）...