[Tracking] Params inconsistencies in our drivers #515

Andreagit97 · 2022-07-30T13:24:52Z

PLEASE NOTE

This issue is mainly for tracking purposes, some points cannot be addressed until we solve the scap-file compatibility issue -> #1381 (comment)

Generic context

The aim of this issue is to track all the inconsistencies when we send event params from our drivers (modern_bpf, bpf, kernel module) to userspace. Some widespread issues that need a dedicated conversion

Today when we send file descriptors fd to userspace, we send them as int64_t while they are represented on int32_t. This leads us to waste a lot of space in our ring buffers... fd params are very common in our event, we waste 4 bytes every time we send a param of this type. Considering a small/medium-size system, we can imagine that it could send also 1 million of fd params per second, this would mean wasting almost 4 MB of space in our ring buffers per second!
Today when we send process identifiers pid to userspace, we send them as int64_t while they are represented on int32_t. This leads us to waste a lot of space in our ring buffers as explained in the previous fd case.
In some syscalls we take the syscalls flags as an int value and we push it to userspace as uint32_t without converting it with our internal PPM representation.
This is similar to the previous point, but even if we send flags/modes with the same type (so take uint32_t and send uint32_t) in some cases we don't convert these values into the scap PPM format, so we cannot use this flags/modes userspace-side even if we catch them driver side.
In some events we send empty params because they are still not implemented.
Every syscall must have its PPM_CODE and its event pair.
Different drivers manage max boundaries in different ways we need to uniform them in some way 👇
update(modern_bpf): reduce the execve instrumentation time with new APIs #648 (comment)

Syscall-specific issues

LEGENDA

[NOT ADDRESSABLE] -> means that the issue is not addressable at the moment, at least until we don't solve the scap file issue, see PLEASE NOTE ☝️
[MODERN_BPF] -> means that the issue is only related to the modern_bpf probe
[BPF] -> means that the issue is only related to the bpf probe
[KMOD] -> means that the issue is only related to the kernel module
⚠️ -> possible problems, fix it!
⬅️ -> only in the enter event
➡️ -> only in the exit event

`open_by_handle_at` ➡️

[MODERN BPF] we can get at maximum 8 path_components we need to find a workaround to manage more components!
open_flags_to_scap() method should receive an int value and not a uint32_t.

`dup3` ➡️

dup3_flags_to_scap() method should receive an int value and not a uint32_t.

`open`

open_flags_to_scap() method should receive an int value and not a uint32_t.

`openat`

open_flags_to_scap() method should receive an int value and not a uint32_t.

`openat2`

open_flags_to_scap() method should receive an int value and not a uint32_t.

`eventfd` ⬅️

[NOT ADDRESSABLE] param 2 is not necessary, there is no flag argument in eventfd, we have it only in eventfd2 https://github.com/falcosecurity/libs/pull/516/files#r935326971. We need a new event

`eventfd2` ⬅️

param 2 (flags) is not implemented, we push 0 to userspace

`inotify_init` ⬅️

[NOT ADDRESSABLE] inotify_init has no syscall arguments but we send one param

`signalfd` ⬅️

[NOT ADDRESSABLE] param 2 (mask) is not implemented, we push 0 to userspace. We should remove it
[NOT ADDRESSABLE] param 3 (flags)is not implemented, we push 0 to userspace. We should remove it. Moreover, this syscall has not a flag argument, please see here for more details https://elixir.bootlin.com/linux/v6.5.5/source/fs/signalfd.c#L314

`signalfd4` ⬅️

[NOT ADDRESSABLE] param 2 (mask) is not implemented, we push 0 to userspace. We should remove it.

`timerfd_create` ⬅️

param 1 (clockid) is not implemented, we push 0 to userspace. We should implement it.
param 2 (flags) is not implemented, we push 0 to userspace. We should implement it.

`userfault_fd` ➡️

param 2 (flags) miss an helper like userfaultfd_flags_to_scap to convert flags to scap notation.

`ptrace` ➡️

[NOT ADDRESSABLE] param 2 (addr) not sure we really need a PT_DYN param, we always send the same len.
[NOT ADDRESSABLE] param 3 (data) not sure about the utlity of sending the data_pointer to userspace.

`mkdirat` ➡️

