Speculative execution আর নিরাপত্তা — Spectre, Meltdown আর প্রতিরক্ষা

১ · দুই রকম অবস্থা — architectural বনাম microarchitectural

পর্ব ৩৭-এ (branch prediction) দেখেছেন, CPU শাখার ফল জানার আগেই অনুমান করে এগিয়ে যায়। পর্ব ৪০-এ (out-of-order execution) এই ধারণা আরও বড় হয়: শত খানেক instruction ক্রমের বাইরে চলে, আর reorder buffer শেষে প্রোগ্রাম-ক্রমে ফল জমা (commit) করে। অনুমানের ভিত্তিতে আগেভাগে কাজ করার এই পদ্ধতির নাম speculative execution. অনুমান ভুল হলে flush — ভুল পথের সব ফল ফেলে দেওয়া হয়, যেন কিছুই ঘটেনি।

“যেন কিছুই ঘটেনি” — এই কথাটি কতটা সত্য? উত্তর নির্ভর করে আমরা কোন অবস্থার কথা বলছি তার ওপর। CPU-র অবস্থা দুই স্তরের:

• Architectural state — ISA যা প্রতিশ্রুতি দেয়: register, PC, মেমরির বিষয়বস্তু, CSR. প্রোগ্রাম instruction দিয়ে এগুলো সরাসরি পড়তে পারে। ভুল অনুমানের পর এগুলো নিখুঁতভাবে আগের অবস্থায় ফেরে — এটাই precise exception আর flush-এর প্রতিশ্রুতি (পর্ব ৩৮, precise বনাম imprecise).
• Microarchitectural state — নির্দিষ্ট chip-এর ভেতরের ব্যবস্থা, যা ISA-তে লেখা নেই: cache-এ কোন লাইন আছে, branch predictor-এর counter আর BTB-তে কী শেখা হয়েছে, TLB-তে কোন ঠিকানার অনুবাদ রাখা আছে। এগুলো শুধু গতিকে প্রভাবিত করে, ফলকে নয় — তাই ভুল অনুমানের পর এগুলো ফেরানোর দরকার আছে বলে কেউ ভাবেনি।

Side channel — তথ্য বেরোনোর পাশের পথ

প্রোগ্রাম cache-এর ভেতর সরাসরি পড়তে পারে না। কিন্তু একটি ডেটা cache-এ থাকলে তা পড়া দ্রুত, না থাকলে ধীর — এই পার্থক্য প্রায় শতগুণ হতে পারে (কেন, তা পর্ব ৪৪-এ, মেমরি হায়ারার্কি)। ফলে গতির মধ্যেই ভেতরের অবস্থার ছাপ থাকে। যে পথে কোনো ব্যবস্থার মূল কাজের বাইরের প্রভাব — সময়, শক্তি-খরচ, শব্দ, বিদ্যুৎ-চুম্বকীয় বিকিরণ — থেকে গোপন তথ্য আন্দাজ করা যায়, তাকে বলে side channel. যখন ছাপটি সময়ের মধ্যে, তখন বিশেষভাবে timing attack.

ধারণাটি নতুন নয়। ১৯৯৬ সালে Paul Kocher দেখান, RSA-র মতো cryptography-র হিসাবে সময় গোপন key-এর ওপর নির্ভর করলে সময় মেপেই key আন্দাজ করা যায়। ২০০৫ সালের দিকে কয়েকটি গবেষণা দেখায়, AES-এর টেবিল-ভিত্তিক বাস্তবায়নে কোন টেবিল-ঘর cache-এ আছে, তা থেকেও key-র তথ্য বেরোয়। অর্থাৎ ২০১৮-র আগেই জানা ছিল: cache ভাগাভাগি করা মানে তথ্য ভাগাভাগির ঝুঁকি. নতুন যা এল তা হলো — speculative execution নিজেই গোপন ডেটা ছুঁয়ে সেই ছাপ তৈরি করতে পারে, এমন কোডের পথে যা প্রোগ্রাম আসলে কখনো চালায়নি।

২ · Spectre v1 — bounds check-এর শাখা ভুল অনুমান হলে

Spectre প্রকাশিত হয় ২০১৮ সালের জানুয়ারির শুরুতে, Meltdown-এর সাথে একই সময়ে। কয়েকটি স্বাধীন গবেষক দল (একটি বড় প্রযুক্তি প্রতিষ্ঠানের নিরাপত্তা-গবেষণা দল আর কয়েকটি বিশ্ববিদ্যালয়ের গবেষক) প্রায় একই সময়ে আলাদাভাবে এগুলো খুঁজে পান বলে জানা যায়। Spectre একটি দুর্বলতা নয়, একটি পরিবার; প্রথম দুটি রূপ সাধারণত “variant 1” আর “variant 2” নামে পরিচিত।

প্রথম রূপের নাম bounds check bypass. সাধারণ নিরাপদ কোডে array পড়ার আগে bounds check থাকে: index সীমার ভেতরে হলেই পড়া। সমস্যা হলো, এই যাচাইটিও একটি শাখা — আর শাখার ফল জানার আগে CPU অনুমান করে। পাঠ্যবইয়ের ধাঁচটি এমন (একবারই দেখানো হলো, পাশে সংশোধিত রূপ):

// উদাহরণ — পাঠ্যবইয়ের ঝুঁকিপূর্ণ ধাঁচ (চালানোর জন্য নয়)
if (i < n) {                 // bounds check: the predictor may guess "true"
    v = table[data[i]];      // data[i] is read on the guessed path, then used as an index
}

// উদাহরণ — সংশোধিত: index masking (Linux kernel-এর array_index_nospec ধাঁচ)
if (i < n) {
    i = array_index_nospec(i, n);   // i outside 0..n-1 becomes 0, even on a guessed path
    v = table[data[i]];
}

লক্ষ করুন, প্রথম কোডে কোনো ভুল নেই — ISA-র দৃষ্টিতে i সীমার বাইরে হলে ভেতরের লাইন কখনো চলে না। ঝুঁকি দুটি শর্ত একসাথে থাকলে: (১) i বাইরের কেউ ঠিক করতে পারে (যেমন একটি system call-এর argument), আর (২) অনুমানের পথে পড়া মানটি আরেকটি মেমরি-ঠিকানার অংশ হয়। নিচের stepper-এ পুরো ঘটনাটি ধারণার স্তরে, কোনো সংখ্যা বা ঠিকানা ছাড়া। “পরে” চাপুন:

Architectural      : প্রতিটি ডাকে i সীমার ভেতরে, ঠিক ফল
Microarchitectural : শাখার counter শিখছে "শর্ত সত্য"

Architectural      : কিছুই বদলায়নি, শাখার ফল এখনো অজানা
Microarchitectural : n-এর মান cache-এ নেই -> তুলনা দেরিতে
                     predictor-এর অনুমান: "ভেতরে"

Architectural      : কিছুই commit হয়নি
Microarchitectural : সীমার বাইরের মান পড়া হলো,
                     সেই মানের ওপর নির্ভর করে একটি cache লাইন আনা হলো

Architectural      : ভুল পথের সব ফল ফেলে দেওয়া হলো
                     register, মেমরি ঠিক আগের মতো ✓
Microarchitectural : flush এটি ছোঁয় না

Architectural      : অক্ষত
Microarchitectural : গোপন মানের ওপর নির্ভরশীল cache-অবস্থা
                     -> গতির পার্থক্যে বাইরে থেকে আন্দাজযোগ্য

Barrier    : তুলনা শেষ না হওয়া পর্যন্ত পরের load অপেক্ষা করে
Index mask : অনুমানের পথেও i সীমার ভেতরে টেনে আনা হয়
ফল         : গোপন মানের ওপর নির্ভরশীল কোনো চিহ্ন তৈরি হয় না

Barrier আর masking — কোনটি কখন

Barrier: x86-এ lfence instruction এই কাজে ব্যবহৃত হয় (নির্মাতাদের নির্দেশিকা অনুযায়ী এটি আগের instruction শেষ না হওয়া পর্যন্ত পরেরগুলো শুরু হতে দেয় না); Arm তাদের নির্দেশিকায় CSDB আর পরে SB-এর মতো barrier instruction-এর কথা বলেছে। Barrier সহজ ও নিশ্চিত, কিন্তু দামি — সেই জায়গায় out-of-order-এর পুরো সুবিধা হারায়। তাই সব শাখায় নয়, শুধু ঝুঁকিপূর্ণ জায়গায় বসানো হয়।

Index masking: তুলনার ফল থেকে শাখা ছাড়াই একটি mask বানানো হয় — index বৈধ হলে সব বিট ১, না হলে সব ০ — আর index-এর সাথে AND করা হয়। Mask-এর হিসাব একটি data dependency, অনুমান নয়; তাই অনুমানের পথেও index বাইরে যেতে পারে না। দাম মাত্র কয়েকটি সরল instruction. Linux kernel-এ এই কাজের জন্য array_index_nospec() নামে একটি সহায়ক আছে, আর system call-এর মতো সীমানার কোডে ব্যবহৃত হয়।

৩ · Spectre v2 আর browser — predictor-কে অন্যের হয়ে শেখানো

