steam: Unhandled exception: illegal instruction in 64-bit code (seccomp) #5250
Comments
No (for only one
No, just lookup the right architecture. (40000003 is i386)
Make sure to run with
Is your firejail/kernel a x86_64 build? Did you tried with |
|
(Offtopic) 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 See this comment for how to format code blocks: See also the "Log" part in the bug report template for the summary tags (to |
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. |
|
Running 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 |
|
trying to run the same program with
And 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... |
|
|
This is my steam.local with !lookup_dcookie, !process_vm_readv added. I am using steam.localHere 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 |
... 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. |
really only the seccomp lines are different seccomp !chroot,!mount,!name_to_handle_at,!pivot_root,!ptrace,!umount2,!lookup_dcookie,!process_vm_readv, I have added !lookup_dcookie and !process_vm_ready to the 64 bit syscalls and added a line for seccomp.32 !kcmp,!ptrace
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. |
Why did you added all the other lines then? https://github.com/netblue30/firejail/wiki/Creating-Profiles
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. Can you try with only this in steam.local. |
|
Oh I will try that then. I just opened steam.profile, made my changes, and saved as steam.local. |
|
Well that works now, there were many more syscalls that had to be unblocked after 212 finally was parsed. 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? |
It ignores any following line starting with |
|
Ok when I comment out the line firejail steamReading profile /etc/firejail/allow-java.inc |
|
firejail/etc/profile-m-z/steam.profile Line 159 in fb87e9a |
|
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 |
If you run |
kmk3
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
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?
The text was updated successfully, but these errors were encountered: