Bug 516057

This is webkit's JS interpreter, ExecutableAllocator.

http://people.redhat.com/drepper/selinux-mem.html
http://gcc.gnu.org/viewcvs/trunk/libffi/src/closures.c?revision=150042&view=markup

for examples of fixes.

Thanks for the bug report!

I think I've traced this to the ENABLE_ASSEMBLER_WX_EXCLUSIVE macro setting in the JS interpreter (as you mentioned, Bill), and am running a mock build now to test it. T

Note that the latest rawhide policy is more lenient about execmem/execstack, and may allow this to work. But that's only a temporary solution.

I believe this to be fixed as of webkitgtk-1.1.12-2.fc12, which was just built
into rawhide yesterday. However as I don't have a rawhide installation available, cCould you please test and verify whether or not the included no-execmem patch was successful in resolving this?

Thanks very much.

I'm not the original reported, but it work OK for me now.

This is back in rawhide with:

webkitgtk-1.1.14-3.fc12.x86_64
selinux-policy-targeted-3.6.32-6.fc12.noarch

*** Bug 522917 has been marked as a duplicate of this bug. ***

*** Bug 524852 has been marked as a duplicate of this bug. ***

*** Bug 525131 has been marked as a duplicate of this bug. ***

midori segfaults with Selinux enabled

Version-Release number of selected component:
fedora-release-11.91-3
midori-0.1.10-1.fc12.x86_64
webkitgtk-1.1.14-3.fc12.x86_64

Created attachment 362503 [details]
backtrace

backtrace