দ্বিতীয় রূপের নাম branch target injection. পর্ব ৩৭-এ (BHT, BTB আর RAS) দেখেছেন, register থেকে আসা গন্তব্যের লাফ (virtual call, function pointer, switch-এর jump table) অনুমান করতে indirect branch prediction লাগে, আর BTB মনে রাখে “এই শাখা শেষবার কোথায় গিয়েছিল”। এই টেবিলগুলো সাধারণত পূর্ণ ঠিকানা দিয়ে tag করা থাকে না (জায়গা বাঁচাতে), আর একই core-এ চলা ভিন্ন প্রোগ্রাম — এমনকি user আর kernel — একই টেবিল ভাগ করতে পারত।

ধারণাটি তাই: এক প্রোগ্রাম নিজের কোডে বারবার এমন লাফ দেয় যা predictor-এর টেবিলে অন্য প্রোগ্রামের একটি indirect শাখার ঘরের সাথে মিলে যায়। ফলে অন্য প্রোগ্রামের সেই শাখা অনুমানে ভুল গন্তব্যে যায় — সেখানে থাকা বৈধ কিন্তু অপ্রাসঙ্গিক কিছু instruction ক্ষণস্থায়ীভাবে চলে আর cache-এ চিহ্ন রাখে। পর্ব ৩৭-এর return address stack-ও একই রকম ভাগাভাগি করা কাঠামো, তাই পরে return-এর অনুমান নিয়েও একই ধরনের সমস্যার কথা প্রকাশিত হয়েছে। মূল কথা: predictor-এর অবস্থা ভাগ করা থাকলে, এক পক্ষ অন্য পক্ষের অনুমান প্রভাবিত করতে পারে।

কেন browser-এর JavaScript বিশেষ চিন্তার কারণ ছিল

Browser প্রতিদিন অচেনা website-এর JavaScript চালায়। এতদিন নিরাপত্তার ভিত্তি ছিল sandbox: ভাষার নিয়ম (array-র সীমা যাচাই, pointer না থাকা) আর JIT compiler-এর (চলার সময় JavaScript-কে machine code-এ রূপান্তর করে যে compiler) যাচাই নিশ্চিত করে যে একটি পাতার কোড অন্য পাতার বা browser-এর ডেটা পড়তে পারবে না। আর অনেক সময় ভিন্ন website একই process-এ, একই address space-এ চলত। Spectre দেখায়, ভাষার bounds check-ও একটি শাখা — অনুমানের পথে সেটিও পার হয়ে যেতে পারে। অর্থাৎ একই address space-এর ভেতরে শুধু software-এর নিয়ম দিয়ে গোপনীয়তা রাখা আর নিশ্চিত নয়. Browser নির্মাতারা তাই দ্রুত পদক্ষেপ নেন (অংশ ৬-এ বিস্তারিত): ভিন্ন site আলাদা process-এ রাখা, সূক্ষ্ম timer মোটা করা, আর কিছু সুবিধা সাময়িকভাবে বন্ধ রাখা।

৪ · Meltdown — অনুমতির যাচাই কখন কার্যকর হয়

পর্ব ৩৮-এ (Exception আর interrupt) দেখেছেন, প্রতিটি প্রোগ্রাম চলে user mode-এ, আর operating system-এর kernel চলে supervisor mode-এ। Page table-এর প্রতিটি ঘরে একটি বিট বলে “এই পাতা শুধু supervisor-এর জন্য”। User mode থেকে সেই পাতা পড়ার চেষ্টা করলে page fault — একটি exception, আর kernel প্রোগ্রামটিকে থামিয়ে দেয়।

প্রশ্ন হলো, এই যাচাইয়ের ফল কখন কার্যকর হয়। Precise exception-এর নিয়মে exception নেওয়া হয় instruction যখন retire (commit) হয়, প্রোগ্রাম-ক্রমে (পর্ব ৪০-এর reorder buffer). কিছু out-of-order নকশায় অনুমতি-যাচাইয়ের ফল শুধু একটি “এটি fault করবে” চিহ্ন হিসেবে instruction-এর সাথে লেগে থাকত, আর load-এর ডেটা ততক্ষণে নির্ভরশীল instruction-গুলোর কাছে পৌঁছে যেত। Retire-এ fault ধরা পড়ে, সব ফল ফেলে দেওয়া হয় — কিন্তু মাঝের সেই ক্ষণস্থায়ী কাজ cache-এ চিহ্ন রেখে যেতে পারত। এই ধারণাকেই Meltdown বলা হয়। Spectre-এর মতো বৈধ কোড ভুল পথে চালানোর দরকার এখানে নেই; সমস্যাটি একটি নির্দিষ্ট নকশাগত সিদ্ধান্তে।

User mode-এর একটি load-এর ঠিকানা kernel-এর পাতায়
TLB / page table: পাতাটি আছে, কিন্তু supervisor-only

অনুমতি-যাচাই  : ব্যর্থ -> ROB-এর ঘরে "fault" চিহ্ন
ডেটা          : তবু ক্ষণিকের জন্য নির্ভরশীল instruction-এর কাছে
exception     : অপেক্ষায়, retire-এর সময়ের জন্য

পরের কয়েকটি instruction মানটি ব্যবহার করে
-> মানের ওপর নির্ভর করে cache-এর অবস্থা বদলায়
(কিছুই commit হয়নি)

load ROB-এর মাথায় পৌঁছাল -> page fault নেওয়া হলো
পরের সব ফল ফেলে দেওয়া হলো (precise exception) ✓
cache-এর চিহ্ন: থেকে গেল ✗

Hardware (নতুন নকশা): অনুমতি ব্যর্থ হলে ডেটা নির্ভরশীলদের কাছে যায়ই না
Software (KPTI)      : user mode-এ kernel-এর পাতা map-ই করা থাকে না
                       -> পড়ার মতো কোনো অনুবাদই নেই

কারা আক্রান্ত, আর পরের “পরিবার”

Meltdown সব CPU-তে কাজ করে না; এটি নির্ভর করে নির্দিষ্ট নকশাগত সিদ্ধান্তের ওপর, আর ২০১৮ সালে কিছু নির্মাতার কিছু প্রজন্মের নকশা আক্রান্ত ছিল। কোন মডেল আক্রান্ত, তার তালিকা নির্মাতারা নিজেরা প্রকাশ করেছিল — সঠিক তথ্যের জন্য সেটিই দেখা উচিত, অনুমান বা লোকমুখের তালিকা নয়।

পরের বছরগুলোতে একই মূল ধারণার — transient execution আর microarchitectural চিহ্ন — আরও অনেক রূপ প্রকাশিত হয়, যাদের কয়েকটির নাম Foreshadow, MDS-পরিবার (যেমন ZombieLoad, RIDL), Retbleed, Downfall. প্রতিটির নিজস্ব খুঁটিনাটি আর নিজস্ব সংশোধন আছে; এই পর্বে সেগুলোর বিস্তারিত নেই। শিক্ষার্থীর জন্য গুরুত্বপূর্ণ হলো পরিবারটিকে চেনা: যেখানেই একটি ভাগাভাগি করা ভেতরের কাঠামো (buffer, cache, predictor) ক্ষণস্থায়ী কাজের প্রভাব ধরে রাখে, সেখানেই একই প্রশ্ন ওঠে।

৫ · KPTI — kernel-এর জন্য আলাদা page table

প্রথমে বুঝি, kernel-এর পাতা user-এর page table-এ কেন থাকত। প্রতিটি system call, interrupt বা exception-এ CPU kernel-এ ঢোকে। Page table বদলানো দামি: page table-এর ভিত্তি-ঠিকানা রাখা register (x86-এ CR3, RISC-V-এ satp) বদলালে TLB-র অনেক অনুবাদ অকেজো হয়ে যেতে পারে (TLB-র কাজ পর্ব ৫০-এ, Virtual memory-র hardware; OS-এর দিক থেকে OS কোর্সের TLB পর্বে)। তাই বহু বছর ধরে OS-গুলো প্রতিটি process-এর page table-এর ওপরের অংশে পুরো kernel map করে রাখত, supervisor-only চিহ্ন দিয়ে। Kernel-এ ঢোকা মানে শুধু mode বদল, page table বদল নয় — দ্রুত। Meltdown দেখাল, আক্রান্ত নকশায় এই চিহ্নের ওপর ভরসা করা যায় না।

সমাধান KPTI (kernel page-table isolation). এর ভিত্তি ২০১৭ সালে প্রকাশিত একটি একাডেমিক প্রস্তাব, KAISER — যা মূলত অন্য একটি kernel-সুরক্ষা (kernel-এর ঠিকানা এলোমেলো রাখা) রক্ষার জন্য প্রস্তাবিত হয়েছিল। Meltdown প্রকাশের সময় Linux-এ এটি KPTI নামে যোগ হয়, আর অন্য বড় OS-গুলোও একই ধারণার নিজস্ব রূপ আনে বলে জানা যায়। নিচের stepper-এ ধারণাটি:

খরচের মোটা হিসাব — শুধু অনুমিত মান দিয়ে

KPTI-র খরচ কত, তা নির্ভর করে CPU, OS-এর সংস্করণ, ASID আছে কি না আর workload-এর ওপর — একটি সংখ্যা সবার জন্য সত্য নয়। কিন্তু ধরনটি একটি সরল সূত্রে বোঝা যায়: প্রতি সেকেন্ডে kernel-এ কতবার ঢোকা হয়, গুণ প্রতিবারের বাড়তি সময়। নিচের calculator-এর প্রতিটি সংখ্যা অনুমান, শেখানোর জন্য বেছে নেওয়া — কোনো নির্দিষ্ট chip-এর পরিমাপ নয়:

// KPTI overhead estimator. EVERY number below is an ASSUMPTION for teaching, not a measurement.
// overhead % = (kernel entries per second per core) x (assumed extra ns per entry+exit) / 1e9 x 100
const extraNs = { "no ASID": 400, "with ASID": 100 };   // ASSUMED extra cost per kernel entry+exit pair
const profiles = [                                      // ASSUMED kernel entries per second per core
  ["number crunching", 1000],
  ["desktop + browser", 20000],
  ["busy web server", 100000],
  ["database, small I/O", 400000],
];
const pct = (rate, ns) => (rate * ns / 1e9 * 100).toFixed(2) + "%";
console.log("ASSUMED VALUES ONLY - measure your own workload before deciding");
console.log("profile".padEnd(21) + "entries/s".padStart(10) + "no ASID".padStart(10) + "with ASID".padStart(11));
for (const [name, rate] of profiles)
  console.log(name.padEnd(21) + String(rate).padStart(10) +
              pct(rate, extraNs["no ASID"]).padStart(10) + pct(rate, extraNs["with ASID"]).padStart(11));
// At what rate does the assumed overhead reach 5% ?
for (const [k, ns] of Object.entries(extraNs))
  console.log(`${k}: 5% overhead at about ${Math.round(0.05 * 1e9 / ns)} entries/s`);

ASSUMED VALUES ONLY - measure your own workload before deciding
profile               entries/s   no ASID  with ASID
number crunching           1000     0.04%      0.01%
desktop + browser         20000     0.80%      0.20%
busy web server          100000     4.00%      1.00%
database, small I/O      400000    16.00%      4.00%
no ASID: 5% overhead at about 125000 entries/s
with ASID: 5% overhead at about 500000 entries/s

৬ · প্রতিরক্ষার অন্য স্তরগুলো — retpoline থেকে browser আর microcode

কোনো একটি প্রতিরক্ষা সব রূপ ঠেকায় না। তাই বাস্তবে কয়েকটি স্তর একসাথে কাজ করে — hardware, firmware, OS, compiler, application. নিচের কার্ডগুলোতে প্রধান স্তরগুলো, ধারণার স্তরে:

Compiler-এর বিকল্প (সংস্করণভেদে বদলায়)

বড় compiler-গুলো এই প্রতিরক্ষাগুলো স্বয়ংক্রিয়ভাবে যোগ করার বিকল্প এনেছে। উদাহরণ হিসেবে, GCC-তে -mindirect-branch=thunk-ধাঁচের আর Clang-এ -mretpoline বিকল্প retpoline বসায়; LLVM-এ “speculative load hardening” নামে একটি বিস্তৃত (আর দামি) v1-প্রতিরক্ষার বিকল্প আছে; Microsoft-এর C/C++ compiler-এ /Qspectre কিছু v1-ধাঁচের জায়গায় barrier বসায় বলে নথিতে বলা আছে। বিকল্পের নাম, আচরণ আর কভারেজ সংস্করণভেদে বদলায়, আর কোনোটিই সব ঝুঁকিপূর্ণ জায়গা নিশ্চিতভাবে ধরে না — তাই নিজের compiler-এর বর্তমান ডকুমেন্টেশন দেখে নেওয়াই নিয়ম।

Browser-এর প্রতিরক্ষা

• Site isolation: ভিন্ন website-এর পাতা আলাদা operating-system process-এ চালানো। তখন একটি পাতার কোড অনুমানের পথেও অন্য site-এর ডেটা নিজের address space-এ পায় না — process-এর সীমানা hardware-এর page table দিয়ে রক্ষিত। ডেস্কটপ browser-এ ২০১৮ সালের দিকে এটি ব্যাপকভাবে চালু হতে শুরু করে বলে জানা যায়; বেশি মেমরি লাগে, এটিই এর দাম।
• মোটা timer: সূক্ষ্ম সময় মাপার API-গুলোর (যেমন performance.now()) নির্ভুলতা কমানো হয়, আর কিছুটা এলোমেলোতা যোগ করা হয়। এটি মূল সমস্যা সারায় না, শুধু কঠিন করে — তাই একা যথেষ্ট নয়।
• SharedArrayBuffer আর cross-origin isolation: একাধিক thread-এ ভাগ করা মেমরি দিয়ে নিজেই সূক্ষ্ম timer বানানো যায়, তাই ২০১৮ সালে প্রধান browser-গুলো এই সুবিধা সাময়িকভাবে বন্ধ করে। পরে এটি ফেরে একটি শর্তে: পাতাটিকে নির্দিষ্ট HTTP header (COOP আর COEP) দিয়ে নিজেকে “cross-origin isolated” ঘোষণা করতে হয়, যাতে অন্য origin-এর সম্পদ অনুমতি ছাড়া সেই process-এ ঢুকতে না পারে। খুঁটিনাটি browser-ভেদে আর সময়ের সাথে বদলেছে।

