VMにCPUファンがあると認識させた話！？

Oh please no。そんなことになったらPC使うのもアプリ書くのも chore になるよ。誰もモバイルOSとかChrome OSで本気で開発しないのには理由があるんだから。

これってLinuxのFlatpakとかMacのSandboxと全く同じアイデアじゃないの？

コンシューマー向けマザーボードでSMBIOS情報が実際のハードウェアと一致してるの見たことないんだよね。マルウェアは実際のハードウェアの50%で失敗してもVM/デバッガーで100%失敗すればいい、って考えてそう。でも、それならSMBIOSよりtiming checks使うはずだけど。

＞ I am yet to see any consumer-oriented motherboard where SMBIOS descriptions have even a passing relationship to the actual hardware.
特に安いchineese boxesに当てはまるね。「to be filled in by OEM」がlive/production BIOS imagesに入ってるのを何度見たか…。Retiredできるくらいだよ（笑）。

Bonus points for a non-unique UEFI UUID が Microsoft Intune / Windows Autopilot に登録されてて、Windows入れたら見知らぬ会社のログインを求められるやつね。 Triple-points if the vendor includes a sticker でネット繋がずにOOBEしろって書いてある。

Microsoftが、自分のものでもないマシンをbrickするのを企業に許してるなんて信じられないよ。犯罪的だね。

他のデバイスのUUIDをハードコーディングするより、もっと悪質ってこと？犯罪みたいだね。

自分のデバイスは好きに触っていいんだよ。Microsoftも君のデバイスで好きにやってるんだからさ。

OEMがやらかしてUUIDを使い回してなかったら、Microsoftが企業にデバイスで好きにやらせてるだけって話だったんだよ。それは別に不合理じゃない。
UUIDを使い回すOEMが、誰のデバイスかっていう цепоを壊してるんだ。

OEMのことは置いといてさ。もし他の人のUUIDが分かっちゃったら、そのUUIDでVMを立ち上げて、それを自分のシステムに追加したら相手のPCを壊せちゃうの？

ミスは起きるもんだよ。大規模だと避けられないんだからさ。
だから、もっと簡単に復旧できるプロセスが必要なのかもね？

僕の高いASUS ROGマザーボード（つまり安物じゃないやつね）も、「OEMが記入する」っていう文字列があって、自分で上書きできなかった気がするんだ。
ASUSはツールを持ってるらしいけど、公開してないんだよね。たぶんPCショップ向けなんだろうな。

そういや、2011年のASUS Zenbook UX21って知ってる？
“Ultrabook”として最初期のモデルだったんだけど、Linuxだと突然シャットダウンするバグがあったんだ。
理由はACPIファームウェアが、物理的に無いSATAコントローラーを初期化しようとして、I/O領域の変なところに書き込んじゃってたかららしいよ。
（リンク見つからなくてごめんね。）

でもまさにそこがポイントなんだよ。
完成したシステムを売るPCショップは、「システム製造元」欄に自分たちの名前を入れることになってるんだ。
もし自分でマザーボードを買ってシステムを組んだなら、誰がその文字列を置き換えるべきだと思う？

それは分かるけど、BIOSで変えられる設定になってるか、少なくともマザーボードのモデル番号がデフォルトになるべきだと思うんだ。
自分で組む場合、ASUSがツールを公開しないから、全く変更できないんだよ。
ていうか、前のPCで使ったショップでさえ、そんなツール持ってなかったよ。
Windowsで変えても、起動するたびにSMBIOSから書き戻されちゃうしね。

PCショップで長く働いてたけど、そんなツールにアクセスできたことなんて一度もなかったな。
正直、大手のOEMしか持ってないようなものみたいだね。

ASUSのドキュメントには載ってるけど、サポートページにはないんだって。たぶん大きなOEM向けに取ってあるんじゃないかな。

昔MS-DOSベースのBIOSフラッシュツールで、コマンドラインオプションで見かけたことがあるよ。どのマザーボードか、どんなオプションだったか覚えてないけどね。

でもさ、ここで話してるのは普通に売ってるコンシューマー向けのマザーボードのことじゃん。ASUSがこういう設定で売ってるのに、それを変える方法をユーザーに提供しないのは変だよね。

デフォルトは”Asus”にしといて、パソコンショップがその設定を変えるツールを持ってるってのはどうかな？

そうするとASUSが組んだ本物のPCと区別つかなくなるよ。でもほとんどの小さいショップはツール持ってないみたいだし、結局、誰も変えられないって逆の状況になるだけじゃない？

自分でPCを組むためにマザーボードを買った場合、その人はOEMだよ。

ASUS以外の”ゲーミング”マザーボードでも同じ感じだったよ。たぶん自作PC組む人はSMBIOSのシリアル番号とか気にしないだろうから、メーカーも力を入れてないんじゃないかな？

もし変えられるなら気になるけど、手に入らない専用ツールが必要なんだよね。他の方法だとUEFIをいじったり、Secure Bootをオフにしないといけなかったりするんだよ。

MSIのPRO Z790-A WIFIってマザーボードで試してみたよ。SMBIOS情報を見てみたら、ManufacturerとかProduct Nameは表示されてるけど、期待したほど埋まってないみたい。
（詳細は省略）
なんか残念…

でもさ、マザーボードを単体で買って、完成品のPCじゃなかったら、システムメーカーって存在しないんだから、そこが埋まってないのは当たり前じゃない？

マルウェアにもバグはあるんだってさ。あるウイルスはバグで拡散速度が半分になっちゃったらしいけど、それでも十分ヤバい損害を与えられるんだって。

Linuxって最近はファンをどうやって見つけるの？ ACPIとかEFIとかかな？ 俺のマシンではちゃんと動いてるんだけどさ。

めっちゃたくさんのマザーボード固有のハックで検出してるみたいだよ。ここにソースがあるから見てみてよ。
https://lxr.linux.no/#linux+v6.7.1/drivers/hwmon/

これってさ、実際にマルウェアがチェックしてるの？それとも研究者が作ったサンプルなの？

そういう変なAPI呼ぶやり方は、解析を難しくするつもりが、AVソフトにすぐ怪しいってバレちゃうよ。難読化してないと逆効果かも。正規のプログラムならいいけどさ。前この分野で働いてたけど、こういうAPI使うのを検出するregex作ったことあるけど結構効果あったよ。

ってことはさ、セキュリティ的にソフトは全部VMの中で動かすべきってこと？

ハードウェアアクセラレーションが無くなっちゃうね。それに、VMを検出したら勝手に止まったり消えたりするマルウェアも多いんだよ。VirtualBoxとかVMwareとかの検出とか、ロシアのキーボード配置を見て止まるロシア系マルウェアとかね。全部じゃないけど、解析されたくなくて勝手に死ぬやつもいるよ。

ハードウェアアクセラレーションが無くなるって話は、だんだん当てはまらなくなってきてるよ。SR-IOVとかS-IOVが普通になってきて、OSも仮想化を使い始めてる。WSLのおかげでハードウェアメーカーも仮想化に協力するようになったし、MicrosoftはGPU仮想化もできる一時的なWindows VMサンドボックスまで出してるんだぜ。

でもさ、それだとVMが直接ハードウェアにアクセスすることになるから、VMを使うメリットが減るか無くなるんじゃない？どっちもいいとこ取りはできないってことだよ。

完全にそうじゃないよ？SIOVとかSRIOVみたいな仮想化されたPCIEフレームワークは、ハードウェアに直接アクセスさせるんじゃなくて、現代のPCがCPUやメモリを仮想化するみたいに、PCIEデバイスの中に仮想化されたデバイスを作る感じだよ。

いや、それがまさにこれらのフレームワークの目的だよ。スピードを得るために…ハードウェアに直接アクセスできるようにするんだ。PCIeってのは（すごく大雑把に言うと）どのVMが要求してるかハードウェアに知らせるための方法なんだ。ここからはハードウェアメーカーが、色んな「パーティション」を分離できるか…全く分離できないか、に委ねられることになる。想像するのが難しいくらい攻撃対象が広がるんだ。

＞ハードウェアに直接アクセスさせる＞メーカー次第とかウソ言うな！
もっとデタラメな投稿続ける前にSR-IOVについてちゃんと読めよ！
https://en.wikipedia.org/wiki/Single-root_input/output_virtu…

じゃあ、何がデタラメだと思うか正確に説明しろよ、内容のないRTFMメッセージでHNのガイドライン違反する前にさ？
お前のリンク先もまさに俺が言ったこと（バスへのマルチプレクサ）と同じこと書いてあるじゃん。これは全部VMにハードウェアへの直接アクセスを与えるためのものなんだよ。そうでなきゃこんな機能について議論する意味ないだろ。これが本当のハードウェアアクセスじゃないなら、何のためのものだと思うんだ？VMホストがIntel PRO1000イーサネットカードをエミュレートしやすくするためか？

こっちの方が何をしてるか分かりやすい説明だよ：
SR-IOV：https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer…
S-IOV：https://cdrdv2-public.intel.com/671403/intel-scalable-io-vir…
これらがやってることは「技術的には」直接バスアクセスをさせてるんだけど、そのバスアクセスは制限されてるんだ。VMのアクセスは全てタグ付けされてて、許可された範囲（設定時のハードウェアのアクセス制御で定義される）外にアクセスしようとしたら、VMが何かを触る前にフォルトが出るんだよ。
これはVT-dとか他のCPU仮想化拡張が、IOMMUを通じて許可やアクセス制御付きでRAMへの直接アクセスを許可するのと似てるね。
そしてSR-IOVとS-IOVのもう一つの主要な要素は、PCI-Eハードウェア自体のインターフェース（仮想関数って呼ばれる）とその文脈、レジスタ、BARなんかを仮想化することなんだ。これはVT-xとか似たような命令がCPU（とレジスタなど）を仮想化するのに似てるよ。そしてこれらの仮想関数はハードウェアでアクセス制御やクォータなんかで制限できるんだ。
だから既存のVT-x拡張はCPUを仮想化してて、既存のVT-d拡張はIOMMUとRAMを仮想化してて、既存のVT-cはネットワークインターフェース（ただしPCI-E全体じゃない）を仮想化してる。今度はSR-IOVとS-IOVがPCI-Eバスをレーンごとのアクセス制御付きで仮想化してるんだ。そしてSR-IOVとS-IOVがPCI-Eデバイスハードウェアとその関数＼インターフェースをバス上で仮想化してるんだ（VT-xやVT-dに似てるね）。
特にS-IOVは、付属機能というより「SR-IOV 2.0」として見るべきだね。仮想関数から物理関数への変換を、CPUやチップセット内のハードウェアからPCI-Eデバイス自体に移動させるんだ。

何がこの混乱を招いてるのか分からないな。
＞技術的には直接バスアクセスをさせてるんだけど、アクセス制御で制限されてる
これはまさに俺が知ってることで、最初の投稿で言ったことだよ：どのVMが何にアクセスしてるか特定する方法。それは…そのVMにハードウェアへのアクセスを与えるためだ。
＞許可された範囲外にアクセスしようとしたら、VMが何かを触る前にフォルトが出る
これも、俺が言ったことと全く同じだよ：メーカー次第でパーティショニングがあるかどうかが決まるんだ。そうじゃないと思うのは希望的観測で、どこから来るのか分からないな。
これはまさにVMにハードウェアへの直接アクセスを与えることの定義だよ。ソフトウェア制御のエミュレーションは一切行われていないから、明示的にコンテインメントを失って攻撃対象を増やすんだ。
一番シンプルなイーサネットカード以外、お前のハードウェアは閉鎖的なファームウェアでこのマルチプレキシングを実装してる可能性が高い。それはハードウェアエンジニアによって書かれたもので、おそらくセキュリティ的には最悪のコードだ。
＞VT-dとか他のCPU仮想化拡張が、IOMMUを通じて許可やアクセス制御付きでRAMへの直接アクセスを許可するのと似てる
全く違うよ。通常IOMMUは、元々RAMに直接アクセスできるハードウェアを制限するために使うものなんだ。
＞そしてSR-IOVとS-IOVのもう一つの主要な要素は、PCI-Eハードウェア自体のインターフェース（仮想関数って呼ばれる）を仮想化することなんだ
これが混乱の原因か？仮想って呼ばれてるから、これが仮想化されてるって思うのか？俺がパーティションって呼ぶのは、ハードウェアの観点からはそれにずっと近いからだよ。
＞既存のVT-x拡張はCPUを仮想化してて、既存のVT-d拡張はIOMMUとRAMを仮想化してて、既存のVT-cはネットワークインターフェース（ただしPCI-E全体じゃない）を仮想化してる
これは全部混ぜてて意味がないね。「RAMを仮想化する」ってどういう意味だ？RAMは通常のMMUですでに仮想化されてるんだ、VT-dは全然必要ない。ハードウェアこそ、メモリの考え方がハードウェアに直接アクセスしてるVMの考え方と一致するように、RAMアクセスも仮想化する必要があるかもしれないんだ（ソフトウェアエミュレーション層を通す代わりにね）、そしてそれがIOMMUの恩恵を受けるんだ（でも一般的には必須じゃない、GARTやVT-cを見てくれ）。
でもこれの全体のポイントは、やっぱりVMにハードウェアへの直接アクセスを与えることだ！ここから正確に何を否定したいんだ？

それじゃサイドチャネル攻撃にやられちゃうよ。セキュリティ的にはソフトなんか全く動かすべきじゃないけど、どうしてもならAWS Lambdaだけ使いなよ。

＞これはまさに俺が知ってることで、最初の投稿で言ったことだよ：どのVMが何にアクセスしてるか特定する方法。それは…そのVMにハードウェアへのアクセスを与えるためだ。
そうだけど、全体的なポイントはVMのアクセスの分離をソフトウェアからハードウェアに移してるってことなんだ。確かにハードウェアのサブセットに直接アクセスさせてるけど、そのハードウェアのサブセットはVMのアクセスから外れた場所からVMのアクセスを制限するように設定されてるんだ。
＞これも、俺が言ったことと全く同じだよ：メーカー次第でパーティショニングがあるかどうかが決まるんだ。そうじゃないと思うのは希望的観測で、どこから来るのか分からないな。
俺の知る限り、それは実際には真実じゃないな。S-IOVとSR-IOVはハードウェアサポートが必要だ。もちろんメーカーは実装をテキトーにやるかもしれないけど、S-IOVとSR-IOVはパーティショニングが必須なんだ。でも、VMにS-IOVやSR-IOV経由でハードウェアへのアクセスを許可してるなら、最低でも暗黙的にハードウェアメーカーが仕様を正しく実装してるって信用してることになる。
＞ソフトウェア制御のエミュレーションは一切行われていないから、明示的にコンテインメントを失って攻撃対象を増やすんだ。
これは真実だけど、VT-xとかVT-dなんかも同じだ（つまり、一般的な仮想化拡張機能ね）。S-IOVやSR-IOVが新しいからとか、「バトルテスト」されてないからとか以外は、それらと比べて真実じゃないってことはない。仮想化拡張を使うなら、もう純粋なソフトウェア仮想化はしてないんだからね。
＞一番シンプルなイーサネットカード以外、お前のハードウェアは閉鎖的なファームウェアでこのマルチプレキシングを実装してる可能性が高い。それはハードウェアエンジニアによって書かれたもので、おそらくセキュリティ的には最悪のコードだ。
全く同じことが現代のCPUのマイクロコードや内部ファームウェア、関連するチップセットにも言えるよ。
＞通常IOMMUは、元々RAMに直接アクセスできるハードウェアを制限するために使うものなんだ。
そうだよ。そしてVT-dはこれをVMのために拡張して、ホストがソフトウェアレベルのリマッピングをする代わりに、ハードウェアレベルのIO、割り込み、DMAリマッピングを導入するんだ。
＞これが混乱の原因か？仮想って呼ばれてるから、これが仮想化されてるって思うのか？俺がパーティションって呼ぶのは、ハードウェアの観点からはそれにずっと近いからだよ。
俺は仮想化って呼ぶよ、だってそれは仮想化だから。SR-IOVではまだ仮想化だけど、アーキテクチャ的にはアクセス制御付きのパーティショニングに似てるのはそうだね、でもそれはそれでも仮想化だよ、ネスティングができないだけだ。でもS-IOVは完全にハードウェア上での仮想化で、仮想デバイスのネスティングもサポートしてる。
＞でもこれの全体のポイントは、やっぱりVMにハードウェアへの直接アクセスを与えることだ！ここから正確に何を否定したいんだ？
ここでの食い違いは、俺（そして他の人もそうだと思うけど）は、ハードウェア仮想化拡張＼フレームワークを通じて、アクセス制御と許可されたハードウェアのサブセットにVMがアクセスすることを、CPU仮想化拡張（これは基本的に常に有効）がそうでないのと同じくらい、「VMにハードウェアへの直接アクセスを与えること」には当たらない、という前提で話してるんだと思う。
———-
編集：あ、別のコメンターが俺たちのコメントチェーンにいたことも付け加えるべきだったな。SR-IOV＼S-IOVが分離と仮想化機能を正しく実装するかどうかのメーカー次第ってところに反論してたのがその人だって気づいたんだ。それがあれば、君が機能が安全であるためにはハードウェアメーカーが正しく実装することに頼ってるってことを俺が100%理解してるのが少し分かりやすくなるかもしれないな。

