Twice the bits, twice the trouble: vulnerabilities induced by migrating to 64-bit platforms
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?
Why don't you delete the codebase? That way is perfectly safe from outside attacks
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?
This is why you need to get intimate with your memory model. Lay it down, caress its every facet, invite its friend CLR (I may be C# biased *cough*), and explore every desire it has. Does it want long? Oh my, that's two 32-bit writes. It may not be atomic, but it will excite you to no end. Is the CLR packing that sweet 64-bit back-end? Mmm baby, atomic all the way. Do you know how to please your environment? I don't think so. Compiler getting ALL up in your business re-arranging those sexy reads and writes? Lock that motha down. Interlock with her every need and you will never go wanting. If the memory is mis-aligned it's your doing and you need to manually adjust for that. Kappa /r/jesuschristreddit deuces :thumbsup:
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?
This is why you need to get intimate with your memory model. Lay it down, caress its every facet, invite its friend CLR (I may be C# biased *cough*), and explore every desire it has. Does it want long? Oh my, that's two 32-bit writes. It may not be atomic, but it will excite you to no end. Is the CLR packing that sweet 64-bit back-end? Mmm, atomic all the way. Do you know how to please your environment? I don't think so. Compiler getting ALL up in your business re-arranging those reads and writes? Lock that motha down. Interlock with her every need and you will never go wanting. If the memory is mis-aligned it's your doing and you need to manually adjust for that. Kappa :thumbsup:
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?
This is why you need to get in touch with your memory model. Lay it down, caress its every facet, invite its friend CLR (I may be C# biased *cough*), and explore every desire it has. Does it want long? Oh my, that's two 32-bit writes. It may not be atomic. Is the CLR packing that sweet 64-bit back-end? Mmm, atomic all the way even though the C# specification doesn't guarantee that. Compiler getting ALL up in your business re-arranging those reads and writes? Lock that motha down. Interlock with its every need and you will never go wanting. If the memory is mis-aligned it's your doing and you need to manually adjust for that. Kappa :thumbsup:
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?
This is why you need to get in touch with your memory model. Lay it down, caress its every facet, invite its friend CLR (I may be C# biased *cough*), and explore every desire it has. Does it want long? Oh my, that's two 32-bit writes. It may not be atomic. Is the CLR packing that sweet 64-bit back-end? Mmm, atomic all the way even though the C# specification doesn't guarantee that. Compiler getting ALL up in your business re-arranging those reads and writes? Lock that thing down. Interlock with its every need and you will never go wanting. If the memory is mis-aligned it's your doing and you need to manually adjust for that. Kappa :thumbsup:
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?
This is why you need to get in touch with your memory model. Lay it down, caress its every facet, invite its friend CLR (I may be C# biased), and explore every desire it has. Does it want long? Oh my, that's two 32-bit writes. It may not be atomic. Is the CLR packing that sweet 64-bit back-end? Atomic all the way even though the C# specification doesn't guarantee that. Compiler getting ALL up in your business re-arranging those reads and writes? Lock that thing down. Interlock with its every need and you will never go wanting. If the memory is mis-aligned it's your doing and you need to manually adjust for that. Kappa :thumbsup:
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?
But, don't you get twice the amount of work done for half the price ? :confused:
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?
The music's more catchy in 8-bits, too. (Anyone not humming an 8-bit game tune by now obviously hasn't lived)
I wanna be a eunuchs developer! Pass me a bread knife!
-
In this study, Wressnegger et al. reveal how a codebase originally written for 32-bit, and which is perfectly secure on 32-bit platforms, can have new vulnerabilities simply by compiling it for 64-bit systems.
That's why I compile everything for 8-bits
Maybe I should switch to 4? That would be more secure, right?