AES-NI ב-OpenSSL מול העברה לליבה: איזה מהם דרוש לכם?

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

שני צירים, לא ציון אחד

הציר הראשון הוא המימוש: האם הקוד שמבצע AES-256-GCM מנותב לגרסה שמשתמשת בהוראות הייעודיות של המעבד, או לשגרה ניידת שמבצעת אותן כאריתמטיקה רגילה. הבחירה הזו חיה בתוך הספרייה הקריפטוגרפית ונעשית כשזו מאותחלת.

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

אף ציר אינו מגביל את השני. VPN במרחב המשתמש על מעבד עם הוראות AES יכול להשתמש בהן כל הזמן, ומסלול בליבה על מעבד בלעדיהן נופל חזרה למימוש תוכנה. התוויות בחומרי ספקים ממעטות לעשות את ההבחנה הזו, ולכן עצות כוונון שמועתקות בין שני המצבים כל כך часто לא עושות דבר.

ציר ראשון: איזה קוד מבצע את ההצפנה

OpenSSL מזהה מאפייני מעבד בזמן האתחול ומשתמש בתוצאה כדי לבחור מסלולי קוד מיטוביים, כפי שמתארת תיעוד יכולות x86. AES-NI הוא אחת היכולות המתועדות מאחורי הניתוב הזה. דבר מזה אינו דורש שהספרייה תהפוך לרכיב בליבה.

ודאו שהמאפיין גלוי לתהליך לפני שאתם מניחים שהמסלול המהיר משמש. בלינוקס המקור הוא שדה flags ב-/proc/cpuinfo, ובתוך אורח הוא משקף את מה שההיפרוויזור חושף ולא את שם הדגם של המארח הפיזי.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

הפקודה השנייה מציינת את הספקים שנטענו באותו build. היא אינה אומרת לכם איזו ספרייה קישר שירות ה-VPN, ומארח יכול לשאת שתי התקנות של OpenSSL בעוד התהליך הרץ משתמש רק באחת מהן.

ציר שני: היכן רץ מסלול החבילות

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

הוא אינו יוצר תמיכת הוראות, אינו מגדיר צופן ואינו גורם למסלול קיים לעבוד.

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

מה כל בחירה קונה, ומה היא אינה יכולה

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

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

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

רשמו את ארבע העובדות לפני שתשנו משהו

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

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

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