Review Request 126161: OS X housekeeping

[Matthew Dawson]

On November 27, 2015 01:02:31 PM Alexander Richardson wrote:
> Has anyone done measurements on a recent system? Does it give any
> noticable benefit?
I have not, nor are my machines good representations.  I don't think 
considering machines with 2G of memory with older processors to be out of line 
of what KDE wants to support.

I don't know if it is still true, but I seem to remember the official NVidia 
drivers had a non-pic libGL, which this system made less painful for the 
system.  I also don't use that driver, so I can't comment on today's reality.

> Because there is definitively a security implication of this as it
> completely breaks ASLR.
I don't believe this completely breaks ASLR, at least no more then a regular 
run of prelink will.

When kdeinit first launches, it is still subject to ASLR, which will randomize 
the location of libraries.  Reusing these locations for all applications 
doesn't fully break ASLR, as it is unknown outside the system where an 
application launches.  Thus for an attacker going after one application, they 
are no further ahead then if you disable this.
It does weaken it some, as once you get the layout of one kdeinit launched 
application, you know locations for every other application in that login 
session.  So if an exploit path involves crossing multiple KDE applications 
using ROP, it will be easier to setup.  Though considering how KDE 
applications currently work, I'm not sure that matters as we don't use 
sandboxes.

So, if this optimization isn't useful anymore, I'm all for removing.  But it 
isn't a major security issue so we shouldn't remove it as a knee jerk 
reaction.
-- 
Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3885 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151127/7864012a/attachment.bin>