selfrando contributor here. it is correct that selfrando is intended as an improvement over ASLR by randomizing code at the function level (vs. module level). this improves resilience to information leaks somewhat, but with mitigations like these, there are no silver bullets.
i think it's ASLR with more entropy by skimming through the paper, but most exploits have read primitives or infoleaks anyways so i don't see how more entropy affects them. If i am right it protects against attackers guessing the ASLR slide, but that's very unreliable and no FBI grade exploit should ever do that.
See "Real-world Exploits against the Tor Browser" pages 9-10 where they conclude,
> The reason is that these function pointers are
only accessed through an indirection layer, i.e., memory
objects on the heap contain a pointer to a virtual table
which is located in the code or data section of the application and contains a number of pointers to virtual
functions. Since the attackers can only disclose the virtual table pointer, but not the virtual table itself, as it is
not on the heap, they cannot disclose gadget addresses.
Note that, when only ASLR is applied, the address of
the virtual table is randomized with the same offset as
the ROP gadgets. Therefore, such an attack can bypass
ASLR but not selfrando.
> We therefore conclude that selfrando can thwart most real-world exploits. Attackers can only succeed in
rare cases where they can disclose the complete heap
and data section.
selfrando github repo: https://github.com/immunant/selfrando feel free to open an issue or write us at team@immunant.com
cheers!