"What causes #Ruby memory bloat?"
@gargron The answer is "using Ruby", obviously!
@keithzg The answer is malloc's overallocation default due to RedHat's preferences and malloc's failure to return free empty heaps as a performance precaution
This is why you don't get memory issues when using jemalloc instead of glibc's malloc
And jemalloc is starting to become friendlier to ASLR. So jemalloc + HardenedBSD = I'm in love!
I would like to see #OpenBSD's malloc imported in HardenedBSD along with Daniel Micay's HardenedMalloc.
@lattera @brnrd @pertho @saper @Gargron @keithzg ASLR is what we call in french « usine à gaz », is an outdated concept, and not even fully protecting against ROP. Like canaries & NX bit in PMMU don’t protect 100% against stack and buffer overflows. I have found a simple 100% operationnal solution stopping these 3 problems just by slitghly modifying any microprocessor architecture. I also consider PMMU a outdated concept.
PaX ASLR and PaX NOEXEC changed forever how exploits are written. Now you must chain multiple vulnerabilities together to gain code execution. They can fully kill certain vulnerabilities and attackers must now pay much closer attention to both control and data flow.
The overarching goal of security is to raise the economic cost of a successful and reliable attack.
PaX ASLR and PaX NOExEC do that and with minuscule overhead on the part of the defender.
So, I wouldn't even come close to saying ASLR is an outdated concept.
Those who claim "ASLR is dead!" either:
1. Don't understand just how much ASLR (and its companion, NOEXEC) have changed exploitation.
2. Have an ulterior motive, a snakeoil sales pitch.
3. Don't actively do exploit dev.
4. Have bought the false narratives of university researchers simply looking for more grant money.
5. Don't fully understand what ASLR is meant to protect against.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!