Skip to content

seccomp: always include the host's native architecture when expanding archMap - #41

Open
bloodsportshooting wants to merge 1 commit into
moby:mainfrom
bloodsportshooting:fix/seccomp-native-arch-48471
Open

bloodsportshooting wants to merge 1 commit into
moby:mainfrom
bloodsportshooting:fix/seccomp-native-arch-48471

Conversation

@bloodsportshooting

Copy link
Copy Markdown

What this PR does

Fixes moby/moby#48471.

When a seccomp profile is expanded from archMap, setupSeccomp only added the host's native architecture if an archMap entry matched it. For architectures the default profile's archMap omits (historically ppc64le), the generated profile had no entry for the host arch, so libseccomp had nothing to attach the -ENOSYS stub to. The result: unknown syscalls returned -EPERM instead of -ENOSYS (e.g. fchmodat2 failing on ppc64le before runc 1.2).

This mirrors the fix already applied upstream in opencontainers/runc#4219: always add the native seccomp architecture when expanding archMap.

Why scoped to archMap only

Profiles that explicitly list their own Architectures are left untouched — injecting the native arch there would change existing, deliberate behavior (and breaks the existing LoadProfile fixture tests). The bug only affects the archMap (default-profile) expansion path.

How to verify

cd seccomp && go test ./...
  • New TestSetupSeccompIncludesNativeArch: archMap present but omits the native arch -> native arch is now in the generated Architectures.
  • New TestSetupSeccompDoesNotInjectNativeArchWithoutArchMap: explicit Architectures, no archMap -> native arch is NOT injected.
  • All existing tests still pass.

Release note

Fixed a bug where the generated seccomp profile could omit the host's native architecture (notably on ppc64le), causing unknown syscalls to return -EPERM instead of -ENOSYS.

… archMap

When a profile is expanded from archMap, setupSeccomp only added the
native architecture if an archMap entry matched it. For architectures
that the default profile's archMap omits (e.g. ppc64le), the generated
profile ended up with no entry for the host arch, so libseccomp had
nothing to attach the -ENOSYS stub to and unknown syscalls returned
-EPERM instead of -ENOSYS (moby/moby#48471).

Mirror the fix already applied in opencontainers/runc#4219: always add
the native seccomp architecture when expanding archMap. Profiles that
explicitly list their own Architectures are left untouched.

Add regression tests covering both the missing-arch and
explicit-Architectures paths.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

seccomp: architecture is not present for (at least) ppc64le

1 participant