שלבים מקדימים - התקנת התוכנות המתאימות (אם עשיתם את ממ"ן 01 אז יש לכם את הכל כבר) והעברת התיקייה xv6-03 למכונה הוירטואלית. פרטים נוספים כאן.
רקע - הפקודה mount מחברת מערכת קבצים מהתקן או מקובץ image לתיקייה קיימת, כך שהקבצים שלה נגישים דרך הנתיב הזה. כלומר, היא מחברת מערכת קבצים נוספת לתיקייה (נקודת עיגון). כמו שהיו לנו namespaceים של PID בממ"ן הקודם, יש כאן namespace של mount, אפשרות לקבוצת תהליכים להיות במערכת קבצים שנקודות העגינה מופרדות משאר המערכת - הקבוצה לא רואה את נקודות העגינה הכלליות, והNS הכללי לא רואה את נקודות העגינה של הNS.
המשימה - לתקן באג במערכת שקשור לטסטים שמורצים בmounttest.
תוכלו להפעיל את מערכת ההפעלה xv6 ולראות שאם ננסה להריץ פעמיים את mounttest (סדרת טסטים שקשורים לmount) ניתקל בkernel panic (תמונה 1).
תוכלו גם להריץ את make qemuss משורת הפקודה באותה תיקייה כדי לראות איך מערכת ההפעלה אמורה להתנהג אחרי שתיקנתם אותה.
תמונה (1) הרצת mounttest פעמיים לפני תיקון
הסבר הבעיה - כפי שניתן לראות מההודעה, המערכת לא מוצאת mount_list object שפנוי להקצות. הבעיה היא שכדי שתהליך יעזוב mount namespace, קוראים לפונקציה namespaceleave מקובץ namespace.c, שקוראת לפונקציה mount_nsleave בקובץ mnt_ns.c, שלא מעדכנת דברים שמו שצריך.
תיקון הבעיה - הפונקציה כעת כמעט ריקה. צריך להוסיף אליה 3 פעולות:
אם התהליך שעוזב את הNS הוא לא אחרון צריך לעדכן את המונה הרלוונטי
אם התהליך שעוזב הוא האחרון
צריך לרוקן את הmounts הקיימים באמצעות פונקציה קיימת באותו קובץ עם שם שמעיד על תפקידה
להדפיס שאין mounts, כלומר להדפיס "Mounts empty"
סיכום ובדיקה -
לסיכום, הקובץ להגשה הוא: mnt_ns.c
בכל קובץ קוד שמגישים אמורים לשים בראש הקובץ, בהערה, תיאור של הקובץ (נראה ששם הקובץ מספיק) וגם שם הסטודנט ומספר ת"ז.
בדיקה סופית - הריצו את mounttest פעמיים. בנוסף אפשר להריץ את הפקודה הבאה אחרי כיבוי של ה QEMU וגם make clean ו make, בלי להפעיל שוב את המכונה, כדי שהבדיקות יקבלו מכונה נקייה.
./runtests.exp my.log
הטסטר לא יציב - מוזמנים להריץ אותו בכל מקרה, אבל לפעמים פתרונות תקינים נופלים בטסטר. העיקר שmounttest ירוץ פעמיים (ויותר) בלי בעיה.
בעיה נפוצה: אין גישה לקובץ runtests.exp. במקרה הזה מריצים את השורה הבאה כדי לתת הרשאות -
chmod +x runtests.exp
רקע - שימוש בDocker בממ"ן הקודם.
הוראות -
צרו את סביבת הDocker באותה צורה שעשיתם בממ"ן הקודם, הפעם כמובן עם שם תיקייה שמתאימה לממ"ן הזה, xv6-03-XX
העלו/הוסיפו לתיקייה הראשית את הDockerfile שהגשתם בממ"ן הקודם וגם זיפ של xv6-01. תפתחו את הזיפ עם הפקודה הבאה:
unzip xv6-01.zip -d xv6-01
אם הזיפ כלל בתוכו תיקייה אז עכשיו כדי להוציא את התיקייה מבתוך התיקייה נריץ
sudo mv ./xv6-01/xv6-01/* ./xv6-01/
sudo rm -rf ./xv6-01/xv6-01
ערכו את הDockerfile
הורידו את סימן ההערה מהשורה של ADD והתאימו את שם התיקיות בשורה הזאת. הפקודה הזאת תוסיף את התיקייה xv6-01 לImage שאתם יוצרים.
הורידו את השורה שמעתיקה את xv6 מגיטהאב
התאימו את שם התיקייה שמבצעים עליה chmod (שימו לב שהיא תיקייה
שנו את השם של הWORKDIR ל"/xv6-01" כדי שנתחיל מבפנים התיקייה הזאת
הרצת הקונטיינר והרצת XV6 בתוכו. תזכורת מהן הפקודות הרלוונטיות:
docker build .
docker images
docker run -it <Image ID>
make clean; make; make qemu-nox
Ctrl-A X
exit
פירוט נוסף על שלבים שנעשו גם בממ"ן הקודם ניתן למצוא בקובץ "פירוט ביצוע משימת "DOCKER.docx" או בסרטון שהכנתי עבור הממ"ן הקודם.
להגשה:
ה Dockerfile כקובץ נפרד - שימו לב להגיש אותו כקובץ בלי סיומת. כשמורידים מהGithub מקבלים קובץ עם סיומת txt.
פקודות וצילומי מסך של הרצת הקונטיינר והרצת XV6 בתוכו.
תשובות על השאלות הבאות עם הסברים קצרים:
האם בבניית Image קיימת אפשרות הכללת xv6 של הקורס לא מתיקיה לוקלית?
למה אחרי הרצת הקונטיינר, אין גישה ישירה מתוכו למערכת הקבצים הלוקלית של Linux?
מי יוצר קונטיינר בפועל: מערכת Linux לוקלית או docker?
האם docker מוסיף תמיכה בהפרדת Namespaces למערכת ההפעלה?
האם docker פועל כ Hypervisor?
שאלות 2 ו3 משקפות את החומר שיש בהרצאות ובמבחן, שאלות 3 ו4 לא בהכרח היו בהרצאות ולא רלוונטיות עבור המבחן.
הערה שלי - התשובה נמצאת במדריך.
הסבירו למה בדיסק אלקטרוני מסוג SSD עדיף להשתמש במערכת קבצים ייחודית.
הערה שלי: שימו לב שהרעיון כאן הוא שבא' מתחשבים אך ורק במקום, ולא אכפת לנו כמה זמן מבזבזים, ובב' מתחשבים רק בזמני גישה ולא אכפת לנו כמה מקום מבזבזים. בנוסף, תלוי בהנחות הסבירות שמניחים אפשר להגיע לתשובות שונות, העיקר כאן באמת ההסבר שנותנים.
בכל רגע נתון גודלו של קובץ יכול לנוע בין 4KB ל 4MB. באיזו מבין 3 השיטות הקצאת מקום הייתם בוחרים כדי ש:
א. בזבוז מקום יהיה מינימאלי.
ב. זמני גישות סדרתיות יהיו מינימליים.
שיטות הקצאת מקום: הקצאה רציפה, רשימה מקושרת, i-node
הניחו הנחות סבירות נוספות אם נדרש. הדגימו חישובים עליהם התבססה ההחלטה.
ענו בנפרד על סעיפים א' וב', התשובות יכולות להיות שונות.
הערה שלי: זה לא חשוב למבחן, אז אם זה מבלבל אל תדאגו, אבל בכל מקרה חשוב להבין מה זה COW בכללי, יש על זה פסקה בתחתית עמוד 133 במדריך.
תקראו את ההסבר של מודל האבטחה וניהול תהליכים במערכת אנדרואיד (פרקים 10.8.10-10.8.12 בספר הקורס ,אין צורך להתייחס לפרטים בפרק 10.8.11, אלא רק למודל עצמו).
א) במה המודל המתואר דומה לקונטיינרים הנידונים בחלק המעשי של מטלות הקורס ובמה הוא שונה ממנו?
ב) באיזה סוג בידוד(הפרדה) מדובר?
ג) איזה יתרון יש לשיטת ניהול זיכרון ראשי (COW (Copy On Write שמערכת אנדרואיד משתמשת בהקשר מימוש מודל התהליכים שלה?
הערה שלי: התשובה נמצאת בסעיף 9.3 של המדריך
תארו בקצרה את 2 שיטות מניעת ניסיון שינוי ה capability שניתנה למשתמש במערכת ללא תמיכת חומרה.
ציינו בקצרה את היתרון והחיסרון של כל אחת מהן.
מגישים זיפ יחיד בשם ex03 עם הקבצים -
את הקובץ ששיניתם בחלק א' של שאלה 1
קובץ הDockerfile מחלק ב' של שאלה 1
קובץ עם התשובות לכל שאר השאלות שקוראים לו ex03.docx או ex03.pdf בהתאם לסוג הקובץ