שיעור 13: תהליך האתחול¶
**חלק א': מאגר ידע למדריך **
1. שרשרת האתחול: מ-Boot ROM דרך LLB ועד הקרנל במחשבי Apple Silicon¶
1. תיאוריה ברמת-על והיסטוריה (High-Level Theory & History)
מבחינה היסטורית, מחשבי מק מבוססי Intel השתמשו במערכת EFI (Extensible Firmware Interface) כדי לנהל את תהליך ה-Boot, ולטעון את קובץ ה-boot.efi ובסופו של דבר את הקרנל. תהליך זה, למרות שהיה פונקציונלי לאורך שנים רבות, היה רגיש מאוד לשינויים חיצוניים, Rootkits, ונוזקות Firmware. הצגת שבב ה-Apple T2 Security Chip במחשבי Intel המאוחרים יותר התחילה לשנות את הפרדיגמה הזו על ידי חיקוי תהליך האתחול המאובטח של מכשירי ה-iOS. במחשבי מק המצוידים ב-T2, השבב מבצע אתחול מאובטח מה-Boot ROM שלו כדי לאמת את מנהל האתחול iBoot. לאחר מכן, iBoot בודק את הקרנל והרחבות הקרנל (kexts), מאמת את קושחת ה-UEFI, וממפה אותה לזיכרון כדי שמעבד ה-Intel יוכל למשוך אותה דרך ה-eSPI. מעבד ה-Intel ממשיך לאחר מכן את שרשרת האמון, מאמת את מנהל האתחול Boot.efi, אשר בתורו מאמת את ה-immutablekernel לפני העברת השליטה ל-macOS.
עם המעבר המוחלט לארכיטקטורת Apple Silicon (מערכת על שבב - SoC), אפל שינתה לחלוטין את מודל האתחול והעתיקה באופן מלא את ארכיטקטורת האבטחה ממכשירי ה-iOS. המודל החדש והמודרני אינו מסתמך רק על תוכנה שטוענת תוכנה, אלא מבוסס לחלוטין על שרשרת אמון המעוגנת בחומרה (Hardware-Rooted Chain of Trust). כל שלב בודד בשרשרת זו חייב לבדוק את החתימה הקריפטוגרפית (Digital Signature) של הרכיב הבא לפני שהוא מעביר אליו את השליטה. אימות מוחלט זה מבטיח שהמערכת תריץ אך ורק קוד חתום ומאושר קריפטוגרפית על ידי אפל.
[!TIP] אנלוגיה היסטורית למדריך: מעניין לציין שבעידן ה-Classic Mac OS, ה-ROM היה צרוב פיזית בחומרה, ועבר ל-Open Firmware (מבוסס שפת Forth) שהעניק גישה אינטראקטיבית אבל היה "סיוט אבטחתי". המעבר ל-UEFI במחשבי אינטל הביא סטנדרטיזציה אבל השאיר חולשות. עם המעבר ל-Apple Silicon, אפל נטשה לחלוטין את UEFI לטובת מנגנון Secure Boot (iBoot) קפדני, אשר מייתר כליל את פתרונות אבטחת ה-Firmware הישנים.
2. ארכיטקטורה טכנית עמוקה (Deep Technical Architecture)
תהליך ה-Boot במחשבי Apple Silicon (שרשרת האתחול) מורכב משלבים קפדניים ובלתי ניתנים לשינוי:
- Boot ROM: זהו השלב הראשון המוחלט והוא צרוב פיזית (Hardcoded) בתוך ה-SoC במהלך הייצור (Read-Only). הוא מכיל את המפתח הציבורי של אפל (Apple Public Key) ומהווה את שורש האמון (Root of Trust). לא ניתן לשנות, לעדכן או להתעסק איתו. אם יש בו כשל קריטי, המכשיר נכנס למצב DFU.
- LLB (Low-Level Bootloader): ה-Boot ROM קורא את ה-LLB מהאחסון הפנימי, מוודא את חתימתו באמצעות המפתח הציבורי, ומריץ אותו. ה-LLB אחראי לאתחול בסיסי של החומרה ולטעינת רכיב ה-Secure Enclave.
- LocalPolicy (מדיניות מקומית): ה-LLB טוען את קובץ ה-LocalPolicy, אשר חתום על ידי ה-Secure Enclave Processor (SEP). קובץ זה מכתיב את תצורת המשתמש ואת מדיניות האבטחה בזמן הריצה (כגון Full Security מול Reduced Security).
- iBoot (Stage 2 Bootloader): ה-LLB מוודא וטוען את ה-iBoot. תפקידו של ה-iBoot הוא לטעון את סביבת ההתאוששות (Recovery Mode) במידה ונדרש, או לאמת את קרנל המערכת (macOS Kernel) ולטעון אותו מתוך ה-Sealed System Volume (SSV). iBoot קורא את ה-LocalPolicy כדי לקבוע אם מותר לטעון גרסאות ישנות של macOS או הרחבות קרנל צד-שלישי.
- macOS Kernel & SSV: הקרנל מאתחל את המערכת, מעגן (Mount) את ה-SSV ומוודא שעץ הגיבוב (Hash Tree) של APFS תואם את החותמת (Seal) של אפל. בתחילה, הקרנל רץ על ליבת מעבד יחידה לפני שהוא מפעיל את שאר הליבות ומשגר את ה-
launchd.
רכיב ה-Secure Enclave מהווה שחקן מרכזי בשרשרת, שכן הוא מספק את מפתחות ההצפנה החומרתיים הדרושים לפענוח ה-Data Volume. אם חתימה כלשהי נכשלת באחד השלבים, תהליך ה-Boot נעצר מיד, מה שמונע ממערכת נגועה לעלות.
ציר הזמן של האתחול וה-"Silent Phase" (השלב השקט)
על פי חפירה לעומק של תהליך האתחול ב-macOS 26 Tahoe, הרישום הפותח בלוג המאוחד (Unified log) הוא הכרזת האתחול (=== system boot:). לאחר מכן יש פער של 5 שניות או יותר, הידוע כהשלב השקט (Silent Phase). במהלך זמן זה, ה-LLB וה-iBoot מתבצעים. הם אינם כותבים ללוג המאוחד אלא משאירים קטעי מידע קריפטיים הידועים בשם "פירורי לחם" (breadcrumbs). לאחר מכן, הקרנל כותב את הודעת הפתיחה הרגילה שלו (kprintf initialized).
במהלך שלב הקרנל, שעון המערכת מסונכרן וזמן שעון-הקיר מותאם. פתיחת ה-Data Volume (Data volume unlock) מתרחשת בערך 10-15 שניות לאחר תחילת האתחול כאשר חלון ההתחברות מוצג. כאשר FileVault מופעל, ל-macOS עדיין אין גישה ל-Data Volume בשלב זה. המשמעות היא שכל הקוד שהופעל עד כה הוא בלתי ניתן לשינוי (נעול בקושחה או ב-SSV). אין גישה ל-/Library או לקבצי משתמש. ברגע שהסיסמה מוזנת, ה-SEP שולח הודעה שהווליום נפתח, והמערכת עוברת לאתחול מרחב המשתמש (Userspace boot), בו רישומי הלוג מזנקים מ-1,000 לשנייה ליותר מ-5,000 לשנייה.
3. פקודות טרמינל, Plists ולוגים (Terminal Commands, Plists & Logs)
-
בדיקת מצב ה-Boot ורמת ה-Secure Boot הנוכחית:
system_profiler SPSoftwareDataType -
בדיקת חותמת ה-SSV של המערכת:
diskutil apfs list(חפשו את השורה "Seal: Broken" או "Seal: Intact"). -
קריאת לוגים מתהליך האתחול והקרנל:
log show --predicate 'subsystem == "com.apple.kernel"' --last boot -
הערת פתרון תקלות: (הערה: אין פקודות טרמינל המאפשרות שינוי או גישה ישירה ל-Boot ROM, LLB או iBoot. רכיבים אלו סגורים לחלוטין למניעת שינוי זדוני "N/A").
4. מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)
אם שרשרת האתחול קורסת או מושחתת (למשל כשל בעדכון קושחה שפגע ב-LLB או ב-iBoot), המק לא ידלק בכלל וייכנס למצב DFU (Device Firmware Update). במצב זה, המק מתפקד כ"לבנה" פסיבית וממתין שמק אחר יתחבר אליו באמצעות כבל וידחוף אליו קובץ IPSW חתום מחדש בעזרת אפליקציית Apple Configurator (או Finder בגרסאות macOS מודרניות). התהליך נקרא Revive (תיקון קושחה ללא איבוד נתונים) או Restore (מחיקת כל הנתונים וצריבה מחדש של הקושחה), והוא המוצא היחידי להחייאת מק מבוסס Apple Silicon עם Boot Chain שבור.
בעת פתרון בעיות הפעלה, משתמשים יכולים לגשת ל-Startup Options ב-Apple Silicon על ידי כיבוי המק, ולאחר מכן לחיצה ממושכת על כפתור ההפעלה עד שיופיע "Loading startup options". מכאן, הם יכולים לבחור כונן הפעלה אחר, לגשת ל-macOS Recovery, או להיכנס ל-Safe Mode (על ידי בחירת ווליום, לחיצה ממושכת על מקש Shift ולחיצה על "Continue in Safe Mode"). מחשבי מק מבוססי Intel ניגשים ל-Safe Mode על ידי הפעלה מחדש והחזקה מיידית של מקש ה-Shift.
אינדיקטורים חזותיים לכשל באתחול כוללים סימן שאלה מהבהב (בעיית דיסק), סימן עצור (עיגול עם קו חוצה המציין מערכת הפעלה לא חוקית), או גלובוס עם אזהרה (כשל ב-Internet Recovery).
2. Startup Security Utility: שינוי רמות האבטחה (Full Security מול Reduced Security) ולמה שנרצה להוריד אבטחה¶
1. תיאוריה ברמת-על והיסטוריה (High-Level Theory & History)
בעידן מחשבי אינטל עם שבב ה-T2, אפל הציגה את ה-Startup Security Utility כדי לאכוף Secure Boot ולמנוע אתחול מכוננים חיצוניים. עם המעבר ל-Apple Silicon, פרדיגמת האבטחה השתנתה: כעת, לכל Volume במערכת יכולה להיות מדיניות אבטחה מקומית (Local Policy) משלו. Startup Security Utility (כלי אבטחת האתחול), הנגיש אך ורק מתוך Recovery Mode, מאפשר למשתמש בעל הרשאות מיוחדות (Volume Owner) לשנות את רמת האבטחה של מערכת ההפעלה ולהתיר טעינה של רכיבי צד-שלישי שאינם חתומים ישירות על ידי אפל כחלק מהמערכת הבסיסית.
[!NOTE] טריוויה למדריך: בעשור הראשון של Mac OS X בכלל לא הייתה מחיצת Recovery! רק ב-2011 (Lion) היא הוצגה לראשונה. היום ב-Apple Silicon קיימת מערכת 1TR (One True Recovery) שעולה ישירות מהחומרה ומייתרת את אינספור קיצורי המקלדת של העבר.
2. ארכיטקטורה טכנית עמוקה (Deep Technical Architecture)
במחשבי Apple Silicon קיימות שתי רמות אבטחה מרכזיות הקובעות כיצד שרשרת ה-Boot מתייחסת לקרנל:
- אבטחה מלאה (Full Security - ברירת מחדל): מערכת ההפעלה מתנהגת בדיוק כמו מכשיר iOS. המק יאתחל אך ורק אם מערכת ההפעלה והקרנל חתומים בצורה מלאה על ידי אפל ללא שינויים. במצב זה נמנעת טעינת הרחבות קרנל צד-שלישי. מצב זה דורש חיבור לאינטרנט במהלך התקנה כדי להגיע לשרת החתימות של אפל (TSS) ולאחזר חתימה מותאמת אישית (APTicket) בהתבסס על ה-ECID של המק, מה שמונע מתקפות Rollback לגרסאות פגיעות.
- אבטחה מופחתת (Reduced Security): מצב המאפשר למשתמש להתקין הרחבות קרנל (Kexts) חיצוניות או פרופילי MDM מתקדמים ללא חתימה מחמירה של אפל. שינוי למצב זה מעדכן את ה-Local Policy (הנשמר בקונטיינר ה-
iSCPrebootב-APFS) שמנחה את ה-iBoot להרשות טעינת Auxiliary Kernel Collection (אוסף קרנל עזר). הוא מוריד את הרף מול אפל, אך דורש אמון במנהל המקומי ומבטל בדיקות TSS מקוונות עבור הפעלת מערכות הפעלה ישנות. - Mac Sharing Mode: במצבי קצה שבהם המערכת פגומה והמשתמש זקוק לחלץ מידע דחוף, ניתן להפעיל מתוך סביבת ה-Recovery את Mac Sharing Mode (Target Disk Mode ההיסטורי). מצב זה מדלג על טעינת מערכת ההפעלה ומריץ שרת SMB וירטואלי מעל כבל Thunderbolt, כך שמק מארח יוכל להתחבר לכונן, לאמת סיסמה מול ה-Secure Enclave, ולהעתיק קבצים מה-Data Volume.
3. פקודות טרמינל, Plists ולוגים (Terminal Commands, Plists & Logs)
-
הצגת סטטוס האבטחה (Local Policy) (ב-Recovery):
bputil -d -
בדיקת מנגנוני ה-SIP ומדיניות ההגנה בסביבה החיה:
csrutil status -
בדיקת סטטוס הסכמת הרחבות הקרנל:
spctl kext-consent status -
הערת פתרון תקלות: לא קיימת פקודת טרמינל המאפשרת הורדת רמת האבטחה מתוך סביבת מערכת חיה. השינוי מחייב אתחול ל-Recovery Mode.
4. מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)
אם משתמש נכנס לכלי אבטחת האתחול ומנסה לשנות ל-Reduced Security אך המערכת מסרבת לקבל את הסיסמה שלו (או שהמשתמש לא מופיע ברשימה), המשמעות היא שהמשתמש אינו "Volume Owner". אין לו Secure Token צמוד לחשבון, ולכן ה-Secure Enclave אינו מכיר בו כגורם מוסמך לעריכת ה-Local Policy. בנוסף, שינוי של רמת אבטחה מחייב פעמים רבות חיבור אינטרנט זמין מכיוון שה-iBoot מנסה "לצלצל הביתה" לשרתי החתימות של אפל (Tatsu Signing Server - TSS) כדי לחתום קריפטוגרפית על המדיניות החדשה. ללא אינטרנט בסביבת ה-Recovery, השינוי עשוי להיכשל.
3. הרחבות קרנל (Kexts): למה אפל הורגת אותן ואיך מתקינים אותן בכל זאת במק מודרני¶
1. תיאוריה ברמת-על והיסטוריה (High-Level Theory & History)
הרחבות קרנל (Kernel Extensions או Kexts) הן פיסות קוד נמוכות הנטענות ישירות לתוך מרחב הליבה של macOS (Ring 0), ומעניקות להן שליטה מוחלטת ואקסלוסיבית על חומרת המערכת והרשת. היסטורית, כלים ארגוניים כמו אנטי-וירוס, פיירוולים חכמים (VPN), ודרייברים לחומרה עשו שימוש כבד ב-Kexts. הבעיה הבסיסית עם ארכיטקטורה זו היא שבאג קטן אחד בקוד של Kext מביא לקריסת המערכת כולה (Kernel Panic), ו-Kext זדוני מוביל להשתלטות עוינת מוחלטת.
כיום, אפל מבצעת Deprecation אקטיבי (הוצאה משימוש) של Kexts לטובת System Extensions הרצות בצורה בטוחה במרחב המשתמש (User Space) הרגיל. אם System Extension קורסת, האפליקציה נכשלת, אך המק ממשיך לפעול. עם זאת, עדיין קיימות תוכנות שורשיות המחייבות טעינת Kext.
[!TIP] פרספקטיבה היסטורית למדריך: מעניין לציין שבעידן ה-Classic Mac OS לא היה ל-Mac קרנל של ממש (במובן המודרני), ולכן גם לא היו Kernel Panics - המערכת פשוט הייתה קורסת כולה וקופאת. המעבר לארכיטקטורת קרנל ב-Mac OS X הוליד את ה-Kernel Panic המפורסם, כאשר דווקא תוספי הקרנל (Kexts) הפכו לעקב אכילס המרכזי של יציבות המערכת עד היום.
2. ארכיטקטורה טכנית עמוקה (Deep Technical Architecture)
במערכות macOS מודרניות (כמו macOS 26 Tahoe), התקנת Kext היא אירוע מורכב ביותר. תחילה, המערכת חייבת להיות מוגדרת תחת Reduced Security. כאשר מתקינים Kext, ה-macOS לא מכניסה אותו ישירות לתוך הקרנל המקורי החתום של המערכת (אשר נעול בתוך ה-SSV). במקום זאת, המערכת מרכיבה קולקציית ליבה נפרדת הנקראת Auxiliary Kernel Collection (AKC).
במהלך ה-Boot, ה-iBoot קורא את ה-Local Policy. אם אישור ה-Kext קיים שם, הוא טוען את ה-AKC במקביל לקרנל המקורי. ארכיטקטורה מבודדת זו מבטיחה שאם מנהל המערכת מחליט להחזיר את האבטחה ל-Full Security, ה-AKC מפסיק להיטען מידית והמחשב חוזר למצבו הבתולי ללא כל קוד ליבה צד-שלישי.
3. פקודות טרמינל, Plists ולוגים (Terminal Commands, Plists & Logs)
-
הצגת Kexts פעילים שאינם של אפל:
kmutil showloaded --list-only | grep -v com.apple -
ניקוי מערך ההכנה של ה-AKC (כלי פתרון תקלות עמוק ב-Terminal):
sudo kmutil clear-staging -
הצגת הרחבות מערכת מודרניות (המחליפות של Kexts):
systemextensionsctl list
4. מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)
תרחיש נפוץ בארגונים: משתמש מתקין כלי אבטחה ישן מבוסס Kext. התוכנה נראית מותקנת, אך היא לא פועלת בפועל מכיוון שהמשתמש לא נכנס ל-Recovery Mode להוריד את רמת האבטחה ולא אישר אותה באופן ידני ב-System Settings. במקרה שהמשתמש כן אישר, וה-Kext תקול ויוצר Kernel Panic מיד עם האתחול, המחשב ייכנס ללולאת הפעלות מחדש (Boot Loop). הפתרון המיידי הוא לבצע אתחול ל-Safe Mode. Safe Mode מדלג אוטומטית על טעינת ה-AKC ומעלה רק את הקרנל הנקי של אפל. משם, מנהל ה-IT יכול להסיר את התוכנה התקולה או לבטל את אישור ה-Kext.
4. תיבול ארגוני: אבטחת ה-Firmware, ניהול מפתחות שחזור מוסדיים במצב Boot, והגבלת משתמשים מלשנות רמת אבטחה¶
1. תיאוריה ברמת-על והיסטוריה (High-Level Theory & History)
בסביבה ארגונית מנוהלת, ה-IT לא יכול לסמוך על כך שמשתמשים יכנסו ידנית למצב Recovery, ישנו הגדרות בכלי אבטחת האתחול (Startup Security Utility), ויאשרו הרחבות ליבה (Kexts) או עדכוני תוכנה כבדים. יותר מכך, הארגון לא רוצה שלמשתמשים תהיה את האפשרות לעשות זאת ללא פיקוח קפדני. בעבר, ה-IT השתמש בסיסמת Firmware (Firmware Password) במחשבי אינטל למנוע גישה לדיסקים חלופיים ולמצב Recovery. ב-Apple Silicon, סיסמת הקושחה בוטלה לחלוטין. הניהול הארגוני השקט נשען כיום לחלוטין על שירות ה-MDM בשילוב ה-Bootstrap Token.
[!TIP] פרספקטיבה לאנשי IT: במחשבי Apple Silicon אין יותר Firmware Password. ההגנה על ה-Recovery מתבצעת כעת על ידי שילוב של FileVault ו-MDM Bootstrap Token, אשר חוסמים שינויים לא רצויים ללא צורך בסיסמת חומרה נפרדת.
2. ארכיטקטורה טכנית עמוקה (Deep Technical Architecture)
ה-Bootstrap Token הוא מנגנון הצפנה והפקדה (Escrow) קריטי. כאשר Mac עובר תהליך הרשמה (Automated Device Enrollment), הוא מייצר את האסימון ושולח אותו באופן מאובטח לשרת ה-MDM. אסימון זה משמש כמיופה כוח בעל הרשאות של "Volume Owner" מול ה-Secure Enclave.
- ניהול Kexts ללא משתמש (Silent Kext Management): כאשר ה-MDM שולח פרופיל מסוג
Kernel Extension Policyהמכיל את ה-Team ID של המפתח, ה-macOS בודקת אם קיים Bootstrap Token תקף. אם כן, היא יכולה לאשר את ה-Kext ולבנות את ה-AKC (Auxiliary Kernel Collection) מאחורי הקלעים, מבלי לבקש מהמשתמש להיכנס ל-Recovery. (הערה: שינוי ל-Reduced Security עדיין דורש אתחול ידני ל-Recovery אלא אם המכשיר הוקצה מראש דרך ADE והונחת מרחוק באמצעות ה-Bootstrap Token). - הגבלת רמות אבטחה: ה-MDM יכול לשלוח תצורה המונעת ממשתמשים לשנות את ה-Startup Security Utility בעצמם, כופה הפעלת Full Security ועוקף כל שינוי מדיניות של Admin מקומי ב-Recovery.
- תחליף ל-Firmware Password: במקום סיסמת קושחה, ארגונים מסתמכים היום על תכונת Activation Lock המקושרת ל-MDM, ועל יכולות Remote Wipe. תכונות אלו מגינות על המחשב מבוסס Apple Silicon כמעט באופן הרמטי במקרה של גניבה, באמצעות נעילת ה-Volume עם ה-Secure Enclave. גישה ל-Recovery דורשת במקרה כזה את סיסמת בעל הווליום או מפתח שחזור מוסדי/אישי (IRK/PRK) אם FileVault פועל.
3. פקודות טרמינל, Plists ולוגים (Terminal Commands, Plists & Logs)
-
בדיקה האם אסימון ה-Bootstrap נתמך והופקד בהצלחה מול ה-MDM:
profiles status -type bootstraptoken -
יצירה והפקדה ידנית של Secure Token ל-MDM במקרה של כשל:
sudo profiles install -type bootstraptoken -
חקירת בקשות פרופילים מול הרחבות קרנל:
profiles show | grep KernelExtensionPolicy -
בדיקת לוגים הקשורים לפעילות ה-MDM עם האסימון:
log show --predicate 'subsystem == "com.apple.ManagedClient" AND composedMessage contains "Bootstrap"' --info
4. מקרי קצה ופתרון תקלות (Edge Cases & Troubleshooting)
אם מערכת ה-MDM מנסה לדחוף למק שדרוג מערכת מלא (Upgrade) או התקנת Kext והפקודה נכשלת שוב ושוב עם הודעת השגיאה "Authorization Required" (דרושה הרשאת Volume Owner), הבעיה נעוצה ב-Bootstrap Token. על התומך לפתוח טרמינל במק ולהריץ את פקודת profiles status -type bootstraptoken. אם הפלט מראה supported: YES, escrowed: NO, משמעות הדבר היא ששרת ה-MDM איבד או מעולם לא קיבל את המפתח הקריפטוגרפי. כדי לתקן זאת, תומך בעל הרשאות Owner במק חייב להריץ sudo profiles install -type bootstraptoken ולהקליד את סיסמתו כדי לשלוח את המפתח מחדש לשרת. פעולה זו תשחזר את היכולת לנהל את ה-Mac בצורה שקטה (Zero-Touch) מרחוק.
💡 עזרים ויזואליים להרצאה (Presentation Visuals)¶
[!NOTE] תמונות אלו ניתנות להקרנה בכיתה בעת הסבר על הנושא, או לשילוב במצגות.
המחשה ויזואלית (עזר לתלמיד)
תמונות אלו ממחישות את הממשק או המנגנון הרלוונטי לנושא השיעור.
