[174735] in North American Network Operators' Group
Re: update
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Sun Sep 28 17:06:31 2014
X-Original-To: nanog@nanog.org
To: "Keith Medcalf" <kmedcalf@dessus.com>
In-Reply-To: Your message of "Sat, 27 Sep 2014 22:50:31 -0600."
<34c2578b1325d341ab62a856c7f40283@mail.dessus.com>
From: Valdis.Kletnieks@vt.edu
Date: Sun, 28 Sep 2014 17:06:01 -0400
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--==_Exmh_1411938361_2244P
Content-Type: text/plain; charset=us-ascii
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....
--==_Exmh_1411938361_2244P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Exmh version 2.5 07/13/2001
iQIVAwUBVCh4OQdmEQWDXROgAQILww/+KOIbuqmpaP/+/Dwc7YO8NL9UFKOUwDMJ
mNOWCssRLUd+DgwlEVLyts1iL2fQ+HZ1nOpC4OPhwawl4e58qs8xIgRw6kkKoG1O
ujP7Jlj5dfDfPHm/NcrUrtdQPQLdTFEkS2ESgqok2eNF/6AB11MAN/60kOwKr/zO
Cq51U/apopCjdh7rObWDGu4seZT9c8z4nAPChn4ZfmCU4AWLuWxcXCUaUtiE5QTM
Nt1Gz1UvHpZq2vfkDvHw4o6HToUs8sYYcMSIujH1SZAdw0RaOvU8i3tL+/LOjiPK
rIOGpf8YuK33oXJgx9y8HbOlPDZN7DciQ9gyc0/mqJ7u9yfEqJJtnOtoDu68SzBT
TduvpP8ydxIVaSHoO3+wKxBAn6D/6lvmBi+EjDj0RQl5DEY7JTm8w+ONUJFIN5ST
a8UPstSzoPD+sEIwz/4tOO/o3MM6dyNusmiWeCvpeDxenXYtywIVR80WAC7Gprv3
0u8vRTuAgkX09f305yqV5eMj5A1fKBQuKjOmiddMQadVZ6Rq4qWhEPTDcXM0xGm6
uM1jwW1aMH5M1Zlg8wjVBjvIWY/N9v2rxElzCKW2hQ12AOfEOdWC4rCKYNY+lklo
OqKmLVv6Oy1g/uuldcV2IX1mAZ3fFNYAKhNTLFcA9NNGr6fFMYPXDz6Z9i1Sbw3l
Q3rUQKIs9V0=
=HW8B
-----END PGP SIGNATURE-----
--==_Exmh_1411938361_2244P--
