Zachowanie PROT_READ i PROT_WRITE z mprotect

Question

Próbowałem użyć mprotect do czytania najpierw, a następnie pisania.

Jest tu mój kod

#include <sys/types.h> 
#include <sys/mman.h> 
#include <stdio.h> 
#include <stdlib.h> 
#include <unistd.h> 

int main(void) 
{ 
    int pagesize = sysconf(_SC_PAGE_SIZE); 
    int *a; 
    if (posix_memalign((void**)&a, pagesize, sizeof(int)) != 0) 
     perror("memalign"); 

    *a = 42; 
    if (mprotect(a, pagesize, PROT_WRITE) == -1) /* Resp. PROT_READ */ 
     perror("mprotect"); 

    printf("a = %d\n", *a); 
    *a = 24; 
    printf("a = %d\n", *a); 
    free (a); 
    return 0; 
} 

Pod Linuksem oto wyniki:

Oto wyjście PROT_WRITE:

$ ./main 
a = 42 
a = 24 

i PROT_READ

$ ./main 
a = 42 
Segmentation fault 

W systemie Mac OS X 10.7:

Oto wyjście PROT_WRITE:

$ ./main 
a = 42 
a = 24 

i PROT_READ

$ ./main 
[1] 2878 bus error ./main 

Dotychczas Rozumiem, że zachowanie OSX/Linux może być różny, ale nie rozumiem, dlaczego PROT_WRITE nie powoduje awarii programu podczas odczytu wartości za pomocą printf.

Czy ktoś może wyjaśnić tę część?

Answer 1

Są dwie rzeczy, które obserwujesz:

1. mprotect nie został zaprojektowany do użytku z stron sterty. Linux i OS X mają nieco inną obsługę sterty (pamiętaj, że OS X używa Mach VM). System OS X nie lubi, aby manipulować stronami sterty.

   Można uzyskać identyczne zachowanie na obu systemów operacyjnych, jeśli przeznaczyć swoją stronę poprzez mmap

   a = mmap(NULL, pagesize, PROT_READ | PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0); 
   if (a == MAP_FAILED) 
       perror("mmap"); 
   

2. To ograniczenie swojej MMU (x86 w moim przypadku). MMU w x86 nie obsługuje zapisywalnych, ale nieodczytywalnych stron. Tak więc ustawienie nie powoduje żadnych zmian. podczas gdy

   usunięto priveledges i otrzymujesz SIGSEGV zgodnie z oczekiwaniami.

Również chociaż nie wydaje się być problemem tutaj, należy albo skompilować kod z -O0 lub ustawić a do volatile int * aby uniknąć optymalizacje kompilatora.

Answer 2

Większość systemów operacyjnych i/lub architektur procesorów automatycznie tworzy coś czytelnego, gdy można go zapisać, więc PROT_WRITE najczęściej oznacza także. Po prostu nie można stworzyć czegoś, co można zapisać, nie czyniąc go czytelnym.Powody mogą być spekulowane, albo nie jest warte wysiłku, aby uczynić dodatkowy bit czytelności w MMU i pamięciach podręcznych, lub jak to było w niektórych wcześniejszych architekturach, faktycznie trzeba przeczytać MMU w pamięci podręcznej, zanim będzie można napisać, więc sprawienie, że coś nieczytelnego automatycznie spowoduje, że nie będzie można go nagrać.

Ponadto prawdopodobnie printf próbuje przydzielić z pamięci uszkodzoną przez mprotect. Chcesz przydzielić pełną stronę z biblioteki libc podczas zmiany jej ochrony, w przeciwnym razie zmienisz ochronę strony, której nie jesteś w pełni właścicielem, a biblioteka libc nie oczekuje, że będzie chroniona. W testach MacOS z PROT_READ tak właśnie się dzieje. printf przydziela niektóre struktury wewnętrzne, próbuje uzyskać do nich dostęp i ulega awarii, gdy są one tylko do odczytu.