Address Space Layout Randomization Considered Harmful

http://lj.rossia.org/users/sadkov/483700.html

Russia cornsidered harmful.

wow nikita your're really are a bydlo brainlet. you should stop talking about things you know nothing about.

One reason for the slowdown is that modern operating systems enforce the so called ASLR

ASLR on Linux has 0.01% impact on performance. after all, it is fairly simple: just calculate jump address instead of hardcoding it (wow, addition, such slowness) http://pages.cs.wisc.edu/~riccardo/736finalpaper.pdf

to mitigate superficial security flaws that could be inside software

it mitigates pretty serious flaws - it makes it more difficult to use ROP/ret2libc techniques when exploiting buffer overflows (and this is what was used for exploiting them after they added non-executable stack to prevent hackers from just putting shellcode on stack and jumping there). in many cases, it makes them unexploitable without an additional infoleak vuln.

There is no way to opt-out from ASLR today

that is simply not true. first of all, ASLR cannot work on non-positionally independent code - so just compiling it while forcing PIC/PIE flags to false is enough to make your're are executable non-ASLR. second of all, you can globally turn off ASLR, at least on Linux:
echo 0 > /proc/sys/kernel/randomize_va_space
all programs started after that won't have ASLR

Additionally, compiler loses the way to use profiler statistics for optimizations, since profiler address space will now be different from the runtime one.

this just isn't true. if you have debug symbols, you can just find the data you need by reading relocation table, all the debuggers know how to do it.

It is also funny how developers silently accept all these training wheels attached to their otherwise lightning fast mountain bike. "Those who sacrifice liberty for security deserve neither."

the same could be said about using a garbage-collected language like Lisp. are you turning into C*dder?

>>3
Now all code is actually position independent. That is now enforced by operating systems and compilers. There is no way to opt-out. All code is force-compiled with PIE, and -no-pic/-no-pie flag is being ignored, as part of this ASLR excuse. The reason for that is to slow down formerly fast apps and sell newer hardware, under the guise of increased security. That is completely irrational, because now large memory sizes allow us to get rid of the hell of dynamic linking at all, compiling all apps statically.

Same happened before, when people silently accepted real mode and other freedoms being taking away. And I mind you, MMU incurs heavy slowdown, due to context switches and address translation latency. You won't find MMU in performance critical systems, like those used by scientists to sample physics experiments.

You don't complain, because you don't even know that your code is being handicapped by all these training wheels. What can I say? Enjoy 2 times slower software with their PIC now! Even more, with the advent of LLVM, soon there will be enforced JIT (managed code), with no access to x86 inline assembly, which will further slowdown any C/C++ code. "Those who sacrifice liberty for security deserve neither."


I repeat: nobody needs security on a gaming machine. It should be an option, not a death sentence.

>>3

the same could be said about using a garbage-collected language like Lisp

My lisp dialect, Symta, has no garbage collection, so it is at least predictable and can be easily interfaced with C/C++.

>>3

ASLR on Linux has 0.01% impact on performance. after all, it is fairly simple: just calculate jump address instead of hardcoding it (wow, addition, such slowness) http://pages.cs.wisc.edu/~riccardo/736finalpaper.pdf

If you calculate inside a tight loop, setting pixels in frame buffer, that would be two times slowdown, because now instead of just copying pixel, you will also have to do addition and waste a register to keep pointer.

take your're are meds and make your're are game

>>7
get mad, security scum

>>8
the only person getting mad is you. security people are actually treated seriously, and OS vendors listen to them by enabling ASLR. you, on the other hand, get banned everywhere you poast and are mostly known for killing hamsters

>>9

security people are actually treated seriously

By whom? I've a gaming PC, and I don't need any dirty security bums and gypsies near it.

by professional dub-checkers

>>11

by professional dub-checkers

Honey, don't. Don't say you dub when you don't, don't say you do when you dub.

Nikita is right this time. Dependent types would have provided real security without the need for ASLR and other crap.

>>13
Is that you Nikita?

>>14
no, it's the anus who thinks dependent types will give him a gf

>>1
ASLR is pure insecurity through obscurity. ASLR does not eliminate any bugs, it's designed to make some exploits of existing bugs slightly more difficult, which also makes tests more difficult. The behavior of your code may be different each time it runs! It does nothing to improve software correctness. Programs will still corrupt other data by writing out of bounds. ASLR only exists because Ctards don't want to check array bounds. Ctard compiler monkeys and Ctard code monkeys point fingers at each other over who should check array bounds, so nobody does it.

>>4
All programs on x86 are already position independent because of segmentation. Ctards want to LARP as PDP-11 hackers so they don't use it.

>>16
From the security standpoint, the problem is that ASLR don't prevents any of these bugs being exploited, just changes method of exploitation slightly. Even worse, it makes people feeling safe, so they stop checking their code bugs.

From the performance standpoint, ASLR don forces all code to be compiled as PIC, which incurs slowdown, and it adds additional slowdown on top of PIC.

From corporate standpoint, it ASLR is a step towards transitioning to completely managed code, which would help further securing their walled gardens.

For CPU producers it helps selling new ASLR ready hardware, so they will be the first to pitch that idea.

>>17
How do we fix this, RISCV is made up of ARM exEmployees

>>18
Dependent types

depend my anus

>>19
What's your VHDL or IEEE 1364?

post number randomization would prevent easy acquisition of dubs

>>18

RISCV

It is not x86. Nobody needs it, beside a few microcontoller companies.

Aumntistic

>>24
anustistic

>>25
How to lear r

>>25
How to learn r programming languafe for data

>>23
Who needs x86?

>>28
legacy software

>>28
0x7000-0x7200 does.

>>29
Why do you need legacy?
>>30
Why do you need that address space?

>>29
Recompile it

>>31
0x7c00

>>32
Recompiling x86 inline assembly?

Dynamic linking is pointless, twas invented when space was expensive.

ASLR is pointless.

All of this security stuff is just pointless,

TempleOS flat rwx memory space is the way forward, he was a genious.

"microarchitectural data sampling vulns" FACK OOOPH

Glowers with 0dai having rwx as they please, we're locked in a prison.

Let's not pretend anything is safe, rwx all the things. The temple calls us.

>>35
Dynamic linking is useful for plugins and similar incremental compilation, when people want to develop in different languages or want to keep codebases clean. But that is all to it. The idea of sharing single version of DLL between unrelated programs is deeply flawed in 21st century and leads to DLL hell.

>>35

TempleOS flat rwx memory space is the way forward, he was a genious.

It should still include sanboxing for developer builds and apps deemed buggy. But stable apps should run in kernel space, without any context switches and training wheels.

>>37
there is no such thing as a stable app, their're are all shit

>>37
Sandbox is security, security is pointless. If you write/run bad code or too much code you should be punished.

Yes yes, fuck protection rings, esp the glower signed ones. All major OS's don't even use all of them so WHY are they there? False sense of safety. 1970s unix mainframe malarky.

>>39
Most of this is because of the insecurity industry which keeps scaring idiot CIOs and businesses in general in order to sell more crap.

>>39
Sandboxing helps debugging.

>>41
I prefer the beach.