lkml.org 
[lkml]   [2008]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning
    On Tue, Aug 05, 2008 at 03:46:03PM -0400, Eric Paris wrote:
    > On Mon, 2008-08-04 at 17:51 -0700, Greg KH wrote:
    > > On Mon, Aug 04, 2008 at 08:32:54PM -0400, Eric Paris wrote:
    >
    > > Oh, and after that, not using a binary interface, have we not learned
    > > from the ioctl mess? I sure thought we had...
    >
    > I don't see a reason why we can't use strings and key=value pairs for
    > any metadata being sent back and forth. That seem more reasonable?

    Sure, but do you really want to put a parser in the kernel (well, make
    that, yet-another-parser-in-the-kernel...)?

    > > > > Heh, so if you want to write a "virus" for Linux, just implement this
    > > > > flag. What's to keep a "rogue" program from telling the kernel that all
    > > > > programs on the system are to be excluded?
    > > >
    > > > Processes can only get this flag one of 2 ways.
    > > >
    > > > 1) register as a client to make access decisions
    > >
    > > How do you do that?
    >
    > open the magic "vetting" file RW and you are a client who can answer
    > access decisions.

    What's to keep anyone from doing this?

    > > > 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.

    > > > In kernel caching is clearly a huge perf win.
    > >
    > > Why? If the cache is also in userspace, it should be the same, right?
    >
    > In kernel cache has 0 context switches for every open. Userspace
    > caching has 2. Every open has to block, switch to the context of the
    > userspace client/cache, get that decisions, and then switch back to the
    > original process.

    Again, compared to what? If you in userspace are doing big complex
    things, such an overhead is trivial.

    And again, realize that Linux has the fastest context switches _by far_
    of any other operating system. It is ok to do things in userspace, we
    are used to that :)

    thanks,

    greg k-h


    \
     
     \ /
      Last update: 2008-08-05 22:25    [W:0.061 / U:119.092 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site