Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning

Nick Piggin
2008-08-06T17:01:21Z

On Wednesday 06 August 2008 21:29, tvrtko.ursulin@sophos.com wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote on 06/08/2008 12:10:58:

> > > code so what am I missing?
> >
> > Maybe... but that's not the same as what requirement 5 calls for.
>
> I see what you mean, it should have been worded better. Nevertheless that
> is what was intended by it - to enable caching only on filesystems where
> it is safe to do so.

That is exactly what you cannot do. Otherwise you have to rewrite
filesystems not to use the pagecache, and probably have to do disallow
or do some horrible hacks to support mmap.

The requirement you actually intend is more like what you said before,
along the lines of "file can't be changed in given set of circumstances".

> > But depending on exactly what semantics you really call for, it can get
> > tricky to account for all of pagecache. Writes can happen through page
> > tables or get_user_pages. True that a process has to at some point have
> > write permission to the file, but the cache itself could be modified
> > even after the file is closed and all mmaps disappear.
>
> I don't have a very good understanding of the VM subsystem I must admit.
> So in other words with the current kernel file modification time is not
> necessarily correct - it represents when the file was last opened for
> modification, not when it was actually modified? (While those two points
> in time can be arbitrarily separated)

It is a best effort thing. When you start mmapping, that allows
get_user_pages, which in turn may be able to take pages and modify
them at fairly arbitrary points in time.

> How would I use those methods for file modification? I am curious to make
> a test case..

Even just with mmap (we do a much better job of it now, but) you
can probably write to a file after mtime if you write to already
dirty pages.