-
Notifications
You must be signed in to change notification settings - Fork 382
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
tetragon: char_buf matchArgs works not as expected #576
Conversation
d596d5f
to
a2c6535
Compare
d8dfd6d
to
b6933fc
Compare
@Y-dc could you rebase and add a test for us? This seems like it would be good to fix. |
b6933fc
to
f6f967f
Compare
f6f967f
to
89b058a
Compare
might be unrelated but there was recent fix from @kevsecurity in that area 5ebb0e3 |
nice fix! I haven't used file buf matching yet, but it's really not relevant. |
89b058a
to
d818f9e
Compare
bpf/process/types/basic.h
Outdated
:); | ||
v = (int)value[j]; | ||
a = (int)args[0]; | ||
v = ((int *)value)[j]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While the original construction was broken (only taking the first byte of the length at &value[j], this replacement appears to incorrectly treat j as a (int *) index rather than a (char *) index. It probably needs to be:
v = *(int *)&value[j];
instead. Similar should be done for the following line, although it obviously matters less.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 It looks like you've removed this change. I think you were right it could do with fixing (for future proofing it nothing else). Did you disagree with "v = *(int *)&value[j];" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think you are right, I agree "v = *(int *)&value[j];". I removed the change to determine whether it was impossible to pass the test case before the change
d7c2860
to
c552d4b
Compare
I have tested successfully. apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: syscall
spec:
tracepoints:
- args:
- index: 5
returnCopy: false
type: fd
- index: 6
returnCopy: false
sizeArgIndex: 8
type: char_buf
- index: 7
returnCopy: false
type: size_t
event: sys_enter_write
selectors:
- matchArgs:
- index: 1
operator: Equal
values:
- "123"
subsystem: syscalls go program print fmt.Printf("123") tetragon log
I need to check the failure of |
i found the reason. but use different copy functions, and the offsets of the string values and char_buf values in the respective copy functions are different. static inline __attribute__((always_inline)) long
copy_strings(char *args, unsigned long arg)
{
int *s = (int *)args;
long size;
size = probe_read_str(&args[4], MAX_STRING, (char *)arg);
if (size < 0) {
return filter;
}
*s = size;
// Initial 4 bytes hold string length
return size + 4;
} |
This patch fixup the char_buf args match (matchArgs) filter. Signed-off-by: dechengyuan <[email protected]>
c552d4b
to
925c50b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR does not add tests, merging #770 does it! |
fix #575 . preferably based on #568 and #564 .
I found the source of the bug in
filter_char_buf
(source code). the comparison of strings and their lengths is wrong.form
__copy_char_buf
(source code) , the targetarg
inargs
should be offset by 8.Signed-off-by: dechengyuan [email protected]