זהו תהליך מתקדם שלא מומלץ למשתמשי Linux חדשים.
מערכת ChromeOS תומכת בהרצת קוד שרירותי בתוך מכונות וירטואליות. זהו מסמך ברמה נמוכה על התמיכה הזו. כדי לקבל תצוגה ידידותית יותר למשתמש, אפשר לעיין בfaq.
דרישות מוקדמות
- מוודאים שמכשיר ChromeOS תומך ב-Linux ב-ChromeOS
-
מוודאים שאתם משתמשים ב-ChromeOS מגרסה 72 (M72+) ואילך (הושקה בפברואר 2019).
- אם צריך, מתחילים עדכון מערכת ומפעילים מחדש את המכשיר.
- הפעולה הזו אמורה לעבוד בערוץ היציב.
- לא צריך להעביר אותו למצב פיתוח.
- הפעלת הקונטיינר של Linux
תכונות של זמן ריצה
התכונות הבאות אמורות לפעול כשמריצים את הקונטיינר של Linux:
- חיבורים לרשת יוצאים (IPv4).
- גרפיקה לא מואצת.
- גרפיקה מואצת (באמצעות OpenGL).
- תוכנות Wayland (מומלץ; דרך Sommelier).
- תוכניות X (תאימות באמצעות Sommelier ו-XWayland).
- פלט אודיו ב-M74 ומעלה, וקליטה/מיקרופון ניסיוניים ב-R79 ומעלה.
תכונות חסרות
יש הרבה דברים פשוטים שאנחנו עובדים על שיפור שלהם. הנה כמה דוגמאות ברורות:
- פענוח קוד של סרטונים באמצעות חומרה.
- IMEs.
צוות ChromeOS שוקל עוד דברים, אבל הוא נוקט גישה מדודה להשקת תכונות חדשות כדי לוודא שאבטחת המערכת הכוללת לא תיפגע. בשאלות הנפוצות בנושא Crostini אפשר לקרוא מידע מפורט יותר על רוב הנושאים שקשורים לפיתוח של Linux ב-ChromeOS.
אבטחה
למרות שהרצת קוד שרירותי היא בדרך כלל סיכון אבטחה, צוות ChromeOS מאמין שמודל זמן הריצה שבו נעשה שימוש ב-Linux במאגר ChromeOS מפחית את סיכון האבטחה הזה ומכיל אותו בצורה מספקת. המכונה הווירטואלית (VM) היא גבול האבטחה, וכל מה שנמצא בתוכה נחשב לא מהימן. בנוסף, תמונת האורח הנוכחית של מכונה וירטואלית מריצה ליבת מערכת הפעלה מותאמת אישית כדי לשפר עוד יותר את אבטחת הקונטיינרים, אבל זה נחשב ליתרון ולא למשהו שצריך להסתמך עליו כדי להבטיח את האבטחה הכוללת של המערכת.
במודל הזה, שאר מערכת ChromeOS אמורה להישאר מוגנת מפני קוד שרירותי (זדוני או מקרי) שפועל בתוך הקונטיינרים בתוך המכונה הווירטואלית.
הקשר היחיד עם העולם החיצוני הוא דרך crosvm, וכל ערוץ מתקשר עם תהליכים נפרדים (שכל אחד מהם נמצא בארגז חול מוגן).
נתוני משתמשים במאגר התגים
במעבר לשירותי ענן, הגישה הנוכחית לאבטחה מדגישה את העובדה שקבלת פרטי כניסה לחשבון (למשל הסיסמאות שלכם ל-Google או לפייסבוק) היא וקטור תקיפה משתלם יותר מאשר תקיפה של המחשב הנייח או הנייד. הן לא שגויות. הפתרון הנוכחי של ChromeOS למכונות וירטואליות או לקונטיינרים לא משפר את המצב הזה. במילים פשוטות, כל מה שמוזן למאגר התגים הוא באחריות המשתמש כרגע. לכן, אם מריצים קונטיינר לא מאובטח או שנפרץ, ואז מקלידים את הסיסמאות בקונטיינר, הן עלולות להיגנב גם אם שאר המערכת של ChromeOS נשארת מאובטחת.
התמדה של תהליכים
תהליכים במכונות וירטואליות ובקונטיינרים לא שורדים יציאה מהחשבון (כי הם נמצאים באחסון המוצפן של המשתמש) והם נסגרים אוטומטית. הם גם לא מופעלים אוטומטית בכניסה לחשבון (כדי למנוע מתקפות מתמשכות), וגם לא יכולים לפעול אוטומטית בהפעלה (ללא סשן כניסה) כי לא תהיה להם גישה (הם נמצאים באחסון המוצפן של המשתמש).
קוד שניתן להרצה ולכתיבה
קובץ האימג' של הדיסק של מכונת ה-VM של Termina מורד למחיצה הניתנת לכתיבה של מצב הנתונים, כמו רכיבים אחרים של Chrome. כדי לוודא שהתוכן לא ישתנה, נעשה שימוש ב-dm-verity. המשמעות היא שניתן לטעון רק תמונות שחתומות על ידי Google, והתמונה תמיד תהיה לקריאה בלבד.
תקיפות חומרה
לנקודות החולשה Meltdown/Spectre יש השלכות על השימוש הבטוח במכונות וירטואליות. הטמענו תיקונים ואמצעי הגנה כדי לוודא שמכונות וירטואליות לא יוכלו לתקוף את מערכת המארח או מכונות וירטואליות אחרות. פרטים נוספים זמינים בדף הוויקי של Chromium OS בנושא סטטוס הפגיעות של Meltdown ו-Spectre במכשירי ChromeOS.
מחזורי חיים
אחרי הפעלת הקונטיינר של Linux (שדואג להתקנה של כל הרכיבים הנחוצים האחרים, כמו Termina), המערכת מוכנה לשימוש.
יכול להיות שהרכיבים האלה מותקנים, אבל שום דבר לא מתחיל לפעול באופן מיידי. כשמתנתקים מהחשבון, הכול נסגר ומופסק, וכשמתחברים לחשבון, שום דבר לא מופעל מחדש באופן אוטומטי.
כשמריצים את אפליקציית Terminal או כל אפליקציית Linux אחרת שמפעילה את הקונטיינר, ואם קונטיינר האב שלה עדיין לא פועל, מכונת ה-VM של Termina תופעל באופן אוטומטי, וקונטיינר Linux ב-ChromeOS שמוגדר כברירת מחדל (שנקרא גם Crostini) יופעל בתוכה. כך תוכלו להתחבר למאגר באמצעות SSH או SFTP (דרך אפליקציית הקבצים).
כשסוגרים את כל האפליקציות שמוצגות, המכונה הווירטואלית או הקונטיינרים לא מושבתים. אם רוצים, אפשר להפסיק ולהתחיל אותם באופן ידני, וגם ליצור יותר מאגרים מאשר מאגר ברירת המחדל.
התמדה של נתונים
כל המכונות הווירטואליות והקונטיינרים שנוצרו, והנתונים בתוך הקונטיינרים האלה, יישמרו בין סשנים של משתמשים (התנתקות/התחברות). הם נשמרים באותו אחסון מוצפן לכל משתמש כמו שאר הנתונים של הדפדפן.
אם מכונה וירטואלית או קונטיינר מופסקים או מושבתים בצורה לא תקינה (למשל, הפסקת חשמל), יכול להיות שיהיה צורך לשחזר את הנתונים, כמו כל דבר אחר במערכת.
תמיכה במכשיר
השאיפה היא ש-Linux ב-ChromeOS יפעל בכל מכשירי Chromebook, אבל ליבת המערכת ותכונות החומרה הנדרשות מגבילות את הפריסה שלו. הצוות התמקד באבטחה וביציבות של המערכת, ובמקביל ביצע backporting של תכונות במקרים שהיה בכך היגיון. אנחנו ממשיכים לעבוד על התחום הזה.
נתמך עכשיו
רשימה של מכשירים נתמכים זמינה במאמר מערכות ChromeOS שתומכות ב-Linux.
דרישות חומרה
נכון לעכשיו, אין כמות מינימלית של זיכרון RAM, נפח אחסון או מהירות מעבד שנדרשים כדי להריץ את קונטיינר Linux ב-ChromeOS, אבל ככל שיש יותר מכל אחד מהם, כך הביצועים של המערכת יהיו טובים יותר.
עם זאת, תצטרכו מעבד שתומך בוירטואליזציה של חומרה. בפלטפורמות x86, יש לזה שמות רבים. Intel מתייחסת לזה כאל VT-x ו-VMX. AMD מתייחסת לזה כאל AMD-V ו-SVM.
מערכות BayTrail
מכשירי Chromebook עם מעבד BayTrail של Intel לא כוללים VT-x. למרות שבדרך כלל המעבד הזה כולל VMX, הגרסה שלו ב-Chromebook לא כוללת אותו, ולכן, לצערי, הוא אף פעם לא ייתמך.
כדי לבדוק אם לוח מסוים נתמך, אפשר לחפש את BayTrail ברשימת המכשירים הציבורית שלנו בעמודה Platform.
גרעיני ליבה ישנים
אין תוכניות לתמיכה ב-Linux 3.14 או בגרסאות קודמות. הן דורשות העברה לאחור של תכונות חדשות, שהיא נרחבת ולעתים פולשנית. לדוגמה:
כדי לבדוק אם לוח נתמך, אפשר לחפש ברשימת המכשירים הציבורית שלנו device list מספרי גרסאות שקטנים מ-3.14 בעמודה Kernel.
מעבדי ARM 32 ביט
קשה להפעיל מכונות וירטואליות במעבדי ARM של 32 ביט, זה לא סטנדרטי ונדרש תיאום עם הקושחה. לצערנו, קושחת ChromeOS לא נוטה להגדיר את התוספים. לכן, אין תמיכה במערכות האלה.
כדי לבדוק אם לוח מסוים נתמך, אפשר לחפש את arm ברשימת המכשירים הציבורית שלנו בעמודה Kernel ABI.