פתרון אמון אתחול ובידוד חומרה

הקריאה הנכונה של הדוח מתחילה מערכים חסרים. כאשר secureBootError מכיל שגיאת הרשאה, אין לנו עדיין תשובה לגבי Secure Boot. כאשר שירות מופיע בconfigured ואינו מופיע בrunning, יש הבדל אמיתי בין רצון המנהל למצב הפעיל שדורש חקירה.

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

בכשל לפני הכניסה בודקים זהות קובץ, חתימה, גרסת מדיניות ואירוע טעינה. בקריסה אחרי הכניסה אוספים dump וסמלים וממפים את מסלול הבקשה; חתימה תקפה אינה הוכחת תקינות זיכרון. בחסימת גרסה ישנה משווים את מדיניות החסימה והגרסה המדויקת, בלי להסיק שהחתימה הקריפטוגרפית עצמה התקלקלה.

הצד המאמת בattestation צריך לקשור תשובה לchallenge טרי, לזהות שהוא סומך עליה ולמדידות שמתאימות למדיניות שלו. את הevent log מפרשים מול הערכים המאומתים, ולא מקבלים טקסט שרירותי מהלקוח כהוכחה. התשובה ״המחשב בטוח״ רחבה מדי; התשובה צריכה לציין אילו רכיבים ומדיניות נבדקו ומה נמצא מחוץ לטווח הראיות.

הדוח הטוב מסיים בממצא מוגבל: תכונה מסוימת נצפתה פעילה בתצורה מסוימת בזמן מסוים. את ההשלכה על הdriver מוכיחים באמצעות ניסוי הטעינה המתאים.