[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Review Request 126161: OS X housekeeping
From:       Alexander Richardson <arichardson.kde () gmail ! com>
Date:       2015-11-27 13:02:31
Message-ID: CA+Z_v8pXkr8HFifDuag4asBK2k4uvdKQBQLR3s5CBhwbPngD7w () mail ! gmail ! com
[Download RAW message or body]

On 26 November 2015 at 18:51, Alex Merry <alex.merry@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

[prev in list] [next in list] [prev in thread] [next in thread]