Microcode, firmware, OS আর নতুন hardware

অনেক প্রতিরক্ষা চালু করতে CPU-র নিজস্ব সহায়তা লাগে, যা আসে microcode update-এ (পর্ব ৩৪-এ দেখেছেন, x86-এর microcode update). এগুলো পৌঁছায় motherboard-এর firmware (BIOS/UEFI) update-এ, অথবা OS প্রতিবার চালু হওয়ার সময় লোড করে। পরের প্রজন্মের chip-গুলোতে নির্মাতারা কয়েকটি সমস্যা hardware-এই সারানোর কথা জানিয়েছেন, ফলে সেখানে software-প্রতিরক্ষার প্রয়োজন ও দাম কমে। কোন chip-এ কোনটি সারানো, তা নির্মাতার নিজস্ব নিরাপত্তা-নির্দেশিকায় দেখতে হয়।

গতির দাম

প্রতিটি স্তরের কিছু দাম আছে: KPTI kernel-প্রবেশে, retpoline প্রতিটি indirect লাফে, barrier যেখানে বসে সেখানে, site isolation মেমরিতে, predictor মোছা context switch-এর পরে নতুন করে শেখায়। কত দাম, তা workload, chip-এর প্রজন্ম আর OS-এর সংস্করণভেদে অনেক বদলায় — system call-ভারী আর I/O-ভারী কাজে প্রভাব বেশি চোখে পড়ে বলে জানা যায়। কোনো একটি শতাংশ সবার জন্য সত্য নয়; নিজের কাজের benchmark-ই নির্ভরযোগ্য উত্তর।

কোন সিস্টেমে কোন স্তরগুলো প্রাসঙ্গিক? নিচের সাহায্যকারী প্রোগ্রামটি কয়েকটি সাধারণ ধরনের সিস্টেমের জন্য একটি তালিকা ছাপে। এটি একটি শিক্ষামূলক চেকলিস্ট, নিরাপত্তা-নিরীক্ষা নয়:

// Defence-layer checklist: which layers matter for which kind of system.
// A teaching aid, not a security audit - always follow the vendor's own guidance.
const layers = [
  ["Keep the OS kernel updated (KPTI, branch-prediction controls)", p => p.os],
  ["Install firmware updates (BIOS/UEFI, CPU microcode if any)",   p => p.os || p.firmware],
  ["Keep the browser updated (site isolation, coarse timers)",     p => p.browser],
  ["Update the hypervisor; isolate tenants (SMT / core policy)",   p => p.tenants],
  ["Build with compiler mitigations where the vendor advises",     p => p.builds],
  ["Use vetted constant-time crypto libraries",                    p => p.crypto],
  ["Read the vendor advisory for this exact CPU or SoC",           p => true],
];
const systems = {
  "home laptop, browser user": { os: true, browser: true },
  "multi-tenant cloud host":   { os: true, firmware: true, tenants: true, crypto: true },
  "backend developer":         { os: true, browser: true, builds: true, crypto: true },
  "small embedded controller": { firmware: true },   // runs no untrusted code
};
for (const [name, p] of Object.entries(systems)) {
  const apply = layers.filter(([, rule]) => rule(p)).map(([text]) => text);
  console.log(`${name} -> ${apply.length} layer(s)`);
  apply.forEach(t => console.log("   - " + t));
}

home laptop, browser user -> 4 layer(s)
   - Keep the OS kernel updated (KPTI, branch-prediction controls)
   - Install firmware updates (BIOS/UEFI, CPU microcode if any)
   - Keep the browser updated (site isolation, coarse timers)
   - Read the vendor advisory for this exact CPU or SoC
multi-tenant cloud host -> 5 layer(s)
   - Keep the OS kernel updated (KPTI, branch-prediction controls)
   - Install firmware updates (BIOS/UEFI, CPU microcode if any)
   - Update the hypervisor; isolate tenants (SMT / core policy)
   - Use vetted constant-time crypto libraries
   - Read the vendor advisory for this exact CPU or SoC
backend developer -> 6 layer(s)
   - Keep the OS kernel updated (KPTI, branch-prediction controls)
   - Install firmware updates (BIOS/UEFI, CPU microcode if any)
   - Keep the browser updated (site isolation, coarse timers)
   - Build with compiler mitigations where the vendor advises
   - Use vetted constant-time crypto libraries
   - Read the vendor advisory for this exact CPU or SoC
small embedded controller -> 2 layer(s)
   - Install firmware updates (BIOS/UEFI, CPU microcode if any)
   - Read the vendor advisory for this exact CPU or SoC

৭ · Constant-time কোড — গোপন ডেটার ওপর শাখা বা index নয়

