Oops when working with syscalls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Well, I can say that this code works. I let the module running for days without problems catching brk, fork and vfork syscalls (and using the system normally). In fact this is the method used by vtune again and very similar to the way that Oprofile does. There is more code including some sentences for restoring the stack properly and some atomic_t variables to perform locks.

When I asked at kerneltrap.org some people told me if I was a virus coder or if I liked the MS-DOS ages ;), well the truth is that this is part of my postgraduate project, and I documented that this can do in user-mode and that there are alternatives to this way ( e.g. using kprobes if I'm not wrong)

Anyway sincerely thanks for your comments.

Best regards

---------- Forwarded message ----------
From: Arjan van de Ven <arjan@xxxxxxxxxxxxx>
Date: May 31, 2006 11:28 PM
Subject: Re: Oops when working with syscalls
To: Fernando Apesteguía < fernando.apesteguia@xxxxxxxxx>
Cc: kernelnewbies@xxxxxxxxxxxx

On Wed, 2006-05-31 at 17:25 +0200, Fernando Apesteguía wrote:
> Hi,
>
> I'm writing a module to profile some syscalls parameters. I replace
> the original functions by my own ones, doing (for brk syscall):
>
> old_brk = (void *) sct[__NR_brk];
> sct[__NR_brk] = (unsigned long *) my_brk;

this code isn't going to work ;)
for one it's full of races already

there is a reason the system call table isn't exported to modules...



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux