Bug 604003 - qtwebkit/jit crashes, requires execmem (selinux)
qtwebkit/jit crashes, requires execmem (selinux)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
14
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: Reopened
: 693141 (view as bug list)
Depends On:
Blocks: qt47 663127
  Show dependency treegraph
 
Reported: 2010-06-15 02:38 EDT by Radek Novacek
Modified: 2016-11-30 19:29 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-03 20:40:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Backtrace QT (6.10 KB, text/plain)
2010-07-08 03:05 EDT, Carl G.
no flags Details
backtrace of plasma-desktop (5.65 KB, text/plain)
2010-07-08 18:10 EDT, Carl G.
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 219441 None None None Never
KDE Software Compilation 241704 None None None Never

  None (edit)
Description Radek Novacek 2010-06-15 02:38:21 EDT
Description of problem:
Plasma crashed after logon. No panel/desktop showed, just crash from plasma.
After moment starting sound is played and then everything work normally (except
plasma). When i ran it from konsole - same behaviour. Emptying ~/.kde has no
effect.

Version-Release number of selected component (if applicable):
kdebase-workspace-4.4.85-3.fc14.i686

How reproducible:
always

Additional info:
Fresh F14 installation and then yum install @kde.
Backtrace is in the KDE bugzilla.
Comment 1 Kevin Kofler 2010-06-15 12:29:11 EDT
This is a crash in Qt's JavaScript JIT. I think we need to disable it again.
Comment 2 Rex Dieter 2010-06-15 12:46:48 EDT
rpm -q qt please

why can't we ever reproduce this reliably?
Comment 3 Rex Dieter 2010-06-15 12:47:36 EDT
Or maybe it's i686-specific (most of our devs use x86_64 it seems, me included)
Comment 4 Radek Novacek 2010-06-16 02:14:46 EDT
Qt version is qt-4.7.0-0.16.beta1.fc14.i686
Comment 5 Radek Novacek 2010-06-16 02:22:44 EDT
It looks like that JavaScript JIT is the problem. I downgraded to qt-4.7.0-0.13.beta1.fc14.i686 (last version with -no-javascript-jit) and now plasma works.
Comment 6 Rex Dieter 2010-06-16 15:37:49 EDT
OK. :(  

How should we move forward, blacklist known-bad platforms or whitelist known-good ones?

(I'm of a mind to use the blacklist strategy).
Comment 7 Rex Dieter 2010-06-16 15:43:20 EDT
can you post the output of:
cat /proc/cpuinfo
Comment 8 Radek Novacek 2010-06-17 02:21:29 EDT
I'm running it in the virtual machine (VirtualBox).

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1675.655
cache size      : 0 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 constant_tsc up pni monitor
bogomips        : 3351.31
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:
Comment 9 Kevin Kofler 2010-06-17 08:20:34 EDT
Can this be reproduced on actual hardware? If not, it needs to be fixed in VirtualBox, not worked around in Qt.
Comment 10 Rex Dieter 2010-06-17 09:38:31 EDT
oh boo.  I think I would have to agree with Kevin here.  we really need this reproducible on bare-metal (or at least pure fedora bits, say using kvm) to justify losing the performance advantages brought but the javascript-jit.
Comment 11 Jaroslav Reznik 2010-06-17 11:17:56 EDT
Do you have selinux enabled? If this is the case (selinux enabled and logged execmem execution), then there's no difference between bare-metal and VirtualBox.
Comment 12 Rex Dieter 2010-06-17 13:58:06 EDT
fwiw, when we first enabled this, we had several independant confirmations that things did work ok, including a i686 kvm-based VM I used.  go figure.
Comment 13 Radek Novacek 2010-06-18 04:08:04 EDT
This is weird. I downgraded qt to -13, upgraded it -18 (works fine) and downgraded again to -16 and now the crash is gone. I don't what happened - I did an yum update meantime, so something might fix that.
Comment 14 Rex Dieter 2010-06-18 09:19:05 EDT
ok, wierd.  let's consider this a passing gremlin, and I'll revert the change.

Please re-open if problems resurface.
Comment 15 Carl G. 2010-07-08 03:05:51 EDT
Created attachment 430252 [details]
Backtrace QT
Comment 16 Carl G. 2010-07-08 03:07:44 EDT
qt-4.7.0-0.24.beta1.fc14.x86_64

I'm not in a VM.
Comment 17 Carl G. 2010-07-08 03:19:10 EDT
Okay i think it's an issue with SELinux, setenforce 0 allow plasma-desktop to start.

----
time->Thu Jul  8 03:12:39 2010
type=SYSCALL msg=audit(1278573159.198:25059): arch=c000003e syscall=9 success=yes exit=140057755234304 a0=0 a1=4000 a2=7 a3=22 items=0 ppid=13603 pid=13606 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="plasma-desktop" exe="/usr/bin/plasma-desktop" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1278573159.198:25059): avc:  denied  { execmem } for  pid=13606 comm="plasma-desktop" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process


       Allow access by executing:
        # setsebool -P allow_execmem 1
type=AVC msg=audit(1278573159.198:25059): avc:  denied  { execmem } for  pid=13606 comm="plasma-desktop" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
        Was caused by:
        One of the following booleans was set incorrectly.
        Description:
        Allow unconfined executables to make their stack executable.  This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla")
 
        Allow access by executing:
        # setsebool -P allow_execstack 1
        Description:
        Allow unconfined executables to map a memory region as both executable and writable, this is dangerous and the executable should be reported in bugzilla")
 
        Allow access by executing:
        # setsebool -P allow_execmem 1
Comment 18 Carl G. 2010-07-08 03:23:14 EDT
Rex, could you look at the backtrace, i'm not sure if it's the same bug or not.
Comment 19 Rex Dieter 2010-07-08 07:43:16 EDT
What applets are active on your plasma-desktop?
Comment 20 Carl G. 2010-07-08 13:56:49 EDT
(In reply to comment #19)
> What applets are active on your plasma-desktop?    

Only Folder View.

I did not forced a relabel of the HDDs from F13 to Rawhide so that might explain the SELinux AVC denial.

I should try to reproduce it in a VM.
Comment 21 Carl G. 2010-07-08 18:10:44 EDT
Created attachment 430492 [details]
backtrace of plasma-desktop
Comment 22 Radek Novacek 2010-07-15 08:30:01 EDT
It's definitely SELinux issue. I reproduced it on new VirtualBox installation, then I ran "setenforce 0" and it didn't crashed. But no crash after "setenforce 1" and after reboot.
Comment 23 Rex Dieter 2010-07-15 10:13:31 EDT
Frankly, I don't care much about this on VirtuslBox (since it may be virtualbox-specific), at the moment.

I care more about bare-metal, and possibly even kvm/qemu.
Comment 24 Carl G. 2010-07-15 15:16:56 EDT
(In reply to comment #23)
> Frankly, I don't care much about this on VirtuslBox (since it may be
> virtualbox-specific), at the moment.
> 
> I care more about bare-metal, and possibly even kvm/qemu.    

Rex, i reproduced it twice and it seems to be related to SELinux. 1st time = updated from F13 to Rawhide and 2nd time it was inside a VM (KVM).
Comment 25 Rex Dieter 2010-07-15 16:24:47 EDT
And yet my f13/i386 kvm vm was fine.  

Maybe this is specific to rawhide selinux policy?
Comment 26 Carl G. 2010-07-15 16:37:19 EDT
(In reply to comment #25)
> And yet my f13/i386 kvm vm was fine.  
> 
> Maybe this is specific to rawhide selinux policy?    

Okay, i will CC Daniel Walsh, maybe he can give us some advices?
Comment 27 Daniel Walsh 2010-07-19 11:57:56 EDT
Does 

chcon -t execmem_exec_t /usr/bin/plasma-desktop

Fix the problem?
Comment 28 Carl G. 2010-07-21 02:17:13 EDT
$ ls -Z /usr/bin/plasma-desktop
-rwxr-xr-x. root root system_u:object_r:execmem_exec_t:s0 /usr/bin/plasma-desktop
Comment 29 Daniel Walsh 2010-07-21 09:14:32 EDT
Is that a yes?
Comment 30 Carl G. 2010-07-21 15:09:10 EDT
(In reply to comment #29)
> Is that a yes?    

Woops sorry Daniel, the file is already labeled execmem_exec_t:s0
Comment 31 Carl G. 2010-07-21 15:18:26 EDT
(In reply to comment #22)
> It's definitely SELinux issue. I reproduced it on new VirtualBox installation,
> then I ran "setenforce 0" and it didn't crashed. But no crash after "setenforce
> 1" and after reboot.    

Could you verify the label on plasma-desktop please, as a confirmation.

I had the same experience, setting setenforce to 0 allowed plasma-desktop to start (for the 1st login), from that point it was fine.
Comment 32 Kevin Kofler 2010-07-21 22:47:12 EDT
Unfortunately, setting execmem on plasma-desktop would not be a real fix even if it solves the problem, there's much more stuff using the QtWebKit JavaScript engine than just Plasma. Any app using QtWebKit (with any JavaScript) or QtScript (which now also uses this JavaScript engine) will use this engine. If the JIT still requires execmem, we will have to disable it again.

The strange thing is that some people apparently have this working with SELinux enabled, others don't.
Comment 33 Daniel Walsh 2010-07-22 10:14:44 EDT
Well you can turn the check off altogether by turning on the

allow_execmem boolean as described above.

setsebool -P allow_execmem 1
Comment 34 Bug Zapper 2010-07-30 08:07:46 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 35 Rex Dieter 2010-08-15 19:40:17 EDT
Carl, if you're still seeing this mind giving output of

rpm -q qt fedora-release
and
cat /proc/cpuinfo
Comment 36 Rex Dieter 2010-08-15 20:12:16 EDT
ok, meh, on my f13/x86_64 box I seem to have 
allow_execmem --> on

what is the f13 and f14 default wrt to allow_execmem?  (I don't recall ever changing it).
Comment 37 Rex Dieter 2010-08-15 20:19:14 EDT
ok, confirmed using f13 live image; 
allow_execmem --> on
is f13 default it seems.

So, this is changing with f14?  We will indeed be forced to disable the jit or find some other workaround.
Comment 38 Kevin Kofler 2010-08-15 20:23:58 EDT
FWIW, the JIT has always been disabled so far. We enabled it with Qt 4.7 because we thought the execmem issues had been resolved upstream given that we couldn't reproduce them. It turns out this is just because F13 allows execmem by default. :-( So disabling the JIT would just be restoring existing behavior of all released Fedoras.
Comment 39 Kevin Kofler 2010-08-15 20:33:33 EDT
And FYI, webkitgtk, which uses the same JIT, is still being built with --disable-jit and has been built that way for almost as long as the JIT exists in the first place.

I think we really need to build Qt with -no-javascript-jit and stop trying to enable it at every single Qt release, each time getting a new bug filed with AVCs and a new discussion. If upstream resolves https://bugs.webkit.org/show_bug.cgi?id=35154 we can reenable it. But so far that bug is being ignored entirely. So -no-javascript-jit is the only sensible option.
Comment 40 Jaroslav Reznik 2010-08-19 04:31:36 EDT
(In reply to comment #39)
> And FYI, webkitgtk, which uses the same JIT, is still being built with
> --disable-jit and has been built that way for almost as long as the JIT exists
> in the first place.
> 
> I think we really need to build Qt with -no-javascript-jit and stop trying to
> enable it at every single Qt release, each time getting a new bug filed with
> AVCs and a new discussion. If upstream resolves
> https://bugs.webkit.org/show_bug.cgi?id=35154 we can reenable it. But so far
> that bug is being ignored entirely. So -no-javascript-jit is the only sensible
> option.

Agreed.
Comment 41 Carl G. 2010-10-06 22:45:19 EDT
Any update on this bug report? Since F14 have allow_execmem => on.
Comment 42 Kevin Kofler 2010-12-15 09:13:27 EST
We build Qt with the JavaScript JIT enabled now.
Comment 43 Kevin Kofler 2011-04-03 20:40:06 EDT
Why is this still open? We decided to close this, given that allow_execmem is on by default.
Comment 44 Kevin Kofler 2011-04-03 21:35:25 EDT
*** Bug 693141 has been marked as a duplicate of this bug. ***
Comment 45 Daniel Walsh 2011-04-29 10:18:35 EDT
*** Bug 654173 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.