האם כיבוי Memory integrity (HVCI) מאיץ את Windows? — מה זה אומר, איך עושים, ואיך מחליטים

שומעים ש”כיבוי Memory integrity מאיץ את המחשב”, אבל כש-Windows Security מציג אזהרה מהססים לשנות. המאמר מפריד שתי שאלות: “האם זה יכול להיות מהיר יותר?” ו”האם מקובל לכבות במחשב שלי?”

הנושא הוא מתג Memory integrity תחת Device security > Core isolation ב-Windows Security. Memory integrity היא יכולת שמגינה על ליבת Windows מפני התקפות שמגיעות דרך drivers; זו אינה הגדרה שקיימת רק כדי להפחית ביצועים. באותו זמן, Microsoft עצמה מציינת שבמכשירי משחקים, בחלק מהתרחישים והתצורות, זה יכול להשפיע על הביצועים.¹

מתחילים במסקנה ובמדריך קריאה לפי מטרה, ואז מסבירים את המנגנון, איך להשוות ביצועים, את קריטריוני ההחלטה, איך לאמת לפני ואחרי השינוי, ואת השלבים לכיבוי ולהחזרה. אם רוצים להעמיק במנגנון, ראו את מאמר הסדרה “Windows Virtualization Internals (חלק 2) — זיכרון שאפילו ה-kernel לא רואה: VBS, HVCI ו-Credential Guard.” המאמר הזה הוא נקודת הכניסה המבואית לזה.

הנחות המאמר

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

יש תצורות שמאיצות כשמכבים. אבל לא כל מחשב מאיץ, והפרש ביצועים לבדו אינו מיישב אם מקובל לכבות.

Memory integrity (HVCI) מבצעת את אימות החתימה של drivers שנטענים ל-kernel (ליבת ה-OS) בתוך סביבה מבודדת שיוצר ה-hypervisor. על ידי הפיכת pages בזיכרון שעברו אימות בלבד לניתנות להרצה, ועל ידי כך שלעולם לא מאפשרים כתיבה ל-pages ניתנות להרצה, היא מקשה להשתלט על ה-PC דרך driver.²³

ציר ההחלטה הוא “למה המחשב הזה משמש?” אם מודדים ומוצאים הבדל, ההבדל הזה חשוב לאופן השימוש במחשב, לא משחקים משחקים שה-anti-cheat שלהם מציין HVCI בשגיאה, והמחשב אינו מטפל בנכסי חברה או במידע רגיש, אז כיבוי הוא אפשרות. אחרת, השארה דולק וחיפוש סיבה אחרת היא הדרך המעשית יותר.

המסקנה, ואיפה לקרוא עוד

גם אם רוצים רק את השלבים, קוראים את קריטריוני ההחלטה בפרק 5 ואת שיטת האימות בפרק 6 לפני שממשיכים לפרק 7. הפעולה שמכבה קצרה, אבל ה-restart והאימות הם חלק מאותה עבודה. אם המתג אפור ואי אפשר להפעיל אותו, לא עוקפים הגדרת מנהל או UEFI lock בעצמכם.

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

2. מפרידים את ארבעת המונחים שמתערבבים

קודם מפרידים את השמות במסך ההגדרות משמות המנגנונים מאחוריהם. מה שמכבים כאן הוא “Memory integrity”, לא את כל הבאים.

2.1 Memory Integrity (HVCI)

זה שם המתג במסך Core isolation ב-Windows Security. רשמית הוא נקרא hypervisor-protected code integrity (HVCI), והתיעוד של Microsoft מתייחס ל-“Memory integrity” ול-“HVCI” כאותו דבר.² כשהמאמר אומר “לכבות”, זה מה שהוא מתכוון.

2.2 Core Isolation

זה שם של מסך ב-Windows Security. הוא מקבץ את יכולות האבטחה ש”מגנות מפני תוכנות זדוניות על ידי בידוד תהליכי ליבה של Windows בזיכרון”, ו-Memory integrity הוא מתג אחד בו.³

המסך עשוי גם לרשום פריטים אחרים, כמו Kernel-mode Hardware-enforced Stack Protection. לעתים קרובות רואים את הביטוי “לכבות Core isolation”, אבל למסך כולו אין מתג; מה שבאמת מחליפים הוא מתג Memory integrity.

2.3 Virtualization-Based Security (VBS)

זה המנגנון ש-Memory integrity יושבת עליו. הוא משתמש ב-Windows hypervisor כדי ליצור סביבה מבודדת שנשארת מוגנת גם אם משתלטים על kernel של ה-OS, ומאכסן שם יכולות אבטחה.⁵

Memory integrity היא אחת מהיכולות שיושבות מעל VBS; גם Credential Guard (הגנה על credentials של דומיין) ואחרות יושבות שם. כיבוי Memory integrity אינו בהכרח עוצר את VBS עצמו (פרק 6).

2.4 Virtual Machine Platform (VMP) ו-Hyper-V

זה פריט תחת “Turn Windows features on or off”, והוא היסוד להרצת מכונות וירטואליות קלות כמו WSL 2.⁶ בהנחיית Microsoft על ביצועי משחקים, הוא רשום לצד Memory integrity כגורם בהשפעת הביצועים.¹ זה מתג נפרד ויכולת נפרדת מ-Memory integrity.

שימו לב ש-Windows Sandbox מופעל לא דרך VMP אלא דרך optional feature ייעודי שנקרא “Windows Sandbox”; הוא אינו תלוי ב-VMP, אבל הוא רץ על אותו Windows hypervisor.⁷

flowchart TB
    accTitle: איך ארבעת המונחים קשורים
    accDescr: מראה את יחס ההכלה שבו Virtualization-based Security (VBS) ו-Virtual Machine Platform יושבים על Windows hypervisor, Memory integrity ו-Credential Guard יושבים על VBS, ומסך Core isolation ב-Windows Security מציג את מתג Memory integrity
    hv["Windows hypervisor"]
    vbs["Virtualization-based Security (VBS)"]
    vmp["Virtual Machine Platform"]
    hvci["Memory integrity (HVCI)"]
    cg["Credential Guard וכו'"]
    ui["מסך Core isolation (מציג את המתג)"]
    hv --> vbs
    hv --> vmp
    vbs --> hvci
    vbs --> cg
    ui -.->|"משקף את ההגדרה"| hvci

איור 1: “Core isolation” הוא שם של מסך, “Memory integrity” הוא מתג בו, VBS הוא היסוד, ו-VMP היא יכולת נפרדת שיושבת על אותו hypervisor.

כלומר, מה שאנשים מתכוונים ב”זה מאיץ כשמכבים” הוא באמת שתי יכולות שיושבות על ה-hypervisor (Memory integrity ו-VMP), והמתג במסך ההגדרות מכבה רק את הראשונה.

3. מה Memory Integrity עושה

הפרק הזה הולך בסדר מה הוא מגן → למה הוא משפיע על ביצועים → האם הוא בכלל מופעל במחשב שלכם. אם רוצים קודם את הפרש הביצועים הצפוי, אפשר להתחיל מהטבלה בפרק 4.

3.1 העברת מחסום ה-driver מחוץ ל-kernel

