[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1218721713.3540.125.camel@localhost.localdomain>
Date: Thu, 14 Aug 2008 09:48:33 -0400
From: Eric Paris <eparis@...hat.com>
To: Theodore Tso <tytso@....edu>
Cc: tvrtko.ursulin@...hos.com, alan@...rguk.ukuu.org.uk,
andi@...stfloor.org, Arjan van de Ven <arjan@...radead.org>,
hch@...radead.org, linux-kernel@...r.kernel.org,
malware-list@...ts.printk.net,
malware-list-bounces@...sg.printk.net, peterz@...radead.org,
viro@...IV.linux.org.uk
Subject: Re: [malware-list] TALPA - a threat model? well sorta.
On Thu, 2008-08-14 at 09:24 -0400, Theodore Tso wrote:
> On Thu, Aug 14, 2008 at 10:30:56AM +0100, tvrtko.ursulin@...hos.com wrote:
> > The thing is the idea never was for clean-dirty "database" to be
> > persistent but to have the same lifetime as the inode (in memory one). And
> > once the cache/database gets invalidated re-scanning happens on-demand so
> > the 5TB problem does not exist. Concerns about multiple clients where
> > every has a different versioning scheme are also not relevant with the
> > proposed versioning scheme (see my reply to Arjan).
>
> So in essence, what I hear you saying is that all AV products want to
> work in a mode where the moment the inode falls out of the inode
> cache, and we lose the "clean" bit, when the inode is brought back
> into the cache, it will be scanned again. That is, the "clean" bit is
> never persistent, and never needs to be stored in memory.
There needs to be a way to say that an inode in cache needs to be
rescanned. 3 states this flag can be. Clean, Dirty, Infected. The
current talpa solution involves a global monotomically increasing
counter every time you change virus defs or make some "interesting"
change. If global == inode flag we are clean. If global == negative
inode flag we are infected. if global > inode flag we are dirty and
need a scan.
> That seems fair; if it turns out there is an AV product that wants to
> optimize this a bit further, as long as we provide a persistent inode
> version/generation number, they can always do their own persistent
> database in userspace.
exporting i_version might be useful for better userspace caching,
although I've yet to see any reasonable description of how a userspace
database can map between data on disk and what they have in userspace.
How can a userspace process, given 2 file descriptors know they are
actually the same thing on disk?
--
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