למחשב ה-Linux שלך יש בעיית Secure Boot - מה לעשות קודם (והפתרון החוצץ שכדאי להימנע ממנו)

אתחול מאובטח תמיד היה מטרד למשתמשי לינוקס, אבל רשויות האישור שפגות של מיקרוסופט מ-2011 הופכות אותו לכאב אמיתי.

המסקנות המרכזיות של Linux-Terminal.com

• לינוקס נתקלת בבעיה חדשה ב-Secure Boot.
• אבל זה לא כמעט כל כך גרוע כמו שחלק מהאנשים מציגים.
• הנה מה שאתה יכול לעשות כדי להתמודד עם הבעיה.

בחזרה בסוף שנות ה-2000, הקושחה של המחשב נעשתה מעבר ל-BIOS ישן ל-UEFI (ממשק קושחה נרחב מאוחד). לצד זאת הופיע Secure Boot. מנגנון אבטחה זה, הנתמך על ידי מיקרוסופט, נועד לעצור bootkits ותוכנות זדוניות ברמת הקושחה שעדיין לא יכל אבטחת מערכת ההפעלה המסורתית לזהות. Secure Boot היה מורכב, אך עשה את העבודה. עבור אנשים שניסו להתקין ולהריץ לינוקס על מחשבי Windows, ההגדרה הזו הייתה כאב ראש אמיתי. וכאן אנחנו, 14 שנה לאחר שהופיע Secure Boot לראשונה במחשבי Windows 8, והוא שוב יכול לגרום לאי נוחות למשתמשי לינוקס.

שוב, כמה חובבי לינוקס בחרדה ש"מיקרוסופט סוגרת את לינוקס החוצה!" זה לא מה שקורה. כפי שמיקרוסופט ציינה, "לתעודות Secure Boot תמיד היו תאריכי תפוגה." כן, כן, זה נכון. מעבר לכך, כפי שציין לאחרונה אד בוט, אף שזה לא כמעט מטריד כל כך עבור משתמשי ווינדוס, ייתכן שלחלק מהאנשים עדיין יהיו בעיות עם תעודות Secure Boot שפגות.

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

בואו נעבור על מה שקורה בפועל, מדוע לינוקס מעורבת, ומה כדאי לכם לעשות לפני 2026 ואילך.

פשרה ישנה מגיעה לפרעון

כדי להבין למה, צריך לחזור לשנים 2011 עד 2012, כאשר UEFI Secure Boot הופיעה לראשונה במחשבים המיועדים לצרכן הרחב. מטרת העיצוב נשמעה סבירה: לעצור קוד לא מהימן מלרוץ לפני מערכת ההפעלה על ידי כך שהקושחה תבדוק חתימות של לודדי אתחול, גרעינים ו-ROMs של אפשרויות.

בפועל, עם זאת, מיקרוסופט קבעה למעשה את שורשי האמון עבור כמעט כל מחשב אישי למשתמשים. במקום ליצור - או לאפשר למשתמשים ליצור - מפתחות ותעודות Secure Boot, רוב ספקי החומרה שלחו מכונות עם סט של מפתחות ותעודות מוגדרות בחומרה הקושחה. רוב המפתחות והתעודות האלה היו "Microsoft 3rd‑party UEFI CA" שיכולות לחתום על מנהלי אתחול של צד שלישי. הפצות שרצו "פשוט לאתחל" במערכות אלה מבלי לבקש מהמשתמשים להחליף מתגים חבויים בקושחה, למעשה היו להן שתי אפשרויות:

• הוראות משלוח למשתמשים לביטול Secure Boot.
• או לשחק לפי זה ולקבל את הטעינה הראשונית הקטנה (shim) שלב ראשון חתומה על ידי CA של UEFI של מיקרוסופט.

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

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

הפשרה הזו עבדה בצורה מרשימה מאוד. במשך יותר מעשור, יכולת לקנות מחשב נייד אקראי, להפעיל Secure Boot, ולהעלות מערכת Fedora, Ubuntu, openSUSE, Debian, RHEL ואחרות, הכל הודות למפתח של מיקרוסופט השמור בקושחה שלך ול-binary חתום על ידי מיקרוסופט בחלוקת EFI System שלך.

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

מה פגה תוקף ב-2026?

שורש הדרמה של היום הוא שהתעודות של 2011 ש-Microsoft השתמשה בהן לחתום על רכיבי Secure Boot מתקרבות לסיום תקופת התוקף הרשמיים שלהן. מספר מתעודות ה-Secure Boot מתקופת 2011 של Microsoft יגיעו לסיום חייהן ב-2026, בשני גלים עיקריים (אמצע השנה ומאוחר יותר במהלך השנה).

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

לעסקים שמבוססים רק על Windows, זה בעיקר תיקון אוטומטי. בעולם ה‑Linux, זו סיפור שונה,

כאשר אנשים שומעים "פג תוקף תעודה," הם נוטים לדמיין משהו כמו תעודת SSL: ברגע שהיא עברה את התאריך "notAfter", הלקוחות מסרבים לתקשר עם השרת. מודל מחשבתי זה גורם לשנת 2026 להישמע כמו קצה מצוק: 24 ביוני מגיע, ובפתאומיות ההפצה שלך לא תאתחל.

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

הנה הבעיה

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

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

הנה מה לעשות:

1. עדכן את קושחת המכשיר שלך

כל ספק עיקרי שולח עדכונים ש, בין השאר, מוסיפים או מתקנים מפתחות Secure Boot בתגובה לתעודות של מיקרוסופט משנת 2023 ולפגי התוקף הקרבים. אינך צריך לדעת את מספרי המפתחות המדויקים כדי ליהנות מהעדכונים; עליך לוודא שהמערכת שלך מקבלת את העדכונים הללו.

במחשב לינוקס טיפוסי, גישה זו מתייחסת לבדוק את אתר התמיכה של היצרן שלך עבור עדכוני BIOS/UEFI שיצאו בשנה או בשנתיים האחרונות. ברבים מהמערכות, ניתן להשתמש בערכת העדכון של הקושחה בלינוקס, fwupd, כדי לבצע זאת מתוך ההפצה שלך. כדי לבצע צעד זה, הרץ את הפקודות הבאות כמשתמש root:

• fwupdmgr רענן
• fwupdmgr קבל-עדכונים
• עדכון fwupdmgr

אם החומרה שלך נתמכת, שלבים אלה יורידו קפסולות קושחה ועדכוני UEFI db/dbx הכוללים את אישורי האבטחה החדשים של Microsoft Secure Boot. לאחר העדכון, תצטרך לאתחל פעם או פעמיים; הקושחה תתעדכן בעצמה, ואתה סיימת.

במערכות ישנות יותר, ייתכן שתצטרכו עדיין להוריד קובץ .exe או .iso מהספק ולעקוב אחרי ההוראות שלהם. ההליך הזה מעצבן, אבל זו משימה חד‑פעמית שמספקת לכם שנים של התנהגות חלקה יותר של Secure Boot.

2. בדוק איך ההפצה שלך מטפלת בתעודות

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

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

בעבורך, המבחן הפשוט ביותר הוא גם המעשי ביותר:

• הורד קובץ ISO עדכני מהפצת הלינוקס שלך וכתוב אותו לכונן USB.
• במכונה עם Secure Boot מופעל והקושחה עודכנה לאחרונה, נסה לאתחל עם מקל ה-USB.
• אם זה עובד בצורה חלקה, השילוב שלך של מפתחות הקושחה וחתימות ההפצה בסדר, ואתה מוכן להמשיך.

עשה את הבדיקה הזאת פעם אחת עכשיו, כדי שתדע איך נראית הנורמה החדשה. אם תמונה עתידית תיכשל בואוט עם Secure Boot מופעל, תוכל לדעת אם ההדרדרות היא בקושחה (המפתחות לא עודכנו), בתמונה של ההפצה, או באינטראקציה לא נעימה בין השניים.

