Linux 5.13 Lands Support For Randomizing Stack Offsets Per Syscall

[oiaohm]

The compiled binary has no notion of LP64/LLP64, since C types are erased. Assembly instructions have no notion of "long" or "long long" or even "pointer". It only matters in the source code when building for a given platform.

True but windows has always had a LP64 complier just you would not have been using the options to expose it.

Windows Services for UNIX<< The posix subsystem that then comes the base WSL1 work. cygwin gcc default build ing LP64 mode on windows was for not just better compatibility with the applications being ported but was to be competitive with the windows posix subsystem.

The reality Weasel here is it possible to produce source code that does not care if you are building with at LP64/LLP64 compiler yes it is just completely avoid using long.

Its is possible to make header files for windows that are for LP64 yes look at cygwin ones.

Is it possible to run gcc on Linux in LLP64 mode yes it is again. As I said LLP64 was in the Linux kernel for 2 particular versions with the X32 for bridging code.

Reason why different platforms outside windows used LLP64 is mostly compiler based or developer short cuts at the time.

Yes I am more than aware that assembly instructions have no notion of long or long long. But the reality is your complier on windows provided by Microsoft is not just at LLP64 complier. Just you would not be choosing to use the LP64 mode of it. Yes it caused some fun issue when people have read windows kernel leaked source and written documentation from it presuming LLP64 when that code is in fact LP64. Its important don't presume windows source is 100 percent LLP64 because that not even true inside Microsoft.

[Weasel]

True but windows has always had a LP64 complier just you would not have been using the options to expose it.

Windows Services for UNIX<< The posix subsystem that then comes the base WSL1 work. cygwin gcc default build ing LP64 mode on windows was for not just better compatibility with the applications being ported but was to be competitive with the windows posix subsystem.

The reality Weasel here is it possible to produce source code that does not care if you are building with at LP64/LLP64 compiler yes it is just completely avoid using long.

Of course it's possible, just avoid using long, or can even #define it (even though it's actually undefined by the spec, it works in practice, so who cares). That doesn't change the fact it's the only LLP64 platform for x86_64.

Personally, I just use the specific sized int types (e.g. int32_t, uint64_t, uintptr_t, size_t, etc). Targeting obscure architectures that have other sizes has a whole load of other problems, so who cares.

[Weasel]

You've already proved you're incompetent beyond a shadow of a doubt. Nice attempt at damage control, my low IQ friend.

Talking to yourself and posting pics of your mirror sounds like some mental problems to me.

The difference is, I code, you google.

[Weasel]

The difference is, I'm a world class expert and you're a delusional midwit.

You should go on Facebook and post your copy-pasted wisdom there. I heard it's THE place for self-proclaimed "experts" that look stuff up from google/wikipedia and are expert at it.

[Weasel]

You're so triggered because you know I outclass you.

You are literally posting memes in a programming topic. I don't think I need to explain to you into what type of category that puts you in.

[reba]

Could a mod please ban this idiot troll?

[piotrj3]

Performance over security was already not a good move with Intel CPUs...1% is not that much. One could argu if it should be enabled by default and then give the possibility to manually disabled it with kernel Boot parameters. Or the other way around.

The idea in security is to do neither. The system is secure simply if it doesn't have vulnerabilities. sandboxes, ASLRs and such things like this random stack offsets are almost always defeated by hackers in the end.

You know all those Intel technologies like SGX for theoretical security, but they one after another get deprecated and useless in the end.

Of course that is utopian dream for programmers just to write secure, so those stuff are simply made to made exploitation much harder.

[Zan Lynx]

The idea in security is to do neither. The system is secure simply if it doesn't have vulnerabilities. sandboxes, ASLRs and such things like this random stack offsets are almost always defeated by hackers in the end.

A virtual machine is a form of sandbox. They are not easily bypassed.

ASLR and other random factors are good for security because they make it very difficult to crack without setting off all kinds of alarms. Instead of an invisible worm program that can slide into a web application undetected, it becomes thousands of segmentation faults.

Security in real life and in computer systems is not just one thing. It has layers. Because that impenetrable outer wall may have a hole dug under it. So you add an inner layer of sentries and dogs walking the boundaries. They may not always be in position to catch intruders but they make it risky. Then you take all the labels off of the doors inside and put suspicious security guards behind a couple of them.

[oiaohm]

Then you take all the labels off of the doors inside and put suspicious security guards behind a couple of them.

I have seen worse in a building a door marked "Long Term Archives" always kept locked. Yep it was a door 4 stories up that lead to the outside of the building that opened in that was effectively out. Scary point it did result in a thief being dead and a stack of legal questions because it appeared as a man trap. The label on the door was kind of true that it was long term archives because a open top skip bin was generally bellow it and due to the business operational rules old records had to be destroyed and disposed of.... just this case the thief came the item disposed of.

Taking the labels off the door is one option putting valid but deceptive labels making thief take a wrong turn is another.