Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

String: Support longer exact match strings #2069

Merged
merged 1 commit into from
Feb 8, 2024

Conversation

kevsecurity
Copy link
Contributor

String matching is limited to strings of length 144 due to the way the hash look up tables were implemented (6 key sizes, 24 byte increments).

This commit adds maps to support larger key/string sizes: 256, 512, 1024, 2048, and 4096. This will therefore permit exact string matches for strings of length up to 4096 (not including null terminator).

Includes tests at map limits.

Extend string matching to strings of length 4096 characters (increased from 144 characters).

@kevsecurity kevsecurity added the release-note/minor This PR introduces a minor user-visible change label Feb 6, 2024
@kevsecurity kevsecurity requested a review from a team as a code owner February 6, 2024 13:30
@kevsecurity kevsecurity requested a review from olsajiri February 6, 2024 13:30
@kevsecurity kevsecurity force-pushed the pr/kevsecurity/string-match-hash-longer branch from 8c7b84e to 1883303 Compare February 6, 2024 13:32
@kevsecurity kevsecurity requested a review from jrfastab February 6, 2024 13:32
@kevsecurity kevsecurity force-pushed the pr/kevsecurity/string-match-hash-longer branch 3 times, most recently from 4e697e9 to f1c95b2 Compare February 7, 2024 17:26
String matching is limited to strings of length 144 due to the way the
hash look up tables were implemented (6 key sizes, 24 byte increments).

This commit adds maps to support larger key/string sizes: 256, 512,
1024, 2048, and 4096. This will therefore permit exact string matches
for strings of length up to 4096 (not including null terminator).

Unfortunately, kernels v5.10 and lower restrict hash key lengths to 512
bytes, so on these kernels the maximum string length is 510 characters
(512 - 2 bytes for embedded string length).

And on older kernels (<5.3) the instruction and complexity limits mean
the new approach is not feasible. Therefore on these kernels, the
maximum string length is 144 characters (as before).

Includes tests at map limits.

Signed-off-by: Kevin Sheldrake <kevin.sheldrake@isovalent.com>
@kevsecurity kevsecurity force-pushed the pr/kevsecurity/string-match-hash-longer branch from f1c95b2 to 1299574 Compare February 7, 2024 18:16
@jrfastab jrfastab merged commit 834b5fe into main Feb 8, 2024
36 checks passed
@jrfastab jrfastab deleted the pr/kevsecurity/string-match-hash-longer branch February 8, 2024 09:00
@dwindsor
Copy link
Collaborator

dwindsor commented Feb 8, 2024

String matching is limited to strings of length 144 due to the way the hash look up tables were implemented (6 key sizes, 24 byte increments).

This commit adds maps to support larger key/string sizes: 256, 512, 1024, 2048, and 4096. This will therefore permit exact string matches for strings of length up to 4096 (not including null terminator).

Includes tests at map limits.

Extend string matching to strings of length 4096 characters (increased from 144 characters).

Hi! Thanks for this fix.

Would it be possible to not store paths in the strings table, rather in another table that's keyed by a (device, inode) tuple in order to remove the limit on older kernels?

@kevsecurity
Copy link
Contributor Author

Would it be possible to not store paths in the strings table, rather in another table that's keyed by a (device, inode) tuple in order to remove the limit on older kernels?

I think that's a different use case. I'll have a think and chat with some colleagues to see if that's possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-note/minor This PR introduces a minor user-visible change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants