パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

極度にセキュアなOS」記事へのコメント

  • たぶんぜんぜんわかってないと思うので、遠慮がちに質問しますが、
    OS/400とかPalmOSとかと同じかんじだと思っていい?
    • by Anonymous Coward
      せんせー
      OS/400とPalmはまったく稼働環境が違うのれすが
      なにをいいたいのかよくわかりません。
      • by Anonymous Coward
        単一レベル記憶だってことだろ。なんか、このネタに関してはタレコミからコメントを書く奴まで、なんか全滅状態で悲惨だな。
        • by Anonymous Coward
          ええと、Linux を含む UNIX 系 OS も 1990年頃 (SunOS4) 以降は全て
          単一レベル記憶では?
          Apollo Domain も UNIX 系 OS に含めるなら、1980年代中盤からあり
          ますね。
          • by Anonymous Coward
            別ACですが、memory mapped file と混同していませんか。Multics や AS/400 は単一レベル記憶ですが、Mach や Unix などの memory mapped file を単一レベル記憶とは呼ばないと記憶しています。単一レベル記憶も memory mapped file の一種ですがより狭い概念では。
            • by Anonymous Coward
              AS/400 の人はそう主張しているかもしれませんが、一般論としては、アクセス可能なストレージを全てメモリで抽象化できれば single level storage の範疇に入ると考える方が普通ではないでしょうか? single level storage を、(Multics 以降で) 初期に実現したシステムとして、AS/400 の以外では Apollo Domain がよく引き合いに出されますが、Domain OS は、memory map するモデルですよね。

              固定長アドレ
              • by Anonymous Coward
                ストレージをメモリにマップするという時点でSLSじゃねーんだよ。
              • by Anonymous Coward
                > ストレージをメモリにマップするという時点でSLSじゃねーんだよ。

                あれ、それでは Domain OS は SLS ではないというご意見なんでしょうか?
                SLSという概念は、Multics発祥なわけですが、Multics の人々は [stratus.com]
                Domain OS が single level storage を実現していると言っている
                わけです
              • by Anonymous Coward
                わかってねーな。
                「マップする」という時点でシングルじゃねーの。
              • by Anonymous Coward
                > 「マップする」という時点でシングルじゃねーの。

                それは AS/400 的な誤解でしょう。
                Apollo Domain が single level storage を実装したシステムであるという定評と矛盾しますから。
              • by Anonymous Coward
                それはあんたの誤解だよ。
                Aegisは知らないが、MulticsにおいてはメモリはSLSのキャッシュにすぎないので「ある空間から別の空間にマップする」という概念はないの。
              • by Anonymous Coward on 2005年01月27日 23時06分 (#685344)
                > MulticsにおいてはメモリはSLSのキャッシュにすぎないので
                > ので「ある空間から別の空間にマップする」という概念はないの。

                Multicsのことは知っています。
                問題は、「ある空間から別の空間にマップする」という操作を要する
                ことが、SLS であるかどうかの判断基準になるかどうかという点ですが、
                Apollo の Aegis がその操作を要すにも関わらず、SLS であると
                Multics の人々から認められている以上、判断基準になると考えるのは
                誤りだと思います。

                > Aegisは知らないが

                Aegis ではオブジェクトアドレス空間が 128bit あるのに対し、
                当時の CPU の仮想メモリ空間は 32bit 以下だったので、
                マッピング操作が必要でした。

                なお、メモリがSLSのキャッシュであるという実装は、Multicsに限らず、
                Aegis も、SunOS4/SVR4/Solaris も同じです。
                親コメント
              • by Anonymous Coward
                だからさ、「ある空間から別の空間にマップする」と言った場合には、ある空間と別の空間の二つがあるわけで、それはSLSとは言わないんだよ。
                Multicsは同一のファイルは同一のセグメントに対応しているから単一レベルと言えるんだけど。

                >なお、
              • by Anonymous Coward
                > だからさ、「ある空間から別の空間にマップする」と言った場合には、ある
                > 空間と別の空間の二つがあるわけで、それはSLSとは言わないんだよ。

                話がループしてますが、もう一度引用しておきます。
                「ある空間から別の空間にマップする」操作を必要とするOS である [multicians.org]
                Apollo Domain の OS (Aegis) を、当の Multics の人々自身
              • by Anonymous Coward
                Aegisが「『ある空間から別の空間にマップする』操作を必要とするOS である」ことの説明がないよ。
                あんたの勘違いじゃねーの。
              • by Anonymous Coward on 2005年01月28日 0時46分 (#685389)
                > 説明がないよ。

                既に #685344 [srad.jp] で説明してます。
                Aegis はアドレスレジスタが 32ビットしかない MC68020 上で動作する OS でしたから、マッピング操作なしに 128bit のアドレス空間にアクセスすることは、ハードウェア的に不可能です。

                ms_$mapl() という関数名で検索すれば、Aegis で file mapping を行っているソースコードを今でも見つけられるようですよ。
                例えば ここ [sourceforge.net]とか、ここ [gnome.org]とか、ここ [koders.com]とか、ここ [netlib.org]とか。
                親コメント
              • by Anonymous Coward
                新参加のACですが。

                > Aegis ではオブジェクトアドレス空間が 128bit ある

                ここが重要ではないですか。
                単一レベル記憶では一つのリニアな抽象アドレス空間があって
                それを実CPUのアドレス空間にマップしているのです。
                実CPUのアドレス空間へのマップは単に実装の問題であって
                OSアーキテクチャではない。
                それに対してLinuxなど通常
              • by Anonymous Coward
                > Aegis はアドレスレジスタが 32ビットしかない MC68020 上で動作する OS でしたから、マッピング操作なしに 128bit のアドレス空間にアクセスすることは、ハードウェア的に不可能です。

                128bit仮想空間を32bitのメモリアドレス空間でキャッシュするのだから、ハードなりソフトなりでなんらかの仕掛けは必要だよ。

                イエスかノーで答
              • by Anonymous Coward
                > Aegisでは「すでにメモリにマップされているファイルをもう一度マップした
                > 場合に、同じアドレスが帰ってくるか?」

                いいえ、同じ仮想アドレスが返ってくるとは限りません。

                オブジェクト・アドレス空間の方が仮想アドレス空間よりずっと広いわけです
                から、もしも同じオブジェクトには同じ仮想アドレスが返ってくるとすると、
                たまたま同じ仮想アドレスにマップされるような異なるオブジェクトを 2つ
                同時にマッ
              • by Anonymous Coward
                > たまたま同じ仮想アドレスにマップされるような異なるオブジェクト
                MulticsのSLSではこれはそもそもありえない。
                あんたの言い分では、オブジェクトはメモリマップされる以前から割り付けられる仮想アドレスが一意に決まっていることになる。
                システム38ではまさにその通りだ。

                Multicsでは
              • by Anonymous Coward
                > 単一レベル記憶では一つのリニアな抽象アドレス空間があって
                > それを実CPUのアドレス空間にマップしているのです。

                Multics は SLS ですが、アドレス空間は「リニア」じゃないです。

                > それに対してLinuxなど通常のUNIX系OSではアーキテクチャで
                > ファイルとファイル内オフセットという2次元のアドレス空間
                > を扱います。

                Multics のアドレス空間も、ファイルを表すセグメント番号と
                そのセグメント内のオフセットの2次元で表します。

                > したがってファイルはリニアなアドレス空間を
                > 持つメモリとはモデルが異なり、そのアー
              • by Anonymous Coward
                > > たまたま同じ仮想アドレスにマップされるような異なるオブジェクト

                > MulticsのSLSではこれはそもそもありえない。

                え?
                私は、もし Apollo Domain が、「すでにメモリにマップされているファイルをもう一度マップした場合に、同じアドレスが返ってくる」とすると、どういう問題が生じるかを説明しているんですが。
                この文章の対象は、Multics ではなくて、Apollo Domain です。
                Multics の場合、こういう問題が生じないことは明らかです。説明するまでもありません。

                > あんたの言い分では、オブジェクトはメモリマップされる以前から割り付け
                > られる仮想アドレスが一意に決まっていることになる。

                いいえ違います。一意に決まっ
              • by Anonymous Coward
                > 5. ファイル A をマップする。ところが、ファイル A が以前使っていたアドレスは、

                ファイルAは一度アンマップされてるんだろ。質問の意味を取り違えるなよ。

                ファイルAをアンマップせずに再度マップしようとした場合にどうなるかを聞いてるんだよ。
                二度目のマップの試みで、最初のマップと異なるア
              • by Anonymous Coward
                > ファイルAをアンマップせずに再度マップしようとした場合にどうなるかを
                > 聞いてるんだよ。

                なるほど、元の質問を誤解していました。申し訳ない。
                答は同じく「いいえ」です。別々にマップされます。

                Apollo Domain は、UNIX の mmap() と同様、マップ時に copy-on-write 属性をつけたり、あるいは、読み書き保護のモードを変えてマップしたりすることができます。このためには、当然、同一のファイルを別々のアドレスにマップする能力が必要になります。
                このような機能は、ページング能力のあるハードウェアでは当たり前に実現できますが、もし AS/400 のように単一のアドレス
              • by Anonymous Coward
                > 答は同じく「いいえ」です。別々にマップされます。

                そうすると、メモリにマップされた時点でオブジェクトの同一性は
                なくなるのか。
                俺にはむしろこっちのほうが使いづらいと思う。

                copy on writeはコピーなので同一オブジェ

Stableって古いって意味だっけ? -- Debian初級

処理中...