それじゃ、アプリごとに長～い権限ダイアログが出てくることになるよ。どのアプリも、ろくな理由もなく（単なるフィンガープリントとして）CPUファンを読みたがるだろうから、どんなアプリも使えるように「許可」をクリックするのに慣れちゃうだろうね。結局マルウェアはすり抜けるだろうさ。これもうモバイルで起きてることだ。

最近のMalwareって意外と署名されてることが多いんだよね。ハッキングされたコード署名証明書が出回ってて、Microsoftは元の顧客のソフトが動かなくなるのを恐れて、証明書の信頼失効に消極的みたい。
Malwareがカーネルに潜り込むためによく使う、脆弱性がある古いドライバも同じ。WMI呼び出しする怪しい小さなバイナリは目立つけど、脆弱性だらけの5年前のオーバークロックツールが同じことしてても怪しまれないかも。
記事で読んだ研究によると、これは検知を避けるためっていうより、マルウェア解析者のマシンで本物のペイロードを実行させないのが目的なんだって。もしAVがフラグ立てたり検知が発動したりしたら、第2段階はダウンロードされず、ニュースになるような悪さをするマルウェアは（まだ）実行されないってこと。

＞ そうだけど、大事なのはVMのアクセス分離をソフトからハードに移してるってこと。ハードの一部分に直接アクセスさせてるけど、そのハードはVMの外からVMのアクセスを制限するように設定されてるんだ。
でも、この“一部分”（普通は機能の一部分じゃないけど）へのアクセスを制御してるのは誰？ 答えはハードウェア。前はソフトがハードをエミュレートしてチェックを入れてた。今はVM OSがハードに直接アクセスしてレジスタを叩いてて、VM間のアクセス隔離は文字通りハードウェアに依存してるんだね。
＞ これは本当だけど、VT-xとかVT-dとか（よくある仮想化拡張）でも同じ。SR-IOVやS-IOVでも、新しくて“戦い慣れてない”って以外は同じだよ。“仮想化拡張を使ってるなら、もう純粋なソフトウェア仮想化じゃない”ってね。
いや、この例えは正しくないな。VT-xがなくても、386時代からCPUは信用できないコードを実行できるように設計されてる。VT-xを追加すると少し変わるけど、全体的なアーキテクチャから見ればほとんど無関係だよ。だってCPUはどっちにしてもVMゲストコードを直接実行してるんだから（VT-xなしでもよく動いた初期の仮想化ソフトを見て）。
ここで言ってるのは、信用できないソフトやユーザーレベルコードからアクセスされるなんて全く想像もしてなかったハードに、信用できないコードが直接アクセスできるようにしてるってこと（GPUみたいに例外は少数あるけどね）。
セキュリティ境界の大きさの違いはものすごく大きくて、想像するのも難しいくらい。
正しい例えは、JavaScript VMがネイティブCPUコードを生成してたのを、インターネットから直接ダウンロードしたネイティブCPUコードを直接実行するのに切り替えるようなもの。8086レベルのCPUに適当にMMUを乗っけた上でね。理論上は動くけど、実際にはみんなゾッとするはずだよ（当然だけど）。それが適切な例え。
SRIOVの議論は的外れ。これらの技術はこういう直接ハードウェアアクセスを可能にするためのもの。SRIOVがハードウェアとVMの間のファイアウォール（君が考えてるもの）なわけじゃない。これらは完全にこの直接ハードウェアアクセスを促進するために設計された技術で、アクセスを防止したり制限したりする目的は全くないんだ。

