Linux - SysCalls. Apeluri de sistem în Linux

Sfârșitul hârtiei / EOP

Cel mai adesea, codul de apel al sistemului cu numărul __nr_xxx definit în /usr/include/asm/unistd.h.pot fi găsite în codul sursă al kernel-ului Linux în funcție sys_xxx.(). (Tabelul de apel pentru i386 poate fi găsit în /usr/src/linux/arch/i386/kernel/entry.s..) Există multe excepții din această regulă, în principal datorită faptului că majoritatea apelurilor vechi ale sistemului sunt înlocuite cu noi, cu ceva fără nici un sistem. Pe platformele cu auto-emulare, cum ar fi Parisc, Sparc, Sparc64 și Alpha, există multe apeluri suplimentare de sistem; Pentru MIPS64 există, de asemenea, un set complet de apeluri de sistem pe 32 de biți.

De-a lungul timpului, dacă este necesar, modificările au avut loc în interfața unor apeluri de sistem. Unul dintre motivele acestor modificări a fost creșterea dimensiunii structurilor sau a valorilor scalare ale apelului de sistem transmis. Din cauza acestor schimbări asupra unor arhitecturi (și anume, diverse grupuri de apeluri similare ale sistemului au apărut pe vechiul 32 biți i386) (de exemplu, trunchia.(2) și trunchate64.(2)), care îndeplinește aceleași sarcini, dar diferă în funcție de mărimea argumentelor lor. (După cum sa menționat deja, nu afectează aplicațiile: Funcțiile Wolved Glibc îndeplinesc unele acțiuni pentru a porni apelul corect al sistemului, ceea ce oferă compatibilitate pe ABI pentru fișierele binare vechi.) Exemple de apeluri de sistem care au mai multe versiuni:

* În prezent există trei diverse versiuni stat.(2): sys_stat.() (un loc __Nr_oldstat.), sys_newstat.() (un loc __Nr_stat.) I. sys_stat64.() (un loc __Nr_stat64.), acesta din urmă este folosit în acest moment. Situație similară S. lSTAT.(2) și fstat.(2). * În mod similar, definit __Nr_oldolduname., __Nr_olduname. și __Nr_unames. Pentru apeluri sys_olduname.(), sys_uname.() I. sys_newuname.(). * În Linux 2.0 a apărut o nouă versiune vM86.(2), se numesc versiuni noi și vechi ale procedurilor nucleare sys_vm86old.() I. sys_vm86.(). * În Linux 2.4 are o nouă versiune gellimit.(2) se numesc versiuni noi și vechi ale procedurilor nucleare sys_old_getellimit.() (un loc __Nr_getellimit.) I. sys_getellimit.() (un loc __Nr_ugetellimit.). * În Linux 2.4 ID-uri de utilizator și grupuri de utilizator crescute de la 16 la 32 de biți. Pentru a susține această modificare, au fost adăugate mai multe apeluri de sistem (de exemplu, chown32.(2), getuid32.(2), getGroups32.(2), setresuid32.(2)), eliminarea apelurilor timpurii cu aceleași nume, dar fără sufix "32". * În Linux 2.4 Suport adăugat pentru accesul la fișiere mari (dimensiunile și compensarea nu se potrivesc 32 de biți) în aplicații pe arhitecturi pe 32 de biți. Pentru a face acest lucru, a fost necesar să se facă modificări ale apelurilor de sistem care să funcționeze cu dimensiuni și deplasări pe fișiere. Au fost adăugate următoarele apeluri de sistem: fcntl64.(2), getdents64.(2), stat64.(2), sTATFS64.(2), trunchate64.(2) și analogii lor care se ocupă de descriptorii de fișiere sau legăturile simbolice. Aceste sisteme solicită abolirea apelurilor vechi de sistem, care, cu excepția apelurilor "stat", sunt, de asemenea, numite, dar nu au un sufix "64".

Pe platforme noi cu numai acces la fișiere pe 64 de biți și 32 de biți (de exemplu, Alpha, IA64, S390X, X86-64), există o singură versiune de apeluri de sistem pentru UID / GID și accesul la fișiere. Pe platformele (de obicei, platforme pe 32 de biți) în care există apeluri * 64 și * 32, alte versiuni sunt depășite.

* Apeluri rT_SIG * Adăugat la kernel 2.2 pentru a susține semnale suplimentare în timp real (a se vedea semnal.(7)). Aceste sisteme solicită abolirea apelurilor vechi cu aceleași nume, dar fără prefixul "RT_". * În provocările sistemului sELECTAȚI(2) și mMAP.(2) Sunt utilizate cinci sau mai multe argumente, ceea ce a provocat determinarea metodei de transmitere a argumentelor la i386. În ancheta acestui fapt, în timp ce alte arhitecturi sună sys_select.() I. sys_mmap.() corespunde cu __Nr_select. și __Nr_mmap., pe i386 ele corespund old_Select.() I. old_mmap.() (Proceduri care utilizează un indicator la blocul de argument). În prezent, nu mai există o problemă cu transferul a mai mult de cinci argumente și este __Nr__newsect.care corespunde exact sys_select.(), și aceeași situație cu __Nr_mmap2..

Mult o mulțime de walrus, este timpul să vorbim.
L. Carolle (Citat pe B. Strawbook)

În loc de administrare.

