Date: Thu, 26 Feb 2004 14:08:17 -0800 From: Kris Kennaway <kris@obsecurity.org> To: John Polstra <jdp@polstra.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: 64btt cvsup? Message-ID: <20040226220817.GA7995@xor.obsecurity.org> In-Reply-To: <XFMail.20040226140242.jdp@polstra.com> References: <20040226204702.GA8602@electra.cse.Buffalo.EDU> <XFMail.20040226140242.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 26, 2004 at 02:02:42PM -0800, John Polstra wrote: > On 26-Feb-2004 Ken Smith wrote: > > On Thu, Feb 26, 2004 at 12:20:33PM -0800, John Polstra wrote: > >> All of a sudden, without any warning, the time() call is likely to > >> start scribbling a 0 into either "a" or "b" -- or, worse yet, into > >> half of the return address or frame pointer. Who knows what the > >> symptoms of that will be? Will they be deterministic? Will they > >> cause ugly security vulnerabilities? Whee! > >=20 > > I think this is why we might be able to get away with not providing > > the compatibility stuff - this part isn't quite true. Users can't > > do a normal upgrade path (cvsup to -current, make buildworld/etc) > > and get to a 64-bit time_t system. If you try to do an upgrade through > > the normal path you break your machine at that point. To make it to > > a 64-bit time_t system without breaking your system you need to follow > > Garance's instructions and use his tools to do the upgrade. So there > > kinda is a warning. >=20 > OK, that's better than I thought. But what about old executables such > as installed ports? Remember, this thread got started because some > people thought old CVSup binaries worked, and some people thought they > didn't. (We still don't know.) >=20 > What happens to somebody who upgrades to a 64-bit time_t system and > then installs a binary package that was built back in the 32-bit > time_t days? >=20 > Lots of things can go wrong here. Note that there has just been a flag day in 5.2-CURRENT that required everyone to rebuild everything linked to libc_r (or take libmap countermeasures). Before that, in 5.1-CURRENT the change to fstatfs() required everyone to rebuild everything that called that function (with no workarounds available). The impact of this change is hardly unprecedented, and when discussed here there was strong consensus that we should just take the hit and do it now before 5.x-STABLE comes along and we lose the justification for breaking binary compatibility. Kris --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAPm5RWry0BWjoQKURAojnAJ41stafsCAW779Vb9kYUqWV4+F1xQCfVylC 2wHCwGBl2GFVBjqW3BJQxgw= =KDuR -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040226220817.GA7995>