Bug 604003 - qtwebkit/jit crashes, requires execmem (selinux)
Summary: qtwebkit/jit crashes, requires execmem (selinux)
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
(Show other bugs)
Version: 14
Hardware: i686 Linux
low
medium
Target Milestone: ---
Assignee: Ngo Than
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
: 693141 (view as bug list)
Depends On:
Blocks: qt47 663127
TreeView+ depends on / blocked
 
Reported: 2010-06-15 06:38 UTC by Radek Novacek
Modified: 2016-12-01 00:29 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-04 00:40:06 UTC
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 07:05 UTC, Carl G.
no flags Details
backtrace of plasma-desktop (5.65 KB, text/plain)
2010-07-08 22:10 UTC, 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

Description Radek Novacek 2010-06-15 06:38:21 UTC
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 16:29:11 UTC
This is a crash in Qt's JavaScript JIT. I think we need to disable it again.

Comment 2 Rex Dieter 2010-06-15 16:46:48 UTC
rpm -q qt please

why can't we ever reproduce this reliably?

Comment 3 Rex Dieter 2010-06-15 16:47:36 UTC
Or maybe it's i686-specific (most of our devs use x86_64 it seems, me included)

Comment 4 Radek Novacek 2010-06-16 06:14:46 UTC
Qt version is qt-4.7.0-0.16.beta1.fc14.i686

Comment 5 Radek Novacek 2010-06-16 06:22:44 UTC
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 19:37:49 UTC
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 19:43:20 UTC
can you post the output of:
cat /proc/cpuinfo

Comment 8 Radek Novacek 2010-06-17 06:21:29 UTC
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 12:20:34 UTC
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 13:38:31 UTC
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 15:17:56 UTC
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 17:58:06 UTC
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 08:08:04 UTC
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 13:19:05 UTC
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 07:05:51 UTC
Created attachment 430252 [details]
Backtrace QT

Comment 16 Carl G. 2010-07-08 07:07:44 UTC
qt-4.7.0-0.24.beta1.fc14.x86_64

I'm not in a VM.

Comment 17 Carl G. 2010-07-08 07:19:10 UTC
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 07:23:14 UTC
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 11:43:16 UTC
What applets are active on your plasma-desktop?

Comment 20 Carl G. 2010-07-08 17:56:49 UTC
(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 22:10:44 UTC
Created attachment 430492 [details]
backtrace of plasma-desktop

Comment 22 Radek Novacek 2010-07-15 12:30:01 UTC
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 14:13:31 UTC
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 19:16:56 UTC
(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 20:24:47 UTC
And yet my f13/i386 kvm vm was fine.  

Maybe this is specific to rawhide selinux policy?

Comment 26 Carl G. 2010-07-15 20:37:19 UTC
(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 15:57:56 UTC
Does 

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

Fix the problem?

Comment 28 Carl G. 2010-07-21 06:17:13 UTC
$ 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 13:14:32 UTC
Is that a yes?

Comment 30 Carl G. 2010-07-21 19:09:10 UTC
(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 19:18:26 UTC
(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-22 02:47:12 UTC
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 14:14:44 UTC
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 12:07:46 UTC
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 23:40:17 UTC
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-16 00:12:16 UTC
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-16 00:19:14 UTC
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-16 00:23:58 UTC
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-16 00:33:33 UTC
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 08:31:36 UTC
(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-07 02:45:19 UTC
Any update on this bug report? Since F14 have allow_execmem => on.

Comment 42 Kevin Kofler 2010-12-15 14:13:27 UTC
We build Qt with the JavaScript JIT enabled now.

Comment 43 Kevin Kofler 2011-04-04 00:40:06 UTC
Why is this still open? We decided to close this, given that allow_execmem is on by default.

Comment 44 Kevin Kofler 2011-04-04 01:35:25 UTC
*** Bug 693141 has been marked as a duplicate of this bug. ***

Comment 45 Daniel Walsh 2011-04-29 14:18:35 UTC
*** 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.