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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <201111301412.13160.tvrtko.ursulin@onelan.co.uk>
Date:	Wed, 30 Nov 2011 14:12:13 +0000
From:	Tvrtko Ursulin <tvrtko.ursulin@...lan.co.uk>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: what's the replace for the big kernel lock after kernel version 2.6.39 for system call.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/