patching the syscall table via a module
afs patches the syscall table when it loads as a module. currently afs pags and pioctl are implemented this way. while this might change in the future, its not going to happen any time soon. i have run into a problem with this recently, and noticed that sys_call_table is declared as .rodata. my older ia64 machines dont seem to enforce the read only, but the new sn machine does!
is there a particular reason the sys_call_table needs to be .rodata and not just .data? could it be changed? it seems the ia64 port is the only port that does this.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · chas williams
chas> afs patches the syscall table when it loads as a module. chas> currently afs pags and pioctl are implemented this way. while chas> this might change in the future, its not going to happen any chas> time soon. i have run into a problem with this recently, and chas> noticed that sys_call_table is declared as .rodata. my older chas> ia64 machines dont seem to enforce the read only, but the new chas> sn machine does!
chas> is there a particular reason the sys_call_table needs to be chas> .rodata and not just .data? could it be changed? it seems chas> the ia64 port is the only port that does this.
I don't have a problem with changing that, but beware that recent Red Hat kernels no longer export the sys_call_table symbol. Personally, I don't like this syscall-patching business either (for several reasons). While a bit rude, perhaps the Red Hat approach will force those who care to find a better solution. ;-)
--david
Quoted 2 lines · In message <[email protected]>,David Mosberger writes:
reasons). While a bit rude, perhaps the Red Hat approach will force those who care to find a better solution. ;-)
i believe the developers of afs are aware of this situation. i dont know if the necessary api has materialized yet though. for the short term, sys_call_table will need to be writable.