רבים מהדיסטרואים של לינוקס הפופולריים ביותר כבר טיפלו בבעיית ה-Secure Boot. חברת Red Hat פרסמה הנחיות ייחודיות לגבי פקיעת ה-Secure Boot ומתחזקת מערכי shim/bootloader של RHEL/Fedora שחתומים ותואמים למודל האמון של מיקרוסופט. משפחת Ubuntu של Canonical מספקת כבר זמן רב תמיכה מלאה ב-Secure Boot. המתקינים והליבות הנוכחיים של Ubuntu חתומים תחת ה-UEFI CA של צד שלישי הקיים של מיקרוסופט.

SUSE ו-openSUSE מוכנות גם הן לעבוד עם רשויות התעודה החדשות. התשתית של Secure Boot בדביאן חשובה מכיוון שה-shim שלה משמשת על ידי הפצות רבות והיא פותחה על ידי צוות חוצה-הפצות. עם זאת, כמה הפצות לינוקס, כגון Arch וקרוביו, לא מקלות על תמיכה ב-Secure Boot.

הדרך לעקוף המפתה

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

אני מבין. עשיתי את זה בעצמי. Secure Boot היה מכאיב מאז שהופיע לראשונה. עבור הרבה משתמשים, הדרך הקלה ביותר הייתה לכבות אותו ולהעלים את הבעיה.

הסכנה היא כאשר הפתרון הזמני הופך לקבוע. כאשר Secure Boot מושבת, אתה מאבד את ההגנה של Secure Boot נגד רוטקיטים ודומיהם. בעוד שרוטקיטים של "script‑kiddie" פחות נפוצים מבעבר לפני עשור, רוטקיטים מודרניים ברמת המשתמש, הליבה ואפילו ברמת ההיפרוויזור עדיין נמצאים בשימוש פעיל גם על ידי פושעים וגם על ידי תוקפים מתוחכמים. רוטקיטים נשארים אחד מסוגי התוכנות הזדוניות המפחידים ביותר כי הם מתמקדים בהסתרה ובקביעות.

האם Secure Boot הוא פתרון קסם? לא. האם הוא מחליף תחזוקה טובה של המערכת, עדכוני תוכנה וגיבויים? בהחלט לא. אבל Secure Boot הוא מגן משמעותי, ואקוסיסטם של לינוקס עבד קשה כדי לגרום לו להיות בעיקר בלתי נראה למשתמשים יום-יומיים. לזרוק את Secure Boot כי הוא מטרד היום זו טעות.

כאן, באופן ספציפי, זה מה שעליך לעשות לגבי התעודות שפג תוקפן.

למחשבים האישיים שלך:

• עדכן קושחה: לפני אמצע 2026, התקן את עדכוני ה-BIOS/UEFI האחרונים מהספק שלך. אם fwupd תומך בחומרה שלך, השתמש בו. זה פחות כואב מלערב כלים של Windows או עדי עדכון אתחוליים.
• אשר ש-Boot מאובטח עדיין עובד: ודא שההפצה הקיימת שלך עולה בצורה נקייה עם Boot מאובטח מופעל. לאחר מכן נסה תמונת לייב עדכנית מאותה הפצה. אם שתיהן עובדות, אתה במצב טוב.
• השאר את Secure Boot פעיל, אם אפשר: התייחס אליו כחלק רגיל ממערכת האבטחה שלך. אם משהו נכשל, נתח את התקלה והשבת אותו זמנית במידת הצורך, אבל אל תתעלם ממנו בקלות.

לשרתים שלך:

• רשום את המלאי שברשותך: ציין אילו מכונות מפעילות Secure Boot ואיזו קושחה הן מפעילות. אין צורך במסד נתונים לניהול תצורה (CMDB) מפואר; גיליון אלקטרוני יספיק.
• לאחד לגרסת קושחה בסיסית: בחר גרסאות קושחה נוכחיות המכילות את מפתחות האתחול המאובטח החדשים (הערות הגרסה של הספק שלך עשויות להזכיר זאת) והפץ אותן בכל המעבדה שלך.
• בדוק תמונות חדשות מוקדם: לפני שאתה משדרג הכל לגרסה ראשית חדשה של הפצה, בדוק את מתקין הגרסה הזו ואת שרשרת האתחול על מערכת מייצגת עם Secure Boot מופעל, כדי לגלות הפתעות על צומת קורבן.

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