Optimization #580
closed
use mpm results for secondary patterns if available
Added by Victor Julien over 11 years ago.
Updated over 8 years ago.
Description
While reviewing mpm pattern distribution, I noticed quite a few sigs have patterns that are not the sigs fast_pattern that are in the mpm anyway because of other sigs. In these cases we could possibly use the mpm results in content validation.
Further explanation of this idea. Say we have 2 sigs in a sgh:
content:"abc"; sid:1;
content:"reallylongstring"; content:"abc"; sid:2;
And assume that for sid 2 we use "reallylongstring" in the mpm.
When the mpm indicates a potential match for sid 2, we know that the mpm actually also looked for sid 2's other pattern as that is the mpm pattern for sid 1. So we may be able to use this info to determine if sid2 can match. Instead of looking for "abc" with the spm, we can lookup in the pmq if we have a match for "abc".
Obviously, this wouldn't be enough when there is a complex relationship between sid 2's patterns, but it may still help perf to check first.
- Assignee set to Anoop Saldanha
1. This optimization is ideal when ones uses single mode.
2. In full mode, a sig might belong to multiple sghs. So the patterns in a sig which can be considered to be mpm-checked, should be present in every sgh the sig is part of.
Anoop Saldanha wrote:
1. This optimization is ideal when ones uses single mode.
2. In full mode, a sig might belong to multiple sghs. So the patterns in a sig which can be considered to be mpm-checked, should be present in every sgh the sig is part of.
Dwelling a bit over (2), we can probably do 2 things -
2.1 A sig is updated with patterns that is common to all the sghs it belongs to.
2.2 A sig is updated with patterns for every sgh it belongs to, but each sgh pattern's stored in a section of its own inside the sig. So when a sig is inspected, we use the sgh index to use the patterns specific to the sgh-sig combination. The issue here is how much data we might end up storing in a sig.
- Priority changed from Normal to Low
- Target version changed from 2.0rc2 to 3.0RC2
- Target version changed from 3.0RC2 to 70
- Status changed from New to Closed
- Assignee deleted (
Anoop Saldanha)
- Target version deleted (
70)
This no longer makes sense. In the new mpm setup we use sid's instead of pid's.
Also available in: Atom
PDF