param 4 (mode) we need to convert the mode to the scap format.

`pipe2`

we need a new event for pipe2 otherwise we cannot catch the flags. Right now we use the same event of pipe.

`renameat2` ➡️

param 6 (flags) we need to convert the flags to the scap format with an helper like renameat2_flags_to_scap.

`execve` ➡️

[NOT ADDRESSABLE] param 7 (cwd) is not implemented, we push 0 to userspace

libs/driver/bpf/fillers.h

Line 2417 in a8561a7

res = bpf_val_to_ring_type(data, (unsigned long)&empty, PT_CHARBUF);
param 17 (tty) is a uint32_t not an int32_t fix(driver, userspace): fix loginuid, euid and tty types to uint32_t #1192
param 19 (loginuid) is a uint32_t not an int32_t, a PR is up fix(driver, userspace): fix loginuid, euid and tty types to uint32_t #1192
[MODERN BPF] param 20 (flags) still to implement.

`execveat` ➡️

[NOT ADDRESSABLE] param 7 (cwd) is not implemented, we push 0 to userspace

libs/driver/bpf/fillers.h

Line 2417 in a8561a7

res = bpf_val_to_ring_type(data, (unsigned long)&empty, PT_CHARBUF);
param 17 (tty) is a uint32_t not an int32_t fix(driver, userspace): fix loginuid, euid and tty types to uint32_t #1192
param 19 (loginuid) is a uint32_t not an int32_t fix(driver, userspace): fix loginuid, euid and tty types to uint32_t #1192
[MODERN BPF] param 20 (flags) still to implement.

`fork` ➡️

[NOT ADDRESSABLE] param 7 (cwd) is not implemented, we push 0 to userspace

libs/driver/bpf/fillers.h

Line 2417 in a8561a7

res = bpf_val_to_ring_type(data, (unsigned long)&empty, PT_CHARBUF);

`clone` ➡️

[NOT ADDRESSABLE] param 7 (cwd) is not implemented, we push 0 to userspace

libs/driver/bpf/fillers.h

Line 2417 in a8561a7

res = bpf_val_to_ring_type(data, (unsigned long)&empty, PT_CHARBUF);

`clone3` ➡️

[NOT ADDRESSABLE] param 7 (cwd) is not implemented, we push 0 to userspace

libs/driver/bpf/fillers.h

Line 2417 in a8561a7

res = bpf_val_to_ring_type(data, (unsigned long)&empty, PT_CHARBUF);

`vfork` ➡️

[NOT ADDRESSABLE] param 7 (cwd) is not implemented, we push 0 to userspace

libs/driver/bpf/fillers.h

Line 2417 in a8561a7

res = bpf_val_to_ring_type(data, (unsigned long)&empty, PT_CHARBUF);

`socket` ⬅️

[NOT ADDRESSABLE] param 1 (domain) the socket_family_to_scap method should receive an int, not a u8, and we need to choose if the param should be on 8 bits or 32 bits. We need also to update the socket_family_to_scap with new socket families.

`connect` ➡️

[NOT ADDRESSABLE] param 2 (tuple) in case of UNIX sockets, not sure about the utility of sending kernel pointers to userspace

`socketpair` ⬅️

Same issues of socket syscall

[NOT ADDRESSABLE] param 1 (domain) the socket_family_to_scap method should receive an int, not a u8, and we need to choose if the param should be on 8 bits or 32 bits. We need also to update the socket_family_to_scap with new socket families.

`socketpair` ➡️

[NOT ADDRESSABLE] param 4 (source) not sure about the utility of sending kernel pointers to userspace
[NOT ADDRESSABLE] param 5 (peer) not sure about the utility of sending kernel pointers to userspace

`accept` ➡️

param 5 (queuemax) using Unix sockets, the max queue length seems not related to the value set by listen, more on this here: new(modern_bpf): add support for some network family syscalls #544 (comment)

`accept4` ⬅️

[NOT ADDRESSABLE] param 1 (flags) still to implement, today we send always 0. This bug is used in the socketcall wokraround

`listen` ⬅️

param 2 (backlog) is an int not a uint32_t, fix listen syscall backlog field size #1256

`bpf` ⬅️

[NOT ADDRESSABLE] param 1 (cmd) is an int not a int64_t

