github-starred/firejail
2
0
Fork 0
mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00
Code Issues 531 Projects Packages Wiki Activity Actions 6

[GH-ISSUE #1504] build failure on some architectures #1004

New issue
Closed
opened 2026-05-05 07:17:38 -06:00 by gitea-mirror · 15 comments
gitea-mirror commented 2026-05-05 07:17:38 -06:00
Owner
Copy link

Originally created by @reinerh on GitHub (Aug 30, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1504

It looks like the mmap2 syscall is not available on every architecture.
Because of this some builds are failing, as SYS_mmap2 is used in src/fseccomp/seccomp.c.
See also: Debian buildd state.

Originally created by @reinerh on GitHub (Aug 30, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1504 It looks like the mmap2 syscall is not available on every architecture. Because of this some builds are failing, as SYS_mmap2 is used in src/fseccomp/seccomp.c. See also: [Debian buildd state](https://buildd.debian.org/status/logs.php?pkg=firejail&ver=0.9.50%7Erc1-1).
gitea-mirror 2026-05-05 07:17:38 -06:00
  • closed this issue
  • added the
    bug
         label
gitea-mirror commented 2026-05-05 07:17:42 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Aug 30, 2017):

@netblue30 has already committed a fix.

But all of the failing builds also include this warning:

../include/seccomp.h:99:3: warning: #warning "Platform does not support seccomp filter yet" [-Wcpp]

I'm not sure if it is meaningful even to build the fseccomp tool or any seccomp related code on a platform if support for seccomp is not complete for the platform. For example, near this warning ARCH_NR is defined as 0 for unsupported platforms, breaking VALIDATE_ARCHITECTURE bpf.

<!-- gh-comment-id:326042467 --> @topimiettinen commented on GitHub (Aug 30, 2017): @netblue30 has already committed a fix. But all of the failing builds also include this warning: ``` ../include/seccomp.h:99:3: warning: #warning "Platform does not support seccomp filter yet" [-Wcpp] ``` I'm not sure if it is meaningful even to build the fseccomp tool or any seccomp related code on a platform if support for seccomp is not complete for the platform. For example, near this warning ARCH_NR is defined as 0 for unsupported platforms, breaking VALIDATE_ARCHITECTURE bpf.
gitea-mirror commented 2026-05-05 07:17:44 -06:00
Author
Owner
Copy link

@netblue30 commented on GitHub (Aug 30, 2017):

Potential fix here:

a93f00cc8e

The second problem is #warning "Platform does not support seccomp filter yet". The code in src/include/seccomp.h looks like this:

#if defined(__i386__)
# define ARCH_NR	AUDIT_ARCH_I386
#elif defined(__x86_64__)
# define ARCH_NR	AUDIT_ARCH_X86_64
#elif defined(__arm__)
# define ARCH_NR	AUDIT_ARCH_ARM
#else
# warning "Platform does not support seccomp filter yet"
# define ARCH_NR	0
#endif

We have seccomp support only for amd64, i386 and arm (32bit). It is possible some platforms don't have seccomp support in Linux kernel. We can easily add all platforms here, but we cannot test them.

<!-- gh-comment-id:326048875 --> @netblue30 commented on GitHub (Aug 30, 2017): Potential fix here: https://github.com/netblue30/firejail/commit/a93f00cc8e0e3f24a6ea2cbf4beb5572357a4c3d The second problem is #warning "Platform does not support seccomp filter yet". The code in src/include/seccomp.h looks like this: ````` #if defined(__i386__) # define ARCH_NR AUDIT_ARCH_I386 #elif defined(__x86_64__) # define ARCH_NR AUDIT_ARCH_X86_64 #elif defined(__arm__) # define ARCH_NR AUDIT_ARCH_ARM #else # warning "Platform does not support seccomp filter yet" # define ARCH_NR 0 #endif ````` We have seccomp support only for amd64, i386 and arm (32bit). It is possible some platforms don't have seccomp support in Linux kernel. We can easily add all platforms here, but we cannot test them.
gitea-mirror commented 2026-05-05 07:17:45 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Aug 30, 2017):

@reinerh: I pushed a3e73427 which should improve the build on several platforms, please test.

<!-- gh-comment-id:326106758 --> @topimiettinen commented on GitHub (Aug 30, 2017): @reinerh: I pushed a3e73427 which should improve the build on several platforms, please test.
gitea-mirror commented 2026-05-05 07:17:45 -06:00
Author
Owner
Copy link

@reinerh commented on GitHub (Aug 30, 2017):

@topimiettinen thank you for the fix!
It is currently building, but unfortunately it failed already on arm64: https://buildd.debian.org/status/package.php?p=firejail&suite=experimental

Though this error seems to be a completely different one now.

Edit: permalink for the new revision.

<!-- gh-comment-id:326130387 --> @reinerh commented on GitHub (Aug 30, 2017): @topimiettinen thank you for the fix! It is currently building, but unfortunately it failed already on arm64: https://buildd.debian.org/status/package.php?p=firejail&suite=experimental Though this error seems to be a completely different one now. Edit: [permalink for the new revision](https://buildd.debian.org/status/logs.php?pkg=firejail&ver=0.9.50%7Erc1-2).
gitea-mirror commented 2026-05-05 07:17:46 -06:00
Author
Owner
Copy link

@reinerh commented on GitHub (Aug 30, 2017):

I guess a default value of "" should fix this issue?

<!-- gh-comment-id:326132891 --> @reinerh commented on GitHub (Aug 30, 2017): I guess a default value of `""` should fix this issue?
gitea-mirror commented 2026-05-05 07:17:47 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Sep 1, 2017):

Yes, it seems none of the syscalls in that list are available. I'll prepare a fix.

<!-- gh-comment-id:326657672 --> @topimiettinen commented on GitHub (Sep 1, 2017): Yes, it seems none of the syscalls in that list are available. I'll prepare a fix.
gitea-mirror commented 2026-05-05 07:17:48 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Sep 1, 2017):

