Bug 1686675

Created attachment 1542008 [details]
backtrace from the crash

From backtrace,

Appears to be some qml/jsruntime JIT issue (in qt5-qtdeclarative I assume):

Thread 1 (Thread 0x7f16c3e6cdc0 (LWP 1220)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 139735806113624, 94740190158032, 139735805972696, 94740190158032, 94740190202768, 94740190158032, 139735806122898, 139735368281656, 25473869312, 139735367981808, 0, 139735368401760, 0, 0, 139735808783288}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007f16c6b1c8b5 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x7ffce9f01570, sa_sigaction = 0x7ffce9f01570}, sa_mask = {__val = {139735805931910, 4294967295, 9324068073094538752, 94740188721824, 1, 140724233311600, 140724233311600, 94740189191664, 139735819755637, 94740189191664, 140724233311600, 94740186923936, 9324068073094538752, 1, 94740189191664, 94740186924336}}, sa_flags = -370141840, sa_restorer = 0x7f16c73e9068 <QCoreApplication::self>}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f16c6b75377 in __libc_message (action=<optimized out>, fmt=fmt@entry=0x7f16c6c838b4 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
        ap = {{gp_offset = 32, fp_offset = 32764, overflow_arg_area = 0x7ffce9f01660, reg_save_area = 0x7ffce9f015f0}}
        fd = <optimized out>
        list = <optimized out>
        nlist = <optimized out>
        cp = <optimized out>
        written = <optimized out>
#3  0x00007f16c6c05d85 in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=false, msg=msg@entry=0x7f16c6c83892 "stack smashing detected") at fortify_fail.c:28
No locals.
#4  0x00007f16c6c05d38 in __stack_chk_fail () at stack_chk_fail.c:29
No locals.
#5  0x00007f16c7d56ffb in QV4::JIT::PlatformAssemblerCommon::link (this=<optimized out>, function=0x562a6b5224e0, jitKind=jitKind@entry=0x7f16c7ed4d8c "BaselineJIT") at ../3rdparty/masm/stubs/ExecutableAllocator.h:167
        dummy = {executableAllocator = {realAllocator = 0x562a6b654e30}}
        linkBuffer = {<JSC::LinkBufferBase<JSC::MacroAssembler<JSC::MacroAssemblerX86_64>, JSC::DefaultExecutableOffsetCalculator>> = {m_executableMemory = {m_ptr = 0x562a6b623760}, m_size = 1350, m_code = 0x7f16a41f3000, m_assembler = 0x562a6b615f68, m_globalData = 0x7ffce9f016c0}, <No data fields>}
        codeRef = <optimized out>
        showCode = false
        doProfile = false
#6  0x00007f16c7d488d3 in QV4::JIT::BaselineAssembler::link (this=<optimized out>, function=<optimized out>) at jit/qv4baselineassembler.cpp:849
No locals.
#7  0x00007f16c7d480f9 in QV4::JIT::BaselineJIT::generate (this=0x7ffce9f017e0) at jit/qv4baselinejit.cpp:72
        code = 0x7f16a43211a0 <error: Cannot access memory at address 0x7f16a43211a0>
        len = 103
#8  0x00007f16c7ccd5af in QV4::Moth::VME::exec (frame=frame@entry=0x7ffce9f01860, engine=engine@entry=0x562a6b655cb0) at jsruntime/qv4vme_moth.cpp:428
        _executionEngineCallDepthRecorder = {ee = 0x562a6b655cb0}
        function = 0x562a6b5224e0
        profiler = {profiler = 0x0, function = 0x7f16adc99e40, startTime = 139735084054224}
        debugger = <optimized out>
        result = 140724233312256
#9  0x00007f16c7cd16ed in QV4::Module::evaluate (this=this@entry=0x7f16adc99e38) at jsruntime/qv4module.cpp:125
        unit = <optimized out>
        v4 = 0x562a6b655cb0
        moduleFunction = 0x562a6b5224e0
        frame = {engine = 0x562a6b655cb0, savedStackTop = 0x7f16adc99e40, parent = 0x0, v4Function = 0x562a6b5224e0, jsFrame = 0x7f16adc99e40, originalArguments = 0x0, originalArgumentsCount = 0, instructionPointer = 0, yield = 0x0, unwindHandler = 0x0, unwindLabel = 0x0, unwindLevel = 0, yieldIsIterator = false, callerCanHandleTailCall = false, pendingTailCall = false}
        frameCleanup = <optimized out>
#10 0x00007f16c7d9cdd1 in QQmlScriptData::scriptValueForContext (parentQmlContextData=<optimized out>, this=0x7f169c0d9ad0) at qml/qqmltypeloader.cpp:2959
        v4 = 0x562a6b655cb0
        qmlExecutionContext = {ptr = 0x7f16adc99e30}
        module = {ptr = 0x7f16adc99e38}
        value = <optimized out>
        scope = {engine = 0x562a6b655cb0, mark = 0x7f16adc99e30}
        qmlContextData = <optimized out>
        v4 = <optimized out>
        scope = <optimized out>
        qmlContextData = <optimized out>
        qmlExecutionContext = <optimized out>
        module = <optimized out>
        value = <optimized out>
        error = <optimized out>

May have to work to get Qt 5.12.x available for f30 testing sooner rather than later, I believe it does resolve at least several issues related to newer gcc.

Oh, sorry for the spam, this is about rawhide/f31, which should have Qt 5.12.x already, sigh :(

I suspect this is due to #1667171.

To prove that:
- change to vty2, login as root and set "setenforce 0"
- systemctl restart sddm

This will bring sddm up

Created attachment 1542505 [details]
SELinux warning

Well, actually the SELinux message is quite different from the one in the above bug, I'll attach it here.

The important part,
type=AVC msg=audit(1552211962.890:178): avc:  denied  { execmod } for  pid=991 comm="sddm-greeter" path=2F6D656D66643A4A4954436F64653A2F6C696236342F6C6962517435516D6C2E736F2E35202864656C6574656429 dev="tmpfs" ino=29321 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=0

indeed, that may very well be it.

Hi, 

This looks suspicious, with execmod you make executable a file that has been modified by copy-on-write. Which is some temp file create by some user. Does anyone know whats going on?

Hey, I'm not sure and can't really check ATM but I'm convinced the weird file could be related to how QML works now in Qt. There's some kind of JIT or maybe even ahead of the time compilation of the QML files to improve startup performance. It could be worth looking into how disable that for SDDM.

But again, I didn't really look into this too deep, I'm reacting based on what came into my email at this moment.

This should be solved on SDDM side, from security POV, it's not safe to allow.

Can you please test if putting QML_DISABLE_DISK_CACHE=1 into the environment fixes this issue?

It may need to be "true" actually

This indeed seem to be what Qt recommend: https://bugreports.qt.io/browse/QTBUG-58508

If setting this environment variable works, I will gladly set in the greeter main() and release the hot fix with SDDM 0.18.1

Build with that workaround on the way for testing,
https://src.fedoraproject.org/rpms/sddm/c/5b3a6cb92dd897d52f215186a7f2942f8699ea90

sddm-0.18.0-5.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-aa37ca72c6

To clarify, is this denial specific to f31+ , or could affect previous fedora releases as well?

Neither installing sddm-0.18.0-5 or manually exporting QML_DISABLE_DISK_CACHE=1 or QML_DISABLE_DISK_CACHE=true seems to work. I still get the same SELinux denial.
This is on a F31 virtual machine.

Is it correct to do a "export QML_DISABLE_DISK_CACHE=1" in vty2 as root and then restart sddm service (which runs on vty1)?

Pretty sure systemd services will not pick up any user environment, which is why I implemented it the systemd service file.

Mattia: did you reboot after installing the -5 package?

sddm-0.18.0-5.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-aa37ca72c6

I can confirm this affects f30 with Qt 5.12.x as well,
https://bodhi.fedoraproject.org/updates/FEDORA-2019-74ad6b133a

Can we rebase this to f30 (or prefer a separate bug)?

Further testing, it appears that setting QML_DISABLE_DISK_CACHE=1 via sddm.service isn't doing what we want.  I can see
/var/lib/sddm/.cache/sddm-greeter/qmlcache
repopulating with content performing 'systemctl start sddm'

It appears to be an important Qt 5.12 feature for 
https://blog.qt.io/blog/2018/11/16/qt-quick-performance-improvements-qt-5-12-lts/
https://blog.qt.io/blog/2018/05/22/optimizing-qml-compiler-pipeline/

As a compromise, can selinux allow this under the specific locations used?  Per
https://doc-snapshots.qt.io/qt5-5.12/qtquick-deployment.html
"Each time you load a changed QML document, the cache is automatically re-created. Cache files are located in a sub-directory of QStandardPaths::CacheLocation with the name "qmlcache". The file extension is .qmlc for QML documents and .jsc for imported JavaScript modules."

In this context, CacheLocation is under $XDG_CACHE_DIR , which defaults to $HOME/.cache

(In reply to Adam Williamson from comment #19)
> Mattia: did you reboot after installing the -5 package?

Yes, I did

Adding an explicit qputenv in sddm's Greeter.app.cpp and now no cdqmlcache is generated, but sddm startup still fails, so perhaps qmlcache is not to blame afterall. ??

Do SELinux denials still show up? The same ones?

Yes and yes, respectively

Reassigning to qt5-qtdeclarative, that's where the JIT lives, since that's our best-guess what's at issue here.

Ideally and personally, selinux policy will likely need adjustment to allow this somehow.  Disabling the JIT is most likely not be practical, if we want kde/plasma to be reliable and functional.

Per comment #27 , I'll reach out to Qt upstream to verify if this is intended behavior or not (I assume yes, but would like to confirm).

In the meantime, selinux-policy maintainers please explore what it would take to remediate this on the policy side, thanks.

commit 75b1d69bcb42ed22a86399a638615ea0e3e0b44d (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec>
Date:   Mon Mar 25 18:18:23 2019 +0100

    Allow xdm_t domain to create own tmp files BZ(1686675)

I suspect that change alone will not be sufficient... it may allow sddm to function, but any other application using QML will likely to fail similarly (including plasmashell).

I needed to change the fix: 

commit b449b264e39f381beef1cb99977f543731972c64 (HEAD -> rawhide, origin/rawhide)
Author: Lukas Vrabec <lvrabec>
Date:   Wed Mar 27 18:42:55 2019 +0100

    Allow xdm_t domain to execmod temp files BZ(1686675)

Any ETA for a similar fix to land for f30?

and what about the concern raised in #c30?

(In reply to Rex Dieter from comment #32)
> Any ETA for a similar fix to land for f30?

I'll create new builds in these days.

(In reply to Adam Williamson from comment #33)
> and what about the concern raised in #c30?

Do we have any similar existing issue? 

Thanks,
Lukas.

I strongly suspect all consumers of Qt5's QML JIT could be affected by this, but I can't confirm until I have a policy to test.  Once you have that built, let us know, and I'll be able to confirm/deny that theory.

The builds attempted today all failed, with this error:

BUILDSTDERR: libsepol.expand_filename_trans: Conflicting name-based type_transition xguest_t cache_home_t:dir "fontconfig":  cache_home_t vs user_fonts_cache_t
BUILDSTDERR: libsepol.expand_module: Error during expand
BUILDSTDERR: /usr/bin/semodule_expand:  Error while expanding policy
BUILDSTDERR: make: *** [Rules.modular:205: validate] Error 1

Looks like a mistake in the change marked "Allow fontconfig file transition for xguest_u user".

Looks like https://github.com/fedora-selinux/selinux-policy-contrib/pull/102 is the fix for this, I guess, but I'll leave it to Lukas to fix up tomorrow...

Issue should be fixed in the latest selinux-policy package for rawhide.

I confirm SDDM now is displayed correctly at startup. I haven't seen any other problem as suggested in comment #35, but I don't know exactly what other applications use QML JIT and can be affected.

I too can confirm both sddm and plasmashell session performs well with selinux-policy-3.14.3-27.fc30.  Thanks!

Once selinux-policy-3.14.3-27.fc30 lands in f30 updates-testing, we can send the Qt 5.12 back to -testing as well.

Great, thanks for testing.