--- On Wed, 7/30/08, John P. Rouillard <[EMAIL PROTECTED]> wrote: > From: John P. Rouillard <[EMAIL PROTECTED]> > Subject: Re: [Simple-evcorr-users] SUPPRESS processing earlier? > To: "Mills, Rocky" <[EMAIL PROTECTED]> > Cc: [email protected] > Date: Wednesday, July 30, 2008, 3:35 PM > In message > <[EMAIL PROTECTED]>, > "Mills, Rocky" writes: > >-----Original Message----- > >>From: John P. Rouillard [mailto:[EMAIL PROTECTED] > >>I'm not sure what you are asking here. There no > such thing as a > >>"static context" in sec. All contexts are > dynamic can be created and > >>destroyed. > >> [...] > >>Hmm, do you mean a constant context that > doesn't depend on the results > >>of the rule match? If so, then no, I don't > think it does a pre-eval on > >>that. Arguably it could do the same on SubStr as > well. Checking > >>through my rulesets, that could be a win depending > on how expensive > >>the regexp is. > > >When I say static context, I mean something like > context=DETECTED_PING > >and by dynamic I mean something like > context=DETECTED_PING_FROM_$1 where > >there is a dynamic value like $1 used in the > expression's name. > >[...] > >So during SEC startup while the rules are loaded before > event processing > >begins, perhaps SEC could examine the rule and it if > does not detect $1 > >or other dynamic values, it could internally flag the > context with [ ! > >NOREGEXP_EXTRACTION ] and then before attempting to > match the new line > >per the regexp it would check the context first and > potentially avoid > >doing the regexp matching. I'm thinking this may > improve performance > >but I don't know the ramifications in doing what > I'm asking about. > > > >I hope that clears up my question. > > It does. It's my second case, quoted above. Interesting > idea. I am > also not quite sure of the ramifications. Risto may have a > better feel > for it.
What could be done is to add a simple check whether the context contains variable symbols at all ($ and %), and tag the context as 'preeval' if it doesn't. Note, however, that this doesn't provide 100% accuracy, since: 1) $ and % symbols could be masked, 2) if a $- or %-variable is not set by a regexp, no substitution is done for the variable. In other words, the actual number of substitutions can be determined only after a regexp match. There is also one downside of the idea of automated tagging -- I haven't tested it, but I am not sure how evaluating a complex context expression with several && and || operators compares to a fairly simple regular expression. If the context expression contain parentheses, the evaluation will involve recursion, so running a simple regexp first might be a quicker way for finding that the rule doesn't match. However, that question needs some further testing. br, risto > > -- > -- rouilj > John Rouillard > =========================================================================== > My employers don't acknowledge my existence much less > my opinions. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Simple-evcorr-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
