SMAP
Kallas även OS Guard (SMAP)
SMAP, Supervisor-Mode Access Prevention, begränsar dataåtkomst i supervisormiljö till sidor tillgängliga för användare såvida inte arkitekturens åsidosättningsvillkor gäller. Den skiljer sig från SMEP, vanligen marknadsförd som Intel OS Guard.
Vad du behöver veta
SMAP, Supervisor-Mode Access Prevention, begränsar dataåtkomst i supervisormiljö till sidor tillgängliga för användare såvida inte arkitekturens åsidosättningsvillkor gäller. Den skiljer sig från SMEP, vanligen marknadsförd som Intel OS Guard.
Hur det fungerar
Operativsystemet kan aktivera SMAP så att oavsiktliga privilegierade dataåtkomster till användarmappningar genererar fel. Kärnrutiner som avsiktligt kopierar användardata använder noggrant kontrollerade åtkomstfönster under arkitekturens regler. Exekveringsbehörighet är en separat fråga som hanteras av mekanismer såsom SMEP och NX.
Där den är användbar
En kärnrutin som tar emot en användarpekare måste validera och komma åt den med hjälp av operativsystemets etablerade funktioner för användarkopiering. SMAP är en försvarsgräns kring sådana åtkomster, inte en ersättning för längdkontroller, livstids hantering eller korrekta privilegiebeslut.
Hur man kontrollerar stöd och aktivering
CPUID.07H.00H:EBX bit 20 enumererar SMAP, medan CR4.SMAP styr aktiveringen. SMEP använder en annan bit. Kontrollera OS-dokumentation och statusgränssnitt; inaktivera inte skyddet som ett generiskt felsökningssteg för applikationer.
Kapacitet, aktivering och tillämpning måste kontrolleras separat. En processor kan stödja ett skydd medan operativsystemet, applikationen eller policyn för virtuella maskiner inte aktiverar det. Ett stödfält i en databas är inte en attestering av ett körande system.
Vad funktionen inte fastställer
Den importerade etiketten OS Guard (SMAP) bör inte läsas som bevis för att SMEP och SMAP är identiska eller att båda är aktiverade. En processorkapacitet fastställer inte skyddsstatusen för en viss kärna, gäst eller drivrutin.
Kompatibilitet och prestanda i praktiken
Håll operativsystem, firmware och berörd runtime uppdaterade. Om ett skydd blottar ett kompatibilitetsproblem, använd tillverkarens diagnostik och uppdateringar som stöds först. En övergripande aktivering av skydd kan påverka orelaterade applikationer och bör följa en uttrycklig distributions- och återställningspolicy.
En praktisk checklista för verifiering
- Registrera den exakta processor- eller plattformsmodellen samt de applikations-, OS- och runtime-versioner som berörs. Behåll formuleringen av det faktiska felet eller kravet.
- Kontrollera tillverkarens referens för den exakta modellen och granska sedan den faktiska kapaciteten och det aktiverade tillståndet i miljön där programmet körs.
- Jämför varje krav för den valda binären eller renderingsmotorn. En snarlikt namngiven funktion, ett alias eller en bred teknikbeteckning räcker inte.
- Bekräfta att applikationen har valt den avsedda implementeringen. Använd dess dokumenterade diagnostik och en reservlösning som stöds när kraven inte uppfylls.
- Gör en ändring som stöds i taget och upprepa samma arbetsbelastning. Håll den ursprungliga konfigurationen och återställningsvägen tillgängliga.
Om funktionen är listad men programvaran inte kan använda den
Börja med den exakta komponenten som fallerar. En hårdvarudatabas beskriver registrerad kapacitet; operativsystemet eller hypervisorn kan exponera en annan faktisk miljö. Ett fel om otillåten instruktion kräver också undersökning av den faktiska felande instruktionen och binärbygget, eftersom korruption eller en orelaterad instruktion utan stöd kan ge ett liknande symptom.
Installera den version av applikationen, drivrutinen eller runtime-miljön som stöds för den exakta plattformen, och använd vid behov tillverkarens dokumenterade baslinje eller reservbygge. En programvaruuppdatering kan inte skapa en instruktion som processorn saknar. Ändringar i firmware och säkerhetspolicy bör följa systemtillverkarens procedur och en återställningsplan snarare än ett generiskt optimeringsrecept.
Källor och omfattning för denna förklaring
Intel 64 and IA-32 Architectures Software Developer's Manual · Intels sakerhetsfunktioner relaterade till transienta exekveringsattacker
Dessa referenser fastställer arkitektoniskt beteende och programvarukrav. De verifierar inte oberoende varje funktionsvärde på en länkad hårdvarumodellsida. För modellstöd, använd den sidans tillverkarbelägg och kontrollera den effektiva systemkonfigurationen. Denna artikel tillhandahåller inte ett prestandatest, en certifiering eller ett oberoende granskningsdatum.
Källor och verifiering
Redaktionellt ägarskap: Feex. Inget oberoende granskningsdatum har registrerats. Hur vi efterforskar.
- Intel 64 and IA-32 Architectures Software Developer's Manual · Volym 1 och 2 beskriver de namngivna instruktionsfamiljerna och CPUID; Volym 3 beskriver tillstånd, sidindelning, VMX och skyddskontroller. Arkitekturdokumentation fastställer inte stöd för en specifik modell.
- Intels sakerhetsfunktioner relaterade till transienta exekveringsattacker · Identifierar Intel OS Guard med SMEP. Detta ar skiljt fran SMAP, trots att vissa importerade funktionsetiketter blandar ihop dessa namn.
Var denna artikel användbar?
Ett ja eller nej räcker. Välj en anledning om du vill, eller lägg till en kort anteckning.
Tack. Det hjälper oss att förbättra den här sidan.