אימות אבטחה ופריסה¶
נניח שה־driver נבנה ללא שגיאות והלקוח קיבל תשובה נכונה פעם אחת. עדיין לא בדקנו מה קורה לאורך קלט שגוי, ביטול בזמן הסרה, הרשאה חסרה או הקצאה שנכשלת. בקרנל, שגיאה במסלול צדדי יכולה להשפיע על כל המערכת, ולכן הצלחת הדגמה בסיסית היא רק תחילת האימות.
נחבר את קובץ ה־sys לחבילת התקנה, לחוזה אבטחה ולבדיקות על VM. לא נפעיל verifier או התקנת driver על מחשב העבודה. ה־host מחזיק קוד וסמלים, וה־target הוא מכונת הניסוי שניתן לשחזר מ־snapshot.
חבילה היא יותר מקובץ sys¶
ה־INF מתאר זהות חומרה, קובצי התקנה, שירות, גרסת framework והגדרות התקן. ה־catalog והחתימה קושרים את החבילה למדיניות האמון של המערכת. שינוי INF או קובץ בינרי אחרי יצירת catalog מחייב יצירה וחתימה מחדש לפי תהליך הבנייה.
בפרויקט נשתמש בהתקן תוכנה עם hardware ID מדויק מסוג Root. הוספת חבילה למאגר drivers באמצעות PnPUtil אינה בהכרח יוצרת התקן root חדש. לכן שלב יצירת ההתקן במעבדה מתבצע לפי תהליך הפריסה של WDK או באמצעות DevCon עם ה־INF וה־ID של הפרויקט.
חתימת בדיקה מתאימה ל־target שהוכן לכך. אין להציג אותה כחתימת הפצה, ואין לשנות את מדיניות האמון של ה־host כדי לחסוך שלב. דרישות הפצה, attestation או HLK משתנות לפי סוג driver ומדיניות Microsoft; בודקים אותן בעת הכנת חבילה אמיתית.
מי רשאי לפתוח ומה מותר לבקש¶
ה־ACL של device מגדיר מי יכול לפתוח ובאילו גישות. שדה access של IOCTL מוסיף דרישה על ה־handle שממנו נשלחה הבקשה. אלה אינם תחליפים לבדיקת lengths, גרסה ומשמעות תוכן הבקשה.
נבחן גם פלט. אם driver מחזיר יותר bytes ממה שאתחל, הוא עלול לחשוף מידע מתוך kernel memory. לכן Information ב־completion צריך לשקף רק נתונים תקפים שהוכנו עבור הקורא. שדה שמור בפורמט צריך להיות מאופס או מוגדר, ולא לקבל padding מקרי.
בפרויקט מגבילים את device למנהלים ול־SYSTEM במכונת היעד. הבדיקה השלילית פותחת מתוך חשבון רגיל ומצפה לדחייה. ההרשאה המצומצמת אינה פוטרת מפענוח בטוח, משום שגם לקוח מורשה יכול להיות פגום.
הפעלת אימות ממוקד¶
ב־VM שהוכן עם debugger ו־snapshot, מפעילים verifier רק עבור driver המעבדה. הפקודות הבאות מיועדות ל־target בלבד ודורשות חלון מנהל שם:
לאחר האתחול שנדרש לפי הכלי, מריצים את מטריצת הבדיקות. בסיום מחזירים את ההגדרה במפורש ומאתחלים לפי הצורך:
הכלי יכול לגרום ל־bugcheck כדי לעצור קרוב להפרת החוזה. לכן שומרים דרך גישה ל־VM ול־snapshot גם אם ה־driver מונע אתחול רגיל. אין לבחור את כל drivers המערכת רק מפני שזו אפשרות בתפריט.
בדיקות standard אינן רשימת כל הבדיקות האפשריות. אפשר להוסיף בדיקות ממוקדות לפי ההשערה, ולתעד את ההגדרה המדויקת. כלי ניתוח סטטי ודרישות ההסמכה של WDK משתנים בין גרסאות; אין להבטיח ש־SDV ישן זמין או נדרש באותו אופן בכל ערכת כלים.
קריאת dump עם שאלה¶
אחרי כשל שומרים dump, קובץ sys וה־PDB המדויק. ב־WinDbg מתחילים בטעינת סמלים ובניתוח, ואז בודקים את הראיות במקום להעתיק את שם ה־module הראשון כתשובה:
.symfix
.reload /f
!analyze -v
lmvm AmitEchoLab
!verifier
!wdfkd.wdfdriverinfo AmitEchoLab
!wdfkd.wdflogdump AmitEchoLab
זמינות פקודות הרחבה והמידע שהן מציגות תלויה בסוג ה־dump ובגרסת הכלים. אם אין אובייקט מסוים ב־dump, אין להמציא את מצבו. בודקים bugcheck parameters, ה־IRQL, כתובת הגישה, call stack ומצב הבקשה או התור שניתן לקרוא.
נניח שהכשל הוא שימוש בבקשה אחרי completion. נרצה למצוא מי השלים, מי שמר handle ואיזה callback הגיע אחר כך. תיקון שמוסיף בדיקת null במקום אחד אינו מספיק אם copy אחר של ה־handle עדיין חי.
מטריצה שמכסה חוזים¶
נבדוק קלט קצר, קלט ארוך, גרסה לא נתמכת, overflow, פלט קצר, IOCTL לא מוכר, גישה ללא הרשאה, cancel מוקדם, cancel מאוחר, סגירת handle והסרת התקן. נוסיף חזרות של start/stop כדי לגלות משאבים שנשארים בין מחזורים.
לכל בדיקה נרשום תוצאה צפויה ברמת החוזה, ולא רק קוד מספרי אחד כאשר מרוץ מאפשר כמה תוצאות תקינות. למשל, בקשה שמתחרה עם ביטול יכולה להסתיים בהצלחה או בביטול, אך לעולם לא פעמיים ולא אחרי שחרור buffer.
גבול ההישג¶
מעבדה שעברה מראה הבנה ומימוש בתחום שנבדק. היא אינה מוכיחה מוכנות להפצה לכל חומרה ולכל build. פריסה אמיתית דורשת מדיניות תמיכה, בדיקות חומרה, חתימה ותהליך עדכון והתאוששות. הקורס דורש לתעד את הגבול הזה בדיוק, לצד ההישגים שכן הוכחו.
קריאה להעמקה¶
התיעוד של Driver Verifier, אבטחת התקן KMDF ובניית driver עם WDK מספק את תהליך האימות. יש לקרוא את דרישות החתימה העדכניות בעת הכנת הפצה בפועל.