Messages in this thread | | | Subject | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning | From | tvrtko.ursulin@sophos ... | Date | Wed, 6 Aug 2008 09:39:03 +0100 |
| |
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.
| |