what's the replace for the big kernel lock after kernel version 2.6.39 for system call.

what's the replace for the big kernel lock after kernel version 2.6.39 for system call.

[Wen Yan Xin]

Hi all,

I have a trouble of working on kernel 2.6.39 and later. Originally when our kernel module startups, it hooks some file system call, like sys_open... , and the big kernel lock - lock_kernel() - will be held before creating the hook to prevent user application use system calls, and be released after the hook created.


But after the kernel 2.6.39, the big kernel lock has been removed. I'm thinking there should be one or more lock that should be used. 

So, my question is which lock should be held now, when we hook the system call of file system?

I'd really appreciate your answer in advance.


--

>>>> 	auth ca64a8ac subscribe linux-kernel wenyan_xin@symantec.com
Succeeded.

Re: what's the replace for the big kernel lock after kernel version 2.6.39 for system call.

[Al Viro]

On Mon, Nov 28, 2011 at 01:03:07AM -0800, Wen Yan Xin wrote:
> Hi all,
> 
> I have a trouble of working on kernel 2.6.39 and later. Originally when our kernel module startups, it hooks some file system call, like sys_open... , and the big kernel lock - lock_kernel() - will be held before creating the hook to prevent user application use system calls, and be released after the hook created.
> 
> 
> But after the kernel 2.6.39, the big kernel lock has been removed. I'm thinking there should be one or more lock that should be used. 
> 
> So, my question is which lock should be held now, when we hook the system call of file system?
> 
> I'd really appreciate your answer in advance.

1) your rootkit has always been racy; taking BKL does *NOT* prevent another
CPU from entering a system call.

2) none; just don't do it.

Re: what's the replace for the big kernel lock after kernel version 2.6.39 for system call.

[Tvrtko Ursulin]

On Tuesday 29 Nov 2011 21:41:36 Al Viro wrote:
> On Mon, Nov 28, 2011 at 01:03:07AM -0800, Wen Yan Xin wrote:
> > Hi all,
> > 
> > I have a trouble of working on kernel 2.6.39 and later. Originally when
> > our kernel module startups, it hooks some file system call, like
> > sys_open... , and the big kernel lock - lock_kernel() - will be held
> > before creating the hook to prevent user application use system calls,
> > and be released after the hook created.
> > 
> > 
> > But after the kernel 2.6.39, the big kernel lock has been removed. I'm
> > thinking there should be one or more lock that should be used.
> > 
> > So, my question is which lock should be held now, when we hook the system
> > call of file system?
> > 
> > I'd really appreciate your answer in advance.
> 
> 1) your rootkit has always been racy; taking BKL does *NOT* prevent another
> CPU from entering a system call.
> 
> 2) none; just don't do it.

Hi Al,

Why not be a nice guy when you already took the effort of replying and mention 
fanotify? Because I am sure you know the history and when you see a security 
vendor asking these things, you never know, maybe it fits their requirements. 
Maybe it is not your favourite thing as well, but not a reason not to mention 
it.

And strictly speaking, rootkits actively try to hide themselves hence whatever 
unsafe, ugly and wrong stuff they might have it is not a rootkit. :)

Regards,

Tvrtko

Re: what's the replace for the big kernel lock after kernel version 2.6.39 for system call.

[Al Viro]

On Wed, Nov 30, 2011 at 09:44:27AM +0000, Tvrtko Ursulin wrote:

> > 1) your rootkit has always been racy; taking BKL does *NOT* prevent another
> > CPU from entering a system call.
> > 
> > 2) none; just don't do it.
> 
> Hi Al,
> 
> Why not be a nice guy when you already took the effort of replying and mention 
> fanotify? Because I am sure you know the history and when you see a security 
> vendor asking these things, you never know, maybe it fits their requirements. 
> Maybe it is not your favourite thing as well, but not a reason not to mention 
> it.

1) I really have not noticed which domain had that come from until after
replying.
2) I have zero sympathy to the author's employer, so even noticing that in
time would not have made the reply any kinder.  Harsher, if nothing else, since
3) said employer was among those who had been told, again and again and again,
that patching syscall table was seriously racy.  Years ago.

> And strictly speaking, rootkits actively try to hide themselves hence whatever 
> unsafe, ugly and wrong stuff they might have it is not a rootkit. :)

Oh?  And how, pray tell, is it _finding_ the syscall table to binary-patch,
if not by rootkit-style methods?  Come to think of that, how does it defeat
the write-protection on said syscall table?

I do stand by my assessment; ignore the domain part of From and Cc and
this question is indistinguishable from "do my homework for me" kind of
question from rootkit-writer.

Re: what's the replace for the big kernel lock after kernel version 2.6.39 for system call.

[Tvrtko Ursulin]

On Wednesday 30 Nov 2011 13:56:48 Al Viro wrote:
> On Wed, Nov 30, 2011 at 09:44:27AM +0000, Tvrtko Ursulin wrote:
> > > 1) your rootkit has always been racy; taking BKL does *NOT* prevent
> > > another CPU from entering a system call.
> > > 
> > > 2) none; just don't do it.
> > 
> > Hi Al,
> > 
> > Why not be a nice guy when you already took the effort of replying and
> > mention fanotify? Because I am sure you know the history and when you
> > see a security vendor asking these things, you never know, maybe it fits
> > their requirements. Maybe it is not your favourite thing as well, but
> > not a reason not to mention it.
> 
> 1) I really have not noticed which domain had that come from until after
> replying.
> 2) I have zero sympathy to the author's employer, so even noticing that in
> time would not have made the reply any kinder.  Harsher, if nothing else,
> since 3) said employer was among those who had been told, again and again
> and again, that patching syscall table was seriously racy.  Years ago.

I then hope if you had spotted the senders domain you would have mentioned 
fanotify, even after flaming them to your hearts content.

> > And strictly speaking, rootkits actively try to hide themselves hence
> > whatever unsafe, ugly and wrong stuff they might have it is not a
> > rootkit. :)
> 
> Oh?  And how, pray tell, is it _finding_ the syscall table to binary-patch,
> if not by rootkit-style methods?  Come to think of that, how does it defeat
> the write-protection on said syscall table?
> 
> I do stand by my assessment; ignore the domain part of From and Cc and
> this question is indistinguishable from "do my homework for me" kind of
> question from rootkit-writer.

I just said, and that with a casual modifier, that it is not a rootkit _by 
definition_ of a rootkit so please don't read more from it than it was.

Tvrtko