> On Wed, Aug 06, 2008 at 10:37:06AM +0100,
tvrtko.ursulin@sophos.com wrote:
> > Greg KH wrote on 05/08/2008 21:15:35:
> >
> > > > > > 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....
> > > > >
> > > > > How long does this whole process take? Seriously is it worth the
> > added
> > > > > kernel code for something that is not measurable?
> > > >
> > > > Is it worth having 2 context switches for every open when none are
> > > > needed? I plan to get numbers on that.
> > >
> > > Compared to the real time it takes in the "virus engine"? I bet it's
> > > totally lost in the noise. Those things are huge beasts with thousands
> > > to hundreds of thousands of context switches.
> >
> > No, because we are talking about a case here where we don't want to do any
> > scanning. We want to detect if it is procfs (for example) as quickly as
> > possible and don't do anything. Same goes for any other filesystem where
> > it is not possible to store arbitrary user data.
>
> See previous messages about namespaces and paths for trying to figure this
> kind of information out in a sane way within the kernel.