We benchmarked it on glibc and the overhead wasn't even measurable. In addition, the average overhead on TCMalloc's testsuite was 0.02%, so the impact is quite negligible.
We've just finished a research when uClibc was used on a Linux OS and there was ASLR for the heap. This protection would have blocked our exploit completely, if it was already deployed.
I agree that on operating systems without ASLR, there isn't any added value for this protection. If there is some way do automatically enable it for ASLR enabled OSes it would be the preferred method. From my experience when security is not opt-in by default, it never gets activated.
On Sun, 16 Feb 2020, 10:10 Kjetil Oftedal, oftedal@gmail.com wrote:
Hi,
Shouldn't this be a config option, since there is a performance hit? On most embedded architectures the heap is in a fixed position, so the there is no randomness to extract from ASLR, thus they are only left with the performance overhead.
Best regards, Kjetil Oftedal
On Sun, 16 Feb 2020 at 07:02, Eyal Itkin eyal.itkin@gmail.com wrote:
Hi,
Sorry for the formatting problem, I'm having trouble sending each open source project the patch in their own format, and I probably mixed up something. The patch is now attached to this email.
In addition, I also attached the White Paper that describes this new security mitigation.
Just as a side note: the patch is signed by eyalit@checkpoint.com but I'm sending this from eyal.itkin@gmail.com due to mail issues with my work e-mail (which is connected to my GitHub account).
Thanks again for your cooperation, Eyal.
On Fri, Feb 14, 2020 at 11:40 AM Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Hi, Eyal Itkin wrote,
Safe-Linking is a security mechanism that protects single-linked lists (such as the fastbins) from being tampered by attackers. The mechanism makes use of randomness from ASLR (mmap_base), and when combined with chunk alignment integrity checks, it protects the pointers from being hijacked by an attacker.
The patch does not apply with git am ontop of uClibc-ng master. What mail client do you use and could you try to use git format-patch -s origin and send an e-Mail with the patch as attachment so it does not get corrupted somehow.
best regards Waldemar
devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel