על בנייה ואבטחת מערכות משובצות

Print Friendly, PDF & Email

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

עם כניסת ה-Raspberry Pi ושלל החיקויים שלו, יותר ויותר אנשים החלו לגלות את עולם ה-SBC (כלומר Single Board Computer – לוח אחד שעליו נמצא הכל, כולל מעבד, זכרון, אחסון ושלל חיבורים לעולם החיצון) ושוק המערכות המשובצות החל לקבל "ניעור" רציני. חברות המייצרות פתרונות הכוללות מערכות משובצות ראו שניתן לרכוש בכמה עשרות דולרים מערכות SBC ל-Embedded, מה שגרם למתחרים הותיקים להוריד מחירים. למי שאינו מכיר – הכרטיסון בתמונה הוא מחשב Raspberry Pi Zero שכולל כל מה שצריך (למעט חיבור רשת קווית שאפשר להוסיף במספר דרכים). העלות? 5 דולר, וזו סתם דוגמא ל-SBC זול שיכול לבצע פרויקטים שונים.

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

  • עצמאית או C/S? אחד הדברים הראשונים החשובים הוא להחליט איך המערכת תרוץ בעצם. האם מדובר במערכת עצמאית שאין לה תקשורת לשום שרת (עצמאית) או C/S (כלומר Client Server)? אם מדובר במערכת עצמאית, אז נצטרך להתקין עליה את כל האפליקציות (תיכף ארחיב על כך), ולדאוג לכך שהיא תפעל כמעט בכל מצב אפשרי, כולל מצב חרום שבו היא יכולה להציג למפעיל אם יש תקלה, מה התקלה ומה קוד התקלה כדי שיצרן הפתרון יוכל לטפל בכך.
    אם מדובר ב-C/S לעומת זאת, אז יהיה כדאי לבנות מערכת כמה שיותר רזה (לא להתקין הפצת לינוקס על המערכת אלא להשתמש ב-Yocto לדוגמא) וכל אפליקציה נחוצה תרוץ על השרת וביניהם התקשורת תעבור ב-TCP/IP, שימוש ב-Web Sockets וכו'.
    אם מדובר במערכת שיש לה תקשורת לשרת אך התקשורת אינה קבועה (אחת לשעה, אחת ליום וכו') אז כדאי יהיה לבנות אותה למצב אחסון זמני כך שברגע שהתקשורת מבוצעת, כל הנתונים מועברים לשרת, מתבצעת בדיקה שהנתונים נשמרו על השרת באופן תקני (אפשר להשתמש במגוון שיטות checksum) ולאחר מכן הנתונים ימחקו מהמערכת המשובצת. מבחינת אפליקציות להתקנה, נצטרך למצוא מה ניתן עדיין להריץ על השרת הרחוק ומה צריך לרוץ מקומית.
  • לא לדסקטופ: יש לא מעט מפתחי מערכות משובצות, שברגע שהם מקבלים מערכת משובצת עם 4 ליבות, 1-4 ג'יגהבייט זכרון ו-64 ג'יגה אחסון eMMC – בונים מערכת כאילו זה לינוקס דסקטופ. זה לא רעיון טוב הואיל וכל מעבד PC פשוט עוקף בסיבוב כל מעבד של מערכת משובצת. בנוסף, מערכות משובצות בקושי מקבלות עדכונים אם בכלל כך שיש סיכוי לא קטן שמערכת כזו בסופו של דבר תיפרץ ומכיוון שמערכות כאלו לא מעודכנות כמעט, הפורץ יכול להיכנס ולהשתמש ברשת הפנימית ובמערכת המשובצת כפי שירצה.
  • דיאטה: מערכת צריכה להיות כמה שיותר קטנה על מנת להקטין את וקטור התקיפה ולאפשר תחזוקה (אם צריך) קלה, ולכן לא מומלץ להתקין עליה מערכות אפליקציות שרת רגילות. צריכים לדוגמא SQL? תכירו את SQLite. צריכים שרת HTTP? יש מספר אפשרויות שמתאימות למערכות משובצות או httpd שמגיע כחלק מ-BusyBox או שימוש בשרת Web מובנה שקיים בפייתון/GO.
  • שפות כתיבת קוד: אם הפתרון הולך לרוץ כ-C/S, אז אתם יכולים לכתוב באיזו שפה שבא לכם ולהריץ את הקוד על השרת. אם זו מערכת עצמאית, אז אני ממליץ לכתוב בפייתון, Go או PERL (לוותיקים שביניכם) וסקריפטים ניתן ב-Bash או Python. יהיו כמובן חברות שירצו לכתוב קוד ב-JAVA או DOT NET (אפשר להריץ Dot Net Core על לינוקס), אבל חשוב לזכור שאם המערכת מבוססת על ARM ותרוץ עצמאית, אפליקציות כמו Wildfly או runtime של Dot Net Core לוקחות לא מעט משאבים ובלא מעט מקרים גורמות למערכת להגיב בצורה איטית.
    חשוב: לא לכתוב קוד אסמבלר יעודי למעבד. נכון, קוד אסמבלר זה נחמד ונותן מהירות (היום זה פחות רלוונטי, GCC מוציא קוד אסמבלי מעולה!) אבל פעם הבאה שהחברה תחליט להחליף מעבד, מישהו יצטרך לשכתב המון קוד אסמבלר מחדש ולכן אני ממליץ לא להיכנס לביצה הזו.
  • רדו מ-Windows: אתם בוודאי נתקלתם בזה בעבר – כספומטים שמגיבים באיטיות, מערכות מידע שלא מגיבות או שפשוט תקועות, קופות רושמות שנתקעות באמצע העברת מוצרים אצל הקופאית ועוד ועוד. מדוע ישנם הרבה פתרונות מבוססי Windows? כי מיקרוסופט מספרת כמה ה-Windows (כולל גירסת ה-Embedded) "יציבה", חברות גדולות עד לפני מס' שנים כתבו קוד שרץ רק על Windows, בנו "פתרון" שמורכב על PC פשוט והרי לכם מערכת שגם עם מיטב המומחים עדיין מצליחה להיות בלתי יציבה ואיטית פתאום.
    כיום ניתן לבנות מערכת משובצת מבוססת לינוקס שלא תתפוס יותר מ-80 מגהבייט אחסון (בערך) ותרוץ יפה על 1 ג'יגהבייט זכרון והמערכת תכלול דפדפן ותמיכה במסך מגע וכל המערכת תעלה מרגע החיבור לחשמל תוך 8-12 שניות עם הצגת לוגו לקוח בשניה הראשונה ולאחר 10-12 שניות הלקוח האנושי יכול להשתמש במערכת בתוך דפדפן סגור (כך שניתן להציג גרפיקה, OpenGL, אנימציה וכו' וגם לחבר את המערכת לציודים אחרים אם צריך).
    מדוע לא עוברים למערכת כזו? בחלק מהמקרים יהיה צורך לכתוב קוד חדש (במקרים כמו קופות), בחלק מהמקרים מדובר בחששות לא מבוססים, ובחלק מהמקרים עקב אי ידיעה או אי הכרת הדברים. אני מקווה בקרוב לקבל כמה מערכות משובצות, לבנות כמה מערכות דמה ולהוציא קליפים להדגמה ביוטיוב..
  • אבטחת מידע: זוכרים שאמרתי שלא כדאי להתקין הפצת לינוקס על מערכת משובצת? זה אחד הדברים הראשונים שפורץ ינסה להשתמש לטובתו, ולכן מומלץ לעבוד עם Busy Box סופר מצומצם במכונה שיכלול אך ורק פקודות הכרחיות, לצמצם הרשאות, לא להריץ הכל כ-root, ואם אפשר – לעבוד עם מפתחות והצפנה, בשביל זה כמעט כל מערכת משובצת מכילה רכיב TPM (לחובבי Raspberry Pi – יש חלק שניתן לרכוש, להרכיב ולהשתמש מבלי להלחים חוטים). אם המכשיר הולך להיבנות בסין, קחו בחשבון שינסו לגנוב לכם את הקוד ולכן הצפנה היא מאוד חשובה.
  • פשוט זה חכםתכירו את אחד החתולים הביתיים שלי – זהו נימי. מדוע אני מציג אותו? כי רמת המשכל של נימי שווה בערך לרמת המשכל של חלק מהאנשים בסין שיבנו ויקימו את המערכת ללקוח ובחלק מהמקרים – זו גם תהיה רמת המשכל של אלו שישתמשו במערכת (כבר ראיתי מישהו שמנסה להכניס בכח את כרטיס האשראי שלו לחור ממנו יוצאת הפתקית בכספומט!).
    לכן – אם המערכת שלכם כוללת אחסון (eMMC, SSD, לא מומלץ דיסק קשיח מכני, SSD הרבה יותר אמין) ואתם צריכים להקים Installer שירוץ על PC ויתקין את המערכת שלכם על הלוח SBC, תשתמשו בכמה שיותר אוטומציה ותנסו לצפות ולפתור כל תקלה אפשרית. אם המערכת נמסרה וישנה תקלה במערכת, תעלו אותה מחדש אוטומטית כך שברגע שהמשתמש יכנס דרך הדפדפן, התקלה תוצג והלקוח יוכל לשלוח לכם צילום מסך שלה.
    חשוב לנסות (אם התקציב מאפשר) לבנות מערכת Dual Boot (מערכת u-boot תומכת בכך) כך שניתן יהיה לשדרג מרחוק את המערכת עם Image תקין, ואפשר להשתמש בגירסת SystemD האחרונה כדי לעלות למערכת חרום אם המערכת הנוכחית לא עולה (אפשר לקרוא על כך כאן).
  • דלת אחורית/כניסה מרחוק: לא תמיד אתם יודעים היכן המערכת תרוץ ואתם לא יודעים מתי ומאיפה תקבלו בקשת תמיכה, ולכן חשוב לבנות זאת כחלק מהמערכת. אל תצפו ממשתמש קצה להקיש פקודות או שתקבלו בלא מעט מקרים – תוצאות מביכות.

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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