Windows Virtualization Internals (חלק 1) — איפה Windows שלכם באמת רץ: hypervisor ו-partitions

מעולם לא יצרתם VM אחד, ובכל זאת System Information (msinfo32) ב-Windows 11 מציג Running בשדה Virtualization-based security. מה המשמעות של התצוגה הזו?

במחשב הזה, Windows המארח עצמו כבר רץ מעל hypervisor. ב-Windows 11, VBS מופעל כברירת מחדל בתצורות שעומדות בתנאים, למשל התקנה נקייה על חומרה תואמת, והיסוד הזה בשימוש גם אם מעולם לא יוצרים VM.¹ גם WSL2 וגם Windows Sandbox משתמשים באותו Windows hypervisor.

חלק 1 מסביר איפה Windows המארח מסיים לרוץ כשמפעילים Hyper-V, דרך חלוקת התפקידים בין CPU, זיכרון ו-I/O של devices. זה הפרק שקודם מיישר את המבט של “תוכנת VM שיושבת מעל Windows”.

“Windows Virtualization Internals” — כל 3 החלקים

מסתכלים על אותו Windows hypervisor בסדר יסוד → בידוד אבטחה → יישום ל-VMs קלות.

הנחות המאמר הזה

איך לקרוא את המאמר הזה

מפת הידע למטה היא רשימת יחסים. בקריאה ראשונה, עקבו אחרי הטקסט מ-סעיף 1, התמונה הגדולה.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 22, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

1. קודם המסקנה

כששומעים Hyper-V, אולי מדמיינים “תוכנת הרצת VM שיושבת מעל Windows”. המבנה בפועל הוא הפוך.

מרגע שמפעילים Hyper-V ועושים reboot, מי ששולט ב-CPUs ובזיכרון הפיזיים הוא ה-hypervisor, ו-Windows המארח רץ מעליו כ-partition הראשון והמועדף, ה-“root partition”.

hypervisor הוא שכבת תוכנה דקה שנכנסת בין החומרה ל-OS, יוצרת סביבות הרצה מבודדות שנקראות “partitions”, ומתווכת גישה לחומרה.² Windows המארח נכנס ל-root partition; VMs נכנסים ל-child partitions.

ה-root partition מטופל באופן מיוחד (יש לו גישה ישירה ל-devices פיזיים ומחזיק את מחסנית הניהול), אבל במובן שהוא אינו שולט ישירות ב-CPUs הפיזיים, הוא עומד באותו מעמד כמו child partition.

flowchart TB
    accTitle: המבנה הכולל אחרי הפעלת Hyper-V
    accDescr: ה-hypervisor יושב ישירות על החומרה הפיזית, ומעליו יושבים ה-root partition שמחזיק את Windows המארח וה-child partitions שמחזיקים VMs
    hw["חומרה פיזית"] --> hv["hypervisor"]
    hv --> root["root partition (Windows המארח)"]
    hv --> child1["child partitions (VMs)"]
    root -.-> stack["מחזיק את מחסנית ניהול הווירטואליזציה ו-device drivers"]

איור 1: Hyper-V אינו “תוכנת VM מעל Windows” אלא שכבה שנכנסת מתחת ל-Windows, ו-OS המארח עצמו רץ בתוך ה-root partition.

אולי תחשבו, “שום דבר לא מרגיש שונה לפני ואחרי ההפעלה, אז האם באמת התרחש היפוך כזה גדול?” כן. בדיוק לכן המבנה הזה בדרך כלל לא מורגש. במאמר הזה מפרקים את ה-diagram האחד הזה משלושה כיוונים: CPU, זיכרון, ו-I/O של devices.

2. מצד ה-CPU — עוד הרשאה אחת מתחת ל-rings

בדיון ה-CPU מבחינים בין ה-rings שמפרידים את ה-kernel מאפליקציות לבין מצבי ההרצה שמפרידים את ה-hypervisor מאורחים. שאלת הסעיף היא: גם kernel האורח רץ ב-ring 0, אז למה אין התנגשות?

2.1. חזרה על ring protection

ל-CPUs מסוג x64 יש רמות הרשאה (rings), ו-Windows מריץ kernel mode ב-ring 0 ו-user mode ב-ring 3. אפליקציות לא יכולות לגעת בחומרה ישירות כי לא ניתן להריץ הוראות מועדפות מ-ring 3.

אז איך משכנים בבטחה כמה OS kernels, שכל אחד רץ ב-ring 0, על אותו CPU פיזי? כל kernel נכתב בהנחה ש”אני שולט ב-CPU”. תנו ring 0 לכולם והם מתנגשים; תמנעו אותו והם לא ירוצו.

flowchart TB
    accTitle: הבעיה של כמה OS kernels שדורשים ring 0
    accDescr: גם kernel המארח וגם kernel האורח נכתבו בהנחת סמכות מלאה ב-ring 0, כך שסולם ה-rings המסורתי לבדו אינו יכול לשכן אותם בבטחה על אותו CPU פיזי
    k1["kernel המארח (מניח ring 0)"] --> want["דורש שליטה ב-CPU הפיזי"]
    k2["kernel האורח (מניח ring 0)"] --> want
    want --> conflict["ה-rings המסורתיים לבדם אינם יכולים ליישב את זה"]
    conflict --> need["נדרש מתווך מעל ring 0"]

איור 2: סולם ה-rings נבנה בהנחת OS אחד, ולכן שכנוע כמה kernels צריך עוד הרשאה אחת מעליו.

2.2. הרחבות וירטואליזציה — מצב השמור ל-hypervisor

מה שפותר את הבעיה הזו הוא הרחבות הווירטואליזציה של ה-CPU (Intel VT-x/AMD-V). Hyper-V דורש מעבד שיש לו את היכולת הזו.² הרחבות הווירטואליזציה מוסיפות, על ציר נפרד מה-rings המסורתיים, “מצב הרצה ל-hypervisor” ו”מצב הרצה לאורחים”. זו הרשאה חזקה אף יותר מ-ring 0, שלפעמים מכנים אותה “ring -1”.

• kernel האורח ממשיך לרוץ ב-ring 0, כמו קודם. אין צורך בשכתוב.
• עם זאת, אותו ring 0 הוא “ring 0 בתוך מצב אורח”, והוא אינו שולט ב-CPU הפיזי כולו.
• כשהאורח פוגע בפעולה מסוימת שדורשת התערבות hypervisor (הוראה שהוגדרה כ-intercept, או exception או הפרה), ה-CPU מעביר שליטה אוטומטית ל-hypervisor (VM Exit). כשה-hypervisor מסיים לטפל, הוא חוזר לאורח (VM Entry). גישות זיכרון רגילות עוברות ישר בלי VM Exit, כל עוד תרגום SLAT מצליח.

גם interrupts עובדים כך. partitions לא נוגעים במעבדים פיזיים ישירות; ה-hypervisor מקבל interrupts ומפנה אותם לכל partition.²

flowchart TB
    accTitle: זרימת הרצת אורח ו-VM Exit
    accDescr: kernel האורח והאפליקציות רצים ב-ring 0 וב-ring 3 במצב אורח; גישות זיכרון רגילות עוברות דרך תרגום SLAT, בעוד פעולות שהוגדרו כ-intercepts ו-exceptions גורמות ל-VM Exit שמעביר שליטה ל-hypervisor, שמחזיר לאורח דרך VM Entry אחרי הטיפול
    guest["רץ במצב אורח (כולל ה-kernel ב-ring 0)"] --> op{"פעולה שצריכה התערבות? (intercepts/exceptions שהוגדרו)"}
    op -->|לא| cont["להמשיך להריץ כמו שזה"]
    op -->|כן| exitEv["VM Exit (ה-CPU מעביר שליטה)"]
    exitEv --> hvp["ה-hypervisor מטפל"]
    hvp --> entry["חזרה לאורח דרך VM Entry"]
    entry --> guest

איור 3: OS האורח ממשיך לרוץ ב-ring 0 בלי שכתוב, וה-CPU קורא ל-hypervisor רק כשצריך.

הלוך-ושוב הזה דומה מאוד לזרימה שעקבנו אחריה בסדרת הזיכרון: “נכנסים ל-kernel ב-page fault, ואז חוזרים לאותה הוראה”. ה-CPU לוקח שליטה דרך מנגנון exception או מעבר, נותן למנהל ברמה גבוהה יותר להחליט, ואז חוזר. בעומק של Windows, הצורה הזו מופיעה שוב ושוב.

2.3. Type 1 ו-Type 2 — ההבדל הוא איפה זה יושב

Hypervisors מחולקים בגדול ל-Type 1 (bare-metal), שרץ ישירות על החומרה, ול-Type 2 (hosted), שרץ מעל OS מארח. Hyper-V הוא Type 1.³ VirtualBox ו-VMware Workstation (כשמריצים standalone) מסווגים כ-Type 2.

כששומעים Type 1, נוטים לדמיין “תצורת שרת בלי OS מארח”, אבל Hyper-V שונה. Windows המארח אינו נעלם; הוא “עובר דירה” לתוך ה-root partition. כשמפעילים Hyper-V ועושים reboot, ה-hypervisor עולה קודם בזמן ה-boot, ואז Windows המארח עולה כ-root partition מעליו.

flowchart TB
    accTitle: ההבדל בין hypervisors מסוג Type 1 ו-Type 2
    accDescr: ב-Type 2 ה-OS המארח יושב על החומרה וה-hypervisor וה-VMs יושבים על ה-OS המארח, ואילו ב-Hyper-V מסוג Type 1 ה-hypervisor יושב ישירות על החומרה וה-OS המארח עצמו נכנס ל-root partition מעליו
    subgraph t2 ["Type 2 (hosted)"]
        hw2["חומרה"] --> hostos["OS מארח"]
        hostos --> hv2["hypervisor"]
        hv2 --> vm2["VM"]
    end
    subgraph t1 ["Type 1 (Hyper-V)"]
        hw1["חומרה"] --> hv1["hypervisor"]
        hv1 --> root1["root partition (OS מארח)"]
        hv1 --> vm1["VM"]
    end
    vm2 ~~~ hw1

איור 4: ב-Type 2 ה-hypervisor יושב על ה-OS המארח, ואילו ב-Hyper-V מסוג Type 1 הסדר הפוך וה-OS המארח עצמו יושב על השכבה צעד אחד מתחת.

על ציר זמן של boot, השינוי שקורה כשמפעילים נראה כך.

flowchart TB
    accTitle: סדר boot אחרי הפעלת Hyper-V
    accDescr: אחרי הדלקה, ה-hypervisor עולה קודם בזמן ה-boot, אחר כך Windows המארח עולה כ-root partition מעליו, ו-VMs, VBS וכדומה עולים אחרי זה
    poweron["הדלקה ותחילת boot"] --> bhv["ה-hypervisor עולה קודם"]
    bhv --> broot["Windows המארח עולה כ-root partition"]
    broot --> blater["VMs, VBS, WSL2 וכדומה עולים מעליו"]
    broot -.-> feel["חוויית המשתמש לא משתנה"]

איור 5: היפוך הסדר כבר הסתיים לפני שמסך ה-logon מופיע, וה-OS המארח עולה על ה-hypervisor מההתחלה.

3. partitions — יחידת הבידוד

מסתכלים מקרוב על partitions, ה”ארגזים” בתמונה הגדולה. מה שרוצים להפריד כאן הוא תיווך CPU וזיכרון, שה-hypervisor מטפל בו ישירות, מ-I/O של devices, שה-root partition בדרך כלל מתווך.

3.1. תפקידים שיש רק ל-root partition

partition היא יחידה לוגית של בידוד שה-hypervisor מספק.² עם זאת, לא כל partition שווה. יש דברים שיש רק ל-root partition.

גישה ישירה ל-devices פיזיים

device drivers לדיסקים, NICs, GPUs וכדומה חיים ב-Windows שבתוך ה-root partition, לא ב-hypervisor. ל-Hyper-V ב-Windows Server יש תצורה שמקצה PCIe device מסוים ישירות ל-child partition (Discrete Device Assignment); במקרה הזה ה-root מוותר על אותו device (זה אינו זמין ב-Windows ללקוח).⁴

מחסנית ניהול הווירטואליזציה

VMMS (Virtual Machine Management Service), שמנהל יצירה, הפעלה ועצירה של VMs, ו-worker process שעולה לכל VM (vmwp.exe) רצים ב-user mode ב-root partition.⁵ אלה חלק מיכולות ניהול ה-VM של Hyper-V, ולכן הם עשויים להיעדר במארח שבו רק ה-hypervisor רץ בשביל VBS או WSL2.

הזכות ליצור child partitions

ה-root partition יוצר child partitions דרך ה-hypercall API (ממשק הקריאה לתוך ה-hypervisor).²

לתכנון הזה יש סיבה. אם שמים כל device driver בתוך ה-hypervisor עצמו, ה-hypervisor הופך ענק ומספר הבאגים ונקודות הכניסה לתקיפה גדל. ה-hypervisor מצמצם את עצמו לעבודה המינימלית של תיווך CPUs וזיכרון, ומשאיר את הטיפול ב-devices ל-Windows שב-root partition. חלוקת התפקידים הזו היא מה ששומר את Hyper-V דק.

flowchart TB
    accTitle: חלוקת תפקידים בין root partition ל-child partitions
    accDescr: ה-root partition מחזיק את מחסנית ניהול הווירטואליזציה ו-device drivers פיזיים ויוצר child partitions דרך hypercalls; child partition רואה רק devices וירטואליים בתצורה הרגילה, ותחת Discrete Device Assignment ב-Windows Server הוא ניגש ישירות ל-device שהוקצה
    subgraph rootp ["root partition"]
        vmms["VMMS ו-worker processes"]
        drv["device drivers פיזיים"]
    end
    subgraph childp ["child partition"]
        gos["guest OS"]
        vdev["בתצורה הרגילה נראים רק devices וירטואליים"]
    end
    vmms -->|יצירה וניהול דרך hypercalls| childp
    hv2["hypervisor (מצמצם את עצמו לתיווך CPU וזיכרון)"] --- rootp
    hv2 --- childp

איור 6: שמים device drivers ומחסנית ניהול בצד ה-root partition כדי לשמור את ה-hypervisor עצמו דק.

3.2. העולם כפי שנראה מ-child partition

ה-guest OS ב-child partition אינו יכול לראות חומרה פיזית ישירות בתצורת device וירטואלי רגילה (החריג היחיד הוא device שהוקצה דרך Discrete Device Assignment ב-Windows Server, כפי שתואר בסעיף הקודם). מה שהוא יכול לראות הם virtual processors, מרחב זיכרון שנראה כשלו, ו-devices וירטואליים. בקשות ל-devices וירטואליים מועברות ל-root partition דרך VMBus או ה-hypervisor.²

הקצאת זמן CPU ותרגום זיכרון דרך SLAT, לעומת זאת, מטופלים ישירות על ידי ה-hypervisor בלי לעבור דרך ה-root. מה שה-root מתווך הוא I/O של devices, לא כל משאב פיזי.

flowchart TB
    accTitle: העולם כפי שנראה מ-child partition
    accDescr: מה שה-guest OS רואה הוא virtual processors, מרחב זיכרון פרטי ל-partition, ו-devices וירטואליים; בקשות ל-devices וירטואליים מועברות ל-root partition דרך VMBus וכדומה, זמן CPU ותרגום זיכרון מטופלים ישירות על ידי ה-hypervisor, ובתצורת Discrete Device Assignment ב-Windows Server רק ה-devices שהוקצו נגישים ישירות
    gos2["guest OS ב-child partition"] --> vcpu["virtual processors"]
    gos2 --> gpa2["מרחב זיכרון פרטי"]
    gos2 --> vdev2["devices וירטואליים"]
    vdev2 -->|"דרך VMBus וכדומה"| rootx["מועבר ל-root partition"]
    gos2 -.->|לא נראה ישירות| phys2["CPUs פיזיים, RAM ו-devices אמיתיים"]
    phys2 -.-> dda2["בתצורת DDA (Windows Server), רק devices שהוקצו נגישים ישירות"]
    vcpu ~~~ phys2

איור 7: בתצורת device וירטואלי רגילה כל מה שהאורח רואה הוא חלון וירטואלי והנתיב לפיזי עובר דרך מתווך; רק device שהוקצה ב-DDA ב-Windows Server הוא החריג.

מה שחשוב כאן הוא שלאפליקציה שרצה על Windows המארח, המבנה הזה כמעט שקוף. קריאות Win32 API וטיפול ב-page fault עדיין מעובדים על ידי Windows kernel שבתוך ה-root partition, כמו קודם. ה-hypervisor מתערב רק כשפוגעים ב-intercept או ב-exception שהוגדרו.

4. מצד הזיכרון — לתרגום הכתובות מתווספת עוד רמה

בזיכרון מפרידים את הכתובת שהאורח מחשיב “פיזית” מהמיקום בפועל ב-RAM. מחזיקים את הסדר GVA → GPA → SPA ומי מנהל כל תרגום.

4.1. שלושה סוגי כתובת

בחלק 1 של סדרת הזיכרון עקבנו אחרי הזרימה שבה כתובת וירטואלית מתורגמת דרך טבלת דפים לכתובת פיזית (“Page Fault ב-Windows (חלק 1): מתי כתובת וירטואלית מקבלת RAM פיזי”). בסביבה וירטואלית מתווספת עוד רמה מתחת לתרגום הזה, ויש שלושה סוגי כתובת.

ה-guest OS מתרגם GVA ל-GPA עם טבלת הדפים שלו. עם זאת, ה-GPA שהאורח רואה אינו כתובת פיזית אמיתית; זה מרחב זיכרון פרטי שמוקדש לכל partition.² מיפוי GPA על המיקום בפועל ב-RAM (SPA) הוא עבודת ה-hypervisor.

4.2. SLAT — תרגום דו-רמתי בחומרה

אם התרגום ברמה השנייה היה נעשה בתוכנה לבדה, ה-hypervisor היה צריך לעקוב אחרי כל עדכון טבלת דפים של האורח אחד-אחד, וזה אינו ריאלי מבחינת ביצועים. לכן ה-CPU מספק מנגנון שעובר על טבלאות התרגום ברמה השנייה בחומרה. זה SLAT (Second Level Address Translation); Intel EPT (Extended Page Tables) ו-AMD RVI הם המימושים.

Hyper-V הנוכחי דורש מעבד 64-bit עם SLAT.⁴

flowchart TB
    accTitle: תרגום כתובות דו-רמתי דרך SLAT
    accDescr: guest virtual address מתורגם ל-guest physical address בטבלת הדפים של ה-guest OS, ואז מתורגם הלאה ל-system physical address ב-SLAT שה-hypervisor מנהל, ומגיע ל-RAM בפועל
    gva["guest virtual address (GVA)"] -->|טבלת דפים של guest OS| gpa["guest physical address (GPA)"]
    gpa -->|"SLAT (טבלאות תרגום EPT/RVI)"| spa["system physical address (SPA)"]
    spa --> ram["RAM פיזי"]
    gpa -.-> note["שכבה שהאורח רק מאמין שהיא פיזית"]

איור 8: טבלת תרגום נוספת, שמנוהלת על ידי ה-hypervisor, יושבת מתחת לטבלת הדפים של האורח, וה-CPU עובר על שתיהן בחומרה.

SLAT אינו יכולת שקיימת רק ליעילות הרצת VM. ה-VBS שנראה בחלק 2 משתמש בתכונה ש”אפשר להחזיק טבלת תרגום SLAT שונה לכל רמת הרשאה” כחומר לגבול אבטחה. הסיבה שאפשר ליצור זיכרון שאפילו ה-kernel לא יכול לראות היא שה-hypervisor מחזיק את התרגום ברמה השנייה. זה קו עלילה לכל הסדרה, אז זוכרים נקודה אחת: “מנהל טבלאות התרגום הוא ה-hypervisor”.

5. מצד I/O של devices — VMBus ושני סוגי device

I/O של devices לוקח נתיב אחר מזמן CPU ותרגום זיכרון. משווים את השיטה שמחקה חומרה אמיתית לשיטה שמשתמשת בנתיב שמיועד לווירטואליזציה.

5.1. גבולות ה-emulated devices

הדרך הקלאסית להראות device ל-child partition היא לחקות במלואה חומרה אמיתית (למשל IDE controller ישן) בתוכנה. התאימות גבוהה כי ה-inbox drivers של ה-guest OS עובדים כמו שהם, אבל VM Exit מתרחש בכל פעם שהאורח דופק על I/O port, והביצועים לא מתרחבים.

flowchart TB
    accTitle: למה I/O ל-emulated device איטי
    accDescr: בכל פעם שהאורח מפעיל I/O port, השליטה עוברת לצד ה-hypervisor דרך VM Exit, ה-device מחוקה בתוכנה, והשליטה חוזרת לאורח, כך שהלוך-ושוב חוזר והוא איטי
    gio["האורח מפעיל I/O port"] --> vex["מתרחש VM Exit"]
    vex --> emu2["ה-device מחוקה בתוכנה"]
    emu2 --> back["חזרה לאורח דרך VM Entry"]
    back -->|חוזר בפעולת הפורט הבאה| gio

איור 9: הלוך-ושוב הזה רץ פעמים רבות מאחורי גישת דיסק אחת, ומחיר התאימות משולם בביצועים.

5.2. VMBus ו-VSP/VSC — נתיב מהיר שתוכנן לווירטואליזציה

לכן ל-Hyper-V יש מנגנון “synthetic device” שתוכנן בהנחת וירטואליזציה. יש שלושה שחקנים.²

• VMBus: ערוץ תקשורת לוגי בין partitions. הוא מספק תקשורת בין-partitions מהירה שמשתמשת ב-shared memory.³
• VSP (Virtualization Service Provider): service שיושב בצד ה-root partition, מקבל בקשות device מהילד, וגשר אותן למחסנית ה-device/backend בצד ה-root. בקשה עשויה להגיע ל-device פיזי, או להיות מטופלת ב-backend בצד המארח כמו virtual disk או virtual switch.
• VSC (Virtualization Service Consumer): synthetic device driver שנכנס ל-guest OS בצד ה-child partition. הוא שולח בקשות ל-VSP מעל VMBus.

דוגמה: איך WriteFile של אורח מגיע למארח

בקשת אחסון מ-guest OS זורמת בסדר הבא.

1. ה-WriteFile של אפליקציית האורח יורד במחסנית ה-I/O של kernel האורח.
2. בתחתית הוא מגיע ל-VSC במקום לחומרה אמיתית.
3. ה-VSC שם את הבקשה על VMBus ומוסר אותה ל-VSP ב-root partition.
4. ה-VSP מזרים את הבקשה למחסנית ה-I/O בצד ה-root. בתצורת virtual disk (VHDX) זה מטופל ככתיבה לקובץ VHDX במארח ובסופו של דבר מגיע לדיסק הפיזי.

הגישה הזו נקראת Enlightened I/O (I/O שמודע לווירטואליזציה), והיא מעלה יעילות בעקיפת שכבת ה-emulation של devices.²

flowchart TB
    accTitle: נתיב I/O של synthetic device
    accDescr: בקשת I/O מאפליקציה ב-child partition מגיעה ל-VSC דרך kernel האורח, חוצה VMBus אל VSP ב-root partition, ובמחסנית ה-I/O בצד ה-root שה-VSP מגשר אליה היא עשויה להגיע ל-device אמיתי דרך device driver פיזי, או להיות מטופלת ב-backend בצד המארח כמו virtual disk או virtual switch
    app["אפליקציה ב-child partition"] --> gk["מחסנית I/O של kernel האורח"]
    gk --> vsc["VSC (synthetic device driver)"]
    vsc -->|VMBus| vsp["VSP (צד ה-root partition)"]
    vsp --> rio["מחסנית I/O בצד ה-root"]
    rio --> pdrv["device driver פיזי"]
    rio --> hb["backend בצד המארח (virtual disk, virtual switch וכדומה)"]
    pdrv --> dev["device פיזי"]

איור 10: ב-synthetic device, I/O של האורח חוצה ל-root partition מעל VMBus ו, דרך המחסנית בצד ה-root, מגיע ל-device אמיתי או ל-backend בצד המארח.

כלומר, אם I/O דיסק או רשת של VM מהיר תלוי לא רק בצד האורח אלא גם ב-מצב מחסנית ה-I/O ו-device drivers בצד ה-root partition. הסיבה שתצפית בצד המארח הכרחית כשחוקרים בעיית ביצועים של VM היא שהנתיב באמת עובר דרך המארח.

flowchart TB
    accTitle: emulated devices מול synthetic devices
    accDescr: emulated device מחקה חומרה אמיתית כך ש-inbox drivers של האורח עובדים אבל הוא איטי; synthetic device הוא driver ייעודי שמניח VMBus והוא מהיר
    dev2{"device שמוצג ל-child partition"} --> emu["emulated device"]
    dev2 --> syn["synthetic device"]
    emu -.-> emuP["מחקה חומרה אמיתית; תאימות קודם"]
    emuP -.-> emuC["צריך התערבות בכל I/O; איטי"]
    syn -.-> synP["תוכנן סביב VMBus; מהיר"]
    synP -.-> synC["דורש driver תואם באורח"]

איור 11: משני סוגי ה-device הווירטואלי, emulated devices נושאים תאימות מיד אחרי התקנת OS, ו-synthetic devices נושאים ביצועים בשימוש יומיומי.

6. למה זה לא בעיית מישהו אחר, גם אם לעולם לא משתמשים ב-VM

6.1. VBS, WSL2 ו-Sandbox משתמשים באותו יסוד

המבנה עד כאן עשוי להיראות כמו “סיפור למי שמעמיד VMs”. כפי שנאמר בפתיחה, עם זאת, ב-Windows הנוכחי ה-hypervisor הוא חלק מחיי היומיום.

• Virtualization-based security (VBS). הוא משתמש ב-Windows hypervisor כדי ליצור סביבה מבודדת ומשכן שם יכולות אבטחה. ב-Windows 11 הוא מופעל כברירת מחדל כשמתקיימים תנאים כמו התקנה נקייה על חומרה תואמת.¹ הפירוט בחלק 2.
• WSL2. הוא מריץ Linux kernel אמיתית בתוך lightweight utility VM.⁶
• Windows Sandbox. סביבת Windows חד-פעמית שמבודדת על ידי ה-hypervisor.⁷ שניהם מכוסים בחלק 3.

flowchart TB
    accTitle: יכולות יומיום שיושבות על אותו hypervisor
    accDescr: לא רק VMs של Hyper-V אלא גם VBS, שמופעל כברירת מחדל במכשירים שעומדים בתנאים כמו התקנה נקייה, וגם WSL2 ו-Windows Sandbox, כולם בנויים על אותו Windows hypervisor
    base["Windows hypervisor"] --> f1["VMs של Hyper-V"]
    base --> f2["VBS (מופעל כברירת מחדל בהתקנות נקיות וכדומה)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["למה זה רץ גם במחשבים שמעולם לא משתמשים ב-VM"]

איור 12: יש יסוד אחד, וה-diagram הזה הוא המקום שבו ההנחה “וירטואליזציה היא סיפור למי שמשתמש ב-VMs” מתפרקת.

6.2. דו-קיום עם תוכנות וירטואליזציה של צד שלישי

עוד דבר שאנשים נתקלים בו בפועל הוא דו-קיום עם תוכנות וירטואליזציה של צד שלישי. כי ה-hypervisor משתמש בהרחבות הווירטואליזציה של ה-CPU באופן בלעדי, בסביבה שבה Windows hypervisor רץ, VirtualBox וכדומה אינם יכולים לרוץ בדרך המסורתית (הדרך שמשתמשת בהרחבות הווירטואליזציה של ה-CPU בעצמה).

לשם כך מסופק API ציבורי בשם Windows Hypervisor Platform, ומחסנית וירטואליזציה של צד שלישי יכולה לרוץ בישיבה מעל ה-Windows hypervisor.⁸ VirtualBox/VMware הנוכחיים יכולים לדור עם WSL2 בזכות המנגנון הזה, אבל הבדלי ביצועים ויכולות שבאים עם החלפת מצב נצפים לפעמים כ”אחרי שהפעלתי Hyper-V (או VBS), תוכנת הווירטואליזציה התחילה להתנהג אחרת”.

flowchart TB
    accTitle: מי הבעלים של הרחבות הווירטואליזציה של ה-CPU, והנתיב לתוכנות וירטואליזציה של צד שלישי
    accDescr: בזמן ש-Windows hypervisor רץ הוא מחזיק באופן בלעדי את הרחבות הווירטואליזציה של ה-CPU; תוכנות וירטואליזציה של צד שלישי שתומכות ב-WHP רצות מעליו דרך Windows Hypervisor Platform, בעוד מימושים שאינם תומכים ב-WHP אינם יכולים לרוץ או מוגבלים ביכולות
    vt["הרחבות וירטואליזציה של CPU (VT-x/AMD-V)"] --> hvon{"האם Windows hypervisor רץ?"}
    hvon -->|לא| direct["תוכנת צד שלישי יכולה להשתמש בהן ישירות"]
    hvon -->|כן| own["ל-hypervisor שימוש בלעדי"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["תוכנת צד שלישי שתומכת ב-WHP רצה מעליו"]
    third -.-> nowhp["מימושים שאינם תומכים אינם יכולים לרוץ, או מוגבלים"]

איור 13: יש בעלים אחד להרחבות הווירטואליזציה, ותוכנת הצד השלישי היחידה שיכולה לדור בזמן שה-hypervisor רץ היא תוכנה שתומכת ב-API הציבורי (WHP).

7. ראו זאת בעצמכם

אפשר לבדוק במחשב שלכם אם hypervisor רץ.

7.1. בדיקת ה-hypervisor ו-VBS ב-PowerShell

קודם, בדיקה שאפשר להריץ בלי הרשאות administrator.

# האם אנחנו רצים מעל hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# מצב VBS (אותו מקור כמו "Virtualization-based security" ב-msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus מחזיר את מצב הריצה של VBS כמספר (2 הוא “Running”).⁹

זהירות אחת. כל מה ש-HypervisorPresent אומר הוא “האם אנחנו רצים מעל hypervisor”; הוא אינו מבדיל root מ-child. אם מריצים אותו על Windows בתוך VM, הוא עדיין מחזיר True, כ-child partition. אם הוא True על Windows במחשב פיזי, אותו Windows נמצא בתוך ה-root partition; קוראים את זה יחד עם סביבת ההרצה.

7.2. להבדיל “רץ” מ”דרישות מוקדמות” ב-systeminfo

הבא, הקלאסי משורת הפקודה.

systeminfo

מסתכלים על “Hyper-V Requirements” בסוף הפלט. במכונה שבה ה-hypervisor עוד לא רץ, הדרישות הבודדות, כמו תמיכה ב-SLAT והאם הרחבות וירטואליזציה מופעלות, מופיעות אחת-אחת. במכונה שבה ה-hypervisor כבר רץ, במקום הדרישות מתקבלת שורה אחת: “A hypervisor has been detected. Features required for Hyper-V will not be displayed.”⁴

השורה האחת הזו היא לכן הצהרה ש-Windows שלכם רץ מעל איזה hypervisor. כמו ב-HypervisorPresent, צריך לקרוא את זה כ”בתוך ה-root partition” במחשב פיזי, או “כ-child partition” בתוך VM.

גם אם כל דרישת systeminfo היא “Yes”, זה אומר רק שצד החומרה מוכן. יכולת Hyper-V עצמה זמינה במהדורות Pro, Enterprise ו-Education, ואינה ב-Home.¹⁰

7.3. כשבודקים במסך, מבחינים איזה פריט בודקים

ב-GUI, בודקים את שורת “Virtualization-based security” תחת “System Summary” ב-msinfo32. שימו לב ש-“Virtualization: Enabled” בחלונית ה-CPU של Task Manager מראה רק אם הרחבות וירטואליזציה מופעלות ב-firmware, וזה מידע נפרד מזה אם hypervisor רץ.

flowchart TB
    accTitle: איך בודקים אם ה-hypervisor רץ
    accDescr: אם systeminfo אומר שזוהה hypervisor אתם רצים על hypervisor (בתוך ה-root partition במחשב פיזי); אם מופיעה רשימת Hyper-V Requirements הוא עוד לא רץ ולכן בודקים כל דרישה כמו SLAT, VM Monitor Mode Extensions ו-DEP, אבל כל Yes אומר רק שצד החומרה מוכן וליכולת Hyper-V יש גם דרישת מהדורה
    start2["להריץ systeminfo"] --> q1{"מה מראה שדה Hyper-V Requirements?"}
    q1 -->|A hypervisor has been detected| running["ה-hypervisor רץ (בתוך ה-root במחשב פיזי)"]
    q1 -->|הדרישות מופיעות ברשימה| notyet["ה-hypervisor עוד לא רץ"]
    notyet --> q2{"כל הדרישות Yes?"}
    q2 -->|הכול Yes| can["צד החומרה מוכן"]
    can -.-> ed["Hyper-V צריך גם Pro/Enterprise/Education"]
    q2 -->|יש No| uefi["לבדוק את הפריטים הרלוונטיים ב-UEFI/BIOS וכדומה"]

איור 14: שדה “Hyper-V Requirements” ב-systeminfo ממלא גם בדיקת מצב ריצה וגם בדיקת דרישות מוקדמות.

8. שלוש קריאות שגויות להימנע מהן בפועל

8.1. “לא הפעלנו Hyper-V, אז לווירטואליזציה אין קשר למחשבים שלנו”

גם אם לא הפעלתם את יכולת Hyper-V (כלי הניהול וסביבת הרצת ה-VM), ה-Windows hypervisor רץ אם VBS מופעל. כשחוקרים בעיית תאימות driver, בדיקת ביצועים, או תקלה בתוכנת וירטואליזציה של צד שלישי, בודקים HypervisorPresent ואת מצב הריצה של VBS, לא אם היכולת מופעלת.

8.2. “Task Manager אומר Virtualization: Enabled, אז Hyper-V רץ”

התצוגה הזו היא על הגדרת firmware (אם VT-x/AMD-V זמין). שופטים את מצב הריצה של ה-hypervisor מ-“A hypervisor has been detected” ב-systeminfo. ולהפך, אם Task Manager אומר “Disabled”, אי אפשר להפעיל גם Hyper-V וגם WSL2, אז בודקים קודם את הגדרות UEFI/BIOS.

flowchart TB
    accTitle: שלוש בדיקות שקל לבלבל
    accDescr: שדה Virtualization ב-Task Manager מראה את הגדרת ה-firmware, רשימת Windows Features מראה את מצב ההתקנה, ו-systeminfo או HypervisorPresent מראים את מצב הריצה; כל אחד עונה על שאלה אחרת
    q3{"מה רוצים לדעת?"} --> a3["האם הרחבות וירטואליזציה מופעלות ב-firmware?"]
    q3 --> b3["האם יכולת Hyper-V הותקנה?"]
    q3 --> c3["האם ה-hypervisor רץ עכשיו?"]
    a3 -.-> a3t["חלונית ה-CPU ב-Task Manager"]
    b3 -.-> b3t["דיאלוג Windows Features"]
    c3 -.-> c3t["systeminfo ו-HypervisorPresent"]

איור 15: אלה שלוש שאלות עצמאיות, והסקת השתיים האחרות מתצוגה אחת היא קריאה שגויה.

8.3. “אם ה-VM איטי, זו בעיית guest OS”

I/O של synthetic device חוצה VMBus אל VSP ב-root partition ועובר במחסנית ה-device/backend בצד ה-root (drivers פיזיים, ועוד עיבוד virtual switch ו-virtual disk). אם מסתכלים רק על counters בתוך האורח, לא תמצאו צוואר בקבוק שיושב באחסון או ב-NIC בצד המארח. העיקרון לבעיות ביצועים של VM הוא לצפות משני הצדדים: האורח והמארח (ה-root partition).

9. סיכום

• כשמפעילים Hyper-V, ה-hypervisor רץ ישירות על החומרה ו-Windows המארח רץ כ-root partition.²
• kernel של ה-guest OS ממשיך לרוץ ב-ring 0, ורק פעולות שהוגדרו כ-intercepts, ועוד exceptions, מועברות ל-hypervisor דרך VM Exit. גישות זיכרון רגילות עוברות דרך תרגום SLAT.
• רק ה-root partition מחזיק device drivers פיזיים ואת מחסנית ניהול הווירטואליזציה, והוא יוצר child partitions דרך hypercalls.²
• הזיכרון הופך לתרגום דו-רמתי GVA→GPA→SPA, והרמה השנייה מטופלת בחומרה על ידי SLAT (EPT/RVI). Hyper-V הנוכחי דורש SLAT.⁴
• I/O של devices נשלט על ידי נתיב ה-synthetic device VSC→VMBus→VSP, והביצועים תלויים גם במחסנית ה-I/O בצד המארח.²
• ב-Windows 11, כי VBS מופעל כברירת מחדל במכשירים שעומדים בתנאים כמו התקנה נקייה, זה לא חריג שה-hypervisor רץ גם במחשב שמעולם לא משתמש ב-VM.¹ אפשר לבדוק את מצב הריצה עם HypervisorPresent ועם systeminfo.

התמונה הגדולה של חלק 1 מתכנסת ל-diagram האחד הזה.

flowchart TB
    accTitle: התמונה הגדולה של חלק 1
    accDescr: ה-hypervisor יושב מתחת ל-root partition ול-child partitions; CPUs מוקצים בתיזמון virtual processors (VM Exits רק ב-intercepts ו-exceptions שהוגדרו), הזיכרון מתווך בתרגום SLAT דו-רמתי, I/O של synthetic device מועבר מעל VMBus ומטופל על ידי VSP של ה-root partition, ול-emulated devices ול-Discrete Device Assignment יש נתיבים אחרים
    up["root partition ו-child partitions"] --> hvS["hypervisor"]
    hvS --> cpuS["CPU: מקצה virtual processors"]
    hvS --> memS["זיכרון: תרגום דו-רמתי דרך SLAT"]
    hvS --> devS["devices: I/O סינתטי מועבר מעל VMBus"]
    cpuS -.-> cpuN["VM Exit רק בהתערבות"]
    devS --> vspS["מטופל על ידי VSP בצד ה-root"]
    devS -.-> devN["emulated devices ו-DDA לוקחים נתיבים אחרים"]

איור 16: תיזמון CPU ותרגום זיכרון מטופלים ישירות על ידי ה-hypervisor (VM Exits רק בהתערבות), ו-I/O של synthetic device מתווך על ידי ה-root partition (ה-VSP) מעבר ל-VMBus.

ההמשך בחלק 2, “זיכרון שאפילו ה-kernel לא רואה — VBS, HVCI ו-Credential Guard”.

אוספים את קו העלילה של המאמר הזה, שה-hypervisor מחזיק את טבלאות התרגום של SLAT, ועוקבים אחרי איך Windows יוצר “זיכרון שלא administrator ולא kernel יכולים לקרוא”.

מאמרים קשורים

• Page Fault ב-Windows (חלק 1): מתי כתובת וירטואלית מקבלת RAM פיזי
• מה באמת אומר Memory Usage ב-Windows — איך לקרוא Working Set, Private Bytes, Commit ו-pagefile
• בניית סביבת אימות לאפליקציות עסקיות עם Windows Sandbox
• Processor scheduling ב-Windows — Background services וליבות P/E

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בתכנון סביבות אימות לאפליקציות Windows, בחקירות ביצועים בסביבות וירטואליזציה, ובניתוח בעיות תאימות של drivers וציוד היקפי.

• פיתוח אפליקציות Windows
• חקירת תקלות ואיתור גורמים
• מינוף נכסים קיימים והגירה
• יצירת קשר

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

כשמפעילים Hyper-V, איפה Windows המארח באמת רץ?

ה-hypervisor לוקח שליטה ישירה על אופן הקצאת CPUs וזיכרון פיזיים, ו-Windows המארח רץ בתוך partition מיוחד שנקרא root partition. השליטה ב-devices פיזיים מטופלת בדרך כלל על ידי drivers בצד ה-root partition. ה-root partition מחזיק את ה-drivers ואת מחסנית ניהול הווירטואליזציה, אבל הבעלות על ה-CPUs הפיזיים שייכת ל-hypervisor.

האם Virtualization: Enabled ב-Task Manager אומר ש-Hyper-V רץ?

לא. התצוגה הזו מראה אם הרחבות הווירטואליזציה של ה-CPU (Intel VT-x/AMD-V) מופעלות ב-firmware. כדי לראות אם hypervisor באמת רץ, חפשו A hypervisor has been detected ב-systeminfo, או בדקו את Win32_ComputerSystem.HypervisorPresent.

למה ה-hypervisor רץ אף שמעולם לא יצרתי virtual machine?

ב-Windows 11, Virtualization-based security (VBS) מופעל כברירת מחדל במכשירים שעומדים בתנאים, למשל התקנה נקייה על חומרה תואמת, ו-VBS בנוי על ה-Windows hypervisor. אותו דבר אם משתמשים ב-WSL2 או ב-Windows Sandbox. זה לא חריג שה-hypervisor רץ בלי קשר לכך שמישהו משתמש ב-virtual machines.

מהו SLAT, ולמה Hyper-V דורש אותו?

SLAT (Second Level Address Translation) הוא המנגנון שבו ה-CPU מתרגם guest physical addresses לכתובות פיזיות אמיתיות; Intel EPT ו-AMD RVI הם המימושים. בלי זה ה-hypervisor היה צריך לתחזק את טבלאות התרגום בתוכנה, וזה לא ריאלי מבחינת ביצועים, ולכן Hyper-V הנוכחי מתייחס אליו כדרישה קשיחה.

אם אפעיל Hyper-V, VirtualBox ו-VMware יפסיקו לעבוד?

מכיוון שה-hypervisor משתמש בהרחבות הווירטואליזציה של ה-CPU באופן בלעדי, hypervisor צד שלישי לא יכול לרוץ בדרך המסורתית. עם זאת, ל-VirtualBox ול-VMware הנוכחיים יש מצב שרץ מעל ה-Windows hypervisor (דרך Windows Hypervisor Platform), כך שגרסאות עדכניות של כל אחד יכולות לדור בכפיפה אחת.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.