update

Sun Sep 28 21:06:01 UTC 2014

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....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140928/b19ea527/attachment.sig>