ל-Windows תמיד היה מנגנון (code integrity) שבודק אם drivers שנטענים ל-kernel חתומים כראוי. הבעיה היא שהקוד שמבצע את הבדיקה עצמו נמצא בתוך ה-kernel. תוקף שהשתלט על ה-kernel יכול להחליף את הבדיקה עצמה.

Memory integrity מריצה את הבדיקה הזו בתוך הסביבה המבודדת של VBS.² הסביבה המבודדת מוגנת על ידי ה-hypervisor, כך שאפילו תוקף שהשתלט על ה-kernel אינו יכול להגיע לבדיקה. בנוסף, היא מטילה את שני הכללים הבאים על זיכרון kernel.²

• page בזיכרון kernel הופך ניתן להרצה רק אחרי שהוא עובר אימות.
• page ניתן להרצה לעולם אינו הופך לניתן לכתיבה.

flowchart TB
    accTitle: טעינת driver כש-Memory integrity מופעל
    accDescr: בקשת טעינת driver מקבלת אימות חתימה בסביבה המבודדת של VBS; אם עוברת היא מותרת כ-page ניתן להרצה ולא ניתן לכתיבה, ואם נכשלת הטעינה נחסמת ונרשמת בלוג CodeIntegrity Operational
    req["בקשת טעינת driver"] --> chk{"מאמתים את החתימה בסביבה המבודדת"}
    chk -->|"עבר"| ok["מותר כניתן להרצה, לא ניתן לכתיבה"]
    chk -->|"נכשל"| ng["טעינה נחסמת"]
    ng --> log["נרשם בלוג CodeIntegrity (3087)"]

איור 2: כי המחסום מחוץ ל-kernel, השתלטות על ה-kernel אינה מאפשרת להחליף את המחסום.

עם הכללים האלה במקום, גם אם פגיעות מאפשרת לתוקף לשכתב זיכרון kernel, התוכן המשוכתב אינו יכול להיכנס להרצה: page ניתן לכתיבה אינו ניתן להרצה, ו-page ניתן להרצה אינו ניתן לכתיבה.² התיאור ב-Windows Security, “מקשה על תוכניות זדוניות להשתמש ב-drivers ברמה נמוכה כדי לחטוף את ה-PC”,³ מתייחס לזה.

3.2 למה זה משפיע על ביצועים

להגנה יש עלות עיבוד. כאן מפרידים בין עלות השימוש ב-hypervisor לבין עלות ניהול הרשאות execute של Memory integrity.

עלות 1: Hypervisor רץ מתחת ל-Windows

VBS דורש hypervisor, וה-hypervisor דורש יכולת CPU שנקראת SLAT (second level address translation).⁵ כי Windows המארח עצמו רץ כ-partition מעל ה-hypervisor, תרגום כתובות זיכרון הופך לשתי רמות, וזה מוסיף overhead. המבנה הזה מכוסה בפירוט ב-“איפה Windows שלכם באמת רץ?”

עלות 2: ניהול האם זיכרון kernel מותר להרצה

Memory integrity אוכפת את הכלל “רק pages שעברו אימות ניתנים להרצה” לא ב-kernel עצמו אלא דרך הגנת הזיכרון של ה-hypervisor. כאן דור ה-CPU עושה הבדל.

התיעוד של Microsoft מסביר ש-Memory integrity עובד טוב יותר במעבדים עם Mode-Based Execution Control (MBEC) ב-Intel Kaby Lake (דור 7) ואילך או Guest Mode Execute Trap (GMET) ב-AMD Zen 2 ואילך. מעבדים ישנים יותר מסתמכים על אמולציה שנקראת Restricted User Mode, כך שהשפעת הביצועים גדולה יותר.⁸

MBEC היא יכולת שמפצלת הרשאת execute של זיכרון ל”מותר להריץ ב-user mode” ו-“מותר להריץ ב-kernel mode” כך שהחומרה יכולה להבחין ביניהם.⁹ Memory integrity רוצה להגביל רק הרצה ב-kernel mode, כך שעם ההבחנה הזו אפשר להשאיר את העבודה ל-CPU. בלי זה, ה-hypervisor לוקח את העבודה בתוכנה.

flowchart TB
    accTitle: שני המקומות שבהם עולה עלות הביצועים
    accDescr: עלות הביצועים של Memory integrity עולה בשני מקומות, two-level address translation שנגרם מה-hypervisor שיושב מתחת, ואכיפת הרשאת execute ל-pages של kernel בצד ה-hypervisor, וגודל האחרון תלוי אם יש MBEC/GMET
    hvci["Memory integrity מופעל"] --> c1["Hypervisor יושב מתחת ל-OS"]
    hvci --> c2["Hypervisor אוכף הרשאת execute"]
    c1 --> t1["תרגום כתובות הופך לשתי רמות"]
    c2 --> q{"ל-CPU יש MBEC / GMET?"}
    q -->|"כן"| small["מטופל בחומרה (השפעה קטנה יותר)"]
    q -->|"לא"| big["אמולציה (השפעה גדולה יותר)"]

איור 3: גודל “זה מאיץ כשמכבים” נקבע בעיקר לפי הענף מימין.

האם ל-CPU שלכם יש MBEC/GMET אפשר לראות מכך אם AvailableSecurityProperties של Win32_DeviceGuard, שמוצג בפרק 6, מכיל 7.⁸

3.3 האם זה בכלל רץ במחשב שלכם?

לפני שעוברים להשוואת הביצועים, נחוצה עוד בדיקה. Windows 11 אינו אומר אוטומטית ש-Memory integrity רץ.

Memory integrity מופעל כברירת מחדל כש-Windows 11 מותקן נקי על חומרה נתמכת; הוא אינו מופעל אוטומטית בשדרוג מ-Windows 10.⁴ התנאים להפעלה אוטומטית הם כדלקמן.⁴

כלומר, במחשב ששודרג מ-Windows 10 ומשמש כפי שהוא, במחשב שאינו עומד בתנאים, או במחשב שהיה בו אפילו driver לא תואם אחד, זה עשוי להיות כבוי מההתחלה. אם הרגשתם ש”זה האיץ אחרי שכיביתי” במצב הזה, משהו אחר היה אחראי. קודם בודקים את המצב הנוכחי בשיטה של פרק 6.

flowchart TB
    accTitle: תנאים שבהם Memory integrity מופעל כברירת מחדל
    accDescr: בהתקנה נקייה של Windows 11 הוא מופעל כברירת מחדל כשכל התנאים מתקיימים, דור CPU, 8 GB זיכרון או יותר, SSD של 64 GB או יותר, drivers תואמים, ווירטואליזציה מופעלת ב-firmware, ואינו מופעל בשדרוג או כשהתנאים אינם מתקיימים
    start["Windows 11 מותקן"] --> how{"התקנה נקייה?"}
    how -->|"Upgrade"| off1["לא מופעל אוטומטית"]
    how -->|"כן"| cond{"תנאי CPU, RAM, SSD, driver"}
    cond -->|"מתקיימים"| on["מופעל כברירת מחדל"]
    cond -->|"לא מתקיימים"| off2["לא מופעל (אפשר להפעיל ידנית)"]

איור 4: “המחשב שלי היה כבוי מההתחלה” אינו חריג. מסתכלים על המצב הנוכחי לפני שמתנסים.

4. האם זה באמת מאיץ? — חומר להחלטה

הנקודה של הפרק הזה היא שהשפעת ביצועים אפשרית, אבל אי אפשר לתת אחוז אחד לכמה זה מאיץ. קוראים בנפרד את ההסבר הרשמי, את הציפייה לכל תצורה, ואת המדידה במחשב שלכם.

4.1 מה Microsoft אומרת

מאמר התמיכה של Microsoft “Options to optimize gaming performance in Windows 11” מציין ש-Windows 11 משתמש בווירטואליזציה ל-Memory integrity (HVCI) ול-Virtual Machine Platform (VMP), ושבמכשירי משחקים, בחלק מהתרחישים ובחלק מהתצורות, עשויה להיות השפעת ביצועים מכך ש-Memory integrity ו-VMP דולקים, והוא נותן את השלבים לכיבוי כל אחד מהם.¹

לכן “זה יכול להיות מהיר יותר” הוא העמדה הרשמית של Microsoft. אבל זה מגיע עם הסייג “בחלק מהתרחישים ובחלק מהתצורות”, ולא ניתן מספר לכמה מהיר יותר.

4.2 תנאים שבהם הבדל סביר, ותנאים שבהם לא

הנה מה שהמנגנון ב-3.2 אומר לנו, לפי מצב. “הציפייה” שכתובה כאן היא מגמה שנגזרת מהמנגנון, לא מדידות שפרסמה Microsoft. למחשב שלכם, מודדים בשיטה של 4.3.

flowchart TB
    accTitle: זרימת החלטה אם כיבוי מאיץ את המחשב
    accDescr: קודם מאשרים אם Memory integrity רץ כרגע; אם לא, מחפשים סיבה אחרת; אם כן, מפצלים את הציפייה לפי אם ל-CPU יש MBEC/GMET ואם הצוואר הוא ה-CPU, ולבסוף מחליטים במדידה באותם תנאים
    s["מרגיש איטי"] --> run{"Memory integrity רץ?"}
    run -->|"לא"| other["מחפשים סיבה אחרת"]
    run -->|"כן"| cpu{"ל-CPU יש MBEC / GMET?"}
    cpu -->|"לא"| likely["הבדל סביר"]
    cpu -->|"כן"| bn{"הצוואר הוא ה-CPU?"}
    bn -->|"כן"| maybe["הבדל יכול להופיע"]
    bn -->|"לא (GPU וכו')"| small["הבדל צפוי להיות קטן"]
    likely --> measure["מודדים באותם תנאים"]
    maybe --> measure
    small --> measure

איור 5: “האם זה יאיץ?” נקבע לפי תצורת המחשב. מה שמיישב בסוף אינו ידע על המנגנון אלא מדידה במחשב שלכם.

4.3 מודדים, לא מנחשים

“מרגיש מהיר יותר מאז שכיביתי” אינו מספיק כדי לשפוט את האפקט של ההגדרה. עשיתם restart למחשב כדי לשנות את ההגדרה, וזה לבדו הופך אותו לקל זמנית.

לפני שמשנים בפועל את ההגדרה, בודקים בפרק 5 אם זה מחשב שמקובל לכבות בו. אם אחר כך משווים, שומרים על הנקודות הבאות. סדר המדידה כמו באיור 6: “מאשרים שדולק ומודדים → מכבים ועושים restart → מאשרים שכבוי ומודדים באותם תנאים.” פרק 6 מכסה איך לאמת, ופרק 7 מכסה איך לשנות את ההגדרה.

המצב והתנאים לקבע במדידה

• מאשרים שהמצב באמת השתנה. אחרי כיבוי ו-restart, משתמשים בשיטה של פרק 6 כדי לאשר ש-Memory integrity נעלם מהשירותים הרצים. אם מודדים בלי זה, אפשר להשוות on מול on.
• משאירים את התנאים זהים. חשמל AC או סוללה, מצב צריכת החשמל, מה רץ ברקע, ולמשחק אותו scene ואותן הגדרות איכות. איך ליישר תנאי השוואה מכוסה ב-“איך משווים נכון מהירות בין גרסאות תוכנה ב-Windows.”

מודדים כמה פעמים, ושואלים אם ההבדל חשוב לאופן השימוש במחשב

משתמשים במשהו שמייצר מספר: benchmark מובנה של משחק, או הזמן שמשימה קבועה לוקחת. מודדים בערך שלוש פעמים כל אחד כשדולק וכשכבוי, ומשווים את החציונים.

מה שמסתכלים עליו אינו רק אם המספר עלה. עלייה של 2% ב-fps ממוצע אינה ניתנת להבחנה על המסך. האם ה-fps המינימלי (stutter) השתפר חשוב יותר לתחושה. בודקים אם ההבדל גדול מספיק כדי להיות חשוב לאופן השימוש במחשב.

flowchart TB
    accTitle: נוהל ההשוואה on/off
    accDescr: מאשרים את המצב הנוכחי ומקבעים תנאים, מריצים את אותה מדידה כמה פעמים, משנים את ההגדרה ועושים restart, מאשרים שהמצב השתנה, חוזרים על אותה מדידה, ומחליטים לפי אם גודל ההבדל חשוב לאופן השימוש במחשב
    a["מאשרים את המצב הנוכחי (פרק 6)"] --> b["מקבעים תנאים ומודדים 3 פעמים"]
    b --> c["משנים את ההגדרה ועושים restart"]
    c --> d["מאשרים שהמצב השתנה"]
    d --> e["מודדים 3 פעמים באותם תנאים"]
    e --> f{"ההבדל גדול מספיק כדי להיות חשוב?"}
    f -->|"כן"| g["עוברים להחלטה בפרק 5"]
    f -->|"לא"| h["מדליקים שוב ומחפשים סיבה אחרת"]

איור 6: לא מבלבלים בין הקלות מיד אחרי restart לבין האפקט של ההגדרה. אישור המצב הוא תנאי מוקדם למדידה.

אם אין הבדל, מחפשים סיבה אחרת

אם לא הופיע הבדל, סיבת האיטיות נמצאת במקום אחר. לאיך לחקור כשכל ה-PC איטי, ראו “WPR/WPA בפועל — מבוא ל-performance analysis מערכתי כשכל ה-PC איטי”, ואם Efficiency mode ב-Task Manager עשוי להיות הסיבה, ראו “מה זה Windows Efficiency mode? - אייקון העלה הירוק ואיך לכבות.”

5. האם מקובל לכבות? — מה מאבדים

“זה מאיץ” ו”מקובל לכבות” הן החלטות נפרדות. גם אם מודדים ומוצאים הבדל, זה לבדו אינו סיבה לכבות. שוקלים את ההגנה שמאבדים מול למה המחשב משמש.

5.1 מה מאבדים

יש שלושה דברים להיות מודעים אליהם: הגנה חלשה יותר, אזהרה, ותוכנה שמפסיקה לעבוד.

המחסום מפני הזרקת קוד ל-kernel נעלם

Memory integrity מקשה להשתלט על ה-kernel דרך driver פגיע או driver לא חתום.² כשזה כבוי, מול התקפה מהסוג הזה המחשב חוזר להיות Windows רגיל.

Windows Security מציג אזהרה

מ-Windows 11 22H2 ואילך, כש-Memory integrity כבוי, Windows Security מציג אזהרה, וסימן אזהרה מופיע גם באייקון בשורת המשימות ובמרכז ההודעות. אפשר לדחות את האזהרה ממסך Windows Security.⁸

משחקים שדורשים HVCI עשויים לא לעלות יותר

חלק ממערכות anti-cheat (כמו Vanguard של Riot Games) משתמשות ב-HVCI (Memory integrity) ב-Windows 11 כדי לאמת שלמות מערכת.

מאמר התמיכה של Riot אומר להפעיל כל אחת מיכולות האבטחה שרשומות בשגיאת VAN: RESTRICTION (כל אחד מ-TPM 2.0, Secure Boot, Memory integrity ו-IOMMU). במחשב שבו השגיאה מציינת HVCI, המשחק לא יעלה אלא אם זה דולק.¹⁰

זה אינו תנאי שמוטל באופן אחיד על כל מחשב, אבל כיבוי בשביל “המשחק שרוצים להאיץ” יכול להשאיר משחק אחר לא מסוגל לעלות.

flowchart TB
    accTitle: מה מאבדים כש-Memory integrity כבוי
    accDescr: כש-Memory integrity כבוי, המחסום מפני הזרקת קוד ל-kernel נעלם, ב-Windows 11 22H2 ואילך Windows Security ממשיך להציג אזהרה, ומשחקים שה-anti-cheat שלהם מציין HVCI בשגיאה כבר לא עולים
    off["Memory integrity כבוי"] --> l1["המחסום מפני הזרקת קוד ל-kernel נעלם"]
    off --> l2["Windows Security מציג אזהרה"]
    off --> l3["משחקים שמציינים HVCI מפסיקים לעבוד"]

איור 7: מאבדים שלושה דברים. מחליטים אם הפרש המהירות שווה את זה רק אחרי שמסתכלים על שלושת אלה.

5.2 קווים מנחים להחלטה

flowchart TB
    accTitle: החלטה אם מקובל לכבות
    accDescr: מחשבים שמעורבים בנתונים עסקיים או ברשת המשרד נשארים דולקים, מחשבים שמשחקים משחקים שה-anti-cheat שלהם מציין HVCI בשגיאה נשארים דולקים, רק מכונה ייעודית שבה מדידה הראתה הבדל היא מועמדת לכיבוי, וכל השאר נשארים דולקים ומחפשים סיבה אחרת
    q1{"מעורב בנתונים עסקיים או ברשת המשרד?"} -->|"כן"| keep1["משאירים דולק (מחפשים סיבה אחרת)"]
    q1 -->|"לא"| q2{"משחקים משחקים שמציינים HVCI?"}
    q2 -->|"כן"| keep2["משאירים דולק"]
    q2 -->|"לא"| q3{"מדידה הראתה הבדל?"}
    q3 -->|"כן"| off["כיבוי הוא אפשרות (מדליקים שוב אם השימוש משתנה)"]
    q3 -->|"לא"| keep3["משאירים דולק"]

איור 8: רק מחשב שמגיע לענף הסופי הוא מועמד לכיבוי.

6. בדיקה אם זה כבוי

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

6.1 המתג מציג את ההגדרה, לא את מצב הריצה

המתג במסך Core isolation ב-Windows Security מציג את ערך ההגדרה. מיד אחרי הפעלה בזמן שמחכים ל-restart, או בזמן ש-Memory integrity לא יכול היה להתחיל באתחול בגלל בעיית תאימות, המתג עדיין יכול להיראות דולק. בודקים את מצב הריצה באחת משתי הדרכים הבאות.⁴

בדיקה על המסך: msinfo32 (System Information)

1. מריצים msinfo32 מ-Win + R.
2. מסתכלים על הסעיף “Virtualization-based security” ליד תחתית “System Summary.”
3. אם “Services Running” כולל “Hypervisor enforced Code Integrity,” Memory integrity רץ.⁸

בדיקה במספר: PowerShell

מריצים את הבאה בחלון PowerShell שנפתח כמנהל.⁸

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning,
                  AvailableSecurityProperties

קוראים את הפלט כך.⁸

אחרי כיבוי ו-restart, זה הצליח אם 2 נעלם מ-SecurityServicesRunning. אם גם SecurityServicesConfigured כבר אינו מכיל 2, זה כבוי גם בהגדרות. קוראים בנפרד את מצב VBS כולו ואת מצב הריצה של Memory integrity.

flowchart TB
    accTitle: הזרימה לבדיקה אם Memory integrity רץ
    accDescr: שואלים Win32_DeviceGuard; אם SecurityServicesRunning מכיל 2, Memory integrity רץ, ואם לא, הוא לא רץ. אם SecurityServicesConfigured בצד ההגדרות יש 2 אבל הוא לא רץ, חושדים ב-restart שממתין או בבעיית תאימות באתחול
    q0["שואלים Win32_DeviceGuard"] --> r{"האם SecurityServicesRunning מכיל 2?"}
    r -->|"כן"| on["Memory integrity רץ"]
    r -->|"לא"| c{"האם Configured מכיל 2?"}
    c -->|"כן"| wait["Restart שממתין או בעיית תאימות באתחול"]
    c -->|"לא"| off["כבוי גם בהגדרות וגם בפעולה"]

איור 9: מסתכלים על Running, לא על Configured. קוראים את ההגדרה ואת הפעולה בנפרד.

6.2 תצורות שבהן ה-hypervisor נשאר אחרי כיבוי

עצירת Memory Integrity בלבד אינה בהכרח עוצרת את היסוד

Memory integrity היא אחת מהיכולות שיושבות מעל VBS. מה שכיביתם הוא Memory integrity לבדו; האם VBS מופעל מנוהל בהגדרה נפרדת (EnableVirtualizationBasedSecurity). התיעוד של Microsoft מתאר במפורש תצורה ש”מפעילה VBS בלבד (בלי Memory integrity).”⁸

יתר על כן, אם משתמשים ב-Hyper-V, WSL 2, Windows Sandbox או Virtual Machine Platform, ה-hypervisor ממשיך להתחיל בשבילם.⁶

משתי העלויות שראינו ב-3.2, זו של “hypervisor יושב מתחת ל-OS” נשארת במקרה הזה גם אחרי כיבוי. אם “Virtualization-based security” ב-msinfo32 עדיין אומר “Running” אחרי כיבוי Memory integrity, היסוד עדיין שם.

flowchart TB
    accTitle: מה נשאר אחרי כיבוי Memory integrity
    accDescr: גם כשמתג Memory integrity כבוי, אם אחת מהגדרת הפעלת VBS, Hyper-V, WSL 2, Windows Sandbox או Virtual Machine Platform מופעלת, ה-hypervisor ממשיך לרוץ ועלות two-level address translation נשארת
    off["Memory integrity כבוי"] --> q{"משהו אחר משתמש ב-hypervisor?"}
    q -->|"הגדרת VBS, Credential Guard"| stay1["ה-hypervisor נשאר"]
    q -->|"Hyper-V, WSL 2, Sandbox, VMP"| stay2["ה-hypervisor נשאר"]
    q -->|"כלום"| gone["היסוד עשוי להיעצר גם כן"]
    stay1 --> cost["עלות two-level address translation נשארת"]
    stay2 --> cost

איור 10: המתג מכבה רק Memory integrity. אם יכולות אחרות צריכות את ה-hypervisor, היסוד נשאר כפי שהוא.

עצירת כל היסוד מחוץ להיקף המאמר

יש הגדרות שמכבות את VBS עצמו ותצורות שלא מתחילות את ה-hypervisor, אבל הן לוקחות כל יכולת מעל VBS, כולל Credential Guard, וגם Hyper-V, WSL 2 ו-Windows Sandbox. זה שינוי גדול בהרבה מ”כיבוי Memory integrity”, וזה אינו אותו דבר. המאמר אינו מכסה את השלבים האלה. אם רוצים לקבל את ההחלטה הזו עם הבנה של המנגנון, קוראים קודם את חלקים 1 ו-2 של הסדרה.

7. איך מכבים

בדרך כלל מפעילים ממסך Windows Security ב-7.1. סעיף 7.2 מכסה מה לבדוק כשאי אפשר להפעיל, ו-7.3 הוא חלופה לסביבות שבהן אי אפשר להשתמש במסך. VMP ב-7.4 היא יכולת נפרדת, כך שזה אינו שלב שמבצעים ברצף כדי לכבות Memory integrity.

7.1 מ-Windows Security (הנוהל התקני)

כיבוי: משנים את ההגדרה, עושים restart, ומאמתים

1. פותחים “Windows Security” מ-Start.
2. בוחרים “Device security” בתפריט השמאלי.
3. פותחים “Core isolation details” תחת “Core isolation.”
4. מחליפים את מתג “Memory integrity” ל-off. אם מופיע אישור מנהל (UAC), מאשרים.
5. עושים restart למחשב. השינוי אינו נכנס לתוקף עד restart.¹
6. אחרי ה-restart, מאשרים שזה כבוי בשיטה של 6.1.

החזרה: משתמשים באותו מסך

כדי לשחזר, מחליפים את המתג ל-on באותו מסך ועושים restart. כשמדליקים, עשויה לרוץ סריקה ל-drivers לא תואמים. אם מופיעה רשימה, לא כופים; מטפלים בסדר שניתן בפרק 8.

אם משווים, מאשרים את מצב הריצה לפני ואחרי השינוי ואז מודדים בשיטה של 4.3. אם ההבדל אינו חשוב לאופן השימוש במחשב, מדליקים שוב ומחפשים סיבה אחרת.

flowchart TB
    accTitle: שלבים לכיבוי Memory integrity מ-Windows Security
    accDescr: מ-Device security ב-Windows Security פותחים Core isolation details, מחליפים את מתג Memory integrity ל-off, עושים restart, ומאשרים עם msinfo32 או Win32_DeviceGuard שזה כבוי
    s1["פותחים Windows Security"] --> s2["אבטחת המכשיר"]
    s2 --> s3["פרטי בידוד ליבה"]
    s3 --> s4["כיבוי תקינות הזיכרון"]
    s4 --> s5["הפעלה מחדש"]
    s5 --> s6["מאמתים בשיטה של פרק 6"]

איור 11: הנוהל עצמו קצר. החלקים שמדלגים עליהם הם שני האחרונים (restart ואימות).

7.2 כשהמתג אפור ואי אפשר לגעת

במחשב חברה או בית ספר, לא עוקפים בעצמכם; פונים למנהל. כשהמתג אפור ואי אפשר להפעיל, הסיבות כוללות את הבאות.

נעול ב-policy או ב-Registry

אם המתג אפור וכתוב “This setting is managed by your administrator,” הגדרת המחשב נעולה ב-Group Policy, Intune או דומה, או שהמסך הושבת דרך ה-Registry.⁸ במחשב חברה או בית ספר, זו כוונת המנהל.

מופעל עם UEFI lock

במחשב שנפרס עם “Enabled with UEFI lock” שנבחר תחת הגדרת Group Policy “Turn On Virtualization Based Security,” ההגדרה נשמרת במשתנה UEFI (firmware), כך שאי אפשר לכבות Memory integrity מרחוק או דרך עדכון policy.⁸

ביטול דורש הסרת ה-policy או הגדרת ה-Registry ואז אדם מול אותו מחשב שמבצע את השלבים לניקוי התצורה השמורה ב-UEFI. תיעוד Credential Guard, שמשתמש באותו UEFI lock, מראה את הנוהל: מוחקים את משתנה EFI עם bcdedit תחת הרשאות Administrator, ומקבלים פיזית את ה-prompt לאישור שמוצג ב-restart.¹¹

כיבוי Secure Boot בלבד בתפריט UEFI אינו מנקה את התצורה השמורה. זה יכול גם לבקש את recovery key של BitLocker. ההגדרה הזו קיימת בדיוק כדי שאי אפשר יהיה לכבות בקלות, ולכן שוב זה תחום המנהל.

flowchart TB
    accTitle: בידוד הסיבה כשהמתג אפור
    accDescr: אם המתג אפור, הוא או מנוהל על ידי מנהל (policy או Registry) או תחת UEFI lock (שדורש ניקוי התצורה השמורה ב-UEFI מול המחשב); בשני המקרים לא עוקפים בעצמכם אלא מתייעצים עם המנהל
    gray["המתג אפור"] --> why{"איזו סיבה מוצגת?"}
    why -->|"מנוהל על ידי המנהל"| pol["נעול ב-policy או ב-Registry"]
    why -->|"נעילת UEFI"| lock["דורש ניקוי תצורת UEFI מול המחשב"]
    pol --> ask["מתייעצים עם המנהל"]
    lock --> ask

איור 12: אפור אינו תקלה; זה הסימן שמישהו נעל במכוון.

7.3 הגדרה דרך ה-Registry (כשאי אפשר להשתמש במסך)

השיטה הזו היא חלופה לסביבות שבהן אי אפשר להשתמש במסך Windows Security, או כשרוצים להגדיר מסקריפט. זו אינה דרך לעקוף הגדרת מנהל. וכשמחזירים, משתמשים במסך ב-7.1.

הערך והפקודה לכיבוי

ערכי ההגדרה ש-Microsoft מתעדת להפעלה ולכיבוי Memory integrity הם כדלקמן.⁸

מריצים את הבאה בטרמינל שנפתח כמנהל, ואז עושים restart.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f

זו אותה פעולה ש-Microsoft נותנת כנוהל לשחזור, מסביבת השחזור (Windows RE), של מחשב שכבר לא עולה אחרי שהופעל Memory integrity.⁸

למה לא לכתוב 1 ל-Registry כשמחזירים

כשמשחזרים, לא כותבים 1 בחזרה ל-Registry; מדליקים ממסך Windows Security ב-7.1. כשמדליקים מהמסך, סריקת ה-drivers הלא תואמים רצה קודם, ואם נמצאים כאלה מוצגת רשימה (פרק 8).³

