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

Parse accept4 flags #864

Closed
wants to merge 4 commits into from
Closed

Conversation

arossert
Copy link
Contributor

This PR addressing #844.
This may break some other code that relies on the filtering of accept by name (I have fixed some chisels that I could find that use this filter).

sysdig-CLA-1.0-contributing-entity: Amir Rossert
sysdig-CLA-1.0-signed-off-by: John Tsai johntsai@paypal.com
@ret2libc
Copy link
Contributor

This look ok to me, although without exporting the flags you won't get much information, except that it is an accept4.

@arossert
Copy link
Contributor Author

I can try to implement this but I don't know where I can get the masking of the flags
like:

#define PPM_SOCK_NONBLOCK	(1 << 0)
#define PPM_SOCK_CLOEXEC	(2 << 0)

If you can give me a direction where to start I will start working on it

@ret2libc
Copy link
Contributor

You can have a look at the open syscall[1] to see how flags are used and converted from native to PPM_* values[2].

[1] https://github.com/draios/sysdig/blob/dev/driver/event_table.c#L26
[2] https://github.com/draios/sysdig/blob/dev/driver/ppm_fillers.c#L554

@arossert
Copy link
Contributor Author

Thanks for the tip but I have an issue with getting the flags.
This is my function:

static inline u32 accept4_flags_to_scap(unsigned long flags)
{
	u32 res = 0;

	if (flags & SOCK_NONBLOCK)
		res |= PPM_SOCK_NONBLOCK;

	if (flags & SOCK_CLOEXEC)
		res |= PPM_SOCK_CLOEXEC;

	return res;
}

When I'm sending args->socketcall_args[3] the result is always 0.

Do I need to do something to put the value in socketcall_args?

@ret2libc
Copy link
Contributor

If I'm not wrong, socketcall_args is initialized only when socketcall syscall is used to multiplex socket-related operations(e.g. bind, recv, etc.). Nowadays x86-64 does not use it, for example. Have a look at https://github.com/draios/sysdig/blob/dev/driver/ppm_fillers.c#L2003 to see how to correctly retrieve the argument when socketcall is used and when it is not.

@arossert
Copy link
Contributor Author

Can you please elaborate on

static inline void syscall_get_arguments(struct task_struct *task,
					 struct pt_regs *regs,
					 unsigned int i, unsigned int n,
					 unsigned long *args)

What does the i and n stands for?

sysdig-CLA-1.0-contributing-entity: Amir Rossert
sysdig-CLA-1.0-signed-off-by: John Tsai johntsai@paypal.com
@arossert
Copy link
Contributor Author

I was able to make it work by using syscall_get_arguments(current, args->regs, 3, 1, &val);
I will appreciate if you can explain how to use syscall_get_arguments() (I was able to make it work by trial and error).

Let me know if I forgot something in the process.

@ret2libc
Copy link
Contributor

I think reading the function at https://github.com/draios/sysdig/blob/dev/driver/ppm_syscall.h#L139 should give you a pretty good understanding of how syscall_get_arguments works. i selects the first argument of the syscall that you want to extract, n tells the number of arguments to extract.

@arossert arossert changed the title distinguish between accept() and accept4() Parse accept4 flags Jun 25, 2017
@ret2libc
Copy link
Contributor

Hi! This looks ok to me apart from the conflicts. I can resolve them when merging, if that's ok with you.

arossert and others added 2 commits September 27, 2017 17:25
…_accept_accept4

# Conflicts:
#	driver/flags_table.c
#	driver/ppm_events_public.h
#	userspace/libscap/flags_table.c
#	userspace/sysdig/chisels/v_incoming_connections.lua

sysdig-CLA-1.0-contributing-entity: Amir Rossert
sysdig-CLA-1.0-signed-off-by: John Tsai johntsai@paypal.com
# Conflicts:
#	driver/ppm_events_public.h
sysdig-CLA-1.0-contributing-entity: Amir Rossert
@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Feb 24, 2023
@github-actions github-actions bot closed this Mar 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants