[klodolph]

Linux has had this a little longer, since 2005 or so:

https://en.wikipedia.org/wiki/Address_space_layout_randomiza...

However, even if the “heap is randomized”, that typically just means that the underlying blocks of memory (e.g. what mmap returns) have randomized virtual addresses. The allocator you use will still have to carve up those blocks from the OS—your kernel does not provide malloc(), after all.

[bennofs]

Userland heap randomization on windows is something different than ASLR. Windows 10 actually randomizes heap layout, not just the offset, by filling larger chunks in random order. So even offsets between allocations don't stay constant.

[kzrdude]

Why doesn't Linux do that, it's kind of an obvious next step?

[ChuckNorris89]

Because the Linux of today is not the product of a company or person with a focused vision but a conglomerate of devs from various foundations or corporations, each with their own agenda. A lot of things may seem "obvious" but depending who's at the helm, other stuff gets prioritized.

I remember, way back when, in college, when I would try to listen to music while my machine was torrenting a movie on the same HDD, the playback of the song would get totally borked because the queuing scheme of the linux I/O scheduler at that time could not cope with this(it was tuned for server operations) even though both Windows and MacOS could handle this scenario without a sweat since like forever.

IIRC BFQ scheduler finally addressed this later but I'm not 100% sure on this info.

[tester34]

What's the goal of the ASLR when software still can workaround it like e.g game cheats that "just" calculate those addresses?

[wyldfire]

ASLR is part of a larger suite of bar-raising security mechanisms [1]

[1] https://en.wikipedia.org/wiki/Defense_in_depth_(computing)

[resoluteteeth]

Once you can execute arbitrary code it's easy to figure out. The point is that it makes it harder to get a vulnerability to the point where it executes arbitrary code in the first place.

[Plutoberth]

We're talking about different security models. Whereas anti-cheat companies seek to prevent code execution or introspection in a certain context (the game) by a user that already has full privileges over the machine, other mitigations seek to prevent privilege escalation or initial access. For example (simplification), a remote exploit that relies on a specific address to work would now have to find an additional information leak. Similarly, code running in usermode cannot simply* know the addresses of objects in the kernel.

* In practice this isn't really true, and there are many ways to bypass KASLR

[jacobush]

Maybe it should.

[im3w1l]

I think the current design comes from the fact that calling the kernel is expensive so it's best not to do it too often.

Maybe with the new ways of interacting with the kernel, like io_uring it can be cheaper.

[scatters]

Perhaps it could be provided by a vDSO, that would then decide if and when to call into the kernel proper.

[pritambaral]

Well, io_uring is cheaper (significantly!) precisely because its for async operations, which can be pipelined. Application logic almost never uses malloc() in asynchronous, pipelineable fashion.

[jacobush]

I’d argue that’s exactly what happens, especially during object initialisation in C++.

[asveikau]

Editing page mappings is also expensive. I think regardless of the mechanism by which the kernel hands out pages, you will pay that cost.

[jacobush]

Still, it would eliminate a whole class of bugs, even with insecure languages such as C.

[tsimionescu]

It may eliminate a whole class of vulnerabilities, not bugs - the bugs would still be there (the program would not behave as expected), but they may not be usable anymore for arbitrary code execution or data smuggling.

[jacobush]

True. Still, it should be easier to find and fix the problem if triggering the makes the program reliably terminate.