仮想化製品多数に「ゲストVM脱出」の脆弱性、影響は極めて重大
悪用された場合、攻撃者がゲスト仮想マシン（VM）から抜け出してホストシステムにアクセスし、任意のコードを実行できてしまう恐れがある。ホストシステムの他に、そのホスト上で実行されている他の全てのVMにアクセスできてしまう可能性もあるという。 この脆弱性は幅広い仮想プラットフォームに影響が及び、デフォルトの設定に対して攻撃が通用し、任意のコードを実行される恐れがあるという点で、過去に見つかった他のVMエスケープの脆弱性とは異なるとCrowdStrikeは指摘。悪用されれば企業などの知的財産や個人情報といった情報の流出につながりかねないと警告している。 脆弱性はハイパーバイザーのコードベースに存在することから、ホストOS（Linux、Windows、Mac OS）に関係なく影響を受ける。また、ゲストOSにも左右されない。 影響を受けることが確認されているベンダーはQEMU、Xen Project
seizhさんはTwitterを使っています: "てかScalaってJavaでできる以上のことは何もできない"
@nakanishiyasuo Javaには無名クラスがあります。お暇があれば双方のバイトコードを逆コンパイルしてみてください。 結局バックエンドはJavaVMですから、JavaScriptに対するAltJSと同じで、皮を被せたところでやれること自体が変わるわけではないのです。
品質の文脈でコメントの代わりのメソッド導入が安易に受け入れられない理由 - きしだのHatena
前提 目的は品質であり、品質のために読みやすさを求める。 メソッドを導入するとコードの複雑度はあがる。 コメントの記述ではコードの複雑度はあがらない。 コードの複雑度が高くなるとバグがでやすくなる。 バグがでやすくなると品質はさがる。 ここまでは今回前提とさせてもらいます。なので、ここで異論があれば、あぁそこに考え方の違いがあったのね、ということで。 目的が読みやすさであれば、まあそれで読みやすい人もいるんですねぇ、ということで終わらせることもできます。 ただ、このまえのエントリでは、品質がテーマです。 そういう前提では、読みやすいだけじゃなくて、品質を落とさないということも大事になります。 メソッドの導入は、基本的に複雑度をあげるので、それはそれでやりすぎるとバグの原因にもなっていきます。 もちろん、メソッドによって式や処理に名前をつけるというのは、複雑度をあげたことを補ってあまる効果が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
