Date:	Wed, 6 Aug 2008 09:39:03 +0100
From:	tvrtko.ursulin@...hos.com
To:	Eric Paris <eparis@...hat.com>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	malware-list@...ts.printk.net
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface	for	on
 access scanning

Eric Paris wrote on 05/08/2008 01:32:54:

> On Mon, 2008-08-04 at 15:32 -0700, Greg KH wrote:
> > Why would userspace care about these meta-file things, what does it 
want
> > with them?
> 
> Honstely?  I don't know.  Maybe someone with access to the black magic
> source code will stand up and say if most of this metadata is important
> and if so how.

In general this metadata provides more context to the event that happened. 
For example reporting - log message/UI popup/centralised something can be 
displayed saying which user running which application was involved with 
bad stuff. Also we can find out where the user is logged in and send him a 
message there.

It is more descriptive than just failing the access with -EACCESS which 
becomes ambigious.

> > > 10. Filesystem exclusions
> > > -------------------------
> > > One pretty important optimization is not to scan things like /proc, 
/sys
> > > or similar. Basically all filesystems where user can not store
> > > arbitrary, potentially malicious, content could and should be 
excluded
> > > from scanning.
> > 
> > Why, does scanning these files take extra time?  Just curious.
> 
> Perf win, why bothering looking for malware in /proc when it can't
> exist?  It doesn't take longer it just takes time having to do
> 
> userspace -> kernel -> userspace -> kernel -> userspace
> 
> just to cat /proc/mounts, all of this could probably be alliviated if we
> cached access on non block backed files but then we have to come up with
> a way to exclude only nfs/cifs.  I'd rather list the FSs that don't need
> scanning every time than those that do....

Agreed.

> > > Closing remarks
> > > ---------------
> > > Although some may argue some of the filters are not necessary or may
> > > better be implemented in userspace, we think it is better to have 
them
> > > in kernel primarily for performance reasons.
> > 
> > Why?  What numbers do you have that say the kernel is faster in
> > implementing this?  This is the first mention of such a requirement, 
we
> > need to see real data to back it up please.
> 
> In kernel caching is clearly a huge perf win.  I couldn't even measure a
> change in kernel build time when I didn't run a userspace client.  If
> anyone can explain a way to get race free in kernel caching and out of
> kernel redirection and scanning I'd love it   :)

When you don't run an userspace client cache should not come into play 
because nothing will be cached (in this iteration at least). So I guess 
you meant something different here? Like not running an userspace client 
and having the filter disabled (or even not) will produce very little 
overhead, probably not observable without micro-benchmarking. Having an 
userspace client which just replies with "allow" should have even less 
performance impact because most inodes will get cached which means filter 
chain will be shorter on subsequent accesses to the same inode.

In either case it will become obvious how huge performance win is to have 
in kernel caching once you get the numbers. Let me know if I can help you 
with that somehow.

Tvrtko


Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.

--
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/

Powered by blists - more mailing lists