mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5250] steam: Unhandled exception: illegal instruction in 64-bit code (seccomp) #2935
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2935
Loading…
Add table
Add a link
Reference in a new issue
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?
Originally created by @swimik on GitHub (Jul 13, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5250
Environment
Description
Fallout 76 worked previously but
ignore seccompwas set due to previous issues with steam and protonRunning
firejail --noprofile steamand then launching the game does work.Adding
ignore seccompto steam.local works againFirejail-profiles is installed
There seems to be a fault with firejail preventing wine from executing a 64 bit instruction causing the game to crash. This is the only game I have encountered this with.
Here is the sequence just before the error, and the error:
firejail steam
Here is it running fine with
firejail --noprofilestarting at the same point:firejail --noprofile steam
Steam is 32bit and installs its own Wine version(which I presume is 32 bit). My machine does not have its own local install of wine. I know for a fact many games I play are 64 bit so its a bit odd it wont run this 64 bit command.
I see two syscalls printing in syslog, 310 gets reported for two different programs, 26 seems to occur all the time and cause no issue in steam
Looking up these syscalls with
firejail --debug-syscallsI get26 = msync, or ptrace in syscalls32
310 = process_vm_readv, or unshare in syscalls32
!ptracehas already been added to steam.profile, adding any of the other three seems to have no effect.Either one at a time or adding all three
Is there some order to commenting out syscalls or does
--debug-syscallsreport the wrong syscall?Or perhaps the syscall actually causing the issue isn't getting reported and I have to try them all?
@rusty-snake commented on GitHub (Jul 13, 2022):
No (for only one
seccomp ...line).No, just lookup the right architecture. (40000003 is i386)
Make sure to run with
seccomp-error-action killorseccomp-error-action logor have your kernel/audit configured to log errnos too.Is your firejail/kernel a x86_64 build? Did you tried with
seccomp.32as well?@kmk3 commented on GitHub (Jul 13, 2022):
(Offtopic)
@swimik
I changed the formatting in the first comment to make it more readable.
When reporting a bug, please use the "Bug report" link, as the sections in the
bug report template are already pre-formatted:
See this comment for how to format code blocks:
See also the "Log" part in the bug report template for the summary tags (to
expand/collapse sections):
@swimik commented on GitHub (Jul 14, 2022):
I am not sure why its trying to do something in i386. Perhaps this is why syscall 26 doesnt affect the systemIm dumb sorry, I read that as i686. of course steam runs i386 because it required everyone on linux to enable multiarch i386 / x86_64 just to run steam.
This command should be helpful. I will try running the program with these enabled to spot the problems better.
Yes its an x86_64 system, its just a standard 64bit Debian system for games. The only real changes are using testing for better drivers and firejail. Steam runs as a 32 bit program, thats why I was looking at 32bit syscalls because just blocking the 64 bit ones didn't seem to work.
@swimik commented on GitHub (Jul 14, 2022):
Running
firejail --seccomp-error-action=kill steamhelped ID some syscalls that were not being reported with normal audit log.I found I had add the 64bit syscall 310, process_vm_readv, as I noted before.
Also the 32 bit syscalls kcmp(349) and ptrace(26)
I am still geting this error
This should be syscall lookup_dcookie but when I add it to steam.local it is not being allowed. Here is what I have
seccomp !chroot,!mount,!name_to_handle_at,!pivot_root,!ptrace,!umount2,!lookup_dcookie,!process_vm_readv seccomp.32 !kcmp,!ptraceI am a bit puzzled why adding !lookup_dcookie to the profile doesnt seem to enable the syscall like adding the other syscalls did.
@swimik commented on GitHub (Jul 14, 2022):
trying to run the same program with
firejail --secomp-error-action=log steamshows audit errors for thisAnd yet the arch=c000003e syscall=310 is process_vm_readv which I have allowed in the seccomp filter. I feel like there is some kind of syntax error or I am doing something wrong here...
@rusty-snake commented on GitHub (Jul 15, 2022):
--debugto see a pseudo assembly version of the compiled seccomp filter.@swimik commented on GitHub (Jul 15, 2022):
This is my steam.local with !lookup_dcookie, !process_vm_readv added.
There is something strange going on. Yesterday I was getting audit logs for !process_vm_readv(310) in syslog. Today I am getting audit logs for !lookup_dcookie(212). Both have been added to steam.local to be allowed.
I am using
firejail --seccomp-error-action=kill --debug steamto try and diagnose whats happening.steam.local
Here is the the diagnostic output, if you look at the seccomp complier you can see that !lookup_dcookie is not being parsed despite being included in steam.local. I imagine if I come back to this tomorrow it will have decided to not compile !process_vm_readv like was happening yesterday(no saved log of that sadly). This is why I wondered if there was some order to seccomp filters.
firejail --seccomp-error-action=kill --debug steam
Edit by @rusty-snake: fix code blocks
@rusty-snake commented on GitHub (Jul 15, 2022):
... looks like a copy of steam.profile.
If you have one line, then no. If there is more then one line I don't think we even have a clear defined handling of it so zour probably better ignoring all later lines.
@swimik commented on GitHub (Jul 15, 2022):
really only the seccomp lines are different
seccomp !chroot,!mount,!name_to_handle_at,!pivot_root,!ptrace,!umount2,!lookup_dcookie,!process_vm_readv,
seccomp.32 !kcmp,!ptrace,
I have added !lookup_dcookie and !process_vm_ready to the 64 bit syscalls and added a line for seccomp.32 !kcmp,!ptrace
What is strange is firejail does recognize and parse the seccomp.32 line. But seems to only partially recognize and parse contents of the seccomp line.
I still show seccomp errors and firejail blocking the program execution unless I include both lines, seccomp and seccomp.32 to include applicable syscalls that steam needs to function.
I tried adding kcmp to the regular seccomp line(which seems to function as 64bit only) and it had no effect because kcmp is a 32 bit syscall. And as the ptrace syscall is both 32 and 64 bit, including it only in the seccomp line only allowed the 64bit ptrace call to function, there were still errors for 32bit ptrace in the syslog, and the program would get blocked at points.
So one part of me thinks something like lookup_dcookie is spelled wrong somewhere in firejail or debians code, preventing it from being recognized when its in the firejail profile. But then again, I HAVE seen it be parsed correctly yesterday and for some reason it is not being properly parsed today. And yesterday my problem was with process_vm_readv not being properly parsed, yet today it is functioning correctly.
The steam.local file has not changed in these two days, aside from me trying different ordering of the syscalls to see if that mattered. Its like its being overriden elsewhere, but from my understanding of firejail is that the .local file is read last and overrides any prior more restrictive settings.
@rusty-snake commented on GitHub (Jul 15, 2022):
Why did you added all the other lines then?
A .local should onlz contain the lines zou want to add.
https://github.com/netblue30/firejail/wiki/Creating-Profiles
https://github.com/netblue30/firejail/wiki/Creating-overrides
No, it's read first. You can use it remove or add restrictions. Whether a line in a .local overrides a line in .profile depends on the override logic of that command.
(no)blacklistfor example has a first win logic whileread-(only/write)has a last win logic.Can you try with only this in steam.local.
@swimik commented on GitHub (Jul 15, 2022):
Oh I will try that then. I just opened steam.profile, made my changes, and saved as steam.local.
@swimik commented on GitHub (Jul 15, 2022):
Well that works now, there were many more syscalls that had to be unblocked after 212 finally was parsed.
What effect does putting the
ignore seccompat the end have? Without it the program wont run, it hangs up at the lookup_dcookie(212) syscall like before.ioperm and nfsservctl showed up in the audit log but the program still ran. Is it a good idea to allow these or should as much stay restricted as possible?
@rusty-snake commented on GitHub (Jul 16, 2022):
It ignores any following line starting with
seccomp.@swimik commented on GitHub (Jul 18, 2022):
Ok when I comment out the line
ignore seccompin steam.local then I am back to firejail either blockingprocess_vm_readvorlookup_dcookie. So something is blocking those out even though they have been whitelisted. I guess Ill look at the other profiles being loaded with steam when it loads.firejail steam
Reading profile /etc/firejail/allow-java.inc
Reading profile /etc/firejail/allow-python2.inc
Reading profile /etc/firejail/allow-python3.inc
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-programs.inc
Warning: cannot create /home/user/.steampath
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
@rusty-snake commented on GitHub (Jul 18, 2022):
fb87e9a4d9/etc/profile-m-z/steam.profile (L159)@swimik commented on GitHub (Jul 19, 2022):
Maybe this is normal but I was looking at it more today and saw these errors for @default-keep, prelist: unknown, unknown.... etc.
firejail steam
That is almost the same number of 'unknown' seccomp filters as I have added to get the profile to work. So if they are unrecognized names then that might explain why they keep being blocked?
Also the line stating
Warning: an existing sandbox was detected. /usr/bin/steam will run without any additional sandboxing featuresThere is not any firejail sandbox running before I try and start steam. again, could be nothing, or its trying to launch multiple sandboxes? I see this if I use the terminal to launch multiple
firejail firefoxinstances for example, but in this case I have made sure not to try and start steam multiple times.@rusty-snake commented on GitHub (Jul 19, 2022):
If you run
firejaul steamrather thanfirejail /usr/bin/steamyou start fitejail a second time in the sandbox becausesteamis the firecfg symlink.