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

人為的メモリエラーでJava/.NET仮想マシンを攻撃」記事へのコメント

  • by Anonymous Coward on 2003年05月23日 1時09分 (#321277)
    光に限らず、何らかのエネルギーを加えればメモリー上のデータが
    化ける可能性はあります。
    しかし、メモリー上でデータが化ける事を前提にプログラムを
    書くことはできません。

    データが化けたかどうかをチェックするプログラムコードだって
    化ける可能性があります。

    メモリーのみならずレジスターレベルまでH/W的に多重化して頂く
    しかありませんな。
    • Re:無理です。 (スコア:2, 参考になる)

      by holon (13785) on 2003年05月23日 3時29分 (#321324) ホームページ 日記
      組み込み系の場合、データ化けは想定内なのでdigestや checksumで
      チェックします。また、code部分のエラーについては watchdogや
      状態遷移チェックとかで検出するようにしています。

      現行の hardwareでもそのあたりの support機能がついているもの
      は多いので、さほど心配しなくてもいいと思います。

      また、Javaに限らず外部環境に弱い hardware一般で起きる事象だと
      思うので、開発される方々には留意してほしいところですね。

      # consumer deviceとかって、ユーザーさんが無理な使い方して
      # 温度上限とか電源環境とかでこけることもよくあるので、そう
      # いうエラー対応とか既に必要なんですよね。実際のとこ。
      親コメント
      • by Anonymous Coward on 2003年05月23日 9時11分 (#321375)
        「無理だ」と言い出したACです。
        ただいま使用中のSH7055Fは、設定するまでWDTが動きません...
        WDTの初期化コードが狂ったとなるとどうなってしまうのか予測
        不可能なので、外部にもWDTを持たせています。こちらは、回路
        構成で監視時間が決まるので、暴走しつづけることは無いだろうと
        願っています。

        ところでこの手の1チップCPUの場合、内蔵RAM・周辺機器レジスタ・
        CPUコアのレジスタの信頼性は等しいと考えるべきなんでしょうか?

        RAMチェック/ROMチェックは簡単に書けるけど、周辺機器レジスタの
        チェックはルーチンが膨大になりそうだし、ポートの設定次第で
        書き込み専用/読み込み専用になる領域もあるし、ユーザーコードでは
        書き込み不可能な領域もあるし、疑い出したらきりが無い。

        みなさん、どのあたりで折り合いをつけているのでしょうか?
        親コメント
        • 信頼性は module/functionごとにかなり違うようです。これは耐性
          の幅とか Trのサイズや logic構造とかのせいだと思います。同じ
          dieにのってる場合でも構成によって違うようです。
            というのも、耐久テストでエラーがでる場所は偏ってることが多い
          からの推測ですが。(一番弱い部分からまず落ちるため)

            周辺device込みの対応については、外部に単純な(=丈夫で安い)
          監視deviceをつけて、automataの statusも監視させるようにし
          ています。(状態遷移の監視)

           折り合いのつけ方って、基本は予算とのご相談になりますね。
          予測するエラー内容と損害量、それと対応コストの比較で。
          予算があれば冗長系入れたり、なければ実装部分の工夫で余裕
          あげたり・・・。「完全な対応はない」ですから。

          # watchdog起動失敗問題などは、system readyの信号をnegative側
          # に圧力かけておけば不具合出れば non-readyにおちてくれますね
          親コメント
        • 信頼性は一個にまとまっているんだからほとんど同じだろうと思っています。
          突き詰めていくと切りがないでしょう。

          人命にかかわることも機密情報を扱うこともないので、大した事はやっていません。
          ・外から来るデータの整合性チェック
        • 内蔵WDTの初期化コードがコケて暴走する可能性と、外部WDTとの配線等にノイズが載って異常動作(イラナイ時にリセットかかっちゃうとか)する可能性のどっちが高いかと言われたら、どっちもどっちというか、むしろ外部WDTの方が信頼性低いような気もし
    • by Rekishi (10137) on 2003年05月23日 2時37分 (#321319)
       非常に重要なものならともかく、数人が困る程度のものなら
      多重化はちょっと大げさかなと。実際自分が困っちゃったら
      いの一番に怒鳴り込んだりしそうですが。
      (といっても、あまりに重要なためメモリが化けたら地球が破滅、
      なんてコンピュータなどあっちゃ困りますが。)

       冗長なビットをちょっと付加すればエラー訂正できること
      ですし。
       いくら暖めたって、1バイトあたり2ビット以上化ける
      なんてことはほとんどないでしょうから。
      (512メガバイトのメモリを積んだPCを1ヶ月使い続けると
       1ビットぐらい化ける、という程度の確率だそうで。
       DRAMでこの程度ならその他のメモリならもっと低いんじゃ
       ないでしょうか。
       ソース失念にて失礼。必要なら誰か探してください・・・)

      # ・・・最近のPCにはメモリがいっぱい載ってるけど、エラー
      # 訂正の仕組みもなしにあんなにたくさんのメモリを使って
      # データ化けで困っている人はいないのでしょうか。
      # サーバ用以外にエラー訂正コード付きメモリってあまり
      # 聞かないし。
      # メモリが化ける前にソフトのバグで落ちちゃうんです
      # かね・・・
      親コメント
      • by Wildcat (2067) on 2003年05月23日 6時02分 (#321338) 日記
        昔の AT 機ってパリティー付きのやつ使ってなかったっけ?
        あれを利用すれば良いんじゃないだろうか。
        --
        (´д`;)
        親コメント
        • by Anonymous Coward
          ECCとパリティの違いさえわかってない人がここに約1名。
          • by Anonymous Coward

            64bitでECC(1bit訂正2bit検出)をやるには8bit余計に必要で、これって8bitごとにパリティをとるのと同じbit数ですよね。ということでパリティ対応メモリは72bit幅で、ECC対応メモリと兼用だったりすることもあるようですよ。

            需要と供給の関係からか、72bit幅メモリは64bit幅にくらべて大幅に高いようではありますが。

    • by Y.. (7829) on 2003年05月23日 3時27分 (#321323) 日記
      しかし、メモリー上でデータが化ける事を前提にプログラムを
      書くことはできません。

      データが化けたかどうかをチェックするプログラムコードだって
      化ける可能性があります。
      じゃぁ 吸い出しターゲットのデータも化けちゃえば問題ないや…
      ん? なんか違うような
      親コメント

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

処理中...