Spectre-এর আগেও cryptography-র জগতে একটি নিয়ম ছিল, যা এখন আরও জরুরি: গোপন ডেটা কখনো ঠিক করবে না কোন শাখা নেওয়া হবে, কোন মেমরি-ঠিকানা পড়া হবে, বা কোনো instruction কত সময় নেবে। এই নিয়মে লেখা কোডকে বলে constant-time code. নামটি একটু বিভ্রান্তিকর — এর মানে “সবসময় ঠিক একই nanosecond” নয়, বরং “সময় আর মেমরি-প্রবেশের ধরন গোপন মানের ওপর নির্ভর করে না”।

সবচেয়ে সাধারণ উদাহরণ দুটি byte-array-র তুলনা — যেমন একটি message authentication code (MAC) বা টোকেন মেলানো। সাধারণ তুলনা প্রথম অমিলেই থেমে যায়: প্রথম byte-ই না মিললে কাজ এক ধাপ, শেষ byte-এ অমিল হলে আট ধাপ। বাইরে থেকে কেউ সময়ের পার্থক্য দেখতে পেলে, তার অনুমান কতটা সঠিক ছিল সেই আভাস পায়। নিচের প্রোগ্রাম সময় মাপে না — শুধু লুপ কতবার ঘুরল তা গোনে, যাতে কাজের পরিমাণের পার্থক্যটি স্পষ্ট দেখা যায়:

// Compare a stored 8-byte tag with a guess in two ways. We COUNT loop steps (work done), not time.
function earlyExitEqual(a, b) {
  let steps = 0;
  for (let i = 0; i < a.length; i++) {
    steps++;
    if (a[i] !== b[i]) return { equal: false, steps };  // stops at the first mismatch
  }
  return { equal: true, steps };
}
function constantTimeEqual(a, b) {           // lengths are public and equal here
  let diff = 0, steps = 0;
  for (let i = 0; i < a.length; i++) {
    steps++;
    diff |= a[i] ^ b[i];                      // remember any difference, never stop early
  }
  return { equal: diff === 0, steps };
}
const stored = [0x3a, 0x91, 0x5c, 0x07, 0xe2, 0x48, 0xbd, 0x16];
const cases = [["mismatch at byte 0", 0], ["mismatch at byte 3", 3], ["mismatch at byte 7", 7], ["all 8 bytes equal", -1]];
console.log("guess".padEnd(20) + "early-exit".padStart(13) + "constant-time".padStart(15));
for (const [label, pos] of cases) {
  const guess = stored.slice();
  if (pos >= 0) guess[pos] ^= 0xff;           // flip one byte to create a mismatch
  const e = earlyExitEqual(stored, guess), c = constantTimeEqual(stored, guess);
  console.log(label.padEnd(20) + `${e.equal}, ${e.steps}`.padStart(13) + `${c.equal}, ${c.steps}`.padStart(15));
}
console.log("(each cell: result, loop steps)");

guess                  early-exit  constant-time
mismatch at byte 0       false, 1       false, 8
mismatch at byte 3       false, 4       false, 8
mismatch at byte 7       false, 8       false, 8
all 8 bytes equal         true, 8        true, 8
(each cell: result, loop steps)

Constant-time-এর তিনটি নিয়ম

৮ · বাস্তব করণীয় আর নকশার শিক্ষা — গতি বনাম নিরাপত্তা

কার কী করণীয়

Linux-এ kernel নিজেই জানায় কোন দুর্বলতার জন্য কোন প্রতিরক্ষা চালু আছে। নিচে কমান্ড আর আউটপুটের ধরন (আপনার machine-এ লাইনগুলো ভিন্ন হবে):