אם כותבים 1 ב-Registry, Memory integrity נדרש באתחול הבא בלי לעבור את הסריקה הזו. אם נשאר driver לא תואם, מזמינים בדיוק את כשל האתחול שפרק 8 מזהיר מפניו. הפעלה דרך policy או Registry מקובלת רק אחרי שאישרתם ברשימת ה-drivers הלא תואמים ובלוג CodeIntegrity שאין בעיה.

כשאין אפקט לשינוי, או שהוא חוזר

במחשב שבו Locked תחת אותו מפתח הוא 1 (UEFI lock), לשינוי הערך הזה אין אפקט.⁸ ובמחשב שמנוהל במדיניות ארגון, ההגדרה חוזרת בפעם הבאה שה-policy מוחל. ה-Registry הוא “תחליף למסך”, לא “אמצעי לעקוף את הגדרת המנהל.”

flowchart TB
    accTitle: תנאים שבהם להגדרת Registry אין אפקט
    accDescr: גם אם Enabled תחת HypervisorEnforcedCodeIntegrity מוגדר ל-0, אין אפקט אם Locked תחת אותו מפתח הוא 1 (UEFI lock), ובמחשב שמנוהל במדיניות ארגון ההגדרה חוזרת בפעם הבאה שה-policy מוחל. מחזירים ממסך Windows Security, לא מה-Registry
    reg["מגדירים Enabled ל-0 ועושים restart"] --> lk{"האם Locked הוא 1 (UEFI lock)?"}
    lk -->|"כן"| no1["אין אפקט (נדרש שחרור בצד UEFI)"]
    lk -->|"לא"| pol{"מנוהל ב-policy?"}
    pol -->|"כן"| no2["חוזר בהחלת ה-policy הבאה"]
    pol -->|"לא"| ok["כבוי (מאמתים בפרק 6)"]
    ok -.-> back["מחזירים מהמסך (הסריקה רצה)"]

איור 13: ערך ה-Registry כותב את אותה הגדרה כמו המסך; הוא אינו יכול לעמוד מעל ה-lock או ה-policy.

7.4 Virtual Machine Platform (VMP) הוא נוהל נפרד

ההנחיה של Microsoft על ביצועי משחקים גם מפרטת VMP, אבל זו יכולת נפרדת מ-Memory integrity. אין צורך להסיר גם VMP כדי לכבות Memory integrity.

בודקים אילו יכולות משתמשים בהן לפני שמסירים

VMP הוא תנאי מוקדם ל-WSL 2.⁶ אם מסירים אותו במחשב שמשתמש ב-WSL 2, או ב-Docker Desktop מעל WSL 2, אלה מפסיקים לעבוד.

Windows Sandbox מופעל דרך optional feature ייעודי ולא דרך VMP, כך שהוא עדיין עובד אחרי הסרת VMP.⁷ אבל כי Sandbox גם רץ על אותו hypervisor, כל עוד ממשיכים להשתמש בו, הוא אחד מגורמי “היסוד נשאר” שראינו ב-6.2.

הקריטריון הוא “מסירים אם לא משתמשים”, לא “מסירים כי זה מאיץ.”

הפעולה כש-VMP אינו בשימוש

VMP מכובה לא ב-Windows Security אלא תחת “Windows Features.”¹

1. מחפשים “Windows features” מ-Start ופותחים “Turn Windows features on or off.”
2. מבטלים את סימון “Virtual Machine Platform” ולוחצים “OK.”
3. עושים restart.

flowchart TB
    accTitle: האם מקובל להסיר Virtual Machine Platform?
    accDescr: אם משתמשים ביכולות שתלויות ב-Virtual Machine Platform, כמו WSL 2 או Docker Desktop (WSL 2 backend), לא מסירים; רק כשלא משתמשים בהן זה מועמד להסרה. Windows Sandbox הוא feature ייעודי, כך שהוא עובד אחרי הסרת VMP, אבל הוא משתמש באותו hypervisor, כך שהיסוד נשאר
    vmp["רוצים להסיר VMP"] --> use{"משתמשים ב-WSL 2 או Docker Desktop?"}
    use -->|"כן"| keep["לא מסירים (הם מפסיקים לעבוד)"]
    use -->|"לא"| ok["מועמד להסרה (מ-Windows Features)"]
    ok --> reboot["Restart ואימות"]
    ok -.-> sb["Sandbox הוא feature נפרד (היסוד נשאר)"]

איור 14: האם להסיר VMP מחליטים לפי “האם משתמשים ביכולת הזו”, לא לפי מהירות.

8. החזרה — טיפול ב-“drivers לא תואמים”

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

8.1 כשאי אפשר להחזיר, בודקים את ה-drivers

כשמנסים להחזיר Memory integrity במחשב שבו הוא היה כבוי, עשויים להגיד שיש “incompatible drivers” ולא להיות מסוגלים להדליק. Windows Security סורק את ה-drivers כשמחליפים את המתג ל-on, ואם driver כלשהו אינו תואם לכללי Memory integrity (3.1), הוא מציג רשימה.³

סדר הטיפול הוא כדלקמן.

1. מזהים את ה-drivers ברשימה. מ-“Review incompatible drivers” במסך Core isolation, מסתכלים על שמות קבצי ה-driver ועל המוציאים לאור שלהם.
2. מחליפים ב-drivers מעודכנים. כפי ש-Microsoft מייעצת, בודקים אם יצרן ההתקן מספק driver מעודכן.³ זה עשוי להיות זמין גם תחת “Optional updates” ב-Windows Update.
3. אם ה-driver שייך להתקן שכבר לא משתמשים בו, מוחקים אותו. Drivers לציוד היקפי שחובר מזמן, או לכלי עזר שמעולם לא הוסרו לגמרי, נשארים לעתים קרובות מאחור.
4. מאשרים בלוג איזה driver נחסם. חסימות של Memory integrity נרשמות ב-Event Viewer תחת Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational, עם event ID 3087 כטיפוסי.⁴

לא כופים הפעלה כשנשארים drivers לא תואמים. Microsoft מזהירה ש-drivers שאינם תואמים ל-Memory integrity יכולים לגרום לתקלות בהתקנים או בתוכנה, ובמקרים נדירים להוביל לכשל אתחול (מסך כחול).⁸ אם המחשב באמת לא עולה, קיים נוהל לשחזר אתחול על ידי הגדרת ערך ה-Registry ב-7.3 ל-0 מסביבת השחזור.⁸

flowchart TB
    accTitle: טיפול במקרה שאי אפשר להחזיר
    accDescr: מזהים את ה-drivers ברשימת ה-drivers הלא תואמים, מחליפים אם ליצרן יש גרסה מעודכנת, מוחקים אם ההתקן כבר לא בשימוש, ואם אף אחד לא אפשרי, לא כופים, משאירים כבוי, ומבקשים מהיצרן גרסה תואמת
    fail["אי אפשר להדליק"] --> list["מסתכלים על רשימת ה-drivers הלא תואמים"]
    list --> upd{"ליצרן יש עדכון?"}
    upd -->|"כן"| fix["מחליפים ומדליקים"]
    upd -->|"לא"| used{"ההתקן בשימוש?"}
    used -->|"לא בשימוש"| rm["מוחקים את ה-driver ומדליקים"]
    used -->|"בשימוש"| wait["לא כופים; מבקשים מהיצרן"]