It does not work, empty syscall lists are not allowed, but I took a different approach with 9252c4c1.

<!-- gh-comment-id:326660928 --> @topimiettinen commented on GitHub (Sep 1, 2017): It does not work, empty syscall lists are not allowed, but I took a different approach with 9252c4c1.
gitea-mirror commented 2026-05-05 07:17:49 -06:00
Author
Owner
Copy link

@reinerh commented on GitHub (Sep 1, 2017):

@topimiettinen Thanks.

Shouldn't the same workaround also be applied to the other SyscallGroupList items in the list?
The compiler already complains at line 86, which is the item before the one you fixed...

<!-- gh-comment-id:326662695 --> @reinerh commented on GitHub (Sep 1, 2017): @topimiettinen Thanks. Shouldn't the same workaround also be applied to the other SyscallGroupList items in the list? The compiler already complains at line 86, which is the item before the one you fixed...
gitea-mirror commented 2026-05-05 07:17:50 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Sep 1, 2017):

Yes in theory, but luckily the other groups don't seem to have the problem, there's always at least one syscall known. Unless I fixed the wrong one... We'll see what happens when you rebuild it.

<!-- gh-comment-id:326683911 --> @topimiettinen commented on GitHub (Sep 1, 2017): Yes in theory, but luckily the other groups don't seem to have the problem, there's always at least one syscall known. Unless I fixed the wrong one... We'll see what happens when you rebuild it.
gitea-mirror commented 2026-05-05 07:17:50 -06:00
Author
Owner
Copy link

@reinerh commented on GitHub (Sep 1, 2017):

@topimiettinen I just confirmed that in arm64 libc the syscalls mentioned in the @cpu-emulation are all not available. So this group would still fail.
(checked syscall.h in this .deb)

