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

Detect cleanups/v4 #9974

Closed
wants to merge 18 commits into from
Closed

Conversation

victorjulien
Copy link
Member

#9949 rebased

Hitting the recursion limit should be rare.
Integrate with rest of content inspect code.
Use stack local var instead of DetectEngineThreadCtx member.

Make sure the limit is a const so we can avoid rereading it.
Flatten else branches after terminating ifs.
Since recursive content matching goes through the buffer from left to
right, it is possible to bail early when isdataat is part of the
recursive checking. If `isdataat:50,relative` fails for offset 10, it
will surely also fail for offset 20. So break inspection in such cases.

The exception is for dynamic isdataat, where the value is determined
by a prior byte_extract that may be updated during the recursion.
DetectEngineThreadCtx::replist is managed elsewhere.
Adjust includes to enable this.
Move reference count to top of DetectEngineThreadCtx, to move it to the
same cache line as the other members that are checked first in Detect().
Move members used by DetectEngineContentInspection() to the same cache line.
Core logic of the tests moved to content inspection code in separate commit.
@victorjulien victorjulien mentioned this pull request Dec 5, 2023
Copy link

codecov bot commented Dec 5, 2023

Codecov Report

Merging #9974 (6d3bfa9) into master (c1bf955) will decrease coverage by 0.01%.
The diff coverage is 95.74%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #9974      +/-   ##
==========================================
- Coverage   82.42%   82.41%   -0.01%     
==========================================
  Files         970      970              
  Lines      271363   271245     -118     
==========================================
- Hits       223667   223551     -116     
+ Misses      47696    47694       -2     
Flag Coverage Δ
fuzzcorpus 64.45% <79.81%> (+<0.01%) ⬆️
suricata-verify 61.31% <85.32%> (-0.05%) ⬇️
unittests 62.87% <81.56%> (-0.02%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 16884

Copy link
Member

@jasonish jasonish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I think some commits could use a little more description.

detect/dns.query: use new content inspect entry

Why?

detect/content-inspect: localize recursion counting

Again, perhaps a little more detail.

Given there is no ticket for these.

Copy link
Contributor

@jufajardini jufajardini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks ok to me, have one double check comment and a question about initialization of a struct value inline.

@@ -28,7 +28,7 @@
/** indication to content engine what type of data
* we're inspecting
*/
enum {
enum DetectContentInspectionType {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to use typedef?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These days I'm finding things that are more explicit easier to work with. Typedef hides important detail.

Comment on lines +721 to +724
bool DetectEngineContentInspectionBuffer(DetectEngineCtx *de_ctx, DetectEngineThreadCtx *det_ctx,
const Signature *s, const SigMatchData *smd, Packet *p, Flow *f, const InspectionBuffer *b,
const enum DetectContentInspectionType inspection_mode)
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I understand correctly that the difference between this and DetectEngineContentInspection is that this one uses specific types for buffer and inspection type? If so, I wonder if this difference, or an indication of preference of usage should be added to the function description or commit.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've update the commit msg. It's a convenience function that keeps the internals of InspectionBuffer hidden from the callers.

Comment on lines 109 to 118
if (unlikely(det_ctx->inspection_recursion_counter == de_ctx->inspection_recursion_limit)) {
ctx->recursion.count++;
if (unlikely(ctx->recursion.count == ctx->recursion.limit)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw that before calling DetectEngineContentInspectionInternal from DetectEngineContentInspection, ctx->recursion.limit was set. However, for other direct calls of DetectEngineContentInspectionInternal I didn't see that being defined. For those cases, is this being defined elsewhere that I missed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

both DetectEngineContentInspectionBuffer and DetectEngineContentInspection set it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the ctx is shared between consecutive recursive calls then, it's actually meant to count and limit that recursion

Comment on lines -582 to +581
endian |= (uint8_t)((flags & DETECT_CI_FLAGS_DCE_LE) ? LittleEndian : BigEndian);
endian = (uint8_t)((flags & DETECT_CI_FLAGS_DCE_LE) ? LittleEndian : BigEndian);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this connected to the rest of the changes here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a minor clarification. The resulting value is the same.

Comment on lines -6796 to -6797
UtRegisterTest("UriTestSig30", UriTestSig30);
UtRegisterTest("UriTestSig31", UriTestSig31);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to double check: is this the commit that added similar logic elsewhere? 32b4423

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heh, no, it's in a branch that is still WIP. I'll drop this commit from here.

@victorjulien
Copy link
Member Author

In general I think some commits could use a little more description.

detect/dns.query: use new content inspect entry

Why?

detect/content-inspect: localize recursion counting

Again, perhaps a little more detail.

Given there is no ticket for these.

Added some explanations

@victorjulien victorjulien mentioned this pull request Dec 6, 2023
@victorjulien
Copy link
Member Author

replaced by #9986

@victorjulien victorjulien deleted the detect-cleanups/v4 branch February 20, 2024 12:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants