From: Eric Paris <eparis@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: tvrtko.ursulin@sophos.com, alan@lxorguk.ukuu.org.uk,
andi@firstfloor.org, Arjan van de Ven <arjan@infradead.org>,
hch@infradead.org, linux-kernel@vger.kernel.org,
malware-list@lists.printk.net,
malware-list-bounces@dmesg.printk.net, peterz@infradead.org,
viro@ZenIV.linux.org.uk
Subject: Re: [malware-list] TALPA - a threat model? well sorta.
Date: Thu, 14 Aug 2008 09:48:33 -0400 [thread overview]
Message-ID: <1218721713.3540.125.camel@localhost.localdomain> (raw)
In-Reply-To: <20080814132455.GE6469@mit.edu>
On Thu, 2008-08-14 at 09:24 -0400, Theodore Tso wrote:
> On Thu, Aug 14, 2008 at 10:30:56AM +0100, tvrtko.ursulin@sophos.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?
next prev parent reply other threads:[~2008-08-14 13:49 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-13 16:36 TALPA - a threat model? well sorta Eric Paris
2008-08-13 16:24 ` Alan Cox
2008-08-13 16:47 ` Eric Paris
2008-08-13 16:37 ` Alan Cox
2008-08-13 17:00 ` Eric Paris
2008-08-13 19:59 ` Alan Cox
2008-08-13 21:24 ` [malware-list] " Press, Jonathan
2008-08-13 21:13 ` Alan Cox
2008-08-13 21:35 ` Rik van Riel
2008-08-13 21:23 ` Alan Cox
2008-08-15 3:25 ` Eric Paris
2008-08-15 20:16 ` Jan Harkes
2008-08-15 22:05 ` Arjan van de Ven
2008-08-17 23:19 ` Eric Paris
2008-08-17 23:26 ` Arjan van de Ven
2008-08-17 21:11 ` David Collier-Brown
2008-08-18 15:33 ` Alan Cox
2008-08-18 16:43 ` Rik van Riel
[not found] ` <20080819071416.GA14731@elf.ucw.cz>
2008-08-19 16:10 ` HSM (was Re: [malware-list] TALPA - a threat model? well sorta.) Rik van Riel
2008-08-19 19:20 ` Pavel Machek
2008-08-19 20:33 ` Rik van Riel
2008-08-20 17:03 ` Pavel Machek
2008-08-13 17:07 ` TALPA - a threat model? well sorta Christoph Hellwig
2008-08-14 13:00 ` Arnd Bergmann
2008-08-13 16:57 ` Greg KH
2008-08-13 17:39 ` Arjan van de Ven
2008-08-13 18:15 ` Theodore Tso
2008-08-13 18:21 ` Arjan van de Ven
2008-08-14 9:18 ` tvrtko.ursulin
2008-08-13 19:02 ` Eric Paris
2008-08-13 19:29 ` Theodore Tso
2008-08-13 21:15 ` [malware-list] " Press, Jonathan
2008-08-14 9:30 ` tvrtko.ursulin
2008-08-14 12:03 ` Press, Jonathan
2008-08-14 12:27 ` tvrtko.ursulin
2008-08-15 14:31 ` Pavel Machek
2008-08-14 13:24 ` Theodore Tso
2008-08-14 13:48 ` Eric Paris [this message]
2008-08-14 15:50 ` Theodore Tso
2008-08-14 17:29 ` Eric Paris
2008-08-14 19:17 ` Theodore Tso
2008-08-14 19:20 ` Eric Paris
2008-08-14 19:34 ` Christoph Hellwig
2008-08-14 19:41 ` Theodore Tso
2008-08-14 20:20 ` Christoph Hellwig
2008-08-14 21:21 ` J. Bruce Fields
2008-08-14 23:34 ` Theodore Tso
2008-08-19 21:43 ` J. Bruce Fields
2008-08-15 1:44 ` david
2008-08-15 2:04 ` Theodore Tso
2008-08-15 3:41 ` Arjan van de Ven
2008-08-15 5:05 ` david
2008-08-15 5:12 ` Johannes Weiner
2008-08-15 5:28 ` david
2008-08-15 5:36 ` david
2008-08-15 4:48 ` david
2008-08-15 8:51 ` Alan Cox
2008-08-15 14:37 ` Pavel Machek
2008-08-13 18:57 ` Eric Paris
2008-08-13 21:39 ` Arjan van de Ven
2008-08-14 14:12 ` Eric Paris
2008-08-14 15:57 ` Arjan van de Ven
2008-08-15 10:07 ` Helge Hafting
2008-08-15 10:37 ` Peter Zijlstra
2008-08-15 13:10 ` [malware-list] " Press, Jonathan
2008-08-15 13:18 ` douglas.leeder
2008-08-15 17:04 ` Theodore Tso
2008-08-15 18:09 ` Press, Jonathan
2008-08-18 10:09 ` Helge Hafting
2008-08-18 10:14 ` Peter Zijlstra
2008-08-18 10:24 ` tvrtko.ursulin
2008-08-18 10:25 ` douglas.leeder
2008-08-15 16:25 ` david
2008-08-15 16:30 ` Press, Jonathan
2008-08-15 17:33 ` david
2008-08-15 17:40 ` Press, Jonathan
2008-08-15 17:47 ` david
2008-08-15 18:06 ` Valdis.Kletnieks
2008-08-15 20:05 ` david
2008-08-15 20:17 ` Theodore Tso
2008-08-15 18:17 ` Press, Jonathan
2008-08-15 20:08 ` david
2008-08-18 10:02 ` Helge Hafting
2008-08-15 10:44 ` tvrtko.ursulin
2008-08-14 9:46 ` [malware-list] " tvrtko.ursulin
2008-08-14 13:46 ` Arjan van de Ven
2008-08-15 1:37 ` david
2008-08-15 1:31 ` david
2008-08-15 16:06 ` Pavel Machek
2008-08-18 12:21 ` david
2008-08-18 13:30 ` Pavel Machek
2008-08-19 0:03 ` david
2008-08-13 18:17 ` Andi Kleen
2008-08-13 18:21 ` H. Peter Anvin
2008-08-13 18:24 ` Arjan van de Ven
2008-08-13 18:40 ` Eric Paris
2008-08-14 0:18 ` Mihai Donțu
2008-08-14 11:58 ` [malware-list] " Press, Jonathan
2008-08-14 12:34 ` Mihai Donțu
2008-08-14 0:14 ` 7v5w7go9ub0o
2008-08-14 2:25 ` 7v5w7go9ub0o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1218721713.3540.125.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=malware-list-bounces@dmesg.printk.net \
--cc=malware-list@lists.printk.net \
--cc=peterz@infradead.org \
--cc=tvrtko.ursulin@sophos.com \
--cc=tytso@mit.edu \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).