# উদাহরণ — Linux-এ প্রতিরক্ষার অবস্থা দেখা (শুধু পড়া, কিছু বদলায় না)
$ grep . /sys/devices/system/cpu/vulnerabilities/*
.../meltdown:Not affected
.../spectre_v1:Mitigation: ...
.../spectre_v2:Mitigation: ...
# প্রতিটি লাইনের তিন ধরনের উত্তর: "Not affected", "Mitigation: ..." বা "Vulnerable"

“Vulnerable” দেখলে প্রথম কাজ OS আর firmware হালনাগাদ করা, তারপর distribution-এর নিরাপত্তা-নির্দেশিকা পড়া। lscpu-এর আউটপুটেও একই তথ্য “Vulnerability” লাইনে দেখা যায়। OS-এর দিক থেকে নিরাপত্তা আর বিচ্ছিন্নতা নিয়ে আরও দেখুন OS কোর্সের নিরাপত্তা পর্বে আর sandboxing পর্বে।

Cloud-এ একাধিক গ্রাহক

Cloud-এ একটি physical server-এ অনেক গ্রাহকের virtual machine চলে, যারা cache, predictor, এমনকি SMT-তে একই core ভাগ করতে পারে। Linux-এ “core scheduling” নামে একটি সুবিধা আছে, যা একই core-এর sibling thread-এ শুধু পরস্পরকে বিশ্বাস করা কাজ চালাতে সাহায্য করে। গ্রাহক হিসেবে আপনার করণীয়: নিজের virtual machine-এর OS হালনাগাদ রাখা, আর অত্যন্ত সংবেদনশীল কাজের জন্য সেবাদাতার নিরাপত্তা-নথি পড়ে দেখা — যেমন একক-গ্রাহকের (dedicated) host-এর বিকল্প আছে কি না। বিস্তারিত ভাবনার প্রশ্ন ০৪-এ।

নকশার শিক্ষা — গতির প্রতিটি কৌশলের দাম

কয়েক দশক ধরে CPU দ্রুত হয়েছে অনুমান, ভাগাভাগি আর পুনর্ব্যবহারের মাধ্যমে: speculative execution, ভাগ করা cache আর predictor, SMT. প্রতিটিই এই অনুমানের ওপর দাঁড়িয়ে যে “ভেতরের অবস্থা ফলকে বদলায় না, তাই নিরাপত্তার প্রশ্নও নয়”। Spectre আর Meltdown দেখাল, ফল না বদলালেও সময় বদলায়, আর সময় তথ্য বহন করে। ফলে নকশাকারদের এখন গতির প্রতিটি কৌশলের সাথে জিজ্ঞেস করতে হয়: কে এই ভেতরের অবস্থা বদলাতে পারে, আর কে তার প্রভাব দেখতে পারে?

গবেষণা কয়েক দিকে সাড়া দিয়েছে। এক, নতুন hardware-নকশার প্রস্তাব — অনুমানের পথে আনা ডেটা আলাদা জায়গায় রাখা আর অনুমান নিশ্চিত হলে তবেই cache-এ বসানো, বা গোপন হতে পারে এমন মানের ওপর নির্ভরশীল ক্ষণস্থায়ী কাজ আটকে রাখা (২০১৮-১৯ সালের দিকের InvisiSpec, STT-র মতো প্রস্তাব)। দুই, hardware আর software-এর মধ্যে নতুন “চুক্তি” — ISA-র মতোই একটি আনুষ্ঠানিক বর্ণনা, কোন তথ্য সময়ের মাধ্যমে বেরোতে পারে আর কোনটি নয়। তিন, compiler আর বিশ্লেষণ টুল, যা ঝুঁকিপূর্ণ জায়গা খোঁজে বা constant-time নিয়ম যাচাই করে। আর software-এর দিকে একটি স্পষ্ট শিক্ষা: বিশ্বাসের সীমানা যেন process বা virtual machine-এর মতো hardware-রক্ষিত সীমানা হয়, একই address space-এর ভেতরে শুধু ভাষার নিয়ম নয়।

৯ · AI-এর যুগে — নিরাপত্তার প্রশ্নে AI, আর যাচাইয়ের অভ্যাস

এই বিষয়ে AI টুল ধারণা ব্যাখ্যায় ভালো, কিন্তু তিন জায়গায় সতর্ক থাকতে হয়: তারিখ ও নাম গুলিয়ে ফেলা, কোন chip আক্রান্ত তা আত্মবিশ্বাসের সাথে বানিয়ে বলা, আর প্রতিরক্ষার খরচের শতাংশ নির্দিষ্ট সংখ্যায় দাবি করা। আর একটি নিয়ম সবসময়: আক্রমণের কোড চাওয়া বা চালানো নয় — শেখার জন্য তার দরকার নেই।

AI-এর উত্তর হাতে পেলে — যাচাইয়ের চেকলিস্ট

• উত্তরে কোনো আক্রমণের কোড বা সময় মাপার কৌশল নেই — থাকলে তা বাদ দিয়ে শুধু ধারণাটুকু নিয়েছি
• প্রতিটি প্রতিরক্ষা সঠিক রূপের সাথে মেলানো হয়েছে (KPTI → Meltdown, retpoline → v2, barrier/masking → v1)
• শতাংশের হিসাব নিজে গুণ করে মিলিয়েছি, আর মনে রেখেছি এটি অনুমিত মানের ফল, পরিমাপ নয়
• কোনো chip আক্রান্ত বা নিরাপদ বলা হলে নির্মাতার প্রকাশিত নির্দেশিকায় খুঁজেছি
• তারিখ আর নাম (২০১৮-র জানুয়ারি, KAISER, retpoline) নির্ভরযোগ্য উৎসে মিলিয়েছি
• নিজের Linux machine-এ প্রতিরক্ষার অবস্থা /sys/devices/system/cpu/vulnerabilities/ থেকে পড়ে দেখেছি