この記事では、まず Cloudflare のセキュリティアーキテクチャの概要を説明し、次によく聞かれる 2 つの話題である V8 のバグと Spectre を扱います。
Workers プロジェクトのごく初期から、セキュリティは高い優先事項でした。共有インフラ上で多数のテナントをホストする場合、さまざまな種類のサイドチャネルが脅威になるという懸念がありました。Cloudflare Workers ランタイムは、サイドチャネル攻撃を防ぐよう慎重に設計されています。
このため、Workers はコードが自分の実行時間をローカルで計測できないように設計されています。たとえば、コード実行中は Date.now() が返す値が固定されます。ほかのタイマーは提供されません。さらに Cloudflare は、攻撃者がアドホックなタイマーを組み立てられる可能性があるため、並行性（例: マルチスレッド）へのアクセスを提供しません。これらの設計選択は、既存アプリケーションが依存する API を取り除くため、Web ブラウザーなどほかのプラットフォームへ後から導入できません。Workers では、最初からのランタイム設計選択があったからこそ可能でした。
これらの初期設計判断は効果を示していますが、Cloudflare は防御の層を増やし続けています。疑わしい Worker と価値の高い Worker のあいだに追加の隔離層を作るため、Worker を再スケジュールして攻撃を乱す手法も含みます。
Workers のアプローチは、業界の大半のアプローチとは大きく異なります。Spectre 系の攻撃 ↗ 全体に耐性があり、それぞれに特別な注意を払う必要もなく、推測実行全般をブロックする必要もありません。ただし Workers のアプローチは異なるため、慎重な研究が必要です。Cloudflare は現在、Graz University of Technology (TU Graz) の研究者と協力して、これまでに行ったことを研究しています。これらの研究者には、Spectre を最初に発見した人々も含まれます。Cloudflare はこの研究の結果が得られ次第公開します。
詳細は、Cloudflare Workers のアーキテクトである Kenton Varda による この講演 ↗ を参照してください。Spectre は終盤で扱われます。
まず Workers ランタイムアーキテクチャの簡単な概要です。
コードサンドボックスの設計には、安全な隔離と API 設計という 2 つの基本部分があります。
まず、コードが許可されていないものにアクセスできない、安全な実行環境を作る必要がありました。
このための主要なツールは、Google が Chrome 向けに開発した JavaScript エンジンである V8 です。V8 は isolate の中でコードを実行し、同じプロセス内でも isolate 外のメモリへアクセスできないようにします。重要なのは、Cloudflare が 1 つのプロセス内で多数の isolate を実行できることです。これは、すべてのマシンで何千ものゲストアプリケーションをホストし、最小のオーバーヘッドで 1 秒あたり何千回もゲストを切り替える必要がある Workers のようなエッジコンピュートプラットフォームに不可欠です。ゲストごとに別プロセスを実行しなければならない場合、Cloudflare がサポートできるテナント数は大幅に減り、エッジコンピュートを少数の大規模 Enterprise 顧客に限定しなければならなくなります。isolate 技術により、Cloudflare はエッジコンピュートを誰にでも提供できます。
ただし Cloudflare は、Worker を専用のプライベートプロセスでスケジュールすることもあります。追加の隔離層が必要な特定機能を Worker が使う場合です。たとえば、開発者が devtools デバッガーで Worker を検査するとき、Cloudflare はその Worker を別プロセスで実行します。歴史的にブラウザーでは、inspector プロトコルはブラウザーの信頼された運用者だけが使え、V8 の残りの部分ほどセキュリティ審査を受けてこなかったためです。inspector プロトコルのバグリスク増加に備えるため、Cloudflare は検査対象の Worker をプロセスレベルのサンドボックス付きの別プロセスへ移します。Cloudflare は Spectre に対する追加防御としてもプロセス隔離を使います。
さらに、ほかの isolate と同じプロセスで動く isolate についても、Cloudflare は各マシンでランタイム全体の複数インスタンスを実行します。これを cordon と呼びます。Worker は信頼レベルを割り当て、信頼の低い Worker とより高い信頼の Worker を分けることで、cordon 間に分散されます。この運用の一例として、Free プランに登録した顧客は、Enterprise 顧客と同じプロセスにはスケジュールされません。これにより、V8 でゼロデイのセキュリティ脆弱性が見つかった場合の防御の層が得られます。
プロセス全体のレベルでは、Cloudflare は防御の層として別のサンドボックス層を適用します。レイヤー 2 サンドボックスは Linux namespaces と seccomp を使い、ファイルシステムとネットワークへのすべてのアクセスを禁止します。namespaces と seccomp はコンテナーの実装によく使われます。ただし Cloudflare の使い方は、通常コンテナーエンジンで可能なものよりはるかに厳格です。プロセス開始後、isolate を読み込む前に namespaces と seccomp を設定するためです。つまり、たとえば Cloudflare は完全に空のファイルシステム（mount namespace）を使え（実際に使っており）、seccomp ですべてのファイルシステム関連システムコールを絶対にブロックできます。コンテナーエンジンは通常、すべてのファイルシステムアクセスを禁止できません。そうすると exec() でディスクからゲストプログラムを起動できなくなるためです。Workers の場合、ゲストプログラムはネイティブバイナリではなく、ファイルシステムアクセスをブロックする前に Workers ランタイム自体の読み込みがすでに終わっています。
レイヤー 2 サンドボックスはネットワークアクセスも完全に禁止します。代わりに、プロセスは同じシステム上のほかのプロセスと話すためのローカル UNIX domain sockets 上の通信に限定されます。外界との通信は、サンドボックス外のほかのローカルプロセスが仲介する必要があります。
特に supervisor と呼ばれるプロセスは、ディスクまたはほかの内部サービスから Worker のコードと設定を取得する責任を持ちます。supervisor は、サンドボックスプロセスが実行すべき Worker に関連する設定以外を読めないようにします。
たとえば、サンドボックスプロセスがまだ見たことのない Worker のリクエストを受け取ると、そのリクエストには添付シークレットを含むその Worker のコードの暗号化キーが含まれます。サンドボックスはそのキーを supervisor に渡し、コードをリクエストできます。サンドボックスは、適切なキーを受け取っていない Worker をリクエストできません。既知の Worker を列挙することもできません。不要な設定もリクエストできません。たとえば、Worker への HTTPS トラフィックに使う TLS キーをリクエストできません。
設定の読み取り以外で、サンドボックスが同じシステム上のほかのプロセスと話す理由は、Workers に公開する API を実装するためです。
次のような言い回しがあります。森で木が倒れても、それを聞く人がいなければ音はするか。Cloudflare の言い回しはこうです。Worker が外界との通信を完全に禁じられた完全隔離環境で実行されても、実際に動いていると言えるか。
完全なコード隔離は、実のところ役に立ちません。Workers が何か有用なことをするには、ユーザーと通信できなければなりません。少なくとも、Worker はリクエストを受け取り、応答できる必要があります。Workers が世界へ安全にリクエストを送るには、API が必要です。
サンドボックスの文脈では、API 設計は新たな責任を負います。Cloudflare の API は、Worker ができることとできないことを正確に定義します。Cloudflare は、許可された操作だけを表現し、それ以上は表現できないよう、各 API を非常に慎重に設計しなければなりません。たとえば、Cloudflare は Workers に HTTP リクエストの送受信を許可しつつ、ローカルファイルシステムや内部ネットワークサービスへアクセスできないようにしたいと考えます。
現在、Workers はローカルファイルシステムへのアクセスを一切許可しません。そのため、Cloudflare はファイルシステム API をまったく公開しません。API がなければアクセスはありません。
では、将来 Workers がローカルファイルシステムアクセスをサポートしたいと考えたと想像してください。どう実現できるでしょうか。Workers はファイルシステム全体を見るべきではありません。ただし、各 Worker がファイルシステム上に、好きなものを保存できる専用のプライベートディレクトリを持つと想像してください。
これを行うために、Workers は capability-based security ↗ に基づく設計を使います。Capability は大きな話題ですが、この場合の意味は、Cloudflare がファイルシステム上のディレクトリを表す Directory 型のオブジェクトを Worker に渡すことです。このオブジェクトはファイルとサブディレクトリの作成・オープンを許可する API を持ちますが、親ディレクトリへさかのぼることは許可しません。実質的に、各 Worker は専用の Directory を、自分のファイルシステムのルートであるかのように見ます。
そのような API はどう実装するでしょうか。前述のとおり、サンドボックスプロセスは実際のファイルシステムにアクセスできません。代わりに、ファイルアクセスは supervisor プロセスが仲介します。サンドボックスは Cap’n Proto RPC ↗ という capability ベースの RPC プロトコルで supervisor と話します。（Cap’n Proto は現在 Cloudflare Workers チームが維持するオープンソースプロジェクトです。）このプロトコルは capability ベースの API を実装しやすく、サンドボックスが実行中の Worker に属するファイルだけにアクセスするよう厳密に制限できます。
ではネットワークアクセスはどうでしょうか。現在、Workers が残りの世界と話せるのは HTTP 経由だけです。受信と送信の両方です。ほかの形式のネットワークアクセス用 API はないため、禁止されています。ただし Cloudflare は将来、ほかのプロトコルをサポートする予定です。
前述のとおり、サンドボックスプロセスはネットワークに直接接続できません。代わりに、すべての送信 HTTP リクエストは UNIX domain socket 経由でローカルプロキシサービスへ送られます。そのサービスはリクエストに制限を実装します。たとえば、リクエストがパブリックインターネットサービス宛てか、Worker のゾーン自身のオリジンサーバー宛てであり、ローカルマシンやネットワークから見える内部サービス宛てではないことを検証します。また、すべてのリクエストに発信元 Worker を識別するヘッダーを追加し、不正なリクエストを追跡してブロックできるようにします。すべてが整うと、リクエストは Cloudflare ネットワークの HTTP キャッシュ層へ送られ、そこからインターネットへ出ます。
同様に、受信 HTTP リクエストは Workers ランタイムへ直接行きません。まず受信プロキシサービスが受け取ります。そのサービスは TLS 終端（Workers ランタイムは TLS キーを見ません）と、特定のリクエスト URL に対して実行する正しい Worker スクリプトの識別を担当します。すべてが整うと、リクエストは UNIX domain socket 経由でサンドボックスプロセスへ渡されます。
自明でないソフトウェアにはすべてバグがあり、サンドボックス技術も例外ではありません。仮想マシン、コンテナー、Workers が使う isolate にもバグがあります。
Workers は、Google が Chrome 向けに構築した JavaScript エンジンである V8 が提供する隔離に大きく依存します。これには長所と短所があります。一方で V8 は非常に複雑な技術であり、仮想マシンより広い攻撃面を作ります。複雑さが増えるほど、何かがうまくいかない機会も増えます。ただし V8 は、おそらく世界で最も人気のあるサンドボックス技術としての立場から、バグの発見と修正に並外れた努力が注がれています。Google は V8 サンドボックス脱出を見つけた人に定期的に 5 桁の報奨金を支払います。Google は、ほとんどの人間より速く自動でバグを見つける fuzzing インフラも運用しています。Google の投資は、悪意ある行為者が見つけて Google が知らない V8 ゼロデイ（バグ）の危険を大きく下げます。
では、バグが見つかり報告されたあとはどうなるでしょうか。V8 はオープンソースなので、セキュリティバグの修正は公開で開発され、全員に同時に公開されます。悪意ある行為者がエクスプロイトを開発する前に、パッチをできるだけ速く本番へ展開することが重要です。
修正の公開からデプロイまでの時間は、パッチギャップとして知られます。Google は以前、Chrome のパッチギャップが 33 日から 15 日に短縮された ↗ と発表しました。
幸い、Cloudflare は Workers ランタイムが動くマシンを直接制御しています。ビルドとリリースプロセスのほぼ全体が自動化されているため、V8 パッチが公開された瞬間に、Cloudflare のシステムは Workers ランタイムの新しいリリースを自動ビルドし、必要な（人間の）レビュアーからワンクリックの承認を得たあと、そのリリースを自動で本番へ押し出します。
その結果、Workers のパッチギャップは現在 24 時間未満です。ミュンヘンの V8 チームが勤務時間中に公開したパッチは、通常、米国の勤務日が終わる前に本番に入ります。
Google の V8 チームは、V8 自体は Spectre を防御できない ↗ と述べています。Workers はこの点で V8 に依存する必要はありません。Workers 環境は、Spectre を緩和する多くの代替アプローチを提示します。
Spectre は、悪意あるプログラムが CPU をだまして、プログラムがアクセスしてはいけないデータを使った計算を推測実行させる攻撃のクラスです。CPU は最終的に問題に気づき、プログラムが推測計算の結果を見ることを許可しません。ただしプログラムは、キャッシュへの影響など、計算の微妙な副作用を見ることで、秘密データのビットを導き出せることがあります。
Spectre の詳細は、このトピックの Learning Center ページ ↗ を参照してください。
Spectre は、現代の CPU に存在する幅広い脆弱性を含みます。具体的な脆弱性はアーキテクチャとモデルによって異なり、まだ発見されていない脆弱性が多数存在する可能性が高いです。
これらの脆弱性は、すべてのクラウドコンピュートプラットフォームの問題です。同じマシンで複数のテナントがコードを実行するときはいつでも、Spectre 攻撃が可能です。ただしテナントが近いほど、特定の脆弱性を緩和するのが難しくなります。既知の問題の多くは、カーネルレベル（プロセス同士の保護）またはハイパーバイザーレベル（VM 同士の保護）で、多くの場合 CPU マイクロコード更新とさまざまな防御（多くは深刻な性能影響を伴う）の助けを借りて緩和できます。
Cloudflare Workers では、テナントはプロセスでも VM でもなく、V8 isolate で互いに隔離されます。つまり Workers は、Spectre 防止を OS やハイパーバイザーのパッチに必ずしも頼れません。Workers は独自の戦略が必要です。
Cloudflare Workers は、すべての Cloudflare ロケーションでコードを実行するよう設計されています。
Workers は誰でも使えるプラットフォームとして設計されています。多数のテナントを扱う必要があり、多くのテナントはトラフィックがごくわずかです。
この 2 点を合わせると、計画は難しくなります。
典型的な、エッジではないサーバーレスプロバイダーは、低トラフィックのテナントを扱うために、そのテナントのトラフィックをすべて 1 台のマシンへ送り、アプリケーションのコピーを 1 つだけ読み込めば済みます。そのマシンがたとえば十数テナントを扱えるなら十分です。そのマシンは数百万台のマシンがある巨大データセンターにホストでき、規模の経済を達成できます。ただしユーザーが近くにいない場合、この集中化はレイテンシと世界的な帯域コストを招きます。
一方 Workers では、トラフィック量に関係なく、現在すべてのテナントがすべての Cloudflare ロケーションで動きます。エンドユーザーにできるだけ近づけるため、Cloudflare は限られた台数のマシンしか置けないロケーションを選ぶこともあります。結果として Cloudflare は、非アクティブなものをオンデマンドで迅速に起動できる能力とともに、マシンあたり何千ものアクティブテナントをホストできる必要があります。つまり各ゲストは数メガバイト以上のメモリを取れません。コールスタックだけで精一杯で、プロセスが必要とするほかのすべてには足りません。
さらに Cloudflare は、コンテキストスイッチが計算として効率的である必要があります。メモリ上の多くの Worker は、ときどきしかイベントを処理せず、多くの Worker は特定のイベントに 1 ミリ秒のごく一部しか使いません。この環境では、単一コアが 1 秒あたり何千もの異なるテナントを簡単に切り替えます。1 つのイベントを処理するには、ゲストアプリケーションとそのホストのあいだでかなりの通信が必要であり、切り替えと通信のオーバーヘッドがさらに増えます。各テナントが独自プロセスに住む場合、このオーバーヘッドは多くのテナントが 1 つのプロセスに住む場合より桁違いに大きくなります。Workers で厳格なプロセス隔離を使うと、CPU コストは共有プロセスの 10 倍にもなり得ます。
Workers を安く、速く、誰でも使える状態に保つため、Cloudflare は 1 つのプロセスで複数テナントをホストする方法を見つける必要がありました。
Spectre に公式の解決策はありません。重い仮想マシンを使う場合でもありません。誰もがまだ脆弱です。
業界は新しい Spectre 攻撃に遭遇します。数か月ごとに研究者が新しい Spectre 脆弱性を発見し、CPU ベンダーが新しいマイクロコードを公開し、OS ベンダーがカーネルパッチを公開します。全員が更新し続ける必要があります。
しかし、最新パッチを展開するだけで十分でしょうか。
まだ公開されていない脆弱性も存在します。Spectre を防御するには、Cloudflare は異なるアプローチを取る必要がありました。既知の個別脆弱性をブロックするだけでは足りません。代わりに、脆弱性のクラス全体を一度に扱う必要があります。
Spectre の包括的な修正が見つかる可能性は低いです。ただし、次の思考実験は検討すべき点を提起します。
根本的に、すべての Spectre 脆弱性はサイドチャネルを使って隠れたプロセッサー状態を検出します。サイドチャネルは定義上、システムの何らかの非決定的な動作の観測を伴います。都合のよいことに、ほとんどのソフトウェア実行環境は非決定性をなくそうと懸命です。非決定的な実行はアプリケーションを信頼できなくするためです。
ただし、まだ一般的な非決定性の種類はいくつかあります。最も明らかなのはタイミングです。業界は、プログラムが毎回同じ時間かかるべきだという考えをずっと前にあきらめました。決定的なタイミングはヒューリスティックな性能最適化と根本的に相容れないためです。ほとんどの Spectre 攻撃は、CPU の隠れたマイクロアーキテクチャ状態を検出する手段としてタイミングに焦点を当てます。
タイマーを不正確にする、またはランダムノイズを加えることで解決できるという提案もあります。ただし、これでは攻撃は止まらず、遅くなるだけだとわかります。タイマーが実時間をまったく追跡するなら、不正確にするためにできることは、攻撃を何度も実行し統計で不整合を取り除くことで克服できます。
多くのセキュリティ研究者は、これで話が終わると見なします。攻撃がまだ可能なら、遅くすることに何の意味があるのでしょうか。
ただし、攻撃を遅くする措置は強力になり得ます。
重要な洞察は次です。攻撃が遅くなるにつれ、さらに遅くするための新しい手法が実用的になります。目標は、十分な手法を連鎖させて、攻撃が興味を失うほど遅くなることです。
暗号の多くは、結局のところ技術的には総当たり攻撃に脆弱です。技術的には、十分な時間があれば破れるのです。ただし必要な時間が数千年（あるいは数十億年）なら、それは十分な防御です。
Spectre 攻撃を無意味なほど遅くするために、何ができるでしょうか。
Workers は、顧客がネイティブコードのバイナリを Cloudflare ネットワーク上で実行するためにアップロードすることを許可しません。JavaScript と WebAssembly だけです。Python、Rust、Cobol などほかの多くの言語は、これら 2 つの形式のいずれかにコンパイルまたはトランスパイルできます。どちらも V8 を通して、真のネイティブコードへ変換されます。
これ自体は、Spectre 攻撃を必ずしも難しくしません。ただし、次のステップを可能にする基礎であるため、ステップ 0 として示します。
ネイティブコードプログラムを受け入れることは、既存の CPU アーキテクチャ（通常は x86）に縛られることを意味します。妥当な性能でコードを実行するには、通常、実際のハードウェア上でコードを直接実行する必要があり、その実行の進み方に対するホストの制御は大きく制限されます。たとえば、カーネルやハイパーバイザーには、アプリケーションが CLFLUSH 命令を呼び出すことを禁止する能力がありません。この命令は サイドチャネル攻撃で有用 ↗ であり、ほかにはほとんど用途がありません。
さらに、ネイティブコードのサポートは通常、既存のオペレーティングシステムとソフトウェアスタック全体のサポートを意味し、それらにはアーキテクチャがその下でどう動くかについての数十年の期待が付いてきます。たとえば x86 CPU は、カーネルやハイパーバイザーが高精度タイマーを読む RDTSC 命令を無効にできます。ただし現実的には、無効にすると多くのプログラムが壊れます。現在時刻を知りたいときはいつでも RDTSC を使うよう実装されているためです。
ネイティブコードのサポートは、将来の緩和手法の選択肢を制限します。抽象的な中間形式を使う方が自由度は大きくなります。
Workers では、Date.now() を呼び出して JavaScript Date API で現在時刻を取得できます。ただし返される時刻値は現在時刻ではありません。Date.now() は最後の I/O の時刻を返します。コード実行中は進みません。たとえば攻撃者が次を書くとします。
let start = Date.now();
for (let i = 0; i < 1e6; i++) {
doSpectreAttack();
}
let end = Date.now();start と end の値は常にまったく同じです。攻撃者は攻撃を実行するために必要な、自分のコードの実行時間測定に Date を使えません。
同様に、Workers ではマルチスレッドと共有メモリは許可されません。1 つのイベント処理に関連するすべては同じスレッドで起きます。そうでなければ、スレッドを競わせて基盤タイマーを推測・確認できるようになります。複数の Worker が同じリクエストを同時に処理することは許可されません。たとえば、ゾーンに Workers で実装された Cloudflare App をインストールし、ゾーン自体も Workers を使う場合、ゾーンへのリクエストは実際には 2 つの Worker が順に処理することがあります。これらは同じスレッドで動きます。
この時点で、コード実行時間のローカル計測は防げます。ただし、リモートではまだ計測できます。たとえば、Worker の実行を起こすリクエストを送る HTTP クライアントは、Worker の応答にかかる時間を計測できます。そのような計測は、インターネットを横断し一般的なネットワーキングコストを伴うため、非常にノイズが多い可能性が高いです。そのようなノイズは、理論上は攻撃を何度も実行して平均を取ることで克服できます。
敵対的テストと一流の Spectre 専門家の助けを借りても、Cloudflare は本番で動くリモートタイミング攻撃を開発できていません。ただし、動く攻撃がないことは、Workers が防御の構築を止める理由にはなりません。代わりに Workers チームは現在、より高度な措置をテストしています。
攻撃が可能だとしても、実行には長い時間がかかります。少なくとも数時間、おそらく数週間です。ただし攻撃が 1 秒でも動くと、さらなる措置を起こすために使える新しいデータが大量にあります。
Spectre 攻撃は、通常のプログラムでは普通見られない異常な動作を示します。これらの攻撃は、マイクロアーキテクチャ効果を増幅するために、意図的に病理的な性能シナリオを作ろうとします。上記で議論した緩和を克服するために、攻撃がすでにループで数十億回実行せざるを得ない場合は特にそうです。これは CPU パフォーマンスカウンターなどのメトリクスに現れがちです。
さて、パフォーマンスメトリクスで Spectre 攻撃を検出するときの通常の問題は、偽陽性がときどきあることです。正当なプログラムが悪い挙動をすることもあります。ランタイムは、性能が悪いという理由ですべてのアプリケーションを止められません。
代わりにランタイムは、疑わしいパフォーマンスメトリクスを持つ Worker を専用プロセスへ再スケジュールすることを選びます。前述のとおり、オーバーヘッドが高すぎるため、すべての Worker でこれを行うことはできません。ただし防御メカニズムとして少数の Worker プロセスを隔離することは許容できます。Worker が正当なら、少しオーバーヘッドが増えた状態で動き続けます。幸い Cloudflare は、ほぼいつでも Worker を専用プロセスへ移せます。
実際、精巧なパフォーマンスカウンターベースのトリガーさえ、ここでは必要ないかもしれません。Worker がイベントあたり大量の CPU 時間を使うなら、コンテキストスイッチの頻度が低いため、専用プロセスへ隔離するオーバーヘッドは相対的に小さくなります。そのためランタイムは、CPU を多く使う Worker にプロセス隔離を使ってもよいかもしれません。
Worker が隔離されると、Cloudflare はほとんどのデスクトップ Web ブラウザーと同様に、オペレーティングシステムの Spectre 防御に頼れます。
Cloudflare は Graz Technical University の専門家と協力して、このアプローチを開発してきました。TU Graz のチームは Spectre 自体を共同発見し、それ以降の多数の続発見にも責任を持っています。Cloudflare は Worker を動的に隔離する能力を開発し、攻撃を確実に検出するメトリクスを特定しました。
前述のとおり、プロセス隔離は完全な防御ではありません。時間とともに Spectre 攻撃の実行は遅くなる傾向があり、Cloudflare は悪意ある行為者を合理的に推測・識別できます。プロセスをさらに隔離すると、潜在的な攻撃はさらに遅くなります。
この時点で、既知の攻撃はすべて防げています。これにより Workers は、ほかのすべての CPU ベースのシステムと同様に、将来の未知の攻撃に対して脆弱なままです。ただし新しい攻撃は一般に非常に遅く、数日以上かかるため、Cloudflare には防御を準備する時間があります。
たとえば、Workers ランタイム全体を毎日再起動することは妥当です。これによりメモリ内のすべての場所がリセットされ、攻撃は秘密の場所を発見するプロセスを再開せざるを得なくなります。Cloudflare は Worker を物理マシンや cordon をまたいで再スケジュールすることもでき、特定の近傍を攻撃できる窓は限定されます。
一般に、Workers は本質的にプリエンプト可能（コンテナーや VM と異なる）なため、Cloudflare は攻撃を妨害する大きな自由度を持ちます。
Cloudflare はこれを、完了するものではなく、継続的な投資と見なしています。