Pe tema dispozitivului intern al kernelului Linux, în general, diferitele sale subsisteme și provocări ale sistemului, în special, au fost scrise și rescrise prin ordin. Probabil, fiecare autor de auto-respect ar trebui să scrie acest lucru, la fel cum fiecare programator de auto-respect trebuie să-și scrie propriul manager de fișiere :) Deși nu sunt un profesionist IT-Raiter și, în general, îmi fac marcajele exclusiv în beneficiul său în primul rând să nu uitați prea repede. Dar, dacă cineva va veni la îndemână notele mele de călătorie, desigur, voi fi fericit doar. Ei bine, în general, terciul nu strică uleiul, deci poate fi chiar posibil să scrie sau să descrie ceva pe care nimeni nu-l deranjează să menționeze.

Teorie. Ce sunt apelurile de sistem?

Când este neinițiată explica ce fel de (sau OS) sunt, de obicei, ei spun următoarele: Computerul însuși este o bucată de fier, dar software-ul este că, datorită căruia este posibil să beneficiezi de această bucată de fier de fier . Rude, desigur, dar, în general, ceva corect. Probabil că aș spune provocările OS și sistemul. De fapt, în diferite apeluri de sistem pot fi implementate în moduri diferite, numărul acestor callalii se poate retrage, dar într-un fel sau altul, într-unul sau altul, mecanismul de apel al sistemului este în orice sistem de operare. În fiecare zi, utilizatorul este în mod clar sau care nu funcționează în mod explicit cu fișiere. Desigur, poate deschide în mod explicit un fișier pentru editare în cuvântul său preferat MS "E sau Notepad" E și poate pur și simplu rulați jucăria, imaginea executabilă a cărei, de asemenea, este stocată și în dosar, care, în Rotiți-vă, trebuie să deschideți și să citiți fișierele executabile de bootloader. La rândul său, jucăria poate deschide și citi zeci de fișiere în procesul de lucru. Bineînțeles, fișierele nu pot citi numai, ci și să scrie (nu întotdeauna, dar aici nu este vorba de împărțirea drepturilor și accesul discret :)). Toate acestea se îndreaptă spre miez (situația din sistemul de operare micronică poate fi diferită, dar acum vom avea tendința neobișnuit de obiectul discuției noastre - Linux, așa că ignor acest moment). Generarea unui nou proces este, de asemenea, serviciul furnizat de kernelul OS. Toate acestea sunt minunate, cum ar fi procesoare moderne Lucrați la frecvențele benzilor Gigahertz și constau din multe milioane de tranzistori, dar ce urmează? Da, că dacă nu ar exista alt mecanism, cu care aplicațiile personalizate ar putea efectua unele destul de obișnuite și, în același timp, lucrurile necesare ( de fapt, aceste acțiuni triviale sunt efectuate la orice, nu este de acord, nu o aplicație utilizator, ci miezul OS - AVT.), atunci sistemul de operare a fost doar un lucru în sine - absolut inutil sau dimpotrivă, fiecare aplicație de utilizator ar fi trebuit să devină sistem de operarePentru a servi independent toate nevoile dvs. Drăguț, nu-i așa?

Astfel, am abordat definiția unui apel de sistem în prima aproximare: un apel de sistem este un tip de serviciu pe care kernelul OS oferă o cerere de utilizator la cererea acestuia din urmă. Un astfel de serviciu poate fi deschiderea deja menționată a fișierului, crearea, citirea, scrierea, crearea unui nou proces, obținând un identificator de proces (PID), montare sistemul de fișiere, Opriți sistemul, în cele din urmă. În viața reală, apelurile de sistem sunt mult mai mult decât este listat aici.

Ce arată un apel de sistem și ce este? Ei bine, de la ceea ce sa spus mai sus, devine clar că apelul de sistem este o subrutină de bază, având o privire corespunzătoare. Cei care au avut experiență de programare în cadrul Win9x / Dos, îmi amintesc probabil întreruperea int 0x21 cu toate (sau cel puțin unele) numeroase funcții. Cu toate acestea, există o singură caracteristică mică cu privire la toate apelurile sistemului UNIX. Prin acord, funcția care implementează apelul de sistem poate primi argumente n sau nu le acceptă deloc, dar într-un fel sau altul, funcția trebuie să returneze valoarea INT. Orice valoare non-negativă este interpretată ca o execuție reușită a funcției de apel al sistemului și, prin urmare, este cel mai mare apel de sistem. Valoarea este mai mică decât zero este o caracteristică a erorii și, în același timp, conține un cod de eroare (codurile de eroare sunt definite în InCOP / ASM-generic / Errno-Base.h și includ / ASM-generic / Errno.h titluri ). În gateway-ul Linux pentru apelurile de sistem până la recent a existat o întrerupere int 0x80, în timp ce în Windows (până la versiunea XP Service Pack 2, dacă nu mă înșel), această gateway este 0x2E întrerupe. Din nou, în kernelul Linux, până de curând, toate apelurile de sistem au fost procesate de funcția System_Call (). Cu toate acestea, după cum sa dovedit mai târziu, mecanismul clasic al apelurilor de sistem de curgere prin intermediul gateway-ului 0x80 conduce la o scădere semnificativă a performanței procesorului. Intel Pentium. 4. Prin urmare, metoda de obiecte partajate dinamice virtuale a venit să înlocuiască mecanismul clasic (DSO - Dynamic Shared Obiect de obiect. Nu se iau în considerare pentru traducerea corectă, dar DSO este că utilizatorii Windows sunt cunoscuți numiți DLL - Bibliotecă descărcabilă și componentă dinamică ) - VDSO. Care este diferența dintre o nouă metodă de la clasic? Pentru a începe cu, înțelegem cu metoda clasică care lucrează prin poarta 0x80.

Sistemul clasic de servicii de serviciu în Linux.

Întrerupe în arhitectura x86.

După cum sa menționat mai sus, mai devreme pentru întreținerea aplicațiilor utilizator uzate 0x80 (int 0x80). Funcționarea sistemului de arhitectură IA-32 este gestionată de întreruperi (strict vorbind, aceasta se referă la toate sistemele bazate pe X86). Când apare un anumit eveniment (un nou timer TIK, orice activitate pe un dispozitiv, erori - diviziune la zero, etc.), se generează o întrerupere. Întreruperea (întreruperea) este numită astfel încât, de obicei, întrerupe cursul normal al codului. Întreruperile sunt acceptate pentru a împărți pe hardware și software (întreruperi hardware și software). Întreruperea hardware sunt întreruperi care sunt generate de dispozitive sistemice și periferice. Dacă aveți nevoie de un dispozitiv, veți atrage atenția kernel-ului de operare (dispozitivul) generează un semnal pe linia de interogare a întreruperii (linia de solicitare IRQ - interruptură). Acest lucru duce la faptul că semnalul corespunzător este generat pe anumite intrări ale procesorului, pe baza cărora procesorul și face soluția să întrerupă fluxul de instrucțiuni și să transfere controlul la dispozitivul de întrerupere a întreruperii, care află deja ce sa întâmplat și ce trebuie făcut. Hardware-ul întrerupe asincron prin natura lor. Aceasta înseamnă că întreruperea poate apărea în orice moment. in afara de asta dispozitiv perifericProcesorul în sine poate produce întreruperi (sau, mai precis, excepții hardware - excepții hardware - de exemplu, diviziunea deja menționată pe zero). Acest lucru se face pentru a notifica sistemul de operare cu privire la apariția unei situații anormale, astfel încât OS să poată lua un fel de acțiune ca răspuns la apariția unei astfel de situații. După procesarea întreruperii, procesorul revine la finalizarea programului întrerupt. Întreruperea poate fi inițiată de aplicația de utilizator. O astfel de întrerupere se numește software. Software-ul întrerupe, spre deosebire de hardware, sincron. Acestea., Atunci când chemați o întrerupere care a cauzat că codul său este suspendat până când întreruperea este servită. Când părăsiți manipulatorul de întrerupere, revine la o adresă pe distanțe lungi salvată mai devreme (când sună o întrerupere) pe stivă la următoarele instrucțiuni după instrucțiunile de apel de întrerupere (int). Manipulatorul de întrerupere este un rezident (în mod constant în memorie) al codului. De regulă, acesta este un program mic. Deși, dacă vorbim despre kernelul Linux, atunci nu există întotdeauna un handler de întrerupere atât de mic. Handler de întrerupere este determinat de vector. Vectorul nu este altceva decât adresa (segment și offset) a codului de pornire, care ar trebui să proceseze întreruperea cu acest indice. Lucrul cu întreruperile este semnificativ diferit în modul real și în modul protejat (modul protejat) al procesorului (amintiți-vă că aici și apoi înțelegem procesoarele Intel și compatibil cu acestea). Într-un mod de procesor real (neprotejat), agenții de întrerupere sunt determinați de vectorii lor care sunt întotdeauna stocați la începutul memoriei. Selectarea adresei dorite din tabelul vectorilor are loc în index, care este și numărul de întrerupere. Suprascrierea unui vector cu un index definit poate fi atribuit pentru a întrerupe propriul său manipulare.

În modul protejat, stivuitorii de întrerupere (gateway-uri, porți sau supape) nu mai sunt determinate utilizând tabelul vectorilor. În loc de acest tabel, tabelul supapei este utilizat sau, mai corect, tabelul de întrerupere - IDT (tabel descriptori de întrerupere). Acest tabel este format de kernel, iar adresa sa este stocată în registrul procesorului IDTR. Acest registru nu este disponibil direct. Lucrul cu acesta este posibil numai prin utilizarea instrucțiunilor LIDT / SIDT. Primul dintre aceste (LIDT) încarcă valoarea IDTR specificată în operand și a fi adresa de bază Întrerupeți mesele de decriptare, secunde (SIDT), stochează adresa tabelului situat în IDTR la operandul specificat. La fel ca o selecție de informații despre segmentul din tabelul descriptorii descriptorilor, un segment al descriptorului segmentului apare, de asemenea, servind o întrerupere în modul protejat. Protecția memoriei este acceptată procesoare Intel. Începând cu CPU I80286 (nu este destul de sub forma în care este acum prezentată, dacă numai pentru că 286 a fost un procesor pe 16 biți - prin urmare, Linux nu poate funcționa la aceste procesoare) și I80386 și, prin urmare, procesorul produce în mod independent toate eșantioanele necesare și Prin urmare, a devenit puternic să se aprofundeze în toate subtilitățile modului protejat (și anume, Linux funcționează în modul protejat) Nu vom. Din păcate, nici timpul, nici capacitățile nu ne permit să ne oprim pentru o lungă perioadă de timp pe mecanismul de procesare a întreruperii într-un mod sigur. Da, acesta nu a fost scopul când scrieți acest articol. Toate informațiile menționate aici pe activitatea procesatorilor familiali H86 sunt destul de superficiale și sunt date doar pentru a ajuta un pic mai bine să înțeleagă mecanismul de funcționare a apelurilor sistemului de kernel. Ceva pe care îl puteți învăța direct din codul Coder, deși, pentru o înțelegere completă a ceea ce se întâmplă, este recomandabil să se familiarizeze chiar și cu principiile regimului protejat. Codul de cod care completează valorile inițiale (dar nu se instalează!) IDT, situat în ARCH / i386 / Kernel / Head.S: / * * setup_idt * * Setează un IDT cu 256 de intrări care indică * ignore_int, întrerupeți porțile. Nu se încarcă efectiv * IDT - care se poate face numai după ce paginarea a fost activată * și kernel-ul sa deplasat la pagina_offset. Întreruperi * sunt activate în altă parte, putem fi relativi * Sigur totul este OK. * * Avertisment:% ESI Este trăit peste această funcție. * / 1.Setup_idt: 2. Lea ignore_int,% EDX 3. Movl $ (__ kernel_cs<< 16),%eax 4. movw %dx,%ax /* selector = 0x0010 = cs */ 5. movw $0x8E00,%dx /* interrupt gate - dpl=0, present */ 6. lea idt_table,%edi 7. mov $256,%ecx 8.rp_sidt: 9. movl %eax,(%edi) 10. movl %edx,4(%edi) 11. addl $8,%edi 12. dec %ecx 13. jne rp_sidt 14..macro set_early_handler handler,trapno 15. lea \handler,%edx 16. movl $(__KERNEL_CS << 16),%eax 17. movw %dx,%ax 18. movw $0x8E00,%dx /* interrupt gate - dpl=0, present */ 19. lea idt_table,%edi 20. movl %eax,8*\trapno(%edi) 21. movl %edx,8*\trapno+4(%edi) 22..endm 23. set_early_handler handler=early_divide_err,trapno=0 24. set_early_handler handler=early_illegal_opcode,trapno=6 25. set_early_handler handler=early_protection_fault,trapno=13 26. set_early_handler handler=early_page_fault,trapno=14 28. ret Câteva comentarii privind codul: Codul dat este scris pe soiurile Assembler AT & T, astfel încât cunoștințele asamblorului dvs. în notația sa obișnuită de informații nu pot fi confuze. Cea mai importantă diferență în ordinea operanilor. Dacă este definită comanda pentru notația Intel - "Baterie"< "источник", то для ассемблера AT&T порядок прямой. Регистры процессора, как правило, должны иметь префикс "%", непосредственные значения (константы) префиксируются символом доллара "$". Синтаксис AT&T традиционно используется в Un*x-системах.

În exemplul dat în liniile 2-4, se stabilește adresa de gestionare a tuturor întreruperilor implicite. Manipulatorul implicit este funcția IGNORE_INT, care nu face nimic. Prezența unui astfel de ștecher este necesară pentru procesarea corectă a tuturor întreruperilor în această etapă, deoarece alții nu mai sunt încă (trad, capcane (capcane) sunt ușor mai mici în codul - despre capcane, consultați Referința manuală a arhitecturii Intel Sau ceva de genul asta, aici nu vom atinge capcanele). În linia 5, tipul supapei este setat. În linia 6, descoperim adresa tabelului nostru IDT în registrul indexului. Tabelul trebuie să conțină 255 de intrări, câte 8 octeți fiecare. În liniile 8-13, completăm întreaga masă ca aceleași valori setate de registrele EAX și EDX - adică, aceasta este o supapă de întrerupere care se referă la Handler Ignore_int. Mai jos, definim un macro pentru a instala capcane (capcane) - rânduri 14-22. În linia 23-26 utilizând macro-ul menționat mai sus. Am stabilit capcane pentru următoarele excepții: Divizia La Zero (0), Early_illegal_OPCODE - Instrucțiuni de procesoare necunoscute (6), Early_Protection_fault - Protecția Memorilor (13), Start_page_fault - Page difuzare eșec (14). În paranteze sunt date "întrerupe" numere generate de o situație de urgență adecvată. Înainte de a verifica tipul procesorului în ARCH / I386 / Kernel / Head.S, tabelul IDT este setat de apelul SETUP_IDT: / * * Start System 32-Bit Configurare. Trebuie să re-realizăm unele dintre lucrurile făcute * în modul pe 16 biți pentru operațiile "reale". * / 1. Call Setup_idt ... 2. Call Check_x87 3. LGDT Early_GDT_DESCR 4. LIDT IDT_DERSCRDupă ce a aflat tipul (CO) al procesorului și efectuarea tuturor acțiunilor pregătitoare din liniile 3 și 4, încărcăm mesele GDT și IDT care vor fi utilizate la primii pori ai kernelului.

Apeluri de sistem și int 0x80.

De la întreruperi se vor întoarce la provocările sistemului. Deci, ceea ce este necesar pentru a servi procesul care solicită un fel de serviciu? Pentru a începe, este necesar să se deplaseze de la inelul 3 (nivelul CPL \u003d 3) pe cel mai afectat nivel 0 (inelul 0, CPL \u003d 0), deoarece Codul Core este situat în segmentul cu cele mai înalte atracții. În plus, codul de funcționare este necesar ca procesul să servească. Este pentru aceasta, se utilizează gateway-ul 0x80. Deși apelurile sistemului sunt destul de multe, pentru tot ce utilizează un singur punct de intrare - int 0x80. Manipulatorul în sine este setat la apelul ARCH / I386 / Kernel / Traps.C :: Trap_init () Funcție: Void __init cap_init (vid) (... set_system_gate (syscall_vector, & sistem_call); ...)Suntem în Trap_init () mai interesați de această linie. În același fișier, puteți privi la codul funcției Set_System_Gate () de mai sus: Static vid __init set_system_gate (nesemnat int n, void * addr) (_set_gate (n, nastape_trap | destinape_dpl3, addr, __kernel_cs);)Aici puteți vedea că supapa pentru întreruperea 0x80 (și anume, această valoare este determinată de Syscall_vector Macro - puteți crede defecțiunea :)) este instalată ca o capcană (capcană) cu nivelul atributelor DPL \u003d 3 (inelul 3) , adică Această întrerupere va fi prinsă când sunați din spațiul utilizatorului. Problema cu tranziția de la inelul 3 în inelul 0 T.O. Rezolvat. Funcția _set_gate () este definită în fișierul antet include / asm-i386 / desc.h. Pentru mai multe curioase, codul este arătat, fără excelență, cu toate acestea: Static inline vid _set_gate (int poarta, int de tip nesemnat, void * addr, nesemnat scurt seg) (__u32 A, b; pachet_gate (& A & B, (nesemnat lung) addr, seg, tip, 0); write_idt_entry (Idt_table , Poarta, a, b);)Să revenim la funcția Trap_init (). Se numește din funcția Start_Kernel () în INI / Main.C. Dacă vă uitați la codul Trap_init (), este clar că această caracteristică corespunde unor valori ale manipulatoarelor actualizate de tabel IDT care au fost utilizate în stadiile incipiente ale inițializării kernelului (recepționate_page_fault, mai devreme_divide_opcode, mai devreme_protection_faulde) sunt înlocuit cu cele care vor fi utilizate deja în acest proces. Lucrările de kernel. Deci, practic am ajuns la esență și deja știm că toate apelurile de sistem sunt procesate uniform - prin intermediul gateway-ului INT 0x80. Ca un handler pentru int 0x80, ca din nou, este văzut din complotul de mai sus al codului ARCH / I386 / Kernel / Traps.C :: Trap_init (), stabilește funcția System_Call ().

sistem_call ().

Codul funcției System_Call () se află în fișierul arc / i386 / kernel / intrare.s și arată astfel: # Sistem de apel Handler Stub Intrare (System_Call) Ring0_int_frame # poate să se relaxeze în spațiul utilizatorului oricum Pushl% eAX # Save_ex cfi_adjust_cfa_offset 4 Save_all get_thread_info (% ebp) # Funcționarea apelului în funcțiune / emulare / * Notă, _TIF_SECCOMPS este un pic numărul 8 , deci are nevoie de testw și nu testb * / testw $ (_ tif_syscall_emu | _tif_sysccomp | _tif_sysccomp | _tif_syccomp | _TIF_SYCCOMP | _TIF_SYCCOMP | _TIF_SYCCOMP | _TIF_SYSCOMP | _TIF_SYSCOMP | _TIF_SYSCOMP | JNZ SYSCALL_TRACE_ENTRY CMPL $ (NR_SYSCALLS),% EAX JAE SYSCALL_BADSYS SYSCALL_CALL: apel * sys_call_table (,% EAX , 4) MOVL% EAX, PT_EAX (% ESP) # Depozitați valoarea de returnare ...Codul nu este afișat complet. După cum puteți vedea, primul sistem_call () configurează un stivă pentru a lucra în inelul 0, economisește valoarea transmisă prin EAX la stivă, salvează toate registrele la stivă, primește datele apelantului și verifică dacă valoarea transmisă a Apelul sistemului nu merge limitele tabelului de apel al sistemului și, în final, utilizând valoarea transmisă în EAX ca un argument, sistem_call () exerciții la un sistem real de ieșire a sistemului, pe baza căruia elementul tabelului se referă indexul la EAX. Acum amintiți-vă vechea masă bună a vectorilor de întrerupere din modul real. Nimic nu reamintește? În realitate, bineînțeles, totul este mai complicat. În particular, apelul de sistem trebuie să copieze rezultatele din stiva de kernel la stiva de utilizator, să treacă codul de returnare și mai multe lucruri. În cazul în care argumentul specificat în EAX nu se referă la un apel de sistem existent (valoarea este peste interval), mergeți la eticheta SYSCALL_BADSYS. Aici, în stiva de deplasare, care ar trebui să fie valoarea EAX, este introdusă valoarea -enosys - apelul sistemului nu este implementat. Această execuție sistem_call () este finalizată.

Tabelul de apel al sistemului este localizat în fișierul arc / i386 / kernel / syscall_table.s și are o vizualizare destul de simplă: Intrare (sys_call_table) .long sys_restsart_syscall / * 0 - Apel de sistem "Setup ()" vechi, utilizat pentru repornire * / .long sys_exit .long sys_fork .long sys_read .long sys_write .long sys_open / * 5 * / .long sys_close .long Sys_waitpid .long sys_creat ...Cu alte cuvinte, întreaga masă nu este altceva decât o serie de adrese de funcții situate în ordinea numărului de numere de apel de sistem pe care aceste funcții sunt servite. Tabelul este o gamă obișnuită a cuvintelor duble ale motorului (sau cuvinte pe 32 de biți - care le place mai mult). Codul de parte a apelurilor de servire a funcțiilor este localizat în partea dependentă de platformă - Arch / i386 / kernel / sys_i386.c și o parte care nu depinde de platforma din kernel / sys.c.

Acesta este cazul provocărilor sistemului și a supapei 0x80.

Noul mecanism de procesare a apelurilor de sistem în Linux. Sysenter / Sysexit.

După cum sa menționat destul de repede, sa dovedit că utilizarea unei metode tradiționale de procesare a apelurilor bazate pe GAITA 0x80 se împinge la pierderea performanței pe procesoarele Intel Pentium 4. Prin urmare, Linus Torvalds a implementat un nou mecanism în kernel, pe baza Instrucțiunile Sysenter / Sysexit și concepute pentru a crește productivitatea kernelului pe mașinile echipate cu procesorul Pentium II și mai mare (este de la procesoarele Intel Pentium II + care sunt susținute de instrucțiunile Sysenter / Sysexit). Care este esența unui nou mecanism? Destul de ciudat, dar esența rămâne aceeași. Execuția sa schimbat. Conform documentației Intel, instrucțiunea Sysenter face parte din mecanismul "apelurilor rapide ale sistemului". În special, această instrucțiune este optimizată pentru o tranziție rapidă de la un nivel de atracții la altul. Dacă este mai precis, accelerează tranziția la inelul 0 (inelul 0, CPL \u003d 0). În același timp, sistemul de operare trebuie să pregătească procesorul să utilizeze instrucțiunea Sysenter. Această setare se efectuează o dată la încărcarea și inițializarea kernel-ului OS. Când sunați Sysenter stabilește registrele procesorului în conformitate cu registrele dependente de mașini instalate anterior. În particular, se stabilesc registrul de segment și registrul indicatorului de instrucțiuni - CS: EIP, precum și segmentul stivei și indicatorul vârfului stivei - SS, ESP. Tranziția la noul segment al codului și offset este realizat de la inelul 3 la 0.

Instrucțiunea Sysexit efectuează acțiuni inverse. Ea produce o tranziție rapidă de la nivelul atracțiilor 0 pe al 3-lea (CPL \u003d 3). În acest caz, registrul segmentului de cod este setat la valoarea segmentului 16+ CS stocată în registrul dependent de mașină al procesorului. Registrul EIP este introdus în conținutul registrului EDX. SS este introdusă în SS 24 și valorile CS înregistrate mai devreme în registrul procesorului dependent de mașină în timpul pregătirii contextului pentru funcționarea instrucțiunii Sysenter. ESP a intrat în conținutul registrului ECX. Valorile necesare pentru funcționarea instrucțiunilor Sysenter / Sysexit sunt stocate la următoarele adrese:

1. SYSENTER_CS_MSR 0x174 este un segment de cod în care este introdus valoarea segmentului în care este introdus codul de selectare a apelului sistemului.
2. SYSENTER_ESP_MSR 0x175 este un pointer în partea de sus a stivei pentru un handler de apeluri de sistem.
3. SYSENTER_EIP_MSR 0x176 - Pointer la offset în interiorul segmentului de cod. Specifică codul de pornire al manipulatorului apelului sistemului.

În ciuda faptului că Linux nu utilizează comutarea hardware a contextelor sarcinilor, kernelul este forțat să seteze înregistrarea TSS pentru fiecare procesor instalat în sistem. Acest lucru se datorează faptului că atunci când procesorul trece de la modul de utilizator în modul kernel, acesta preia adresa stivei de kernel de la TSS. În plus, TSS este necesar pentru a controla accesul la porturile I / O. TSS conține o hartă a drepturilor de acces la porturi. Pe baza acestei cărți, devine posibilă controlul accesului la porturi pentru fiecare proces care utilizează instrucțiuni in / out. Aici TSS-\u003e X86_TSS.ESP1 indică stiva de kernel. __Kernel_cs indică în mod natural segmentul codului de coder. Deplasarea EIP indică adresa funcției Sysenter_entry ().

Funcția Sysenter_entry () este definită în fișierul ARCH / i386 / kernel / intrare și are acest tip: / * Sysenter_return indică după instrucțiunea "Sysenter" din pagina VSYSCALL. Vedeți VSYSCALL-SYSTENTY.S, care definește simbolul. * / # SYSENTER SALVER Handler intrări (Sysenter_entry) CFI_STARTPROC SIMPLE CFI_SIGNAL_FRAME CFI_DEF_CFA ESP, 0 CFI_Register ESP, EBP MOVL TSS_SYSENTER_ESP0 (% ESP),% ESP SYSENTER_PAST_ESP: / * * Nu este nevoie să urmați această secțiune IRQ-uri On / Off: Sistemul SysCall * Dezactivat IRQ-uri și aici îl activăm imediat după intrarea: * / Enable_Interrupts (CLBR_NONE) CFI_ADJUST_DS) CFI_ADJUST_DS) CFI_ADJUST_DS_OFFset SS, 0 * / Pushl% EBP CFI_ADJUST_CFA_Offset 4 CFI_rel_Offset ESP, 0 PUTHFL CFI_ADJUST_CFA_Offset 4 Pushl $ (__ user_Cs ) Cfi_adjust_cfa_offset 4 / * cfi_rel_offset cs, 0 * / / * * împingere curent_thread_info () -\u003e sysenter_return la stiva. * Este necesar un mic pic de fixup offset - 4 * 4 înseamnă cele 4 cuvinte * împinse mai sus; +8 corespunde setării esp0 copy_thread "* / pushl (ti_sysenter_return-thread_size + 8 + 4 * 4) (% esp) cfi_adjust_cfa_offset 4 cfi_rel_offset EIP, 0 / * * Încărcați potențialul al șaselea argument de la stiva de utilizator. * Atent la securitate . * / CMPL $ __ Page_Offset-3,% EBP Jae Syscall_fault 1: MOVL (% EBP),% EBP .Section __ex_table, "A" .Align 4 .long 1b, syscall_fault .Predict Push% EAX CFI_ADJUST_CFA_Offset 4 Save_all Get_Thread_Info (% EBP) / * Notă, _TIF_SECCOMPP este biți numărul 8, deci are nevoie de testw și nu testb * / testw $ (_ tif_syscall_emu | _TIF_SYCCOMP | _TIF_SCCOMP | _TIF_SYCCOMP | _TIF_SYCLAL_AUDIT), TI_FLAGS (% EBP) JNZ SYSCALL_TRACE_ENTRY CMPL $ (NR_SYSCALLS),% EAX jae syscall_badsy sunat * sys_call_table (,% eAX, 4) Movl% EAX, PT_eAx (% esp) Disable_interrupts (CLBR_ANY) TRACE_IRRUPS_OFF MOVL TI_FLAGS (% EBP),% ECX TestW $ _TIF_ALLWORK_MASK,% CX JNE SYSCALL_EXIT_WORK / * Dacă se modifică ceva trebuie să dezactiveze, de asemenea, sysexit * / movl pt_eip (% esp),% EDX MOVL PT_OLDESP (% ESP),% ECX XORL% EBP,% EBP trace_irqs_on 1: MOV PT_FS (% ESP),% FS \u200b\u200bEnable_Interrupts_Sysexit cfi_endproc .pusection .Fixup, "Ax" 2: Movl $ 0, PT_FS (% ESP) JMP 1b .section __ex_table, "a" .align 4 .LONG 1B, 2B Endprocection Endproc (Sysenter_entry)Ca și în cazul sistemului_call (), lucrarea principală este efectuată în șirul apelului * sys_call_table (,% eAX, 4). Un handler de apel specific al sistemului este numit aici. Deci, se poate vedea că un pic sa schimbat. Faptul că vectorul de întrerupere este acum înfundat în fier și procesorul ne ajută mai repede de la un nivel al atracțiilor la alta modificări doar câteva detalii ale executării cu același conținut. Adevărat, aceste schimbări nu se termină. Amintiți-vă de ce a început narațiunea. La început, am menționat despre obiectele comune virtuale. Deci, dacă mai devreme punerea în aplicare a sistemului de apel, să spunem, din biblioteca libc a arătat ca un apel de întrerupere (în ciuda faptului că biblioteca a luat unele funcții pentru a reduce numărul de întrerupătoare de context), acum datorită apelului de sistem VDSO să fie făcute aproape direct, fără participarea libcului. De asemenea, el ar putea fi efectuat direct, din nou, ca o întrerupere. Dar acum apelul poate fi solicitat ca funcție obișnuită exportată dintr-o bibliotecă dinamic (DSO). La încărcarea kernelului determină ce mecanism ar trebui și poate fi utilizat pentru această platformă. În funcție de circumstanțe, kernelul stabilește punctul de intrare la o funcție care efectuează apelul sistemului. Mai mult, funcția este exportată în spațiul utilizatorului Linux-Gate.So.1 Bibliotecă. Linux-gate.so.1 Biblioteca fizică nu există pe disc. Ea, dacă o puteți pune, este emulată de miez și există exact cât funcționează sistemul. Dacă opriți sistemul, subminează rădăcina FS dintr-un alt sistem, atunci nu veți găsi acest fișier pe rădăcina FS. De fapt, nu veți putea să o găsiți nici măcar pe un sistem de lucru. Din punct de vedere fizic, pur și simplu nu este. Acesta este motivul pentru care Linux-Gate.So.1 este altceva ca VDSO - I.E. Obiect partajat dinamic virtual. Kernel-ul afișează biblioteca dinamică în acest mod în spațiul de adrese al fiecărui proces. Asigurați-vă că acest lucru este ușor dacă executați următoarea comandă: [E-mail protejat]: ~ $ Cat / proc / auto / hărți 08048000-0804C000 R-XP 00000000 08:01 46 / CAT 0804C000-0804D000 RW-P 00003000 08:01 46 / BIN / CAT 0804D000-0806E000 RW-P 0804D000 00:00 0 ... B7FDF000-B7FE1000 RW-P 00019000 08:01 2066 /lib/ld-2.5.so BFFD2000-BFFE8000 RW-P BFFD2000 00:00 0 FFFFE000-FFFFF000 R-XP 00000000 00:00 0Aici, cea mai recentă linie este obiectul interesului: FFFFFE000-FFFFFF000 R-XP 00000000 00:00 0Din exemplul de mai sus, se poate observa că obiectul ia în memorie exact o pagină - 4096 octeți, aproape pe curțile din spate a spațiului de adrese. Să tragem un alt experiment: [E-mail protejat]: ~ $ Ldd `care pisica linux-gate.so.1 \u003d\u003e (0xfffe000) libc.so.6 \u003d\u003e /lib/tls/i686/cmov/libc.so.6 (0xb7e87000) / lib / ld-linux .So.2 (0xb7fdf000) [E-mail protejat]: ~ $ Ldd `la care gcc` linux-gate.so.1 \u003d\u003e (0xfffe000) libc.so.6 \u003d\u003e / /lib/tls/i686/cmov/libc.so.6 (0xb7e3c000) / lib / ld-linux .So.2 (0xb7f94000) [E-mail protejat]:~$ Aici tocmai am luat două aplicații. Se poate observa că biblioteca este afișată în spațiul de adresă al procesului unul cu aceeași adresă permanentă - 0xFFFFE000. Acum, să încercăm să vedem ce este stocat pe această pagină de memorie este de fapt ...

Efectuați o deplasare a paginii de memorie în cazul în care codul VDSO partajat este stocat utilizând următorul program: #include #include #include int principal (char * vdso \u003d 0xffffe000; char * tampon; fișier * f; tampon \u003d malloc (4096); dacă (! tampon) ieșire (1); memcy (tampon, VDSO, 4096) ; dacă (f \u003d fopen ("test.dump", "w + b"))) (fără tampon); ieșire (1);) FWRITE (tampon, 4096, 1, F); FCLOSE (F ); Liber (tampon); retur 0;)Strict vorbind, înainte de a putea fi făcut mai ușor, folosind echipa dd dacă \u003d / proc / sine / mem de \u003d test.dump bs \u003d 4096 Skip \u003d 1048574 Count \u003d 1Dar miezurile începând cu versiunea 2.6.22 sau poate chiar mai devreme, nu mai afișează memoria de proces pentru a fi fișier / proc / `Pid` / Mem. Acest fișier este salvat, evident, pentru compatibilitate, dar nu conține mai multe informații.

Comiteți și executați programul dat. Să încercăm să dezasamblați codul rezultat: [E-mail protejat]: ~ / Tmp $ objdump --disassemble ./test.dump ./test.dump: Format fișier fișier Elf32-i386 Dezasamblu de secțiune .Text: FFFFE400<__kernel_vsyscall>: FFFFE400: 51 Push% ECX FFFFE401: 52 Push% EDX FFFFE402: 55 Push% EBP FFFFE403: 89 E5 MOV% ESP,% EBP FFFFE405: 0F 34 Sysenter ... FFFFFFE40E: EB F3 JMP FFFFE403<__kernel_vsyscall+0x3> FFFFE410: 5D POP% EBP FFFFE411: 5A POP% EDX FFFFE412: 59 POP% ECX FFFFE413: C3 RET ... [E-mail protejat]: ~ / Tmp $Aici este poarta noastră de acces pentru apelurile de sistem, toate pe palmă. Procesul (sau, Biblioteca de sistem Libc), care numind funcția __kernel_vsysCall cade pe adresa 0xFFFFFE400 (în cazul nostru). Apoi, __kernel_vsyscall salvează conținutul registrelor ECX, EDX, EDX în stiva de procesare a ECX, EDX, am vorbit deja despre registrele de înregistrare ECX și EDX mai devreme, se utilizează mai târziu pentru a restabili stiva utilizatorului. Instrucțiunea Sysenter este executată, "Interceptarea întreruperii" și, ca rezultat, următoarea tranziție către Sysenter_entry (vezi mai sus). Instrucțiunea JMP la 0xFFFFE40E este introdusă pentru a reporni provocarea sistemului cu un număr de 6 argumente (vezi http://lkml.org/lkml/2002/12/18/). Codul postat pe pagină este în Arc / i386 / kernel / vsyscall-enter.s (sau arc / i386 / kernel / vsyscall-int80.s) pentru capcana 0x80). Deși am constatat că adresa funcției __kernel_vsyscall este permanentă, dar există o opinie că nu este. De obicei, poziția punctului de intrare în __kernel_vsysCall () poate fi găsită de vectorul Elf-AUXV folosind parametrul at_sysinfo. Vectorul Elf-AUXV conține informații transmise procesului prin stivă la pornire și conține diverse informații necesare în timpul programului. Acest vector, în special, conține variabile ale mediului înconjurător, argumente și așa mai departe ..

Iată un mic exemplu despre cum să se refere direct la funcția __kernel_vsysCall direct: #Include. int pid; Int Main () (__asm \u200b\u200b("MOVL $ 20,% EAX \\ n" "Apel *% GS: 0x10 \\ n" "MOVL% EAX, PID \\ N"); Printf ("PID:% d \\ n" , Pid); retur 0;)Acest exemplu este luat de pe pagina Manu Garg, http://www.manugarg.com. Deci, în exemplul dat, facem apelul GetPid () () (numărul 20 sau altfel __nr_getpid). Pentru a nu urca din stiva de proces în căutarea variabilei AT_SYSIINFO, folosim faptul că biblioteca de sistem libc.SO este copiată de valoarea variabilei AT_SYSInfo la unitatea de comandă a fluxului (blocul de control al firului TCB). Acest bloc de informații, de regulă, se referă la selector în GS. Presupunem că pe offset 0x10 există un parametru dorit și efectuați un apel la adresa stocată în% GS: $ 0x10.

Rezultate.

De fapt, practic, o creștere specială a performanței, chiar și cu sprijinul acestui FSCF (Fast System Call Facility), nu este întotdeauna posibil să se realizeze. Problema este că, oricum, procesul rar se referă direct la kernel. Și pentru aceasta există motive bune. Utilizarea bibliotecii libc vă permite să garantați portabilitatea programului, indiferent de versiunea kernel-ului. Și este prin biblioteca standard de sistem pe care majoritatea apelurilor de sistem merge. Chiar dacă colectați și instalați cel mai recent kernel asamblat pentru o platformă care acceptă FSCF, aceasta nu este o garanție a creșterii productivității. Faptul este că biblioteca dvs. de sistem libc.SO va fi îndreptată pentru a utiliza int 0x80 și poate face față doar tranziției lui Glibc. Interfața VDSO și __kernel_vsyscall și __kernel_vsysCall sunt acceptate în Glibc, consider că este greu să răspund.

Link-uri.

Manu Garg Page, http://www.manugarg.com
Scatter / Adunați ThouGhts de Johan Petersson, http://www.trilihium.com/johan/2005/08/linux-gate/
Vechiul înțelegere a kernelului Linux unde fără el :)
Și, desigur, codurile sursă Linux (2.6.22)