I had a similar approach working, but was still tweaking the implementation. You beat me to the punch. Doh! My working version did an objdump of vmlinux to determine the opcode boundaries. One potential flaw in this approach is the instructions that are over-written by the jump and copied to the assembler routine (dobrk2) can't include any operations that have relative addresses or offsets. Fortunately, this seems quite rare from a brief scan of various kernel routines. However, its probably worth checking the assembler routine before issuing the module load. I still think this is a better approach than my initial version that "fixed" calls and jumps. Nice work. --Shane > > It would be less intrusive to the kernel to supply a fixed do_brk() > > and replace the do_brk with a jump to your version. > > I've written similar patch few days ago. The patch only modifies first > instructions of do_brk() (it replaces them with jmp to function in LKM. > It can be downloaded from http://wizard.ath.cx/fixbrk.tar.gz > > But beware, I wrote it in rush and it's pretty odly written :-) But it > worked on my two servers (both were running 2.4.21 kernel with grsecurity > patch). > > Greetings > > Pavel Palát > > -- > Pavel "harry_x" Palát > harry_x@babylon5.cz > irc: #mistral.cz on IRCnet > > The only way of finding the limits to the possible is by going beyond them to the impossible > Arthur C. Clark > ------------------------------------------------------------------------ Shane Canon voice: 510-486-6981 PSDF Project Lead fax: 510-486-7520 National Energy Research Scientific Computing Center 1 Cyclotron Road Mailstop 943-256 Berkeley, CA 94720 canon@nersc.gov ------------------------------------------------------------------------
