Question about multiple seccomp system calls during runc init

[ilp-sys]

Hi, I was analyzing runc’s init process and observed the following logs:

1.
2025-09-10 06:24:32.292958562 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=0 )
2025-09-10 06:24:32.292959793 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=-22(EINVAL) )

2.
2025-09-10 06:24:32.292961894 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=1 )
2025-09-10 06:24:32.292964500 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=-14(EFAULT) )

3.
2025-09-10 06:24:32.292965571 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=1 )
2025-09-10 06:24:32.292967225 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=-14(EFAULT) )

4.
2025-09-10 06:24:32.292968274 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=2 )
2025-09-10 06:24:32.292968617 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=0 )

5.
2025-09-10 06:24:32.292969631 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=2 )
2025-09-10 06:24:32.292969858 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=0 )

6.
2025-09-10 06:24:32.292970830 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=1 )
2025-09-10 06:24:32.292972429 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=-14(EFAULT) )

7.
2025-09-10 06:24:32.292973422 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=1 )
2025-09-10 06:24:32.292975029 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=-14(EFAULT) )

8.
2025-09-10 06:24:32.292976077 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=3 )
2025-09-10 06:24:32.292976354 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=0 )

9.
2025-09-10 06:24:32.292977330 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=1 )
2025-09-10 06:24:32.292978905 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=-14(EFAULT) )

10.
2025-09-10 06:24:32.519345671 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init > seccomp(op=1 )
2025-09-10 06:24:32.520313156 runc:[1:CHILD](3786:3786:3775) runc:[1:CHILD] init < seccomp(res=0 )

The last seccomp call seems to correspond to the actual filter installation, but what are the preceding calls for?

I could not find a direct reference to these calls in the runc source code, nor any usage of SECCOMP_SET_MODE_STRICT or similar constants.

Could someone clarify:

• What triggers these multiple seccomp system calls during init?

• Are they related to capability probing or some internal checks?

• Where in the runc source code are these calls actually made?

Any pointers would be appreciated.

Thanks.

[cyphar]

It might be more helpful to use strace -f -e seccomp to get the arguments as well, but my guess is that this is for kernel feature detection.

Note we do not call seccomp(2) directly in runc, instead we use the official Go bindings for libseccomp so you'll need to look at libseccomp to see what they're doing.

EDIT: Sorry, we do call seccomp(2) at the end to load the filter because we have code to patch the filter generated by libseccomp. See #2750.

[ilp-sys]

Thanks for your reply! I really appreciate it.

The strace results show

[pid  4151] seccomp(SECCOMP_SET_MODE_STRICT, 0x1, NULL) = -1 EINVAL (Invalid argument)
[pid  4151] seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address)
[pid  4151] seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_LOG, NULL) = -1 EFAULT (Bad address)
[pid  4151] seccomp(SECCOMP_GET_ACTION_AVAIL, 0, [SECCOMP_RET_LOG]) = 0
[pid  4151] seccomp(SECCOMP_GET_ACTION_AVAIL, 0, [SECCOMP_RET_KILL_PROCESS]) = 0
[pid  4151] seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_SPEC_ALLOW, NULL) = -1 EFAULT (Bad address)
[pid  4151] seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER, NULL) = -1 EFAULT (Bad address)
[pid  4151] seccomp(SECCOMP_GET_NOTIF_SIZES, 0, {seccomp_notif=80, seccomp_notif_resp=24, seccomp_data=64}) = 0
[pid  4151] seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC_ESRCH, NULL) = -1 EFAULT (Bad address)

Since the third argument is null, as you mentioned, this looks like some kind of probing procedure.

The first nine calls happen during configuration:

FlagSupported -> setFlag -> filter.SetLogBit -> f.setFilterAttr -> seccomp_attr_set

The last call seems to install the filter:
InitSeccomp -> PatchAndLoad -> sysSeccompSetFilter -> unix.RawSyscall(unix.SECCOMP, ..)

Why does the configuration phase use libseccomp, while the actual filter installation uses a direct RawSyscall?

[cyphar]

Sorry, you're quite right that we actually do call seccomp(2) directly. This wasn't always the case, hence my answer.

The reason is because we need to patch the cBPF program generated by libseccomp, and libseccomp doesn't let you load arbitrary filters. The patching we do is to fix -ENOSYS handling of filters like Docker's default filter (which causes very painful issues when programs start trying to use new syscalls -- see #2750 for the PR which added this and contains more details). This is a long-standing problem that libseccomp is still working on fixing. There are still issues with this approach -- see moby/moby#42871.

The first phase is not really "configuration", it's filter generation and we use libseccomp for that (at least, for the moment) because it's quite complicated to compile filters.

[ilp-sys]

Thanks for clarifying, that answered my question.