איור 15: התיקון הנכון הוא עדכון driver. כפייה אינה שווה את מחיר מחשב שלא עולה.

8.2 רשת הביטחון שמכבה אוטומטית יש לה תנאים

מנגנון שמוגבל למחשבים שבהם הופעל אוטומטית

מחשב שבו Windows הפעיל Memory integrity אוטומטית (ההפעלה ברירת המחדל ב-3.3, או מחשב שבו היצרן הפעיל אותו בתמונת המשלוח) עשוי לשאת רשת ביטחון שמכבה אוטומטית את Memory integrity בחזרה אם מתרחשת קריסה באתחול מיד אחרי ההפעלה.

התיעוד של Microsoft מתאר את רשת הביטחון הזו כעובדת כשערכי ה-Registry WasEnabledBy ו-EnabledBootId מוגדרים, כפעילה רק לשלושת האתחולים אחרי ההפעלה, וכתצורה שיצרנים מגדירים בתמונת המשלוח.⁴

ההתנהגות הזו אינה מתועדת למקרה שבו הדלקתם בעצמכם ממסך Core isolation. כשמחזירים ידנית, לא מסתמכים על רשת הביטחון הזו; מנקים קודם drivers לא תואמים בשלבים של 8.1.

גם כשזה כיבה אוטומטית, הסיבה אינה מיושבת

התופעה “מיד אחרי התקנה נקייה, זה היה כבוי בשלב כלשהו” יכולה להיות תוצאה של רשת הביטחון הזו שפעלה. אבל מה שהיא רושמת הוא רק העובדה ש”האתחול נכשל מיד אחרי ההפעלה.” היא אינה קובעת שהסיבה הייתה driver לא תואם. כשל אתחול מסיבה לא קשורה באותה תקופה מייצר אותה תוצאה.

התיעוד של Microsoft גם מסביר שאם כשלי אתחול ממשיכים אחרי ש-Memory integrity כבוי, ההגדרה משוחזרת בנימוק ש-Memory integrity לא היה הסיבה.⁴

Driver לא תואם הוא סיבה סבירה, לכן קודם משיגים אימות מרשימת ה-drivers הלא תואמים ומלוג CodeIntegrity. אם נמצא משהו, מטפלים בשלבים של 8.1; אם לא נמצא כלום, חוקרים את סיבת כשל האתחול במקום אחר.

flowchart TB
    accTitle: רשת הביטחון שמכבה אוטומטית במחשבים שבהם הופעל אוטומטית
    accDescr: במחשב שבו Windows הפעיל אוטומטית (WasEnabledBy ו-EnabledBootId מוגדרים), Memory integrity עשוי לכבות אוטומטית בחזרה אם מתרחשת קריסה באתחול תוך שלושה אתחולים מההפעלה. כשהודלק ידנית ההתנהגות הזו אינה מתועדת, לכן לא מסתמכים על רשת הביטחון. גם כשכיבה אוטומטית, זה רישום של כשל אתחול ולא סיבה מיושבת, לכן משיגים אימות מרשימת ה-drivers הלא תואמים ומלוג CodeIntegrity, מטפלים בפגיעה בעדכון או במחיקה, ואחרת חוקרים סיבה אחרת
    en["Memory integrity הופך למופעל"] --> how{"הופעל אוטומטית (WasEnabledBy)?"}
    how -->|"הודלק ידנית"| manual["רשת הביטחון אינה מתועדת"]
    how -->|"אוטומטי"| boot{"קריסה תוך 3 אתחולים?"}
    boot -->|"לא"| fine["נשאר מופעל ורץ"]
    boot -->|"כן"| auto["מכבה אוטומטית בחזרה"]
    auto --> chk{"פגיעה ברשימה או בלוג?"}
    chk -->|"כן"| fix["מטפלים בעדכון או במחיקה"]
    chk -->|"לא"| other["חוקרים סיבה אחרת"]

איור 16: רשת הביטחון פועלת רק במחשבים שבהם הופעל אוטומטית; אי אפשר להסתמך עליה כשהדלקתם ידנית. גם כשהיא פועלת, זה אות ולא אבחון, לכן משיגים אימות מהרשימה ומהלוג לפני שמתקנים משהו.

9. אי-הבנות נפוצות

לבסוף בודקים את הנקודות שקל לבלבל לפני ואחרי שינוי ההגדרה.

9.1 “כיביתי Core Isolation”

Core isolation הוא שם של מסך; מה שבאמת כיביתם הוא מתג Memory integrity (פרק 2). הפריטים האחרים באותו מסך, ו-VBS עצמו, אינם כבויים.

9.2 “כיבוי תמיד מאיץ”

זה יכול להיות מהיר יותר כש-Memory integrity באמת רץ, ה-CPU הוא הצוואר, ובמיוחד כשל-CPU אין MBEC/GMET (פרק 4). משחקים תלויי GPU, ואיטיות עם סיבה אחרת, אינם משתנים.

9.3 “החלפת המתג ל-off היא סוף הסיפור”

זה אינו נכנס לתוקף עד restart, ואחרי ה-restart עדיין צריך לבדוק את מצב הריצה בנפרד (פרק 6). ולהפך, במחשב נעול ב-policy או ב-UEFI lock, המתג חוזר גם אם נוגעים בו.

9.4 “לכיבוי אין השפעות אחרות”

המחסום מפני הזרקת קוד ל-kernel נעלם, Windows Security ממשיך להציג אזהרה, ומשחקים שה-anti-cheat שלהם מציין HVCI בשגיאה כבר לא עולים (פרק 5).

9.5 “כיבוי גם עוצר את ה-hypervisor”

Memory integrity היא יכולת אחת מעל VBS; אם אחת מהגדרת VBS, Credential Guard, Hyper-V, WSL 2, Windows Sandbox או VMP מופעלת, ה-hypervisor ממשיך לרוץ (6.2).

flowchart TB
    accTitle: אי-הבנות ומה קורה בפועל
    accDescr: האי-הבנה ש-Core isolation כובה מתאימה לעובדה שזה היה מתג Memory integrity; האי-הבנה שתמיד מאיץ מתאימה לכך שזה תלוי בתצורה; האי-הבנה שהמתג הוא הסוף מתאימה לכך שנדרשים restart ואימות; והאי-הבנה שה-hypervisor גם נעצר מתאימה לכך שהוא נשאר ליכולות אחרות
    m1["כיבו Core isolation"] --> r1["מה שכובה הוא מתג Memory integrity"]
    m2["תמיד מאיץ"] --> r2["תלוי בתצורה. מודדים ומחליטים"]
    m3["המתג הוא הסוף"] --> r3["נדרשים restart ובדיקת מצב ריצה"]
    m4["ה-hypervisor גם נעצר"] --> r4["הוא נשאר אם יכולות אחרות צריכות אותו"]

איור 17: רוב אי-ההבנות מגיעות מערבוב בין “שם המסך” לבין “שם המנגנון.”

10. סיכום

Memory integrity (HVCI) הוא מנגנון שמעביר את המחסום ל-drivers שנכנסים ל-kernel לסביבה מבודדת מחוץ ל-kernel. למעבר הזה יש מחיר, הנחת hypervisor מתחת ואכיפת הרשאת execute על ידי ה-hypervisor, ולפי התצורה זה משפיע על ביצועים.

