2038 Yılı Problemi

Unix sistemlerde ki 2038 yılı problemi üzerine bir yazı:
http://mail.baskent.edu.tr/~20194562/y2k38.txt

Not: Yazıyı yazma amacım tamamen konunun ilginç gelmesi ve konu üzerinde daha fazla bilgi sunmak içindir. Y2K'daki gibi felaket tellallığı değildir.

Not2: Yinede gömülü (embedded) gömülü sistemlerde sorun yaşanabilir

Editörün Notu: Bu problem 2001'de 1 Ocak 1970'den bu yana (Unix'in doğumgünü) saniye sayısı 1 Milyarı vurduğunda da yaşanmış, Digitürk hizmeti o gece patlamıştı mesela ;)

Görüşler

anonim
21 yıl önce

link kırık

sceylani
21 yıl önce

Google cache''''den sayfanin icerigine baktim ve buraya alinti yapiyorum :

Time bug back again - 2038
by Hüseyin Uslu
raistlinthewiz@hotmail.com

17.02.2003
(nearly 35 years before the y2k38)

Introduction ........................................................... 1
The problem ............................................................ 2
A closer look on *Nix time ............................................. 3
Testing the problem .................................................... 4
Fixes? ................................................................. 5
Another Interesting Issue .............................................. 6
Resources .............................................................. 7
Notes .................................................................. 8

1 - Introduction y2k38 bug
----------------

Time is one of the most important things in our life. We use it everywhere;
In our daily life, and in data-critic applications. Most you reading this
document problably be aware of the Yeark 2K bug that was mostly used by media.
If media didn''''t show so interest on this y2k bug, probably only we the computer
geeks would be aware of it. But by media, anybody walking in the street knows
about it. Our topic in this paper is not the Y2k. But a similar problem that
we''''re approaching. From the topic you can see it''''ll occur in 2038. You can say
there is many years. Why now to think on it? This is a completely wrong idea.
Do you think that computer programmers wasn''''t aware of Y2K before? No, they knew
it but they thought like this: When time comes we can fix it. We saw the results:
A chaos happened. Software firms adding Y2K compatible label to their
products, some hardware cards for fixing, media saying our daily-life will crash.
You now that most of the crash, problems didn''''t occured. We''''re lucky.
But be sure that this doesn''''t mean we''''ll be luck with y2k38.

As you know there is many years before y2k38. But this paper''''s aim is to make
people informed about it and to make people start working on fixes. I''''ve already
read many articles on this topic. This paper will have the same ideas, my aim
is to make all ideas combined in one paper.

This paper contains ideas of mine other peoples (that wrote papers) on topic.
I''''m completely open to topic and wait for your ideas, topics, fixes.

2 - The Problem y2k38 bug
---------------

Here I''''ll discuss the problem first.
To understand the problem we must understand the unix timing. As most of you know
unix was here before 1970s. So when it was designed , designers had to gave it a
birth date for timing issues. The selected birth date was January 1 1970, 12:00:00
AM (GMT). All looks of OK up to now. In unix, there is a clock for measuring seconds
elapsed since the unix birth. This is a counter simply counting every seconds. By
kernel system calls and library functions this value is converted to Human Readable
Format. (For example February 17 2003, 13:54:04)

Problem arives here:
This seconds elapsed value, is a 32bit variable (32 bit signed). The largest value
it can handle is 2**31-1 = 2,147,483,647.
If we calculate the maximum time we can handle (since the unix birth) we''''ll see that
it''''s: January 19 2038, 03:14:07 (GMT) Tuesday.

What will be when time ticks 03:14:08 ?

Probably your *nix box will go to it''''s birth date:
- January 1 1970, 00:00:00 (GMT) Thursday
- Or December 13, 1901 20:45:52, Friday
- Or as some reports claims: December 32, 1969!

Maybe some machines will not be affected and we know that some unix vendors started
using 64bit signed time variables.With this time epoch it will be safe until December
4 4,292,277,026,596 C.E, 15:30:08 (GMT) Sunday. Which is a very very far future that
even we can not easily write it''''s date.

3 - A closer look on *Nix time y2k38 bug
------------------------------

In this section i''''ll try to get in deeper and try to inspect *nix code. I
selected Linux as our test & inspecting platform. I selected the 2.4.20 as kernel
version to inspect on. And for hardware specific thing, I chose the i386 as the platform.

For inspecting the code own: goto http://lxr.linux.no

Let''''s inspect the code:

in time.h, beginning with line 88 we can see:

88 struct timeval {
89 time_t tv_sec; /* seconds */
90 suseconds_t tv_usec; /* microseconds */
91 };

tv_sec is the seconds elapsed since birth time, and tv_usec provides the number
of miliseconds elapsed since the last second began. Now let''''s find what time_t is.

time_t appears in types.h line 69.

67 #ifndef _TIME_T
68 #define _TIME_T
69 typedef __kernel_time_t time_t;
70 #endif

let''''s go on witg __kernel_time_t :

__kernel_time_t appers in hardware specific files:
it''''s defined in:

include/asm-x86_64/posix_types.h, line 22
include/asm-ppc64/posix_types.h, line 37
include/asm-i386/posix_types.h, line 22
include/asm-mips/posix_types.h, line 29
include/asm-alpha/posix_types.h, line 23
include/asm-m68k/posix_types.h, line 22
include/asm-sparc/posix_types.h, line 13
include/asm-ppc/posix_types.h, line 24
include/asm-sparc64/posix_types.h, line 13
include/asm-arm/posix_types.h, line 34
include/asm-sh/posix_types.h, line 22
include/asm-ia64/posix_types.h, line 26
include/asm-mips64/posix_types.h, line 30
include/asm-s390/posix_types.h, line 30
include/asm-parisc/posix_types.h, line 26
include/asm-parisc/posix_types.h, line 31
include/asm-cris/posix_types.h, line 29
include/asm-s390x/posix_types.h, line 31

As we work on i386 platform, I''''ll work with include/asm-i386/posix_types.h.

include/asm-i386/posix_types.h, line 22 :

here it appears:

22 typedef long __kernel_time_t;

__kernel_time_t is a typedefed long.

As you can see here the problem arrives.

In i386 specific time.c file:

/*
266 * This version of gettimeofday has microsecond resolution
267 * and better than microsecond precision on fast x86 machines with TSC.
268 */
269 void do_gettimeofday(struct timeval *tv)
270 {
271 unsigned long flags;
272 unsigned long usec, sec;
273
274 read_lock_irqsave(&xtime_lock, flags);
275 usec = do_gettimeoffset();
276 {
277 unsigned long lost = jiffies - wall_jiffies;
278 if (lost)
279 usec += lost * (1000000 / HZ);
280 }
281 sec = xtime.tv_sec;
282 usec += xtime.tv_usec;
283 read_unlock_irqrestore(&xtime_lock, flags);
284
285 while (usec >= 1000000) {
286 usec -= 1000000;
287 sec++;
288 }
289
290 tv->tv_sec = sec;
291 tv->tv_usec = usec;
292 }

Here we can see the xtime.tv_sec appears as long integer.
do_gettimeofday is i386 specific implementation.

The general time.c appearing under /kernel contains the:

97 asmlinkage long sys_gettimeofday(struct timeval *tv, struct timezone *tz)
98 {
99 if (tv) {
100 struct timeval ktv;
101 do_gettimeofday(&ktv);
102 if (copy_to_user(tv, &ktv, sizeof(ktv)))
103 return -EFAULT;
104 }
105 if (tz) {
106 if (copy_to_user(tz, &sys_tz, sizeof(sys_tz)))
107 return -EFAULT;
108 }
109 return 0;
110 }

sys_gettimeofday system call function for user mode programs that requires time info.
This function calls the do_gettimeofday function. We see that timeval is used
everywhere and for i386 it''''s not safe.

And lastly the kernel code includes a notice about 2038 bug.
Here it''''s:

52 /* Converts Gregorian date to seconds since 1970-01-01 00:00:00.
53 * Assumes input in normal date format, i.e. 1980-12-31 23:59:59
54 * => year=1980, mon=12, day=31, hour=23, min=59, sec=59.
55 *
56 * [For the Julian calendar (which was used in Russia before 1917,
57 * Britain & colonies before 1752, anywhere else before 1582,
58 * and is still in use by some communities) leave out the
59 * -year/100+year/400 terms, and add 10.]
60 *
61 * This algorithm was first published by Gauss (I think).
62 *
63 * WARNING: this function will overflow on 2106-02-07 06:28:16 on
64 * machines were long is 32-bit! (However, as time_t is signed, we
65 * will already get problems at other places on 2038-01-19 03:14:08)
66 */
67 static inline unsigned long
68 mktime (unsigned int year, unsigned int mon,
69 unsigned int day, unsigned int hour,
70 unsigned int min, unsigned int sec)
71 {
72 if (0 >= (int) (mon -= 2)) { /* 1..12 -> 11,12,1..10 */
73 mon += 12; /* Puts Feb last since it has leap day */
74 year -= 1;
75 }
76
77 return (((
78 (unsigned long) (year/4 - year/100 + year/400 + 367*mon/12 + day) +
79 year*365 - 719499
80 )*24 + hour /* now have hours */
81 )*60 + min /* now have minutes */
82 )*60 + sec; /* finally seconds */
83 }

And in some sections of the code i found this text:

9 * Pad space is left for:
10 * - 64-bit time_t to solve y2038 problem
11 * - 2 miscellaneous 32-bit values
12 */

This means there is not a fix for the problem for now but at least some little work
is going on.

4 - Testing the problem y2k38 bug
-----------------------

Now the part comes: How we can test it.
While researching on topic i found some test codes.

test.pl - A test perl script
---- cut here -----

#!/usr/local/bin/perl

use POSIX;
$ENV{''''TZ''''} = GMT;

for ($clock = 2147483641; $clock

int main(void)
{
long clock;
for (clock=2147483641;clock<2147483651;clock++)
{
printf(%s ,ctime(&clock));
}

return 1;
}

---- cut here -----

Again i tested it within the same machine. Here is the output:

20194562@mail:~/2038bug$ ./y2k38
Tue Jan 19 05:14:01 2038

Tue Jan 19 05:14:02 2038

Tue Jan 19 05:14:03 2038

Tue Jan 19 05:14:04 2038

Tue Jan 19 05:14:05 2038

Tue Jan 19 05:14:06 2038

Tue Jan 19 05:14:07 2038

Fri Dec 13 22:42:48 1901

Fri Dec 13 22:42:49 1901

Fri Dec 13 22:42:50 1901

Here is the machine info:

20194562@mail:~/2038bug$ uname -a
Linux mail 2.4.16 #2 Tue Dec 4 14:47:43 EET 2001 i686 unknown

less /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 10
cpu MHz : 800.047
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat p
se36 mmx fxsr sse
bogomips : 1595.80

As we see this is a problemed box.

5 - Fixes? y2k38 bug
-----------------------

There are two type of fixes:

- Software fix
- Hardware fix

Software fix is using a data type that can handle bigger values. (For example windows
NT based system uses 64bit value). Or maybe using some other algorithms.

Hardware fix is using 64bit platforms that threats long values larger.

Here is Free Software Foundation''''s statement on topic:
This 32-bit count will overflow in 2038; but there will be no problem in that year,
because by then all systems will have redefined time_t to be a 64-bit integer.

What we can do now? We must force all *nix vendors to make the fix. Every seconds
ticks, we get closer to bug which is a really big Crash.

6 - Another Interesting Issue y2k38 bug
-----------------------------

Here is another interesting isssue:

timeval is used also within the schudeler. In the desicion of choosing correct
process to run timeval structure takes place in Linux. I''''ll make future works
on issue and try to make some cracking with process timers.

7 - Resources y2k38 bug
-------------

Here is some resources i used while writing this paper.

* Originally I read the issue from:
http://black.box.sk/articles/13/2038-time-bug.txt
I want to specially thank author of this article.

* Kernel Projects For Linux, Gary Nutt ISBN: 0-201-61243-7

* http://maul.deepsky.com/%7Emerovech/2038.html

* http://computer.howstuffworks.com/question75.htm

* http://www.gsp.com/2038/

* http://www.gnu.org/software/year2000.html

8 - Notes: y2k38 bug
----------

Ideas, fixes, discussions are welcome:
raistlinthewiz@hotmail.com

I''''m not a native English speaker. Sorry for and mistakes.

anonim
21 yıl önce

bazen mail.baskent.edu.tr sorun cıkariyor. su anda link calisiyor
/raistlinthewiz

Görüş belirtmek için giriş yapın...

İlgili Yazılar

14,000 PC Windows'dan LİNUX'a Geçiyor

malkocoglu
29 Mayıs 2003, 1 dakika okuma süresi

Münih belediyesi, Windows'dan vazgeçip, 14,000 makinasına Linux yükleyecek. Bu olay, masaüstü ortamda Linux'un yerini ispatlayan önemli bir gelişme.

http://www.desktoplinux.com/news/NS3199247984.html

Ücretsiz Linux CD Projesi

anonim
8 Eylül 2005, 1 dakika okuma süresi

Oktay Altunergil tarafından kurulan ve Jeremy Hise, David Ky ve Emre Sağlam tarafından destek verilen Ücretsiz Linux CD Projesi, isteyen herkese ücretsiz Linux CD'si ulaştırmayı amaçlayan bir oluşum.

HP, GNU/Linux Tabanlı Dizüstü Bilgisayar Piyasaya Sürecek

malkocoglu_2
6 Ağustos 2004, 1 dakika okuma süresi

Hewlett-Packard, SUSE Linux ile yüklenmiş olarak satılacak yeni bir dizüstü bilgisayarı çok yakında piyasalara duyuracak. HP'nin bu tür bir ürünü piyasaya süren ilk bilgisayar şirketi olduğu iddia edildi.

HP unveils Linux-based laptop

Linux 2.6´nın Harika Dünyası

FZ
21 Temmuz 2003, 1 dakika okuma süresi

Linux çekirdeği 1991 yılında Finlandiya´lı Linus Torvalds tarafından yüksek lisans projesi olarak başlatılmış, Minix benzeri bir işletimi sisteminin 80386 işlemcili PC´ler üzerinde çalışması hedeflenmişti. Linus´un bu proje için aklına gelen ilk isim Freax idi ve neyse ki bundan çok kısa sürede vazgeçti. Çekirdeğin ilk kararlı sürümü olan Linux 1.0, Mart 1994´te dünya kamuoyuna açık kodlu ve bedelsiz olarak sunuldu. O sırada resmen sadece i386 mimarisini ve tek işlemcili makinaları destekliyordu.

Sene 2003, yaklaşık 9 yıl sonra Linux 2.6 binlerce gönüllü ve çalışkan yazılım ve donanım uzmanının çabaları sonucunda yine kamuoyuna sunulmak üzere.

Paylaşmak istediğim bir anı

cayfer
8 Kasım 2002, 1 dakika okuma süresi

Dün akşam evde ilginç bir olay yaşadım: 14 yaşındaki küçük oğlum Murat sinirli bir şekilde odasından çıkıp "Yetti artık!" diye yanıma geldi. "Hayrola?" diyince "yarından başlayarak LINUX'a geçiyorum!" dedi. Nedenini sorunca "bu çakılmalardan, ikide bir reboot etmek zorunda kalmaktan ve virüslerden bıktım artık." yanıtını verdi. "Ama o zaman oyunlarını oynayamazsın" falan diyince "Abim benim sevdiğim oyunların hepsini halletmis, üstelik MSN, AIM hepsi varmış. MP3'ler için de çok iyi bir program varmış. Filim de seyrediliyormuş. Ödevlerimi de LINUX'un ofis programıyla yaparım" dedi ve makinasındaki önemli dosyalarını benim makinama yedeklemeye başladı. "Bi tek photoshop yokmuş, onu da kullanmayabilirim" diyince GIMP'ten söz ettim ve çok sevindi.

14 yaşında bir çocuk... Benden ve ağabeyinden etkilenmemiş olmasına olanak yok elbette ama hiç kimsenin zorlaması olmadan, bir akşam durup dururken odasından "Yeter artık..." diye fırlıyorsa MS ürünleriyle profesyonel iş yapmaya girişeceklerin bir kez daha düşünmesi gerekir gibime geliyor.