Zenbleed, האחרון בסדרה ארוכה של באגי אבטחה למעבדים, הוא דבר נוסף שצריך לתקן. הנה מה שאתה צריך לדעת.
לאחר שפורסמו מעללי המעבד Spectre ו-Meltdown בשנת 2018, עולם המחשוב היה די ערני על מציאת באגי אבטחה ופרצות במעבדים, ובחמש השנים האחרונות, חוקרים מצאו המון. ב-24 ביולי, ניצול נוסף נחשף בפומבי לאחר שדווח לראשונה במאי. הפעם, זה ספציפי למעבדי AMD הבנויים על ארכיטקטורת Zen 2, והוא מכונה "זנבליד". הנה כל מה שאתה צריך לדעת על Zenbleed ומה זה אומר על העולם.
איך Zenbleed עובד?
Zenbleed דומה מאוד לבאגי אבטחה אחרים מבוססי חומרה כמו Spectre בכך שהוא מנצל את היכולת הספקולטיבית של מעבדים. על מנת לשפר ביצועים, מעבדים לשער או לחזות את הדבר הבא שהם צריכים לעשות, ומאז שספקטר נחשף לראשונה, העולם למד שספקולציות עלולות להיות מאוד לא בטוחות אם עושים זאת באופן לא תקין.
רישומים במעבד יכולים להכיל כמות קטנה של נתונים, בדרך כלל הוראה, כתובת אחסון או כל סוג אחר של נתונים קטנים. אוגרי XMM בארכיטקטורת x86_64 (לכן, כל אחד ממעבדי ה-Zen 2 המושפעים) יכולים לשמש רק לביצוע חישובים על נתונים, לא להתייחס לזיכרון. זה מורחב ל-256 סיביות במקרה של אוגרי YMM, ו-512 סיביות באוגרי ZMM. במקרה זה, XMM מתייחס ל-128 הסיביות התחתונות של ה-
סה"כ 512 סיביות של אוגרי ZMM.אוגרים אלה שימושיים להפליא להרבה דברים שונים, כולל פונקציות C סטנדרטיות. הפגיעות מנצלת לרעה ביצוע ספקולטיבי ותחזיות שגויות מסתעפות כדי לירוק למעשה פיסת נתונים אקראית מהזיכרון, אבל הנתונים האלה יכולים להיות מ כל דבר. פונקציות ספריית C סטנדרטיות כמו strlen, המודד את אורך המחרוזת, יכולות להשתמש באוגרים אלה להעברת נתונים בסביבה, וייתכן שבמקרה, סיסמה שבה אתה משתמש יכלה לרוע מזלם ליפול לאחת מהן רושמת.
חיזוי ענפים וביצוע ספקולטיבי מתייחסים באופן כללי למועד שבו המחשב שלך מבצע פעולות שעדיין אינן נחוצות אך ככל הנראה יהיה צורך במחזורים הבאים. זה נעשה לעתים קרובות בזמנים שבהם למערכת שלך יש משאבים פנויים, מכיוון שהוא מאיץ את העיבוד הכולל כאשר הוראות או נתונים לא היו עדיין מוכנים עבור ה-CPU. אם העבודה שבוצעה אינה נחוצה, היא בדרך כלל נמחקת והמעבד יכול לקפוץ לאן שהוא צריך כדי לבצע את ההוראה הבאה, הנכונה. כאשר הוא עושה זאת, זה נקרא חיזוי שגוי של ענף.
היכן שמתעוררת בעיה היא בהוראה vzeroupper, אשר מאפסת את הביטים במיקום 128 ומעלה של אוגרי YMM ו-ZMM. זה נעשה במיוחד בעת מעבר בין AVX לקוד SSE מדור קודם, מכיוון שהוא מבטל את הביצועים עונשים הנגרמים מתלות שקרית תוך הימנעות מהשפעה הדומה לקידום מספרים שלמים ב ג.
אם המעבד מבצע באופן ספקולטיבי הוראת vzeroupper, אין החזרה נכונה. עם זאת, ניתן לאלץ את מעבדי ה-Ryzen המושפעים להתאושש ממנו, אם כי באופן שגוי. ברגע שהייתה במצב זה, התוכנית המופעלת כעת יכולה לרגל אחר הרשמים הללו בזמן אמת, ולצפות בנתונים הזורמים במערכת בכל זמן נתון.
אילו מעבדים מושפעים מ-Zenbleed, ומתי יהיו תיקונים זמינים?
כאמור, רק מעבדי AMD המבוססים על ארכיטקטורת Zen 2 ידועים כפגיעים לבאג האבטחה Zenbleed, אך ארכיטקטורת Zen 2 הניעה מעבדים בשלוש סדרות, מה שהופך את זה לבולגן להבין אילו מעבדים פגיעים ואילו אינם. הנה טבלה שאמורה להבהיר את הכל:
מעבדים מושפעים | |
---|---|
סדרת Ryzen 3000 |
הכל מלבד APUs (למשל Ryzen 3 3200G) |
אפוס רומא |
את כל |
סדרת Ryzen 4000 |
את כל |
סדרת Ryzen 5000 |
רק ה-5300U, 5500U ו-5700U |
סדרת Ryzen 7000 |
רק 7020 APUs (למשל Ryzen 3 7320U) |
מדובר בכמות די גדולה של מעבדי AMD, ואלה רק אלה שאושרו עד כה. Zen 2 משמש גם ב-APUs המפעילים את Steam Deck, Xbox Series S ו-X ו-PS5. לא שמענו בשום אופן אם גם המעבדים האלה מושפעים, אבל אם לשפוט לפי הדרך שבה הניצול הזה עובד, אני אתפלא אם הם לא יושפעו גם הם. לא סביר ש-AMD תיקנה אותו ב-Xbox וב-PS5 מכיוון שגם שבבים מסדרת 7020, שהם חדשים יותר, מושפעים.
בזמן כתיבת שורות אלה, מיקרוקוד נשלח לליבת לינוקס שיתקן את הפגיעות הזו, וייתכן שלמערכת ההפעלה או ה-BIOS שלך כבר יש עדכון שמתקן בעיה זו.
מה זה אומר עבור מחשבים שמשתמשים במעבדים פגיעים?
זה דבר שקשה לענות עליו כי לא כל המחשבים שווים. עבור אנשים רגילים שמשתמשים רק במחשבי גיימינג שולחניים ומחשבים ניידים, כנראה שלא תצטרכו להיות כל כך מודאגים. זהו ניצול די מתוחכם ולמרות שזה ידוע לציבור כעת, אין עדיין דוגמאות ידועות של תוקף שמשתמש ב-Zenbleed כדי לפרוץ לשום דבר.
עם זאת, ההימור גבוה בהרבה עבור מרכזי נתונים ואנשים חשובים המטפלים במידע רגיש במחשבים שלהם. יש סיבה לכך ש-AMD הייתה מאוד ברורה ש-Epyc Rome תוקן לפני שהפגיעות פורסמה לציבור: הרבה דברים רגישים מידע מטופל על ידי מעבדי Epyc, וזה יהיה אסון אם מעבדים כלשהם המפעילים שרתים בקנה מידה גדול היו מוצלחים תקפו. ליבת לינוקס 6.4.6 כבר שוחררה ומתקן את הפגיעות הזו על ידי כניסת ה- תיקון מיקרוקוד רשמי מ-AMD. סביר להניח שמיקרוסופט תשלב משהו דומה ב-Windows.
באופן מדאיג, ייתכן שתיקוני ה-BIOS הרשמיים של AMD לא יצאו במשך מספר חודשים, במקרה זה, יש "קצת עוף" שאתה יכול להגדיר אם אתה על מחשב לינוקס או FreeBSD. במכונות לינוקס, אתה יכול להשתמש ב-msr-tools ולהפעיל את הפקודה הבאה.
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))
ב-FreeBSD, אתה יכול גם להשתמש בדברים הבאים.
cpucontrol(8)
השבתת SMT אינה מספיקה כדי להפחית את הפגיעות.
דבר אחד שהופך את Zenbleed לרע במיוחד הוא ש-Zen 2 היה אחת מארכיטקטורות ה-CPU הפופולריות ביותר של AMD. זה התחיל את הקאמבק של AMD ב-2019 ו-2020, והמון אנשים, חברות וארגונים עדיין משתמשים במחשבים עם מעבדי Zen 2 ב-2023, במיוחד Epyc Rome מעבדים. זה לא רע כמו ספקטר (שמשפיע כמעט על כל המעבדים לפני 2019) ומלטדאון (שמשפיע כמעט על כל המעבדים של אינטל לפני 2019), אבל זה עדיין די בסדר נָפוֹץ.
תיקוני אבטחה עבור נקודות תורפה כמו זה גם גורמות לעתים קרובות לעונש ביצועים, אבל אמר AMD החומרה של טום שהעונש הזה יהיה תלוי במעבד ובעומס העבודה. ספקולציות וחיזוי היו די חשובים לביצועי המעבד, כך שלא ברור אם תיקון פוטנציאלי כלשהו יראה ירידה משמעותית בביצועים.