ההחלטה קלה יותר לארגן בשלושת השלבים הבאים.

1. בודקים את השימוש ומה מאבדים. המועמד לכיבוי הוא מכונה ייעודית שאינה מעורבת בנתונים עסקיים או ברשת המשרד ושאינה משחקת משחקים שה-anti-cheat שלהם מציין HVCI. מהירות לבדה אינה מחליטה.
2. מאשרים את מצב הריצה, ואז מודדים באותם תנאים. משתמשים ב-msinfo32 או ב-Win32_DeviceGuard כדי לאשר שהמצב השתנה לפני ואחרי השינוי. הבדל סביר ביותר ב-CPU-ים ישנים בלי MBEC/GMET ובמשחקים תלויי CPU, ובלתי סביר במשחקים תלויי GPU ובשימוש יומיומי. מודדים כמה פעמים ורואים אם ההבדל חשוב לאופן השימוש במחשב.
3. מחליטים אם לשמור או לשחזר לפי ההבדל והשימוש. כיבוי הוא אפשרות כשמדידה מראה הבדל. במחשב שמשתמש ב-Hyper-V, WSL 2, Sandbox או VMP, היסוד נשאר וההבדל הצפוי אינו סביר. אם ההבדל אינו חשוב לאופן השימוש במחשב, מדליקים שוב, וחוזרים כשהשימוש משתנה. כשאי אפשר להחזיר, התיקון הנכון הוא עדכון driver; לא כופים.

“זה מאיץ כשמכבים” אינו שקר. אבל רק עם שלושה תנאים מצורפים, “במחשב שלכם,” “נמדד,” ו”יודעים מה מאבדים,” זה הופך לחומר להחלטה.

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

• Windows Virtualization Internals (חלק 2) — זיכרון שאפילו ה-kernel לא רואה: VBS, HVCI ו-Credential Guard
• Windows Virtualization Internals (חלק 1) — איפה Windows שלכם באמת רץ: hypervisor ו-partitions
• Windows Virtualization Internals (חלק 3) —‏ VM שעולה תוך שניות: WSL2, Windows Sandbox ו-containers
• מה זה Windows Efficiency mode? - אייקון העלה הירוק ואיך לכבות
• איך משווים נכון מהירות בין גרסאות תוכנה ב-Windows
• WPR/WPA בפועל — מבוא ל-performance analysis מערכתי כשכל ה-PC איטי
• Processor scheduling ב-Windows —‏ Background services וליבות P/E

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

KomuraSoft LLC מטפלת בחקירות תאימות בין אפליקציות Windows ליכולות אבטחה (Memory integrity, VBS, App Control), בניתוח פגמים שנגרמים מ-drivers, ובחקירות ביצועים שמבודדות את הסיבה ל”המחשב או האפליקציה איטיים” דרך מדידה. מגיעים אלינו מהנקודה שבה “כיבוי לא האיץ”.

• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• פיתוח אפליקציות Windows
• יצירת קשר

קישורים

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

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

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

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

שאלות נפוצות

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

מה זה Memory integrity (HVCI)?

זו היכולת תחת Device security > Core isolation ב-Windows Security, שנקראת רשמית hypervisor-protected code integrity (HVCI). היא מבצעת את אימות החתימה של drivers שנטענים ל-kernel (ליבת ה-OS) בתוך סביבה מבודדת שיוצר ה-hypervisor, הופכת לניתנות להרצה רק pages שעברו אימות, ולעולם אינה מאפשרת כתיבה ל-pages ניתנות להרצה. מטרתה להקשות על תוכניות זדוניות להשתלט על ה-PC דרך drivers ברמה נמוכה.

האם כיבוי Memory integrity באמת מאיץ את המחשב?

חלק מהתצורות מאיצות; אחרות כמעט לא משתנות. Microsoft מציינת שבמכשירי משחקים, בחלק מהתרחישים והתצורות, Memory integrity ו-Virtual Machine Platform יכולים להשפיע על הביצועים. ההשפעה סבירה יותר ב-CPU-ים ישנים בלי Mode-Based Execution Control (ב-Intel מהדור ה-7 ואילך) או Guest Mode Execute Trap (ב-AMD מ-Zen 2 ואילך), כי ב-CPU-ים האלה הפונקציה מאומלצת ועלות הביצועים גדלה. לעומת זאת, במשחקים שתלויים ב-GPU, או כשהאיטיות מגיעה ממחסור בזיכרון, מהדיסק, מחום או ממצב צריכת החשמל, כיבוי לא משנה כלום. הדרך האמינה להחליט היא למדוד במחשב שלכם באותם תנאים.

איך מכבים Memory integrity?

פותחים Windows Security, הולכים ל-Device security > Core isolation details, מחליפים את מתג Memory integrity ל-off, ועושים restart למחשב. ההגדרה אינה נכנסת לתוקף עד restart. אם המתג אפור וכתוב "This setting is managed by your administrator", הוא נעול במדיניות הארגון; לא משנים בעצמכם, פונים למנהל.

כיביתי, אז למה זה לא מהיר יותר?

קודם מאשרים שזה באמת כבוי, באמצעות הסעיף Virtualization-based security ב-msinfo32 (System Information) או המחלקה Win32_DeviceGuard ב-PowerShell. זה עדיין יכול להיות דולק כי לא עשיתם restart או כי policy החזיר אותו. אחר כך, אם משתמשים ב-Hyper-V, WSL 2, Windows Sandbox או Virtual Machine Platform, ה-hypervisor עצמו ממשיך לרוץ גם אחרי כיבוי Memory integrity. ואם Memory integrity מעולם לא הייתה הסיבה לאיטיות מלכתחילה, כיבוי לא יאיץ כלום.

מה לעשות כשאי אפשר להחזיר Memory integrity (נאמר שיש drivers לא תואמים)?

בודקים את רשימת ה-drivers הלא תואמים שמוצגת במסך Core isolation ב-Windows Security, והתיקון הנכון הוא להחליף אותם ב-drivers מעודכנים מיצרן ההתקן. אם ה-driver שייך להתקן שכבר לא משתמשים בו, אפשר למחוק אותו. איזה driver נחסם אפשר גם לאשר בלוג CodeIntegrity Operational ב-Event Viewer (event ID 3087 הוא הטיפוסי). כפייה של הפעלה כשנשארים drivers לא תואמים אינה נתמכת גם אצל Microsoft, והמחשב עלול לא לעלות.

כיביתי בשביל משחק, ועכשיו משחק אחר לא עולה.

חלק ממערכות anti-cheat (כמו Vanguard של Riot Games) משתמשות ב-Memory integrity (HVCI) ב-Windows 11 כדי לאמת שלמות מערכת, ובמחשב שבו שגיאת VAN: RESTRICTION מציינת HVCI, המשחק לא יעלה אלא אם זה דולק. זה אינו נדרש באופן אחיד בכל מחשב Windows 11; זה תלוי במה שהשגיאה מפרטת. אם זה חל עליכם, מדליקים שוב Memory integrity ועושים restart. מחליטים אם לכבות לפי גם המשחק שרוצים להאיץ וגם המשחק שדורש HVCI.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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