`flock` ⬅️

param 2 (operation) we need to read it as an int and then convert it to uint32_t, while today we read it as an unsigned long

`quotactl` ⬅️

param 1 (cmd) we need to read it as an int and then convert it to uint32_t, while today we read it as an unsigned long
param 3 (id) is an int not a int32_t

`quotactl` ➡️

param 13 (dqi_flags) add conversion to scap format

`unshare` ⬅️

param 1 (flags) we need to read it as an int and then convert it to uint32_t, while today we read it as an unsigned long

`mount` ⬅️

param 1 (flags) if we want to use this info in userspace we need to convert it into scap format.

`umount2` ⬅️

param 1 (flags) if we want to use this info in userspace we need to convert it into scap format. This field should be an int not a int32_t, fix umount2 syscall flags type, add conversion helper function #1255
we need to define a new event pair (PPME_SYSCALL_UMOUNT2_E, PPME_SYSCALL_UMOUNT2_X)

`linkat` ➡️

param 6 (flags) we need to read it as an int and then convert it to uint32_t, while today we read it as an unsigned long

`unlinkat` ➡️

param 4 (flags) we need to read it as an int and then convert it to uint32_t, while today we read it as an unsigned long

`setns` ⬅️

param 2 (nstype) we need to read it as an int and then convert it to uint32_t, while today we read it as an unsigned long

`setrlimit` ⬅️

param 1 (resource) we need to read it as an int and then convert it to uint8_t, while today we read it as an unsigned long

`prlimit64` ⬅️

param 2 (resource) we need to read it as an int and then convert it to uint8_t, while today we read it as an unsigned long

`sendto` ⬅️

[NOT ADDRESSABLE] param 3 (tuple) should be catched in the exit event when we know the outcome of the syscall otherwise there is the risk to catch something wrong.

`sendmsg` ⬅️

[NOT ADDRESSABLE] param 3 (tuple) should be catched in the exit event when we know the outcome of the syscall otherwise there is the risk to catch something wrong.

`ppoll`⬅️

[NOT ADDRESSABLE] param 3 (sigmask) we send only the first 32 bits

`ppoll`⬅️

[NOT ADDRESSABLE] param 3 (sigmask) we send only the first 32 bits

`ppoll`⬅️

[NOT ADDRESSABLE] param 3 (sigmask) we send only the first 32 bits

`recvmmsg`:

[NOT ADDRESSABLE] Empty instrumentation

`sendmmsg`:

[NOT ADDRESSABLE] Empty instrumentation

The text was updated successfully, but these errors were encountered:

FedeDP · 2022-08-01T07:19:26Z

Hi Andrea, like always, good catch! :D

I agree with you; i'd phrase it in a different way actually:
"if we today are able to push to userspace 1mln fd-only events, we could instead push up to 2mln fd-only events"
This hits even harder :)

To retain backward compatibility, i think we could:

add a new PT_FD32 and PT_PID32
new drivers will send PT_PID32 and PT_FD32
we are still compatible with old 64-bit types, while reading from scap files
of course, bump maj schema version :/

This fixes the first 2 points; the others are different cases instead.

Andreagit97 · 2022-08-01T13:09:51Z

Hi Andrea, like always, good catch! :D

I agree with you; i'd phrase it in a different way actually: "if we today are able to push to userspace 1mln fd-only events, we could instead push up to 2mln fd-only events" This hits even harder :)

🤯 🤯

To retain backward compatibility, i think we could:
* add a new `PT_FD32` and `PT_PID32`

* new drivers will send PT_PID32 and PT_FD32

* we are still compatible with old 64-bit types, while reading from scap files

* of course, bump maj schema version :/
This fixes the first 2 points; the last is a different case instead.

Completely agree with this solution!

incertum · 2022-08-01T17:29:36Z

Love it, big +1, great catch!

FedeDP · 2022-08-02T08:49:49Z

First 2 points will be addressed by #526

Andreagit97 · 2022-08-02T16:09:51Z

I have slightly changed the issue format with Generic event issues and Specific event issues in this way it should be more maintainable, thank you to @hbrueckner @Molter73 @FedeDP for all the help in finding new issues

jasondellaluce · 2022-08-02T16:16:38Z

