Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755839AbYHRRjU (ORCPT ); Mon, 18 Aug 2008 13:39:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753487AbYHRRjM (ORCPT ); Mon, 18 Aug 2008 13:39:12 -0400 Received: from mail.lang.hm ([64.81.33.126]:55207 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752360AbYHRRjM (ORCPT ); Mon, 18 Aug 2008 13:39:12 -0400 Date: Mon, 18 Aug 2008 10:38:54 -0700 (PDT) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: Eric Paris cc: Alan Cox , tvrtko.ursulin@sophos.com, Theodore Tso , davecb@sun.com, Adrian Bunk , linux-kernel , malware-list@lists.printk.net, Casey Schaufler , Arjan van de Ven Subject: Re: [malware-list] scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning In-Reply-To: <1219080504.15566.65.camel@localhost.localdomain> Message-ID: References: <20080818153212.6A6FD33687F@pmx1.sophos.com> <1219076143.15566.39.camel@localhost.localdomain> <20080818171500.78590801@lxorguk.ukuu.org.uk> <1219080504.15566.65.camel@localhost.localdomain> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1213 Lines: 30 On Mon, 18 Aug 2008, Eric Paris wrote: > On Mon, 2008-08-18 at 17:15 +0100, Alan Cox wrote: >>> read -> we have the ALLOW/mark result bit in core set so just allow. >> >> Don't think we need this - SELinux can do that bit >> >>> mtime update -> clear ALLOW/"mark result" bit in core, send async >>> notification to userspace >> >> Why via the kernel ? > > the single in core allow/deny bit is so that the vast majority of > operations are completely free. Say we scan/index /lib/ld-linux.so.2 > once. Do you really want every single read/mmap operation from then on > to have to block waiting for the userspace caches of you HSM, your AV > scanner, and you indexer? If all three tell the kernel they don't need > to see it again and that information is easy and free to maintain, lets > do it. this is why the proposal caches the results of all the scanners with the file (in the xattrs), rather then having each scanner store it's own scan results David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/