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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel