Suricata

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.

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.