באמצעות קלסר IPC

דף זה מתאר שינויים במנהל ההתקשרות באנדרואיד 8, מספק פרטים אודות השימוש ב- IPC קלסר ומפרט את מדיניות SELinux הנדרשת.

שינוי לנהג קלסר

החל מאנדרואיד 8, מסגרת אנדרואיד ו- HALs מתקשרים כעת זה עם זה באמצעות קלסר. מכיוון שתקשורת זו מגדילה באופן דרמטי את תעבורת הקלסרים, אנדרואיד 8 כולל מספר שיפורים שנועדו לשמור על מהירות ה- IPC של קלסר. SoC ספקים יצרני ציוד מקורי צריכים להתמזג ישירות מן הענפים הרלוונטיים של 4.4 אנדרואיד, אנדרואיד-4.9, ומעלה של הקרנל / נפוצה הפרויקט.

דומיינים מרובים (הקשרים)

נפוץ -4.4 ומעלה, כולל במעלה הזרם

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

פיזור-איסוף

נפוץ -4.4 ומעלה, כולל במעלה הזרם

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

• לאחר בהמשכים אותו לתוך Parcel בתהליך קורא
• פעם נהג הקרנל כדי להעתיק את Parcel לתהליך היעד
• ברגע כדי unserialize Parcel בתהליך היעד

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

נעילה מגורעת

נפוץ -4.4 ומעלה, כולל במעלה הזרם

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

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

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

ירושה בעדיפות בזמן אמת

Common-4.4 ו- common-4.9 (במעלה הזרם בקרוב)

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

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

מרחב משתמשים משתנה

אנדרואיד 8 כולל את כול מרחב משתמש השינויים נדרש לעבודה עם נהג קלסר הנוכחי בליבה המשותפת עם חריג אחד: היישום המקורי ירושה עדיפה בזמן אמת להשבית /dev/binder השתמש IOCTL . הפיתוח שלאחר מכן העביר את השליטה בירושה בעדיפות לשיטה דקה יותר שהיא לכל מצב קלסר (ולא לפי הקשר). לפיכך, IOCTL איננו הסניף המשותף אנדרואיד והוא במקום להגיש הגרעינים המשותפים שלנו .

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

SHA עבור גרעינים נפוצים

כדי להשיג את השינויים הדרושים במנהל ההתקשרות, סנכרן עם ה- SHA המתאים:

• משותף-3.18
  cc8b90c121de ANDROID: קלסר: אל תבדוק הרשאות פריו בעת שחזור.
• משותף -4.4
  76b376eac7a2 ANDROID: קלסר: אל תבדוק הרשאות פריו בעת שחזור.
• משותף-4.9
  ecd972d4f9b5 ANDROID: קלסר: אל תבדוק הרשאות פריו בעת שחזור.

שימוש ב- IPC קלסר

מבחינה היסטורית, תהליכי ספק השתמשו בתקשורת בין -תהליכים מקשרת (IPC) לתקשר. בשנת אנדרואיד 8, את /dev/binder צומת המכשיר הופכת בלעדית לתהליכי מסגרת, תהליכי ספק כלומר כבר אין לו גישה אל. תהליכים הספק יכול לגשת /dev/hwbinder , אבל חייבים להמיר ממשקי AIDL שלהם לשימוש HIDL. עבור ספקים שרוצים להמשיך להשתמש בממשקי AIDL בין תהליכי ספקים, אנדרואיד תומכת ב- IPC קלסר כמתואר להלן.

vndbinder

אנדרואיד 8 תומכת בדומיין קלסר חדש לשימוש על ידי שירותי הספק, לגשת באמצעות /dev/vndbinder במקום /dev/binder . עם תוספת של /dev/vndbinder , אנדרואיד עכשיו יש שלושה דומיינים IPC הבאים:

דומיין IPC	תיאור
/dev/binder	IPC בין תהליכי מסגרת/אפליקציה עם ממשקי AIDL
/dev/hwbinder	IPC בין תהליכי מסגרת/ספק עם ממשקי HIDL IPC בין תהליכי ספק עם ממשקי HIDL
/dev/vndbinder	IPC בין תהליכי ספק/ספק עם ממשקי AIDL

עבור /dev/vndbinder להופיע, להבטיח את הפריט תצורת הקרנל CONFIG_ANDROID_BINDER_DEVICES מוגדר "binder,hwbinder,vndbinder" (זוהי ברירת המחדל ב עצי הקרנל המשותף של אנדרואיד).

בדרך כלל, תהליכי ספק לא לפתוח את נהג קלסר ישירות ובמקום לקשר נגד libbinder ספריית מרחב המשתמש, אשר פותחה את נהג קלסר. הוספת שיטה ::android::ProcessState() בוחרת את נהג קלסר עבור libbinder . תהליכי ספק צריכים להתקשר בשיטה זו לפני הקורא לתוך ProcessState, IPCThreadState , או לפני ביצוע שיחות קלסר בכלל. להשתמש, למקם את השיחה הבאה לאחר main() של תהליך ספק (לקוח ושרת):

ProcessState::initWithDriver("/dev/vndbinder");

vndservicemanager

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

עם זאת, שירותי הספק יכול כעת להשתמש vndservicemanager , מופע חדש של servicemanager כי שימושים /dev/vndbinder במקום /dev/binder ואשר בנויה מאותם מקורות כמו מסגרת servicemanager . תהליכי ספק לא צריך לעשות שינויים לדבר vndservicemanager ; כאשר תהליך ספק פותח / dev/vndbinder , חיפושי שירות אוטומטי ללכת vndservicemanager .

vndservicemanager בינארי כלול makefiles התקן ברירת המחדל של אנדרואיד.

מדיניות SELinux

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

1. גישה /dev/vndbinder .
2. בינדר {transfer, call} ווים לתוך vndservicemanager .
3. binder_call(A, B) עבור כל תחום הספק שרוצה לקרוא לתוך B תחום הספק על ממשק קלסר הספק.
4. רשות {add, find} ושירותים vndservicemanager .

כדי למלא את דרישות 1 ו 2, להשתמש vndbinder_use() המאקרו:

vndbinder_use(some_vendor_process_domain);

כדי למלא דרישה 3, את binder_call(A, B) עבור הספק מעבד A ו- B כי הצורך לדבר על קלסר יכול להישאר במקום, ואינו צריך שינוי שם.

כדי למלא דרישה 4, עליך לבצע שינויים באופן הטיפול בשמות שירותים, תוויות שירות וכללים.

לפרטים על SELinux, לראות אבטחה משופרת לינוקס ב Android . לפרטים על SELinux ב Android 8.0, לראות SELinux עבור אנדרואיד 8.0 .

שמות שירותים

בעבר, תהליכי הספק רשום שמות שירות בתוך service_contexts קובץ והוסיף מקביל כללים לגישת קובץ. דוגמה service_contexts קובץ device/google/marlin/sepolicy :

AtCmdFwd                              u:object_r:atfwd_service:s0
cneservice                            u:object_r:cne_service:s0
qti.ims.connectionmanagerservice      u:object_r:imscm_service:s0
rcs                                   u:object_r:radio_service:s0
uce                                   u:object_r:uce_service:s0
vendor.qcom.PeripheralManager         u:object_r:per_mgr_service:s0

בשנת 8 אנדרואיד, vndservicemanager עומסי vndservice_contexts להגיש במקום. שירותי ספק נודדות אלי vndservicemanager (ואשר נמצאים כבר הישן service_contexts הקובץ) יש להוסיף את החדש vndservice_contexts הקובץ.

תוויות שירות

בעבר, שירות תוויות כגון u:object_r:atfwd_service:s0 הוגדרו בתוך service.te קובץ. דוגמא:

type atfwd_service,      service_manager_type;

בשנת 8 אנדרואיד, אתה חייב לשנות את הסוג כדי vndservice_manager_type ולעבור כלל אל vndservice.te הקובץ. דוגמא:

type atfwd_service,      vndservice_manager_type;

כללי מנהלי שירות

בעבר, הכללים שניתנו תחומים גישה להוסיף או למצוא שירותים servicemanager . דוגמא:

allow atfwd atfwd_service:service_manager find;
allow some_vendor_app atfwd_service:service_manager add;

ב- Android 8, כללים כאלה יכולים להישאר במקומם ולהשתמש באותה מחלקה. דוגמא:

allow atfwd atfwd_service:service_manager find;
allow some_vendor_app atfwd_service:service_manager add;