Closed wouterdb closed 10 years ago
Please post your System Information. Steam Client -> Help -> System Information. Consider putting it into pastebin.com for better readability of the bugtracker.
I just launched at my archlinux, and i get to the menu. I can't try the ingame because I'm at class right now
Intel HD graphics, intel celeron p4500, 4 GB ram DDR3, archlinux
IT WORKS! but with a little bug: I can't change the config. I can play at 1366 at a very low fps rate (In windows I couldn't play much better neither)
I have the same issue, also on Fedora 20 but with a Radeon 5750 on the OSS radeon driver.
gdb backtrace output is here: http://pastebin.com/sUXTNT1W steam hardware info: http://pastebin.com/s5KVrEx0
Let me know if you need more information.
Looking at the backtrace this might be SELinux / hardening related; can you guys temporarily disable that to confirm that this avoids the problem? We can then fix it on our end if that's the case.
I can confirm that it is an SELinux issue
It works now
On Wed, Feb 26, 2014 at 5:59 PM, Pierre-Loup A. Griffais < notifications@github.com> wrote:
Looking at the backtrace this might be SELinux / hardening related; can you guys temporarily disable that to confirm that this avoids the problem? We can then fix it on our end if that's the case.
Reply to this email directly or view it on GitHubhttps://github.com/ValveSoftware/portal2/issues/50#issuecomment-36148207 .
I can also confirm that it works here.
If it's any help, here's the selinux output:
type=AVC msg=audit(1393434270.192:374): avc: denied { execheap } for pid=1979 comm="portal2_linux" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1393434270.192:374): arch=40000003 syscall=125 success=yes exit=0 a0=b48a000 a1=15000 a2=7 a3=ffd138ac items=0 ppid=1976 pid=1979 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=1 tty=(none) comm="portal2_linux" exe=2F686F6D652F6D6574656765722F2E6C6F63616C2F73686172652F537465616D2F537465616D417070732F636F6D6D6F6E2F506F7274616C20322F706F7274616C325F6C696E7578 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Thanks for the fast response!
Seeing this on Fedora 21. `
`
Your MP3 decoder seems to panic if it can't use execheap. As it has been stated many times, execheap is dangerous, and would be blocked on Windows as well by DEP. I think you should consider changing your MP3 decoder to not use execheap. If you really must write it to a memory, this link: http://www.akkadia.org/drepper/selinux-mem.html has a way of avoiding the SELinux AVC of execheap in a a bit safer way, tho I'm not sure why you'd need execheap on Linux but not on Windows.
It shouldn't crash if it fails that, tho. And I think that if HL2 can work without allowing execheap, Portal 2 should work as well. It shouldn't execheap to begin with, but if you decide to do it anyway, it should not crash when it fails.
I have almost completed the game on Fedora 20 with Intel mesa drivers without any crashes. I have my SELinux disabled.
To play Portal 2 you need to have SELinux disabled. Closing this out.
David, this is unacceptable. execheap()
is dangerous, and disabling selinux is even more dangerous. You are exposing thousands of users to a major security threat.
@davidw-valve Not an acceptable response, sorry! Please reopen this. Don't ever ask users to disable security features as a workaround. Just stop being a security issue in the first place.
If you set off a metal detector at a security checkpoint of some kind you don't just switch it off to prevent the buzzing. Instead you investigate the issue further to remove the aspect that causes the buzzing or verify whether the buzzing was justified ("It's just me nail clippers, I swears!"). Okay sure, Portal 2 segfaulting isn't gonna lead to a plane exploding but it's the same basic concept.
You guys are in a tenuous position right now where you're basically telling other developers how to do Linux game dev. Don't give out the message that it's acceptable to disable security features to get games working. I don't think you tell Windows users to disable UAC at any time, either, right?
Oh hey, let's disable VAC too because you're preventing some people from playing TF2.
There are two options:
1) Fix this potential security flaw now; or 2) Fix this later, after it's been exploited and caused untold damages.
I know which one I'm hoping for, and would hope that such a blatant disregard for security does not develop over a scant decade.
I apologize for the mis-communication: Some underlying infrastructure our games rely on is incompatible with SELinux. We are hoping to correct this. Of course closing this bug isn't appropriate and I am re-opening it.
Thank you.
Thank you, David.
Android has SEAndroid which is compulsory as of Kit Kat. If Valve ever want to target Andeoid or Tizen then it needs to be fixed. These days I do not feel safe not running SELinux, which is why I choose Fedora as the default policy us great. Setting up Ubuntu and Debian to have the same policy is a lot of hassle.
You can add in exceptions per program (instruction are in the denial message), whilst this is still insecure for that program. You do not need to disable the entire SELinux!!
1) Please advise people how to add a temporary policy for Portal 2 and remove it after. 2) Please fix the issue by using the advised work around such as two mmaps on the same file one for exec and one for write. 3) The steambox will benefit greatly from running SELinux especially if you open up Steam to all developers and the potential for malware and games harvesting data increases.
Other than that thank you for the continued contribution to Linux and Games!
@x414e54 I completely disagree, adding an exception or disabling the executable memory protection is a bad idea, and you are compromising your system by doing so. Valve should not advise users regarding SELinux at all, and rather continue working on fixing the underlying (security) issue.
Until then, I'd recommend people who care about the security of their workstations to not play Portal 2.
I would recommed people who care about the security of their work stations just to turn them off and not use them. But Security is not about black and white it is about levels of risk and an exception just for Portal 2 is far better than disabling SELinux. Some people will be excited to play it they are willing to take that risk. Just as you are willing to take the risk that Portal 2 is not in fact malware itself regardless of SELinux.
Using executable heap does not give the program any extra privileges, it prevents a malicious third party attacker exploiting that application usually to gain root (which is not what Portal 2 is running as). There needs to be an entry point for that application and a feasible way to exploit it. You first need to find a buffer overflow for example. Even if someone did manage to find a way to exploit it remotely maybe using crafted mp3 files on a malicious server. The best they would get is access as your user. There is nothing stopping Portal 2 just having a direct code execution vulnerabilities else-where, using methods SELinux does not protect against. Furthermore there is nothing stopping Valve using Portal 2 as a trojan for the NSA or Steam as a botnet on your computer.
It is bad Valve need to fix it but let's not overreact.
@x414e54
I would recommed people who care about the security of their work stations just to turn them off and not use them.
That's logical fallacy.
But Security is not about black and white it is about levels of risk and an exception just for Portal 2 is far better than disabling SELinux.
Where do you draw the line what should be exception and what not.
Some people will be excited to play it they are willing to take that risk. Just as you are willing to take the risk that Portal 2 is not in fact malware itself regardless of SELinux.
So we all should ignore the security hole, because the are ppl who don't care (don't understand risk)?
In the next paragraph you're just derogating implication of this security issue. I guess you don't have much experience with this problematic.
To be honest sadly I do understand the issues and sometimes exceptions are made temporary or otherwise for reasons you do not control and may not like. The best option is to be informed about the issue so you can make your own decision, it is your decision where you draw the line.
A good example is magnetic stripe cards in the USA, people in europe use EMV because it is more secure and magnetic stripe and card numbers are crazy. Someone excepted that risk on their behalf, and their only choice is either go with it, or don't use a card and wait till it is fixed.
Unfortunately it is not a fallacy. It is stupid yes, but the work station you buy probably came from parts from another country with different regulations. From a company you have no idea if they even have a security department. There are plenty of hardware exploits waiting there. You then download an iso for Linux from some site using SSL, which is vulnerable from a selection of recent issues using a rediculosuly large set of CAs you have no idea if they have been compromised or not. If the site even used SSL for your distribution, or you even bothered to check what it was using. You then use this image and assume that the PGP keys have not been altered because you could not be bothered to verify the hash they provide. Once this is done you look over the any recent Linux kernel vulnerabilities navigate to steampowered.com and download the Steam installer completely unverified and install it. You then overlook the fact that someone in valve could have been hire by any number of governments to install a remote access tool into Steam. Overlook all of the vulnerabilities that do not get picked up by SELinux but still provide remote code execution, from a policy that has many exceptions that you did not verify yourself anyway. You then proceed to install indie games from any number of untrusted developers that could be reading your home folder and sending it over the internet. But you get to the Portal 2 BETA... And stop and kick up a huge fuss because that is your line, the line that you don't fully understand but popular media has decided to tell you is worse than all of these other issues you have previously accepted.
I really thank valve for helping bring all this to Linux and help push open source and PC gaming. It is more than many other companies have done. But the kind of bullyist attitude we see from some people does not help progress. If people from the beginning explain the issue and risk, rather than blowing everything into an "omagherd valve hate security" maybe people are less likely to say "disable selinux" and close issues, to "we are fixing the issue with our third party, but you can add an exception if you really want to play it now, the issue is explained fully here... Oh we are also including SELinux and permissions/sandboxing with steam also!".
Why not just use opus and an open source opus decoder instead of mp3 with a closed source mp3 decoder? After all, it's significantly lower latency, produces a smaller file size, and has better audio quality than mp3 (indistinguishable from WAV/FLAC, unless you are an animal).
We have just shipped an update which includes an attempt to fix this issue. Would appreciate SELinux users testing it and giving feedback on whether it works.
Note: your system will need to allow execution on files in /tmp
I can confirm it works on Fedora now, but startup seems to be slower than usual - the game froze for about 10 seconds (and I got the "application is have stopped responding" dialog box) before the menu was shown.
Thanks for fixing this issue!
Update: it seems to be more than 10 seconds. Now it was frozen for at least 20. The game starts up, I see the Valve intro video, then the screen goes black, then I hear the music and see the menu.
/tmp/dumps
was created with a file in it with the stdout output from the game, it's full of about 2000 lines of ZZZ: RELOCATE by -922882048 to 0xef3e00e4 (4324) vs 0xef3e0000 0xef3fb000 1
and such. So, I assume this slow startup thing is because of all those memory relocations (your workaround against the SELinux execheap thing?). Maybe you are relocating too much? Is all that you are relocating really needs that relocation? maybe you are relocating normal libraries when you only need to do that to stuff you "jit".
It will be slower to startup because there is some debug code included. That will be removed in the next update with a (hopefully) final fix to this problem.
A new update has been released with debugging code removed. It should now also work even if /tmp is noexec.
Closing this out. Please let me know if it fails for anybody.
When launching on fedora 20, with intel graphics, the game segfaults
when launching from steam, the console output is
when launching from console
If additional information is required, I can collect it.
Wouter
PS: keep up the great work