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

Allow AARCH64 syscalls for worker runtime #8457

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rdrgmnzs
Copy link

Signed-off-by: Rodrigo Menezes [email protected]

Changes proposed by this PR

As AARCH64 becomes more popular allow the worker runtime to execute syscalls for it (ex. Mac M1 or AWS Graviton machines).

Another option is to completely remove the seccomp architectural limitation as per https://github.com/opencontainers/runtime-spec/blob/72c1f0b44f7976960febe9e48e36c88d12ec9b72/specs-go/config.go#L635 by default only the native architecture of the kernel is permitted.

Relates to #8451

@rdrgmnzs rdrgmnzs requested a review from a team as a code owner June 27, 2022 22:03
@xtremerui xtremerui added this to the v7.9.0 milestone Jun 28, 2022
@xtremerui
Copy link
Contributor

Thx for the PR! Is there a way to test this change? Unfortunately we don't have a M1 machine here.

@rdrgmnzs
Copy link
Author

rdrgmnzs commented Jun 29, 2022

@xtremerui the only ways I can think to test this is either having access to a Mac M1 / AWS Graviton instance or if install QEMU create a AARCH64 VM and try to run the docker-compose example (using the ARM64 docker image) inside the emulated AARCH64 VM.

@xtremerui
Copy link
Contributor

I afraid we will have to hold on this until someone actually try the binary on such arch.

@xtremerui xtremerui removed this from the v7.9.0 milestone Jun 29, 2022
@rdrgmnzs
Copy link
Author

@xtremerui would the option of removing the seccomp CPU architecture limit work for you? That way you could simply test out the regular binary and ensure that by default seccomp is really limited just to the default hosts architecture like mentioned in https://github.com/opencontainers/runtime-spec/blob/72c1f0b44f7976960febe9e48e36c88d12ec9b72/specs-go/config.go#L635 . That would also have the effect of no having to maintain this for any possible future CPU architectures that come out (not that it happens often).

@xtremerui
Copy link
Contributor

This should be answered to the discussion but I would posted here too. The seccomp arch limit we have came from here.

Reading through the issue I feel if guardien doesn't add AARCH64 as a supporting arch, we probably can't either, especially without being properly tested.

It is also mentioned in the original issue #5194 that the grant from Concourse itself is too broad so we should not remove the seccomp to use the default hosts architecture.

@taylorsilva
Copy link
Member

@rdrgmnzs I have an M1 that I can test this on. How would I test it? Do you have general steps I can follow? I can probably figure out the details if you have some guidelines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants