Oppgavetilstand - Task state segment

Den oppgave tilstand segment ( TSS ) er en struktur på x86 -baserte datamaskiner som inneholder informasjon om en oppgave . Den brukes av operativsystemet kjernen for oppgavebehandling. Spesielt lagres følgende informasjon i TSS:

  • Prosessorregister tilstand
  • I / O-porttillatelser
  • Pekepinner på indre nivå
  • Forrige TSS-lenke

All denne informasjonen skal lagres på bestemte steder i TSS som spesifisert i IA-32 manualene.

Plassering av TSS

TSS kan ligge hvor som helst i minnet . Et segmentregister kalt task register (TR) har en segmentvelger som peker på en gyldig TSS-segmentbeskrivelse som er bosatt i GDT (en TSS-deskriptor kan ikke være bosatt i LDT ). Derfor, for å bruke en TSS, må følgende gjøres av operativsystemkjernen:

  1. Opprett en TSS-deskriptoroppføring i GDT
  2. Last inn TR med segmentvelgeren for det segmentet
  3. Legg til informasjon i TSS i minnet etter behov

Av sikkerhetshensyn bør TSS plasseres i minne som bare er tilgjengelig for kjernen .

Oppgaveregister

TR-registeret er et 16-biters register som har en segmentvelger for TSS. Det kan lastes gjennom LTR- instruksjonen. LTR er en privilegert instruksjon og fungerer på en måte som ligner på andre segmentregistreringsbelastninger. Oppgaveregisteret har to deler: en del som er synlig og tilgjengelig for programmereren, og en usynlig som automatisk lastes fra TSS-deskriptoren.

Registrer stater

TSS kan inneholde lagrede verdier for alle x86- registrene. Dette brukes til oppgavebytte . Det operativsystem kan laste TSS med verdiene til de registre som de nye oppgave behov og etter å utføre en maskinvare oppgave bryter (for eksempel med en IRET instruksjonen) x86 CPU laster de lagrede verdier fra TSS i de riktige registre. Vær oppmerksom på at noen moderne operativsystemer som Windows og Linux ikke bruker disse feltene i TSS da de implementerer programvareoppgavebytte.

Merk at i løpet av en maskinvareoppgavebryter blir visse felt i den gamle TSS oppdatert med CPUens nåværende registerinnhold før verdiene fra den nye TSS leses. Dermed leses / skrives noen TSS-felt, mens andre er skrivebeskyttet:

  • Lese / skrive felt : leses og skrives under en bryter for maskinvareoppgave.
    • Alle generelle registre ( EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP);
    • Alle segment registre ( CS, DS, ES, FS, GS, SS);
    • Gjeldende kjøringstilstand ( EIP, EFlags);
    • Den Linkfeltet i nye TSS, hvis oppgave bryteren var på grunn av en CALLeller INTi stedet for en JMP.
  • Skrivebeskyttede felt : les bare når det er nødvendig, som angitt.
    • Kontrollregister 3 ( CR3), også kjent som Page Directory Base Register ( PDBR).
      Les under en maskinvareoppgavebryter.
    • The Local Descriptor Table register ( LDTR);
      Les under en maskinvareoppgavebryter.
    • De tre privilegium-nivå stack-par ( SS0:ESP0, SS1:ESP1, SS2:ESP2);
      Les under et mellomnivå CALLeller for INTå etablere en ny stabel.
    • IO Port Bitmap-pekeren ( IOPB) og selve I / O Port Bitmap;
      Les under en IN, OUT, INSeller OUTSinstruksjon om CPL > IOPLå bekrefte undervisningen er lovlig (se I / O-port tillatelser under).

Den PDBRfeltet er faktisk den aller første man lese ut av den nye TSS: siden en maskinvare oppgave bryter kan også bytte til en helt annen side tabellen kartlegging, alle andre felt (spesielt LDTR) står i forhold til den nye kartleggingen.

I / O-porttillatelser

TSS inneholder en 16-biters peker til I / O-port tillatelseskart for den aktuelle oppgaven . Denne bitmappen, vanligvis satt opp av operativsystemet når en oppgave startes, spesifiserer individuelle porter som programmet skal ha tilgang til. I / O-bitmappen er et lite utvalg av porttilgangstillatelser; hvis programmet har tillatelse til å få tilgang til en port, lagres et "0" ved den tilsvarende bitindeksen, og hvis programmet ikke har tillatelse, lagres et "1" der. Hvis TSS 'segmentgrense er mindre enn full bitmap, antas alle manglende bits å være "1".

