OS X / macOSのバージョンは2038年問題に対して脆弱ですか？

2000年ごろ、Apple は 1984年以降のすべてのMacがY2K問題を回避し、今後数千年の日付を処理できるプレスリリースを作成しました。

良いニュースは、1984年の導入以来、Macintoshコンピューターは2000年に移行できることです。実際、Mac OSおよびほとんどのMacアプリケーションは、29,940年まで内部で生成された日付を正しく処理できます。

この声明は、Mac OS 9が最新のオペレーティングシステムであったときに作成されました。

それ以来、OS X（現在はmacOSと呼ばれています）は、Unixから派生した主要なオペレーティングシステムです。これは、どのバージョンも2038年問題（Unixのようなシステムに影響するY2K問題に匹敵する問題）に対して脆弱であることを意味しますか？または、Appleが29,940年と互換性があることについて述べた声明はまだ当てはまりますか？

OS X 10.6 "Snow Leopard"より前のすべてのバージョンには、2038年の問題があります。10.6のほとんどのインストールと10.7 "Lion"のすべてのインストールにより、問題の主な原因が修正されました。ほとんどなくなっていますが、2038年のバグはいくつかのアプリで生き残るかもしれません。

私の古いPowerPC MacはOS X 10.4.11「Tiger」を実行しています。システム環境設定の日付と時刻に行き、2038年以降の日付を入力しようとしましたが、2037年12月31日に日付をリセットしました。2038年に何かが間違っていることがわかりました。

OS Xは、BSD経由でUnixから派生しています。OS X用アプリは、ファイルを開いたりインターネットに接続したりするためにBSDシステムコールを使用します。BSDには長い歴史があり、そのシステムコールの一部は1980年代からのものです。そのシステムコールの1つはgettimeofday()、4.1cBSDで初めて登場しました。UC Berkeley は、2038年の半世紀以上前の1982年に4.1cBSDをリリースしました。時間gettimeofday()はの整数ですtime_t。秒をカウントします。ゼロは、1970-01-01 00:00:00 UTCのUnixエポックです。

私の古いPowerPC Macではtime_t、符号付き32ビット整数です。これにより、2038年の問題が発生します。署名された32ビットtime_tの範囲は-2147483648〜2147483647です。これは、1901-12-13 20:45:52 UTC〜2038-01-19 03:14:07 UTCの時間しか保持できません。これがオーバーフローすると、gettimeofday()2038年1月19日月曜日から1901年12月13日金曜日に日付が反転します。

修正は、32ビットtime_tから64 ビットに移行することですtime_t。OS Xの場合、この移行は32ビットポインターから64ビットポインターへの別の移行とともに発生しましたが、64ビットポインターには64ビットプロセッサが必要です。Appleはtime_t、64ビットプロセッサ用に64 ビットのみを提供しています。32ビットプロセッサが64ビットを処理することは可能ですtime_tが、Appleはその機能を提供しませんでした。

Appleのコンパイラは、OS X 10.0 "Cheetah"（time_t32ビットおよびoff_t64ビット）以来、32ビットプロセッサで64ビット整数をサポートしています。UnixおよびBSDではoff_t、ファイルまたはディスク全体のサイズです。32ビットでoff_tは、OS Xは2 GiB未満のディスクに制限されます。Apple off_tは64ビットと定義したため、OS Xはより大きなディスクで動作しました。Apple time_tは10.0で32ビットと定義したため、time_t後で64ビットへの移行が必要になりました。

私の古いPowerPC Macでは、ヘッダーファイル<ppc/_types.h>は__darwin_time_tとして定義されていlongます。Intel Macの場合、ヘッダー<i386/_types.h>は同じことを行います。OS Xではlong、ポインターと同じサイズになります。したがって、ポインターが64ビットになり、64ビットにlongもなり、64ビットにもなりtime_t、2038年問題の主な原因が修正されました。

Appleの64ビット移行ガイドには、「OS X v10.6より前は、オペレーティングシステムに同梱されていたアプリケーションはすべて32ビットアプリケーションでした。v10.6以降、オペレーティングシステムに同梱されているアプリケーションは一般に64ビットアプリケーションです。 」ウィキペディアから、10.6にはIntelプロセッサが必要であり、10.7には64ビットIntelプロセッサが必要であることを知っています。32ビットIntelプロセッサで10.6を実行しているMacには、32ビットアプリが必要でした。私は、10.6を実行しているほとんどのMacと10.7を実行しているすべてのMacには、64ビットポインターと64ビットの64ビットアプリがあると結論付けていますtime_t。Appleは2038年1月よりかなり前の2011年に10.7をリリースしました。

64ビットtime_tでは、2038年のバグはほとんどなくなりましたが、いくつかのアプリで存続する可能性があります。古い32ビットアプリは、新しいシステムでも実行される可能性があります。また、64ビットアプリにはコーディングの誤りや古いデザインが含まれている可能性があり、64ビットtime_tから32ビットに変換される可能性があります。これは、macOSだけでなく、すべてのシステムの問題です。

マッハ時間もあります。OS Xのカーネルは、BSDとMachを組み合わせています。ほとんどのアプリはを使用してBSDから時間を取得しますが、BSDをgettimeofday()回ってMachから時間を取得する方法があります。これはさらに困難です。プログラムはmach_host_self()、ホストポートを取得するために呼び出し、次にhost_get_clock_service()を取得しCALENDAR_CLOCK、最後にを取得しclock_get_time()ます。

10.4 "Tiger"を実行している私の古いMacでは<mach/clock_types.h>、時間をunsigned int（内部struct mach_timespec）として宣言しています。これは、0〜4294967295の範囲で、1970-01-01 00:00:00 UTC〜2106-02-07 06:28:15 UTCの範囲の符号なし32ビット整数です。これは、2038年問題を2106年問題に交換します。29,940年には到達できません。

host_get_clock_service()Appleが時間を取得するためのより高速な方法を提供していたため、10.0 "Cheetah"から廃止されたと思われます。これらはgettimeofday()カレンダー時間用のBSD でありmach_absolute_time()、単調時間用のAppleのものでした。gettimeofday()2106ではなく、2038年に問題を置くことを好みます。

エルキャピタンは影響を受けません：

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++)
{
print ctime($clock);
}

このperlスクリプトは、以下の出力を提供します。

Family-iMac:~ dude$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G1004
Family-iMac:~ dude$ /Users/dude/Desktop/2038.pl 
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

この非常に興味深いサイトから情報が収集され、スクリプトが圧縮されて骨組みになりました。

さて、El Capitan 10.11.6に関する限り、答えはPerlスクリプトを使用するほど簡単ではありません。

これを試すと

macmladen@buk $ touch -t 205012121212 my
macmladen@buk $ ls -al
total 104
drwx------  7 root root    4096 Dec 25 13:42 .
drwxr-xr-x 23 root root    4096 Dec  4 17:06 ..
-rw-r--r--  1 root root       0 Dec 12  2050 my

したがって、macOSが最も低いことを証明し、システム層は Y2038のバグから安全です。つまり、システム自体に障害は発生せず、正常に動作します。

ただし、アプリケーションレベルでは、常にそうとは限りません。

日付を2040にプッシュしようとすると、システム設定の日付と時刻は2038年1月1日に設定して応答しました（自動的に設定をオフにする必要があります）

つまり、アプリケーションに応じて、Y2038のバグにどのように対応するかが決まります。