On Sat, 27 Sep 2014 22:50:31 -0600, "Keith Medcalf" said:
If you had been rational about the change to from x86 -> x64 and 32-bit userland to 64-bit userland, you would have limited all processes to the same per-process address space as they had in the x86 model in order to prevent the introduction of vulnerabilities such as this, and only permitted larger address spaces for processes that required them (ie, were part of the justification for making the change).
If security was *that* easy, we'd all be good at it. First off, security never lives in a vacuum - it gets to trade off with other concerns, like performance and usability. There are workloads where the fact that x86_64 uses wider variables and thus more memory bandwidth is outweighed by the fact that the increased number of effectively usable registers drastically reduces the number of memory accesses needed. So it's not just about address space. Secondly, if you convert everything to the x64_64 model rather than keeping *two* sets of ABI around, you've just halved your attack surface, and reduced the number of ways you can accidentally mess yourself up by updating the 64-bit library and missing the 32-bit one (or vice versa). And if you've just eaten, I suggest you *not* look at the mess involved in making sure that things like ioctls pass the same structure to the kernel whether they're calling from a 32 bit or a 64 bit binary. So there's a case to be made that if even only *some* of your code needs 64-bit mode, you should cut it *all* over....