64btt cvsup?

Kris Kennaway kris at obsecurity.org
Thu Feb 26 14:08:20 PST 2004

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!
> > 
> > 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.
> 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.)
> 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?
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20040226/302e8dd5/attachment.bin

More information about the freebsd-sparc64 mailing list