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

Enable seccomp for s390x and ppc: s390x part #23172

Merged
merged 1 commit into from
Jun 7, 2016
Merged

Enable seccomp for s390x and ppc: s390x part #23172

merged 1 commit into from
Jun 7, 2016

Conversation

michael-holzheu
Copy link
Contributor

@michael-holzheu michael-holzheu commented Jun 1, 2016

Patches required to enable seccomp support for s390x:

  • seccomp_default: Add s390 compat mode
  • seccomp_default: Use correct flags parameter for sys_clone on s390x
  • seccomp_default: Add s390 specific syscalls
  • test_integration: Do not run seccomp default profile test on s390x
  • Dockerfile.s390x: Enable seccomp for s390x

Please do not merge until all prerequisites of issue #23171 are fulfilled.

@thaJeztah
Copy link
Member

Looks like build is failing currently;

18:00:31 ---> Making bundle: validate-default-seccomp (in bundles/1.12.0-dev/validate-default-seccomp)
18:00:33 # github.com/docker/docker/profiles/seccomp
18:00:33 ./seccomp_default.go:33: undefined: types.ArchS390
18:00:33 ./seccomp_default.go:33: undefined: types.ArchS390X
18:00:33 profiles/seccomp/seccomp.go:13: running "go": exit status 2
18:00:34 Build step 'Execute shell' marked build as failure

@thaJeztah thaJeztah added the status/failing-ci Indicates that the PR in its current state fails the test suite label Jun 1, 2016
@michael-holzheu
Copy link
Contributor Author

Looks like build is failing currently;

@thaJeztah this is expected because docker/engine-api#248 [4] from issue #23171 is missing in Docker. Once we have all prerequisites we have to bump all the vendor versions.

@justincormack
Copy link
Contributor

justincormack commented Jun 2, 2016

Should be ok once the requisite parts are merged and tests pass, plus we resolve the extra syscalls needed for s390x discussed in #23171

@justincormack
Copy link
Contributor

@michael-holzheu You need to run go fmt on seccomp_default.go

@justincormack
Copy link
Contributor

@michael-holzheu do you want to add s390_runtime_instr to the whitelist in this PR or can do later? (I am really not sure about the pci ones right now...)

@michael-holzheu
Copy link
Contributor Author

@michael-holzheu do you want to add s390_runtime_instr to the whitelist in this PR or can do later?

IMHO we can do this later with another pull request (when we are sure about all syscalls).

@justincormack
Copy link
Contributor

@michael-holzheu as we are clear now, maybe add here now?

@justincormack justincormack removed the status/failing-ci Indicates that the PR in its current state fails the test suite label Jun 3, 2016
@michael-holzheu
Copy link
Contributor Author

@michael-holzheu as we are clear now, maybe add here now?

Ok also ok for me. I will update the PR.

@thaJeztah
Copy link
Member

@michael-holzheu can you squash your commits?

case "s390", "s390x":
syscalls = append(syscalls, []*types.Syscall{
{
Name: "s390_runtime_instr",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor nit I was trying to keep the syscalls in alphabetical order everywhere in this file (not 100% sure they all are but I just noticed here...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor nit I was trying to keep the syscalls in alphabetical order everywhere in this file

Ok so I will move s390_runtime_instr to the end of the three syscalls.

@michael-holzheu
Copy link
Contributor Author

@michael-holzheu can you squash your commits?

I can do this. So in general you want one commit per PR?

@justincormack
Copy link
Contributor

@michael-holzheu we don't have a strict rule it depends on the PR, but in this case they are implementing a single feature and are all small so one commit is cleaner and easier for people to follow later when they are looking back at the history.

To implement seccomp for s390x the following changes are required:

1) seccomp_default: Add s390 compat mode

   On s390x (64 bit) we can run s390 (32 bit) programs in 32 bit
   compat mode. Therefore add this information to arches().

2) seccomp_default: Use correct flags parameter for sys_clone on s390x

   On s390x the second parameter for the clone system call is the flags
   parameter. On all other architectures it is the first one.

   See kernel code kernel/fork.c:

   #elif defined(CONFIG_CLONE_BACKWARDS2)
   SYSCALL_DEFINE5(clone, unsigned long, newsp, unsigned long, clone_flags,
                   int __user *, parent_tidptr,

   So fix the docker default seccomp rule and check for the second
   parameter on s390/s390x.

3) seccomp_default: Add s390 specific syscalls

  For s390 we currently have three additional system calls that should
  be added to the seccomp whitelist:

  - Other architectures can read/write unprivileged from/to PCI MMIO memory.
    On s390 the instructions are privileged and therefore we need system
    calls for that purpose:

    * s390_pci_mmio_write()
    * s390_pci_mmio_read()

  - Runtime instrumentation:

    * s390_runtime_instr()

4) test_integration: Do not run seccomp default profile test on s390x

   The generated profile that we check in is for amd64 and i386
   architectures and does not work correctly on s390x.

   See also: 75385dc ("Do not run the seccomp tests that use
   default.json on non x86 architectures")

5) Dockerfile.s390x: Add "seccomp" to DOCKER_BUILDTAGS

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
@justincormack
Copy link
Contributor

@michael-holzheu remind me what we need to fix to get the CI for Z not to hang? It would be nice to fix it.

@michael-holzheu
Copy link
Contributor Author

@michael-holzheu remind me what we need to fix to get the CI for Z not to hang? It would be nice to fix it.

We need updated glibc packages in the s390x/gcc:6.1 image. The fix is accepted in Debian, but they have not released a new package up to now. As a workaround I manually built packages and suggested @tianon (who is responsible for the images) to integrate them. But unfortunately I did not get an answer up to now :-(

@justincormack
Copy link
Contributor

@michael-holzheu maybe you can create an issue for that so it doesnt get lost...

@justincormack
Copy link
Contributor

LGTM

I think we now are just waiting for opencontainers/runc#866

@thaJeztah thaJeztah added this to the 1.12.0 milestone Jun 7, 2016
@thaJeztah
Copy link
Member

LGTM, thanks @michael-holzheu!

@thaJeztah
Copy link
Member

Windows doesn't use this, and failure is not related, so merging

@thaJeztah thaJeztah merged commit eb6b5a6 into moby:master Jun 7, 2016
@michael-holzheu
Copy link
Contributor Author

I think we now are just waiting for opencontainers/runc#866

Yes. And after this is done we have to bump runc in Docker and use the correct RUNC_COMMIT in the Dockerfiles.

@justincormack
Copy link
Contributor

Yes the runc bump will happen anyway as we are waiting for 1.0.
On 7 Jun 2016 1:16 p.m., "Michael Holzheu" notifications@github.com wrote:

I think we now are just waiting for opencontainers/runc#866
opencontainers/runc#866

Yes. And after this is done we have to bump runc in Docker and use the
correct RUNC_COMMIT in the Dockerfiles.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#23172 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAdcPAqdCDrEpTmqfvU74jdowBhWtZd7ks5qJWEOgaJpZM4Ir0N4
.

@michael-holzheu
Copy link
Contributor Author

Regarding our s390x CI problem:

@michael-holzheu maybe you can create an issue for that so it doesnt get lost...

I now opened issue #24748 to track this.

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.

4 participants