Setting this as blocking final release as it could have unpredictable and wide-ranging effects (lots of stuff uses WebKit to render Web content these days, and we don't want all those apps falling over apparently at random).

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I thought that this had been fixed with the no-execmem patch. Seems not. :(

Unfortunately, it wasn't until recently (when I acquired my lovely T500) that I could move my desktop to Rawhide. I'll look into this further first then when I home from class this evening. :)

Thanks.

*** Bug 525583 has been marked as a duplicate of this bug. ***

I've built 1.1.15.1-3 into rawhide this morning, which disables the JIT. It's a temporary hack, but does workaround this bug until I can delve into the code more deeply and figure out why it's still using executable memory even with ENABLE_ASSEMBLER_WX_EXCLUSIVE defined from the patch.

is it a good enough 'temporary hack' that we can ship the beta with it if necessary?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I confirm that webkit built with JIT disabled makes the following apps stop crashing wit this SELinux denial:
- liferea (this bug)
- empathy (bug 525583)
- epiphany (possibly bug 510931)

What is the restriction that selinux is failing from?  Does it not allow switching to and from writable and executable memory?

@Adam: Yes, this at least makes WebKit function properly. The only downside is a bit of a performance hit on JavaScript-heavy pages since the JIT compilation is disabled. But, I've been using this over the past couple of days with Epiphany and Midori without issue. If it comes down to it, this should be an okay EVR for the beta.

@Oliver: According to the description from Ulrich Drepper (http://people.redhat.com/drepper/selinux-mem.html), the restriction is that somewhere in the JIT compiler, memory is either being mapped anonymous and executable (with mmap and PROT_EXEC), or is mapping a file a file with MAP_PRIVATE and both PROT_EXEC and PROT_WRITE. 

Admittedly I've not looked into it any deeply yet, and am not sure where this bug occurs (or which of these it its) within the JIT code.

Thanks.

> @Oliver: According to the description from Ulrich Drepper
> (http://people.redhat.com/drepper/selinux-mem.html), the restriction is that
> somewhere in the JIT compiler, memory is either being mapped anonymous and
> executable (with mmap and PROT_EXEC), or is mapping a file a file with
> MAP_PRIVATE and both PROT_EXEC and PROT_WRITE. 
> 
> Admittedly I've not looked into it any deeply yet, and am not sure where this
> bug occurs (or which of these it its) within the JIT code.
> 
> Thanks.  

I was wanting to know what memory access restrictions SELinux is enforcing -- i work on the JSC JIT so know what JSC is doing :D

*** Bug 512139 has been marked as a duplicate of this bug. ***

Is anyone going to answer my question?

I'm not sure how the answer in #21 isn't clear -- it's one of those two, and the code in question should make it fairly obvious which.

This bug was discussed at the blocker bug review meeting today. As per #512845, execmem checks are disabled in final release, so execmem problems do not need to block the release. it's still a valid bug, though.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

For anybody l(In reply to comment #3)
> http://people.redhat.com/drepper/selinux-mem.html
> http://gcc.gnu.org/viewcvs/trunk/libffi/src/closures.c?revision=150042&view=markup
> 
> for examples of fixes.    

For anyone looking at this code: The top URL has changed to http://www.akkadia.org/drepper/selinux-mem.html

I built a webgkitgtk here with JIT re-enabled and with Peters patch for f14. 

http://koji.fedoraproject.org/koji/taskinfo?taskID=2460974

I think the performance increase is pretty big. 
(sunspider: ~1200 without JIT, ~350 with. Firefox4 gets ~600 here(smaller is better))

I am also not seeing any execmem denials with the above build on my f14 machine. 
Can other folks give a look and see?

I don't know that it's worth looking at changing in f12/f13 at this point, but I would really like to fix rawhide and f14 if possible.

*** Bug 524806 has been marked as a duplicate of this bug. ***

Sorry for additional spam, forgot to cc myself here. ;(

Well, I went ahead and pushed this into rawhide's 1.3.4 version. ;) 

Please feel free to re-open this or file a new bug if you see it occuring again there... 
I'll probibly also update f14 at some point before release too if possible.

Since Fedora 14 webkitgtk segfaults when all selinux allow_exec* booleans are set to off.

I have a machine where all these allow_exec* booleans are turned off and i cannot use devhelp and midori any longer (since upgrading to Fedora 14).

Some might say, that i even cannot use firefox if the booleans are set this way, but at least in Firefox you can turn off jit in preferences.

Rebuilding webkitgtk-1.3.6-1.fc14 with --disable-jit fixes the segfaults in devhelp and midori (and presumably all other software that depends on webkitgtk).

Is it possible to package two versions of webkitgtk, one with --disable-jit and one normal?

Uh. I do not see any segaults or issues here with selinux. I use midori full time. 

perhaps you are seeing bug: 648319 ?

I was pretty sure, that my problem is related to this bug, did not seem like 648319 at first. Now i am not sure any more, since it webkit applications started crashing with webkitgtk-1.3.4.

I will provide a kickstart file to reproduce my problem, then we'll see.

Unfortunately i had not the time to provide a kickstart file by now, but i can confirm the behaviour i described in comment 33 on a pretty untouched Fedora 14 i686 desktop installation. The problems are the same on x86_64.

If allow_execstack == 0: devhelp, midori will at startup crash

If allow_execstack == 1: devhelp, midori work fine

The following snippets are ltrace/strace snippets with allow_execstack=0:

$ ltrace midori
<... webkit_web_view_new resumed> )                                                = 0x8cab028
webkit_web_view_get_type(0x2aad7b, 0x53827c, 0xbfa32678, 0x48a5da, 0x8b3e858)      = 0x8d18770
g_type_check_instance_cast(0x8cab028, 0x8d18770, 0xbfa32678, 0x48a5da, 0x8b3e858)  = 0x8cab028
webkit_web_view_open(0x8cab028, 0x80bea9b, 0xbfa32678, 0x48a5da, 0x8b3e858 <unfinished ...>
g_str_hash(0x8da1c20, 0xdba44c, 5, 0xda9000, 0x432af0)                             = 49
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
$ 

$ strace midori
gettimeofday({1290999203, 862043}, NULL) = 0
mmap2(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EACCES (Permission denied)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault
$ 

Perhaps this helps to point me to the right bug/people to get this resolved.

I don't see this here. ;( 

Try a 'fixfiles onboot' reboot and see if the problem persists?

fixfiles onboot did not resolve the problem.

But i realized that midori seems not a good example for my problems with webkitgtk since f14. Depending on the user a browser has plugins enabled which crash when not allowed execstack, execmem, so my problem with midori is esoteric and not a common use case.

But devhelp is a very good example. I have an old box here, Pentium 4/3.40, i686. I installed Fedora i386 DVD (Use All Space, Enable Installation repo, Enable Fedora - i386 repo, Enable Fedora - i386 updates repo (not testing)). Only customization is: Add package group "Gnome Software Development".

After reboot, login, check for any outstanding updates:

1. devhelp runs without crashes

2. setsebool allow_execmem=0

3. devhelp crashes with "Segmentation fault (core dumped)"

And i am sure this worked in f13.
And i know that compiling webkitgtk with --disable-jit helps.

Version information: webkitgtk-1.3.6-1.fc14, devhelp-2.32.0-1.fc14

ok. I had some time to dig around some more this weekend... 

this bug seems to be 32bit specific, which explains why I never saw it. (I only have one small netbook thats still 32bit). 

So, now that I can duplicate it, will see if I can find a fix, or be forced to disable jit. ;( 

allow_execmem is not default right?

What is the stack trace of the failure? eg. is it during a call to mmap or writing to memory later?

I'm still not sure i fully understand the SELinux restrictions -- does it disallow flipping memory between writable and executable, so requiring two pages being mapped, one writable one executable? or does it simply disallow memory to be writable and executable at the same time?

If the latter then simply switching ENABLE_ASSEMBLER_WX_EXCLUSIVE to 1 in Platform.h (or as a define leading into the build) should be sufficient to have everything work correctly.  If it's crashing at that point due a W/X violation then it would be really good to know what the stacktrace is as it may point to new code that isn't ensuring correct permissions prior to writing.

If selinux disallows a given page to ever alternate between writable and executable then that will need support coded into JSC, in which case a bug will need to be filed at bugs.webkit.org, and realistically someone who works with SELinux will probably need to do the work (as we won't be able to test).  We will of course be happy to help anyone who wants to work on that though.

I've been trying to get a trace off my little netbook, but abrt has been spinning for a long time. ;( 

If someone could duplicate this on a 32bit box and attach the trace here (or point to an abrt bug where it's filed) that would be great. ;)

I still can't seem to get my little netbook to spit out a trace. ;( 
Anyone else able to do so for me?

Also, 1.3.7 is out (it has some issues where it's not building/installing translations so I have not made any update for it). You can try a scratch build at: 

http://koji.fedoraproject.org/koji/taskinfo?taskID=2658851

1.3.8 is out: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2683278

testing welcome.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping