On 26 November 2015 at 18:51, Alex Merry <alex.me...@kde.org> wrote: > On 2015-11-26 09:27, René J.V. Bertin wrote: >> >> There's something I don't really understand though: the exact same >> question you asked above. >> What's the difference between starting kwrite directly on the >> commandline (or through execve()), and dlopen'ing it? Why does the >> code go through that on Linux? Whatever that difference is, it's >> probably the reason why the approach fails on OS X. > > > If I recall rightly, it's a speed thing. kdeinit pre-loads some libraries > common across most KDE applications (eg: Qt5Core and Qt5Gui, which are > reasonably large). fork()+dlopen() can then make direct use of these > already-loaded libraries, whereas an exec() would have to reload/remap them > all. > > I think there's also possibly some memory-usage benefits from the fact that > fork() gives you copy-on-write access to kdeinit's memory pages. > > Alex
Has anyone done measurements on a recent system? Does it give any noticable benefit? Because there is definitively a security implication of this as it completely breaks ASLR. As the processes share an address space all functions in QtCore, etc (including dangerous ones such as system() from libc) will always be at the same address. It also means that if someone is trying to run a ROP attack he only needs to find the addresses of useful gadgets once as all processes launched by kdeinit will have the gadgets at exactly the same address. Do we really still need this optimization? Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
