What if any, are the security considerations of deciding to use an x64 vs x86 architecture?
EDIT: To be clear, this answer addresses the question of "Is it more secure to compile my app for 32-bit x86 vs x86-64?", and does not address the question of which hardware is more secure.
This is a partial duplicate of Do 64-bit applications have any security merits over 32-bit applications?, but broader and also that question is quite old.
In most ways, x64 is better. A few reasons:
size_tis 64 bits, it's far less likely that an integer overflow will occur due to addition or multiplication, which makes some common buffer overflow scenarios less likely.
- Because the actual amount of physical or virtual memory that can be allocated is much lower than
SIZE_T_MAX, some scenarios that might otherwise lead to overflows will instead lead to memory allocation failures, which are easier to detect. For example, if an attacker can instantiate an arbitrary number of 32-byte structs in a buffer based in the length of an input string, trying to get 0x0800 0001 of them will overflow a 32-bit
size_tbut not a 64-bit one while being a long (but not impossibly long) input, and 0x0800 0000 0000 0001 of them will overflow a 64-bit
size_tbut would also be an utterly impossibly long input.
- Because the address space is so much larger, higher-entropy ASLR can be used. With low-entropy ASLR, an attacker that can quickly try the same attack multiple times, or that can try attacking many victims at once, may succeed simply out of sheer luck. The smaller address space also sometimes limits what relocations are even possible for loaded libraries, which also impairs ASLR. This is the main aspect of the question linked above.
- Because 32-bit processes can only allocate (4GB-kernel reserved space) memory, a large but finite memory leak or expensive allocation can starve or crash them, where a 64-bit process would be fine (assuming there's enough physical RAM).
However, it's not all upside. One advantage of 32-bit processes is that a misbehaving one simply can't consume all available RAM on a modern system. I once found my PC running extremely slowly, and realized it was because a chat app had a remotely triggerable memory leak and had consumed all 32GB of RAM on my PC. While in this case it wasn't actually malicious, it was a sober reminder that a bug (or vuln, even if not usable for code execution) in single misbehaving app, running in the background, can severely impair the functioning of the whole computer. If the app had been 32-bit, it would only have been able to consume a few GB, and performance of the machine wouldn't have been meaningfully impacted at all.
However, the correct way to achieve this advantage is with limits and/or sandboxes. All major consumer and server OSes have ways to put limits on how many resources a process can consume, which are both more customizable than simply relying on the 32-bit limit, and can be applied to any program regardless of how it was compiled. Furthermore, sandboxing can reduce the impact of other vulnerabilities (or non-exploitable bugs).