"Don’t Set Your iPhone Back to 1970, No Matter What" http://www.wired.com/2016/02/dont-set-your-iphone-back-to-1970-no-matter-wha... @dashdashado
The bug reportedly affects only 64-bit platforms. Perhaps some part of the OS X boot process naively iterates from time stamps starting from 1970 up through "now", and treats 1969-12-31 UTC as a very large (perhaps unsigned) time stamp. On a 32-bit platform there are only 4 billion time stamps or so, so even a naive approach could work in a reasonable amount of time; a 64-bit platform, though, would have about 4 billion times more work to do, and users understandably don't want to wait that long. If we were designing POSIX from scratch, perhaps we could let (time_t)0 denote the Big Bang. Then, iPhone users would need to set the date to ~13,798,000,000 BCE to expose the bug. Nobody would have the patience to do that, since the UI forces them to scroll back year-by-year to the desired date. Problem solved!
On Feb 12, 2016, at 7:28 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
The bug reportedly affects only 64-bit platforms. Perhaps some part of the OS X boot process naively iterates from time stamps starting from 1970 up through "now", and treats 1969-12-31 UTC as a very large (perhaps unsigned) time stamp.
$ egrep 'typedef.*clock_sec_t' xnu-3247.1.106/osfmk/kern/clock.h typedef unsigned long clock_sec_t; typedef uint32_t clock_sec_t; $ egrep 'typedef.*time_t' xnu-3247.1.106/bsd/i386/_types.h typedef long __darwin_time_t; /* time() */ Signed? Unsigned? Depends on what your code is including and how it's handling times; signed at the UNIX layer, but if you dive down into the bits of Mach that underlie some of the UNIX bits....
On 2016-02-12 20:28, Paul Eggert wrote:
The bug reportedly affects only 64-bit platforms. Perhaps some part of the OS X boot process naively iterates from time stamps starting from 1970 up through "now", and treats 1969-12-31 UTC as a very large (perhaps unsigned) time stamp. On a 32-bit platform there are only 4 billion time stamps or so, so even a naive approach could work in a reasonable amount of time; a 64-bit platform, though, would have about 4 billion times more work to do, and users understandably don't want to wait that long. If we were designing POSIX from scratch, perhaps we could let (time_t)0 denote the Big Bang. Then, iPhone users would need to set the date to ~13,798,000,000 BCE to expose the bug. Nobody would have the patience to do that, since the UI forces them to scroll back year-by-year to the desired date. Problem solved!
Specifying mktime(3) result (time_t)-1 as the error flag where time_t is signed always struck me as a nasty discontinuity on the day before the Unix epoch. Specifying either INT_MAX or UINT_MAX depending on the signedness, and maybe a nice symbol like E_TIME_T, would have reduced the range by all of a second, but also reduced the chances of these naive bugs having much impact, as that big blob of UPPERCASE could act as a clue stick, whereas -1 can be missed on a quick scan. For time(3) result (time_t)-1 meaning time is unavailable is reasonable, but again {,U}INT_MAX could also have been used for consistency. The C and POSIX standards still have a few of these cases where magic numbers are not defined as symbols lurking in their dark corners. Either programmers have to define their own symbols, each differently, or specify a constant, and maybe also a comment, if their maintainers are lucky! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Most likely hypothesis is that someone wrote if ((t = time(NULL)) < 0) ... https://news.ycombinator.com/item?id=11095740 Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Fisher, German Bight, Humber, Thames, Dover, Wight: North or northeast 5 to 7, occasionally gale 8 at first in Thames and Dover, becoming variable 4 later. Moderate or rough. Wintry showers, becoming mainly fair. Good, occasionally poor.
On Feb 15, 2016, at 3:16 AM, Tony Finch <dot@dotat.at> wrote:
Somebody should inform Mr. or Ms. fpgaminer that there's a Mach layer below the BSD layer, and it uses *unsigned* seconds and microseconds, so that he or she understands why statements such as "... iOS likely is _not_ using u64. It's a BSD derivative, so it's using time_t, which is signed." are based on an incorrect assumption.
On 2016-02-15 04:43, Guy Harris wrote:
On Feb 15, 2016, at 3:16 AM, Tony Finch <dot@dotat.at> wrote:
https://news.ycombinator.com/item?id=11095740 Somebody should inform Mr. or Ms. fpgaminer that there's a Mach layer below the BSD layer, and it uses *unsigned* seconds and microseconds, so that he or she understands why statements such as "... iOS likely is _not_ using u64. It's a BSD derivative, so it's using time_t, which is signed." are based on an incorrect assumption.
I would hope by now that Mach is using POSIX standard struct timespec in ns rather than still using the old struct timeval in us. I can appreciate why OS internals would prefer unsigned times, but many(/most/all?) hosted libraries use signed time_t so apps can easily use times before the epoch. Given that the standard error value is -1, it is not unreasonably naive to conclude that time_t is intended to be signed, and libc variants using GCC normally define time_t as signed. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On Feb 15, 2016, at 5:34 AM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
I would hope by now that Mach is using POSIX standard struct timespec in ns rather than still using the old struct timeval in us.
The version of Mach inside XNU isn't using either one at the lowest level. It's using a uint64_t with platform-dependent units. (It looks as if the units are nanoseconds on x86; I don't know what they are on ARM.) That value can be converted to unsigned-seconds-and-unsigned-microseconds with absolutetime_to_microtime(), or to nanoseconds-since-the-Epoch with absolutetime_to_nanoseconds(). Inside the "BSD" part of the kernel, struct timeval, with a signed time_t for seconds, is still used in some places.
participants (5)
-
Arthur David Olson -
Brian Inglis -
Guy Harris -
Paul Eggert -
Tony Finch