Tracking down all of this is of incredible value. Thank you a lot!

hbrueckner · 2022-08-03T08:08:42Z

I have slightly changed the issue format with Generic event issues and Specific event issues in this way it should be more maintainable, thank you to @hbrueckner @Molter73 @FedeDP for all the help in finding new issues

You are welcome! Many thanks @Andreagit97 for the excellent summary and tracker of all the review follow-ups!

gnosek · 2022-12-02T15:05:41Z

"if we today are able to push to userspace 1mln fd-only events, we could instead push up to 2mln fd-only events"
This hits even harder :)

Optimism is awesome but let me cool it down a little bit :P Every event has this header, which is somewhat larger than the zero bytes it would need for that claim to be true ;)

struct ppm_evt_hdr {
#ifdef PPM_ENABLE_SENTINEL
    uint32_t sentinel_begin;
#endif
    uint64_t ts; /* timestamp, in nanoseconds from epoch */
    uint64_t tid; /* the tid of the thread that generated this event */
    uint32_t len; /* the event len, including the header */
    uint16_t type; /* the event type */
    uint32_t nparams; /* the number of parameters of the event */
};

BTW, we could probably easily change nparams to 16 bits. If we do expect >64k parameters, we can hack something for the (hopefully rare) events that exceed this number.

We could also trim the tid to 32 bits, but then we use this struct all over userspace too (#sadpanda), and other environments may want large tids (e.g. gvisor), so we would have to decouple these two structs and copy data field by field between them.

Don't let me distract you from tracking down the inconsistencies though, that's an awesome job!

These two changes would cut down 6 bytes from every event, equivalent to one and a half fds with no schema changes, just a major api version bump.

FedeDP · 2022-12-02T15:10:49Z

You are right, of course! Nonetheless, we are wasting lots of bytes that, all together, would:

speed up pushing events (because we need to write, and later read, a little bit less on the ring buffer)
clear up space for new events

I was a bit over-reacting though, agree ahah

BTW, we could probably easily change nparams to 16 bits. If we do expect >64k parameters, we can hack something for the (hopefully rare) events that exceed this number.
We could also trim the tid to 32 bits, but then we use this struct all over userspace too (#sadpanda), and other environments may want large tids (e.g. gvisor), so we would have to decouple these two structs and copy data field by field between them.

Yep!

Don't let me distract you from tracking down the inconsistencies though, that's an awesome job!

You gave thorough ideas! And data :D

I think @Andreagit97 is working on porting current modern-bpf tests to work with kmod and old bpf; this should help us spot many more inconsistencies!

poiana · 2023-05-02T13:28:02Z

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

poiana · 2023-06-01T13:30:53Z

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

Andreagit97 · 2023-06-01T17:09:04Z

/remove-lifecycle rotten

- change the flags (param 1) from u32 to s32 - add a userspace to scap flag conversion helper routine Reported by: github issue falcosecurity#515 Signed-off-by: Ofer Heifetz <[email protected]>

bump schema version minor Reported by: github issue #515 Signed-off-by: Ofer Heifetz <[email protected]>

- change the flags (param 1) from u32 to s32 - add a userspace to scap flag conversion helper routine Reported by: github issue #515 Signed-off-by: Ofer Heifetz <[email protected]>

Andreagit97 · 2023-10-04T12:15:06Z

I've added the [NOT ADDRESSABLE] marker to all issues that we cannot address now due to the scap-file management #1381 (comment)

LucaGuerra · 2023-10-04T12:17:55Z

Thank you Andrea, I think this makes it much clearer 🙏

ecbadeaux · 2023-11-29T03:31:27Z

@Andreagit97 Please mark dup3 as completed with strikethrough.

ecbadeaux · 2023-12-16T04:50:21Z

@incertum @Andreagit97 Can you guys also mark setns, flock, and unshare as complete?

poiana · 2024-03-17T21:49:52Z

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

FedeDP · 2024-03-18T08:28:19Z

/remove-lifecycle stale

poiana · 2024-06-16T09:53:48Z

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

Andreagit97 · 2024-06-17T08:11:17Z

/remove-lifecycle stale

poiana · 2024-09-15T10:10:45Z

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

FedeDP · 2024-09-16T06:49:50Z

/remove-lifecycle stale

poiana · 2024-12-15T10:12:49Z

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

FedeDP · 2024-12-16T08:04:17Z

/remove-lifecycle stale

Andreagit97 added the kind/documentation Improvements or additions to documentation label Jul 30, 2022

This was referenced Aug 1, 2022

new(modern_bpf): add support for chdir family syscalls #509

Merged

new(modern_bpf): add support for notify syscalls #516

Merged

Andreagit97 mentioned this issue Aug 1, 2022

new(modern_bpf): add support for rename family and pipe family syscalls #518

Merged

FedeDP mentioned this issue Aug 2, 2022

wip: fix: PT_FD, PT_ERRNO, PT_PID, PT_FDLIST with int32 #526

Closed

hbrueckner mentioned this issue Aug 9, 2022

new(modern_bpf): add support for some network family syscalls #544

Merged

hbrueckner mentioned this issue Sep 2, 2022

new(modern_bpf): add support for bpf, flock, ioctl, quotactl, unshare, mount, umount2 #549

Merged

hbrueckner mentioned this issue Oct 18, 2022

update(modern_bpf): reduce the execve instrumentation time with new APIs #648

Merged

hbrueckner mentioned this issue Jan 30, 2023

new(driver): unify support for io_uring syscall family between drivers #844

Merged

loresuso mentioned this issue Feb 16, 2023

new(modern_bpf): add support for lseek and llseek system calls #890

Merged

Andreagit97 mentioned this issue Feb 20, 2023

[Feature] implement new event pairs for a restricted set of syscalls #911

Closed

17 tasks

Andreagit97 mentioned this issue Mar 25, 2023

[FEATURE] Address last inconsistencies in our syscalls #1004

Open

27 tasks

poiana added the lifecycle/stale label May 2, 2023

poiana added lifecycle/rotten and removed lifecycle/stale labels Jun 1, 2023

poiana removed the lifecycle/rotten label Jun 1, 2023

Andreagit97 modified the milestone: 0.12.0 Jun 7, 2023

poiana pushed a commit that referenced this issue Aug 18, 2023

fix listen syscall backlog field size

2293e3e

bump schema version minor Reported by: github issue #515 Signed-off-by: Ofer Heifetz <[email protected]>

Andreagit97 modified the milestones: driver-backlog, TBD Sep 4, 2023

This was referenced Oct 3, 2023

[postponed] bpf issue 515 (fix: param 1 (cmd) is an int not a int64_t) #1381

Closed

[postponed] inotify issue 515 (fix: inotify_init has no syscall arguments but we send one param) #1382

Closed

ecbadeaux mentioned this issue Nov 2, 2023

cleanup(driver): fix flags param #1469

Merged

ecbadeaux mentioned this issue Nov 25, 2023

cleanup(driver): params inconsistencies #1512

Merged

ecbadeaux mentioned this issue Dec 4, 2023

cleanup(driver): unlinkat & linkat flags #1538

Merged

poiana added the lifecycle/stale label Mar 17, 2024

poiana removed the lifecycle/stale label Mar 18, 2024

poiana added the lifecycle/stale label Jun 16, 2024

poiana removed the lifecycle/stale label Jun 17, 2024

poiana added the lifecycle/stale label Sep 15, 2024

poiana removed the lifecycle/stale label Sep 16, 2024

poiana added the lifecycle/stale label Dec 15, 2024

poiana removed the lifecycle/stale label Dec 16, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Tracking] Params inconsistencies in our drivers #515

[Tracking] Params inconsistencies in our drivers #515

Andreagit97 commented Jul 30, 2022 •

edited by incertum

Loading

FedeDP commented Aug 1, 2022 •

edited

Loading

Andreagit97 commented Aug 1, 2022

incertum commented Aug 1, 2022

FedeDP commented Aug 2, 2022

Andreagit97 commented Aug 2, 2022

jasondellaluce commented Aug 2, 2022

hbrueckner commented Aug 3, 2022

gnosek commented Dec 2, 2022

FedeDP commented Dec 2, 2022

poiana commented May 2, 2023

poiana commented Jun 1, 2023

Andreagit97 commented Jun 1, 2023

Andreagit97 commented Oct 4, 2023

LucaGuerra commented Oct 4, 2023

ecbadeaux commented Nov 29, 2023

ecbadeaux commented Dec 16, 2023

poiana commented Mar 17, 2024

FedeDP commented Mar 18, 2024

poiana commented Jun 16, 2024

Andreagit97 commented Jun 17, 2024

poiana commented Sep 15, 2024

FedeDP commented Sep 16, 2024

poiana commented Dec 15, 2024

FedeDP commented Dec 16, 2024

[Tracking] Params inconsistencies in our drivers #515

[Tracking] Params inconsistencies in our drivers #515

Comments

Andreagit97 commented Jul 30, 2022 • edited by incertum Loading

PLEASE NOTE

Generic context

Syscall-specific issues

LEGENDA

open_by_handle_at ➡️

dup3 ➡️

open

openat

openat2

eventfd ⬅️

eventfd2 ⬅️

inotify_init ⬅️

signalfd ⬅️

signalfd4 ⬅️

timerfd_create ⬅️

userfault_fd ➡️

ptrace ➡️

mkdirat ➡️

pipe2

renameat2 ➡️

execve ➡️

execveat ➡️

fork ➡️

clone ➡️

clone3 ➡️

vfork ➡️

socket ⬅️

connect ➡️

socketpair ⬅️

socketpair ➡️

accept ➡️

accept4 ⬅️

listen ⬅️

bpf ⬅️

flock ⬅️

quotactl ⬅️

quotactl ➡️

unshare ⬅️

mount ⬅️

umount2 ⬅️

linkat ➡️

unlinkat ➡️

setns ⬅️

setrlimit ⬅️

prlimit64 ⬅️

sendto ⬅️

sendmsg ⬅️

ppoll⬅️

ppoll⬅️

ppoll⬅️

recvmmsg:

sendmmsg:

FedeDP commented Aug 1, 2022 • edited Loading

Andreagit97 commented Aug 1, 2022

incertum commented Aug 1, 2022

FedeDP commented Aug 2, 2022

Andreagit97 commented Aug 2, 2022

jasondellaluce commented Aug 2, 2022

hbrueckner commented Aug 3, 2022

gnosek commented Dec 2, 2022

FedeDP commented Dec 2, 2022

poiana commented May 2, 2023

poiana commented Jun 1, 2023

Andreagit97 commented Jun 1, 2023

Andreagit97 commented Oct 4, 2023

LucaGuerra commented Oct 4, 2023

ecbadeaux commented Nov 29, 2023

ecbadeaux commented Dec 16, 2023

poiana commented Mar 17, 2024

FedeDP commented Mar 18, 2024

poiana commented Jun 16, 2024

Andreagit97 commented Jun 17, 2024

poiana commented Sep 15, 2024

FedeDP commented Sep 16, 2024

poiana commented Dec 15, 2024

FedeDP commented Dec 16, 2024

Andreagit97 commented Jul 30, 2022 •

edited by incertum

Loading

`open_by_handle_at` ➡️

`dup3` ➡️

`open`

`openat`

`openat2`

`eventfd` ⬅️

`eventfd2` ⬅️

`inotify_init` ⬅️

`signalfd` ⬅️

`signalfd4` ⬅️

`timerfd_create` ⬅️

`userfault_fd` ➡️

`ptrace` ➡️

`mkdirat` ➡️

`pipe2`

`renameat2` ➡️

`execve` ➡️

`execveat` ➡️

`fork` ➡️

`clone` ➡️

`clone3` ➡️

`vfork` ➡️

`socket` ⬅️

`connect` ➡️

`socketpair` ⬅️

`socketpair` ➡️

`accept` ➡️

`accept4` ⬅️

`listen` ⬅️

`bpf` ⬅️

`flock` ⬅️

`quotactl` ⬅️

`quotactl` ➡️

`unshare` ⬅️

`mount` ⬅️

`umount2` ⬅️

`linkat` ➡️

`unlinkat` ➡️

`setns` ⬅️

`setrlimit` ⬅️

`prlimit64` ⬅️

`sendto` ⬅️

`sendmsg` ⬅️

`ppoll`⬅️

`ppoll`⬅️

`ppoll`⬅️

`recvmmsg`:

`sendmmsg`:

FedeDP commented Aug 1, 2022 •

edited

Loading