<!-- gh-comment-id:326685462 --> @reinerh commented on GitHub (Sep 1, 2017): @topimiettinen I just confirmed that in arm64 libc the syscalls mentioned in the @cpu-emulation are all not available. So this group would still fail. ([checked syscall.h in this .deb](http://ftp.de.debian.org/debian/pool/main/g/glibc/libc6-dev_2.24-17_arm64.deb))
gitea-mirror commented 2026-05-05 07:17:51 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Sep 2, 2017):

I pushed a workaround f883155b for @cpu-emulation and removed the wrong one.

<!-- gh-comment-id:326731576 --> @topimiettinen commented on GitHub (Sep 2, 2017): I pushed a workaround f883155b for @cpu-emulation and removed the wrong one.
gitea-mirror commented 2026-05-05 07:17:52 -06:00
Author
Owner
Copy link

@reinerh commented on GitHub (Sep 7, 2017):

@topimiettinen Thanks, it helped for some architectures.
But I noticed that also all syscalls from the @obsolete and @raw-io group are not available on some architectures (e.g. arm64).

Would it make sense to add the dummy syscall to all groups?

<!-- gh-comment-id:327845264 --> @reinerh commented on GitHub (Sep 7, 2017): @topimiettinen Thanks, it helped for some architectures. But I noticed that also all syscalls from the @obsolete and @raw-io group are not available on some architectures (e.g. arm64). Would it make sense to add the dummy syscall to all groups?
gitea-mirror commented 2026-05-05 07:17:53 -06:00
Author
Owner
Copy link

@reinerh commented on GitHub (Sep 10, 2017):

Here are the build results for 0.9.50.

<!-- gh-comment-id:328314794 --> @reinerh commented on GitHub (Sep 10, 2017): [Here](https://buildd.debian.org/status/logs.php?pkg=firejail&ver=0.9.50-1) are the build results for 0.9.50.
gitea-mirror commented 2026-05-05 07:17:54 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Sep 10, 2017):

Thanks, please test c3acf2d2.

I think other groups shouldn't need any workarounds, they all contain enough common syscalls.

Maybe there are better approaches to solve the build problems. If an architecture does not have seccomp support in Firejail yet, we should disable HAVE_SECCOMP (even if a header file exists) and stop building fseccomp (or build a dummy executable). An empty syscall list could be accepted in some cases, like only for internal use but not in lists given by the user.

<!-- gh-comment-id:328326105 --> @topimiettinen commented on GitHub (Sep 10, 2017): Thanks, please test c3acf2d2. I think other groups shouldn't need any workarounds, they all contain enough common syscalls. Maybe there are better approaches to solve the build problems. If an architecture does not have seccomp support in Firejail yet, we should disable HAVE_SECCOMP (even if a header file exists) and stop building fseccomp (or build a dummy executable). An empty syscall list could be accepted in some cases, like only for internal use but not in lists given by the user.
gitea-mirror commented 2026-05-05 07:17:56 -06:00
Author
Owner
Copy link

@reinerh commented on GitHub (Sep 14, 2017):

Thank @topimiettinen!
The fix was helping (build state (the sh4 error is something unrelated)). I've also cherry-picked it into the 0.9.50-bugfixes branch.

<!-- gh-comment-id:329630071 --> @reinerh commented on GitHub (Sep 14, 2017): Thank @topimiettinen! The fix was helping ([build state](https://buildd.debian.org/status/logs.php?pkg=firejail&ver=0.9.50-2) (the sh4 error is something unrelated)). I've also cherry-picked it into the 0.9.50-bugfixes branch.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
serialize_remounts_v2
landlock_v4
landlock
release-0.9.64
release-0.9.62
gitlab_ci
LTSbase
fred_ctests
docs
0.9.80
0.9.80-rc1
0.9.78
0.9.76
0.9.76-rc4
0.9.76-rc3
0.9.76-rc2
0.9.76-rc1
0.9.74
landlock-split
0.9.72
0.9.72rc1
0.9.70
0.9.68
0.9.68rc1
0.9.66
0.9.66rc1
0.9.64.4
0.9.64.2
0.9.64
0.9.64rc1
0.9.62.4
0.9.62.2
0.9.62
0.9.56.2-LTS
0.9.60
0.9.60-rc1
0.9.58.2
0.9.58
0.9.58-rc1
0.9.56-LTS-release
0.9.56-LTS
0.9.56
0.9.56-rc1
0.9.54
0.9.54-rc2
0.9.54-rc1
0.9.52
0.9.38.12
0.9.50
0.9.50-rc1
0.9.48
0.9.46
0.9.46-rc1
0.9.44.10
0.9.44.8
0.9.44.6
0.9.38.10
0.9.44.4
0.9.38.8
0.9.44.2
0.9.44
0.9.44-rc1
0.9.38.4
0.9.42
0.9.42-rc2
0.9.38.2
0.9.42-rc1
disable-globalcfg
0.9.40
0.9.40-rc1
0.9.38
0.9.38-rc1
0.9.36
0.9.36-rc1
0.9.34
0.9.34-rc1
0.9.32
0.9.32-rc1
0.9.30
0.9.30-rc1
Labels
Clear labels   
LTS merge

   
LTS merge

   
bug

   
bug

   
converted-to-discussion

   
doc-todo

   
documentation

   
duplicate

   
enhancement

   
file-transfer

   
firecfg

   
firejail-in-firejail

   
firetools

   
graphics

   
help wanted

   
information_old

   
installation

   
invalid

   
modif

   
moved

   
needinfo

   
networking

   
notabug

   
notourbug

   
old-version

   
overlayfs

   
packaging

   
profile-request

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question_old

   
removal

   
runtime-permissions

   
sandbox-ipc

   
security

   
stale

   
wiki

   
wiki

   
wontfix

   
wordpress

   
workaround
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1004
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?