Funksjonen fungerer som følger: når et program utsteder en x86 I / O- portinstruksjon som IN eller OUT (se x86 instruksjonsoppføringer - og merk at det er versjoner av byte-, ord- og dword-lengde), vil maskinvaren gjøre en I / O-privilegienivå (IOPL) sjekker om programmet har tilgang til alle I / O-porter. Hvis det nåværende privilegienivået (CPL) i programmet er numerisk større enn I / O-privilegienivået (IOPL) (programmet er mindre privilegert enn det IOPL spesifiserer), har ikke programmet I / O-port tilgang til alle porter. Maskinvaren vil da sjekke I / O-tillatelsesbitmappen i TSS for å se om det programmet har tilgang til den eller de spesifikke portene i IN- eller OUT-instruksjonen. Hvis (alle) relevante bit (er) i I / O-portens tillatelsesbitmap er / er klare, får programmet tilgang til porten / portene, og instruksjonene får lov til å utføre. Hvis (noen av) de aktuelle bitene er innstilt - eller hvis (noen av) bitene er over TSS 'segmentgrense - har ikke programmet tilgang og prosessoren genererer en generell beskyttelse feil . Denne funksjonen tillater operativsystemer å gi selektiv porttilgang til brukerprogrammer.

Pekepinner på indre nivå

TSS inneholder 6 felt for å spesifisere den nye stakkpekeren når en privilegienivåendring skjer. Feltet SS0 inneholder staksegmentvelgeren for CPL = 0, og feltet ESP0 / RSP0 inneholder den nye ESP / RSP-verdien for CPL = 0. Når et avbrudd skjer i beskyttet (32-biters) modus, vil x86- CPU-en se i TSS etter SS0 og ESP0 og laste inn verdiene i henholdsvis SS og ESP. Dette gjør at kjernen kan bruke en annen bunke enn brukerprogrammet, og også ha denne stakken unik for hvert brukerprogram.

En ny funksjon introdusert i AMD64- utvidelsene kalles Interrupt Stack Table (IST), som også ligger i TSS og inneholder logiske (segment + offset) stack-pekere. Hvis en avbruddsbeskrivelsestabell angir en IST-oppføring som skal brukes (det er 8), vil prosessoren laste den nye stakken fra IST i stedet. Dette gjør at velkjente stabler kan brukes i tilfelle alvorlige feil ( NMI eller dobbel feil, for eksempel). Tidligere pekte oppføringen for unntak eller avbrudd i IDT på en oppgaveport, noe som fikk prosessoren til å bytte til oppgaven som pekes av oppgaveporten. De opprinnelige registerverdiene ble lagret i TSS-strømmen da avbruddet eller unntaket skjedde. Prosessoren satte deretter registrene, inkludert SS: ESP, til en kjent verdi spesifisert i TSS og lagret velgeren til forrige TSS. Problemet her er at bytte av maskinvareoppgaver ikke støttes på AMD64.

Forrige TSS-lenke

Dette er en 16-bits velger som gjør det mulig å koble denne TSS til den forrige. Dette brukes bare til bytte av maskinvareoppgaver. Se IA-32 manualene for detaljer.

Bruk av TSS i Linux

Selv om det kan opprettes en TSS for hver oppgave som kjører på datamaskinen, oppretter Linux-kjernen bare en TSS for hver CPU og bruker dem til alle oppgaver. Denne tilnærmingen ble valgt ettersom den gir enklere bærbarhet til andre arkitekturer (for eksempel støtter AMD64- arkitekturen ikke maskinvareoppgavebrytere), og forbedret ytelse og fleksibilitet. Linux bruker bare bitmap for I / O-porttillatelse og indre stabelfunksjoner i TSS; de andre funksjonene er bare nødvendig for maskinvareoppgavebrytere, som Linux-kjernen ikke bruker.

Unntak knyttet til TSS

X86- unntaksvektoren 10 kalles ugyldig TSS-unntak (#TS). Den utstedes av prosessoren når noe går galt med TSS-tilgangen. For eksempel, hvis et avbrudd skjer i CPL = 3 og overfører kontroll til CPL = 0, blir TSS brukt til å trekke ut SS0 og ESP0 / RSP0 for stakkbryteren. Hvis oppgaveregisteret inneholder en dårlig TSS-velger, vil en #TS-feil bli generert. Det ugyldige unntaket fra TSS skal aldri skje under normal operativsystemoperasjon, og er alltid relatert til kjernefeil eller maskinvarefeil.

For mer informasjon om unntak fra TSS, se Volum 3a, kapittel 6 i IA-32 manualen.

TSS i x86-64-modus

Den x86-64 Arkitekturen tillater ikke maskinvare oppgave brytere. Imidlertid kan TSS fortsatt brukes i en maskin som kjører i 64 bit utvidede moduser. I disse modusene er TSS fortsatt nyttig når den lagrer:

  1. Stakepekeren adresserer for hvert privilegienivå.
  2. Pekeradresser for Interrupt Stack Table (delen av pekepinnene på det indre nivået ovenfor, diskuterer behovet for dette).
  3. Offset-adresse for bitmap for IO-tillatelse.

Oppgaveregisteret utvides også i disse modusene for å kunne holde en 64-biters base-adresse.

Referanser

Eksterne linker