Abstrakt. Denna handledning handlar om runtime efterlevnad och förespråkar dess användning som en förlängning av runtime verifiering. Medan forskningsinsatser i körtid verifiering har främst handlat om upptäckt av missuppfostran och erkännande av önskade beteenden, runtime efterlevnad syftar främst till att kringgå missuppfostran av system och att garantera önskade beteenden. För det första föreslår vi en jämförelse mellan kontroll av körtid och verkställighet av körtid. Vi presenterar sedan tidigare teoretiska modeller för genomförandemekanismer och deras uttryckskraft när det gäller verkställighet. Sedan ser vi över det befintliga arbetet med runtime surveillance monitor syntes. Slutligen föreslår vi några framtida utmaningar när det gäller tekniken för att kontrollera efterlevnaden av reglerna. Kontroll av drifttid [1, 2] är en väletablerad teknik som består i att använda en monitor för att vid drifttid övervaka genomförandet av ett underliggande program mot en uppsättning förväntade egenskaper. En monitor är ett beslutsförfarande med en utdatafunktion (t.ex. en statsmaskin vid hantering av regelbundna egenskaper) bearbetning (steg för steg) en utförandesekvens av det övervakade programmet, och producerar en sekvens av domar (sanning värden av en sanning-domän) som indikerar uppfyllelse eller brott mot en egendom. Även om upptäckten ibland kan vara en tillräcklig säkerhet för vissa system, förekomsten (resp. Icke-förekomst) av egendomsöverträdelser (s.k. Valideringar) kan vara oacceptabla för andra. Verkställighet av körtid [3] [4] [5] [6] av den önskade egendomen är en möjlig lösning för att säkerställa förväntade beteenden och undvika missuppfostran. Inom denna teknik övervakaren inte bara observerar det aktuella programmet exekvering, men också ändrar det. Den använder en intern memoreringsmekanism för att säkerställa att den förväntade egenskapen uppfylls: den läser fortfarande en inmatningssekvens men producerar nu en ny händelsesekvens på ett sådant sätt att egendomen upprätthålls. Det exakta och formella förhållandet mellan inmatnings- och utmatningssekvenser styrs vanligen av två begränsningar: sundhet och transparens. Ur en abstrakt synvinkel innebär dessa begränsningar monitorn att minimalt ändra inmatningssekvensen för att säkerställa den önskade egenskapen. När programmet beter sig väl, kan exekutionsövervakaren låta programmet köra med minst inflytande. Om programmet beteende är på väg att uppvisa en avvikelse w.r.t. den förväntade egenskapen använder monitorn sin interna memoreringsmekanism för att förhindra missuppfostran. Praktiska tillämpningar av regelefterlevnad. Det har förekommit många praktiska tillämpningar av teorin om driftstöd (t.ex. [7] [8] [9] för programsäkerhet, eller i [10–11] för tillträdesregler). De flesta av dem är uppbyggda på en längre version med fler resultat och exempel finns på författarens webbsida. Schneiders modell av säkerhetsautomat. Även om vi i denna handledning kommer att se en idémässig skillnad mellan verkställighet och verifiering, finns det i praktiken inte alltid någon tydlig åtskillnad mellan dessa discipliner. Som så, även tidigt runtime verifiering ramar var ofta utformade för att, säg, "utöva någon kod" när en egendom kränks, vilket ändrar den ursprungliga program exekvering. Till exempel, när en fastighet blir kränkt: -JPAX [12], RMOR [13] tillåter att ange call-back-funktioner som får kallas; -Temporal Rover [14] gör det möjligt att ange en massa kod som ska köras; -MOP [15] utökar monitorer med undantag hanterare. Reaktioner på fel används dock sällan eller saknar åtminstone en systematisk och formell studie. Dessutom är det tydligt att förebyggande av dåliga beteenden skulle vara mer önskvärt än att ge reaktioner till dem ("bättre säker än ledsen"). Handledning. Denna handledning fokuserar på arbetet med att bygga en teori om runtime efterlevnad som, som vi tror, växer fram som en ny verksamhet. Vi förespråkar att det används som en viktig kompletterande verksamhet för kontroll av körtiden. Eftersom ett alfabet E, en sekvens σ på E är en total funktion σ : I → E där jag är antingen intervallet [0, n] för vissa n  på N, eller själva N. Den tomma sekvensen betecknas med. Vi betecknar med E * uppsättningen av finita sekvenser över E och av E  på uppsättningen av oändliga sekvenser över E. E *  på E är noterad E ∞. Vi kommer att anta viss förtrogenhet med begreppen sekvens, prefix och fortsättning. Vi kommer att använda σ ··n, för n  på N \ {0}, för att beteckna prefixet av σ längd n. Avrättning sekvenser. I körtid verifiering och genomförande tekniker, som vi inte är medvetna om programspecifikationen, är det övervakade programmet ofta betraktas som en generator av sekvenser. Således, körtiden aktivitet fokuserar på en begränsad alfabetet  på c av konkreta händelser eller operationer som programmet kan utföra. Sådana sekvenser kan göras av t.ex. resursåtkomsthändelser på ett säkert system eller kärnoperationer på ett operativsystem. I ett programvarusammanhang kan dessa händelser utgöra en relevant undergrupp av instruktioner (t.ex. variabla ändringar eller proceduranrop). Dessa operationer bestämmer sanningen värdet av egenskaper. Således, för att jämföra programmets avrättningar med egendomen, dessa konkreta händelser bör abstrakteras i en ändlig uppsättning abstrakta händelser, en. Denna abstraction är en underliggande korrespondens  och en kartläggning av varje händelse av en konkret händelse till förekomsten av en abstrakt händelse 1. För att förenkla notationer, i denna handledning kommer vi att tala enhetligt om utförande sekvenser, och använda en enhetlig alfabetet  på. Utförandesekvenser, d.v.s. eventuellt icke-avslutande körningar, spänner över. Policyer mot egenskaper. Som ofta nämns i verifieringslitteraturen är en egenskap en uppsättning enskilda utförandesekvenser, d.v.s. en egenskap partitionerar uppsättningen möjliga utförandesekvenser. Schneider [3] skiljer egenskaper från policy. En policy definieras över uppsättningar av utförandesekvenser, d.v.s. en policypartitioner 1 Detta är exakt syftet med programinstrumentering (jfr. Avsnitt 2.1. Observera också att problemet kan vara något mer komplicerat när man hanterar parametriska händelser, händelser som också beror på konkreta verkställande värden (se. [16] till exempel). 2 uppsättningen uppsättningar av utförande sekvenser. Egenskaper representerar således en undergrupp av policyer. Endast egenskaper är lämpliga för en övervakningsmetod eftersom de kan beslutas om enstaka utföranden; genom en predikat tillämpas på utförande sekvenser i isolering. Tvärtom kan policyer som inte är egenskaper inte övervakas eftersom de skulle kräva information från andra avrättningar. Till exempel [3], förbjuda informationsflöde från två variabler i ett program är en policy och inte en egenskap eftersom kontroll det skulle kräva många utföranden för att avgöra om värden korreleras. Dessutom, i denna handledning, eftersom vi har att göra med runtime tekniker, kommer vi endast att överväga egenskaper definierade på linjära utföranden, exklusive specifika egenskaper definierade på grenning utförande sekvenser [17]. Runtime ramar har övervägt egenskaper på ändliga, infinita, eller både finita och infinita sekvenser. Vi kommer att notera Π den egendom som granskas och Π (σ) när sekvensen σ tillhör Π.
Merparten av arbetet med detta ämne ägnades åt efterlevnad av otidsenliga egenskaper (se REF för en kort översikt).
You should Better Enforce than Verify ⋆
{'venue': 'RV', 'journal': None, 'mag_field_of_study': ['Computer Science']}