＞ 前はソフトがハードをエミュレートしてチェックを入れてた。今はVM OSがハードに直接アクセスしてレジスタを叩いてて、VM間のアクセス隔離は文字通りハードウェアに依存してるんだね。
これはもう何十年も前の話だよ。CPUは仮想化のほとんどをハードウェアに任せてる。ほとんどのソフトはハードウェアを設定したり、ちょっとした繋ぎの役割をしてるだけで、別のアーキテクチャを完全にエミュレートしてるんじゃない限りはね。
＞ 信用できないソフトやユーザーレベルコードからアクセスされるなんて全く想像もしてなかったハードに、信用できないコードが直接アクセスできるようにしてるってこと（GPUみたいに例外は少数あるけどね）。
デバイスがSR-IOVやS-IOVをサポートしてるなら、それは仕様を満たすように設計されてるはず。古いハードウェアでスイッチを有効にするだけじゃないんだ。スタック上の全てのデバイスが標準をサポートしてる必要があって、だからそれらの仕様が課すセキュリティ境界を少なくとも尊重しようと設計されてるはずだよ。
＞ JavaScript VM generting native cpu code into directly executing native CPU code directly downloaded from the internet.
これはまさに今のモダンブラウザがやってることだよ。ChromeのV8 JSエンジンはJSをパースしてV8バイトコードを生成する。そして実行時にV8 JITがそのバイトコードをネイティブマシンコードにコンパイルして、そのネイティブコードをハードウェアで実行するんだ。JSを解釈してるんじゃなくて、JSをCPUで動くネイティブコードにコンパイルしてるんだよ（予測を使って、コードパスが実行される前にコンパイルが終わるようにしてる）。
＞ On a 8086 level CPU with a haphazardly added MMU on top of it. Sure, works on theory. In practice, it will make everyone shiver (and with reason). That is the proper analogy.
これも正しくない。P2P DMAサポートは、コンシューマー向けPCI-Eデバイス（主にNVME、ネットワークHBA、GPU）では何年も前から一般的だし、データセンターなんかでは少なくとも10年前から利用可能だよ。
＞ On a 8086 level CPU with a haphazardly added MMU on top of it.
あと、細かいことだけど、80286（オリジナルの8086から4年足らずでリリースされた8086 CPUの第3世代）には適切なセグメンテーションサポート付きの統合MMUがあったんだ。さらに、MMUは8086よりずっと前から存在してた。8086に最初から統合されてなかったのは、ターゲット市場に必要なかっただけ。
＞ The discussion about SRIOV is a red herring because these technologies are about allowing this direct hardware access. It is not that SRIOV is a firewall between the hardware and the VM (or whatever it is that you envision). They are technologies entirely designed to facilitate this direct hardware access, not prevent or constrain it in any way.
繰り返すけど、これも単に正しくない。これらはハードウェアを分割し、そのセグメントの隔離を強制するためのフレームワークを提供してる。それはホストが設定したもの以外のハードウェアへのアクセスを「防止し、制限する」ことを意図してるんだ。
——
もしSR-IOVやS-IOVが謳ってる機能を果たしてないという引用を提供できるなら、喜んでこの議論を続けよう。

＞ 何がおかしいと思うか具体的に説明しないで、内容のないRTFMメッセージでHNガイドラインに違反するの？
違反って…落ち着いてよ。最初の文を読むだけでよかったんだけど、言い換えてあげるよ。
＞ In virtualization, single root input/output virtualization (SR-IOV) is a specification that allows the isolation of PCI Express resources for manageability and performance reasons.
（仮想化では、SR-IOVは管理性とパフォーマンスのためにPCI Expressリソースの分離を可能にする仕様です。）

アンチウイルスソフトが、静的な呼び出しを解析してマルウェアかどうかを推測するだけっていうのは、正直すごいウザいよね。それやってるなら、信頼できるソフトの許可リスト作って、リストにないソフトはマルウェアだってマークした方がよっぽどマシじゃない？ ほとんど同じように機能すると思うけど。

＞ ハッキングされたコード署名証明書が出回ってて、Microsoftは元の顧客のソフトが動かなくなるのを恐れて、証明書の信頼失効に消極的みたい。
俺が知る限り、ほとんど（全部？）のコード署名CAはこれに対して取り締まりを強化してる（というかMicrosoftがプッシュしてるのかも）。署名キーを物理またはクラウドホストのHSMに置くのを義務付けてるんだ。例えば、DigiCertでコード署名証明書を買おうとすると、配送オプションはクラウドか物理HSMしか選べないよ。
https://www.digicert.com/signing/code-signing-certificates

コツは「CrowdStrike」みたいな会社になること。カーネルレベルで動くクソソフトに署名してもらえば、怪しいシステムAPI呼び出しもやりたい放題。VMかどうか判断するなんて考える必要ないよ。
検証してないコード＼リリースを顧客のプロダクションマシンにばらまいて、世界が炎上するのを見るんだ。フライトは遅延、重要なインフラは攻撃され、‘リアル’な人々に影響が出る。
‘正規の’会社は、ブラックハットハッカーや国家主体が夢にも見られないほどの損害をアメリカ企業に与えてきた。
libzma内のxz utilの裏にいる奴らは、ClownStrikeやSolarWindsのような会社が引き起こした損害に匹敵するものを目指してるんだよ。