Clang 15 Lands Support To Randomize Structure Layout, Linux Prepares To Use It

[phoronix]

Phoronix: Clang 15 Lands Support To Randomize Structure Layout, Linux Prepares To Use It

In matching behavior already provided by the GCC compiler, LLVM/Clang has landed "RandStruct" functionality to allow optionally randomizing the structure layout for C code...

https://www.phoronix.com/scan.php?pa...nux-RandStruct

[rafanelli]

This feature is used for security reasons I suppose?

[mouacyk]

It's used to slow down really optimized structs.

[Raka555]

I can also see it breaking some debugging tools ...

[Raka555]

To me a more use full variant on that theme would be to rearrange the structs for optimal layout.
I know other compilers like rust do that already, but I am not aware that the C compilers or LLVM backend can do that.

[NobodyXu]

To me a more use full variant on that theme would be to rearrange the structs for optimal layout.
I know other compilers like rust do that already, but I am not aware that the C compilers or LLVM backend can do that.

Randomise struct layout is a security feature to make exploit hard, it's not to arrange struct for optimal layout.

[IndioNuvemChuva]

It's used to slow down really optimized structs.

I take it you like your exploits to run as fast as possible?

[pthariensflame]

And for what it's worth, rustc has this capability already, albeit unstable (-Zrandomize-layout and -Zrandom-seed). I wouldn't be surprised to see further integration there.

[Raka555]

Randomise struct layout is a security feature to make exploit hard, it's not to arrange struct for optimal layout.

I know that, but the actual protection versus breakage potential is not worth it in my eyes.
And what I meant is that if they are going to break things, I would rather see a size/speed benefit than a security benefit.

[coder]

I don't love it. It basically just introduces another potential source of ABI breakage. It means that all code, which is using a certain struct, has to be compiled with the same seed parameter. And heaven help you if you need to use two (or more!) different libraries that were each built with different seed parameters!

And for what benefit? The only point I can see is that they want to keep someone with the header file from having full access to a program's data structures. However, if you have the compiled code and know a bit about what it does, then you can still reverse-engineer the struct layouts. In other words, it's a false sense of security.

You see ideas like this, pretty often. Something that seems potentially valuable, but the downsides really outweigh the practical benefits. IMO, it should have been killed before ever getting implemented. But, once GCC did it, Clang pretty much had to.

I suppose the next logical thing is to randomize function parameters? Ugh. Pretend I didn't say that.