Izolacija kernela sigurnosna je tehnologija temeljena na virtualizaciji koja pruža dodatni sloj zaštite od inteligentnih napada. Integritet memorije dio je tehnologije izolacije kernela, značajke osmišljene za sprječavanje umetanja zlonamjernog koda u vrlo sigurne procese. Zaštita je osigurana činjenicom da se stranica virtualne memorije jezgre počinje izvršavati tek nakon što uspješno prođe provjeru integriteta.
Pogledajmo kako omogućiti značajku Integriteta memorije u Windows 10. ažuriranju za travanj 2018. za jačanje sigurnosti vašeg računala.
Omogućavanje integriteta memorije
- Otvorite sigurnosni centar Windows Defender.
- Odaberite odjeljak "Sigurnost uređaja".
- U odjeljku "Izolacija jezgre" kliknite vezu "Detalji izolacije jezgre".
- Pomaknite prekidač "Integritet memorije" u aktivni položaj.
Nakon dovršetka ovih koraka morate ponovno pokrenuti računalo kako bi promjene stupile na snagu.
Bilješka: Da bi ova značajka radila, vaš procesor mora podržavati tehnologije virtualizacije. Osim toga, virtualizacija mora biti omogućena u BIOS-u ili UEFI-ju. U suprotnom, funkcija neće biti dostupna.
Rješavanje problema s izolacijom kernela
U nekim slučajevima možete naići na probleme s kompatibilnošću u nekim aplikacijama ako je omogućena izolacija kernela. Da biste riješili problem, morat ćete onemogućiti funkciju.
Ako pokušate onemogućiti integritet memorije u Windows Defender Security Centeru, ali opcija postane siva i vidite poruku "Ovu postavku kontrolira vaš administrator", još uvijek možete onemogućiti značajku pomoću registra.
Bilješka: Neispravna promjena registra može uzrokovati ozbiljne probleme. Preporuča se napraviti sigurnosnu kopiju vašeg Windows registra prije izvođenja ovih koraka. U izborniku uređivača registra odaberite Datoteka > Izvezi da biste spremili sigurnosnu kopiju.
- Pritisnite kombinaciju tipki Windows + R za otvaranje prozora Pokreni.
- Upišite regedit i kliknite OK za pokretanje uređivača registra.
- Idite na sljedeći put:
- Dvaput kliknite na unos Omogućeno.
- Promijenite vrijednost s 1 na 0.
- Pritisnite OK.
Za onemogućavanje također možete koristiti gotove
Upravitelj napajanja pazi na potrošnju energije u cijelom sustavu. Povijesno se upravljanje napajanjem sastojalo od isključivanja monitora i zaustavljanja okretanja diskova. Ali ovaj problem brzo postaje sve složeniji - zbog zahtjeva za duljim trajanjem baterije na prijenosnim računalima, kao i zbog razmatranja uštede energije na stolnim računalima (koja su stalno uključena) i visoke cijene energije koju troše farme poslužitelja.
Nove značajke upravljanja napajanjem uključuju smanjenje potrošnje energije komponenti kada se sustav ne koristi prebacivanjem pojedinačnih uređaja u redundantno stanje ili čak njihovim potpunim isključivanjem (pomoću prekidača za napajanje). Višeprocesorski sustavi onemogućuju pojedinačne procesore kada nisu potrebni i mogu čak smanjiti radni takt procesora (kako bi se smanjila potrošnja energije). Kada je procesor u stanju mirovanja, njegova potrošnja energije je također smanjena jer ne mora raditi ništa osim čekati da se dogodi prekid.
Windows podržava poseban način isključivanja koji se naziva hibernacija, koji kopira svu fizičku memoriju na disk i zatim smanjuje potrošnju energije na minimum (prijenosna računala mogu raditi tjednima u stanju hibernacije) uz minimalno trošenje baterije. Budući da se cijelo stanje memorije zapisuje na disk, možete čak zamijeniti bateriju prijenosnog računala (dok je u hibernaciji). Kada sustav izađe iz stanja hibernacije, vraća spremljeno stanje memorije (i ponovno inicijalizira uređaje). Ovo stavlja računalo u isto stanje u kojem je bilo prije hibernacije (bez potrebe za ponovnom registracijom i pokretanjem svih aplikacija i usluga koje su bile pokrenute. Windows pokušava optimizirati ovaj proces ignorirajući neizmijenjene stranice (one koje su sigurnosno kopirane na disku) i komprimira ostale memorijske stranice kako bi se smanjio potreban I/O algoritam za hibernaciju koji automatski uravnotežuje I/O propusnost sustava kako bi se smanjila potreba za I/O propusnošću, ali u isto vrijeme učinkovitije I/O propusnost omogućuje izbjegavanje kompresije pri ulasku u stanje hibernacije S najnovijom generacijom multiprocesora, ulazak i izlazak iz stanja hibernacije može potrajati samo nekoliko sekundi, čak i ako sustav ima veliku količinu RAM-a.
Alternativa hibernaciji je stanje pripravnosti, u kojem upravitelj napajanja prebacuje cijeli sustav u stanje niže potrošnje energije (koristeći samo dovoljno energije za regeneraciju stanja dinamičke memorije). Budući da se memorija ne mora kopirati na disk, ulazak u ovo stanje brži je od hibernacije na nekim sustavima.
Unatoč dostupnosti stanja hibernacije i stanja mirovanja, mnogi se korisnici nisu riješili navike isključivanja osobnog računala nakon završetka rada.
Hibernacija se koristi u sustavu Windows za izvođenje pseudo gašenja pri pokretanju pod nazivom HiberBoot, što je mnogo brže od normalnog gašenja i pokretanja. Kada korisnik naredi sustavu da se ugasi, HiberBoot odjavljuje korisnika iz sustava i zatim stavlja sustav u stanje hibernacije u trenutku kada se sustav može ponovno normalno prijaviti. Kasnije, kada korisnik ponovno uključi sustav, HiberBoot će nastaviti s radom sustava s korisnikove točke prijave. Korisniku se sve ovo čini kao vrlo brzo gašenje, budući da je većina koraka inicijalizacije sustava preskočena. Naravno, ponekad se sustav mora stvarno isključiti kako bi se riješili problemi ili instaliralo ažuriranje kernela. Ako je sustavu naređeno da se ponovno pokrene, a ne da se isključi, on izdrži pravo gašenje i izvodi normalno pokretanje.
Očekuje se da računalni uređaji na telefonima i tabletima, kao i nove generacije prijenosnih računala, uvijek troše malu količinu energije. Kako bi osigurao ovaj način rada, moderni Windows implementira posebnu verziju upravljanja napajanjem nazvanu CS (connected standby). CS je moguć na sustavima s namjenskim hardverom za mrežno povezivanje koji može nadzirati promet preko malog skupa veza koristeći mnogo manje energije od pokretanja CPU-a. Ispada da je CS sustav uvijek uključen, CS se izlazi odmah čim korisnik uključi ekran. Povezani način mirovanja razlikuje se od uobičajenog načina mirovanja jer će se CS sustav također probuditi kada primi paket od nadzirane veze. Nakon što baterija počne biti prazna, CS sustav ulazi u stanje hibernacije kako bi se izbjeglo potpuno pražnjenje baterije i mogući gubitak korisničkih podataka.
Postizanje dugog vijeka trajanja baterije zahtijeva više od pukog gašenja procesora što je češće moguće. Također je važno držati procesor isključen što je duže moguće. Mrežni hardver CS sustava omogućuje da procesori ostanu isključeni dok podaci ne stignu, ali drugi događaji mogu uzrokovati ponovno uključivanje procesora. Upravljački programi Windows uređaja koji se temelje na NT-u, sistemske usluge i same aplikacije često se pokreću bez posebnog razloga, samo radi provjere statusa stvari. Ova aktivnost anketiranja obično se temelji na postavljanju mjerača vremena za povremeno pokretanje koda na sustavu ili aplikaciji. Anketiranje na temelju signala mjerača vremena može zbuniti događaje uključene u procesor. Kako bi se to izbjeglo, moderni Windows zahtijeva od takvih mjerača vremena da specificiraju marginu pogreške koja omogućuje operacijskom sustavu da agregira događaje mjerača vremena i smanji broj zasebnih vremena pokretanja za procesor. Windows također definira uvjete pod kojima aplikacija koja nije aktivno pokrenuta može izvršavati kod u pozadini. Operacije kao što su provjera ažuriranja ili osvježavanje sadržaja ne mogu se izvesti samo kada se od vas zatraži da se pokrenu nakon isteka vremena. Aplikacija se mora povinovati operativnom sustavu u pogledu takve pozadinske aktivnosti. Na primjer, provjera ažuriranja trebala bi se dogoditi samo jednom dnevno ili sljedeći put kada se uređaj puni baterijom. Skup proxy poslužitelja sustava pruža različite uvjete koji se mogu koristiti za ograničavanje aktivnosti u pozadini. Ako pozadinski zadatak zahtijeva jeftin pristup mreži ili korisnička dopuštenja, proxy poslužitelji neće izvršiti zadatak dok ne postoje potrebni uvjeti.
Danas se mnoge aplikacije implementiraju s lokalnim kodom i uslugama smještenim u oblaku. Windows pruža Windows Notification Service (WNS), koji uslugama trećih strana omogućuje slanje obavijesti Windows uređaju u CS-u bez potrebe da CS mrežni hardver posebno osluškuje pakete s poslužitelja trećih strana. WNS obavijesti mogu vas upozoriti na vremenski kritične događaje, kao što je dolazak tekstualne poruke ili VoIP poziva. Kada stigne WNS paket, procesor će se morati uključiti kako bi ga obradio, ali CS mrežni hardver ima mogućnost razlikovati promet s različitih veza, što znači da se procesor ne mora uključiti kao odgovor na svaki nasumični paket dolaze iz mrežnog sučelja.
Upravljački programi načina rada jezgre: 1. dio: Osnovni pojmovi - Arhiva WASM.RU
Pregled arhitekture
Unutarnji svijet Windowsa 2000 podijeljen je na dva dijela s jasno definiranim granicama, kako u pogledu adresnog prostora tako i u smislu prava i odgovornosti koda koji se izvodi u tom adresnom prostoru.
S podjelom adresnog prostora sve je iznenađujuće jednostavno. Sva četiri gigabajta dostupna u 32-bitnoj arhitekturi podijeljena su na dva jednaka dijela (izostavljam 4GT RAM Tuning i Physical Address Extension kao egzotične). Donja polovica posvećena je procesima korisničkog načina rada, a gornja polovica pripada kernelu.
Malo je kompliciranija podjela prava i obaveza.
Sljedeći procesi smatraju se korisničkim procesima:
- Procesi podrške sustavu - na primjer, Winlogon proces prijave (implementiran u \%SystemRoot%\System32\Winlogon.exe);
- Servisni procesi - na primjer, uređaj za ispis u čekanju;
- Korisničke aplikacije - Postoji pet vrsta: Win32, Windows 3.1, MS-DOS, POSIX i OS/2;
- Podsustavi okruženja - podržana su tri podsustava okruženja: Win32 (implementiran u \%SystemRoot%\System32\Csrss.exe), POSIX (implementiran u \%SystemRoot%\System32\Psxss.exe), OS/2 (implementiran u \%SystemRoot %\System32\os2ss.exe).
Jezgra se sastoji od sljedećih komponenti:
Izvršni sustav - upravljanje memorijom, procesi i niti, itd.;
- Kernel - raspoređivanje niti, slanje prekida i izuzetaka, itd. (implementirano u \%SystemRoot%\System32\Ntoskrnl.exe);
- Upravljački programi uređaja - upravljački programi hardverskih uređaja, mrežni upravljački programi, upravljački programi sustava datoteka;
- Hardverski sloj apstrakcije (HAL) - izolira gornje tri komponente od razlika između hardverskih arhitektura (implementirano u \%SystemRoot%\System32\Hal.dll);
- Prozori i grafički sustav - funkcije grafičkog korisničkog sučelja (GUI) (implementirano u \%SystemRoot%\System32\Win32k.sys).
Riža. 1-1. Pojednostavljeni dijagram Windows 2000 arhitekture
Korisnički način rada i način rada jezgre
Iako obitelj procesora Intel x86 podržava četiri razine privilegija (koje se nazivaju prstenovi zaštite), Windows koristi samo dvije: 0 za kernel način i 3 za korisnički način. To je zbog podrške drugih procesora (alpha, mips), u kojima su implementirane samo dvije razine privilegija. Prethodna izdanja sustava Windows NT podržavala su ove arhitekture, ali Windows 2000 ostao je samo x86.
Komponente korisničkog načina rada imaju vlastite zaštićene adresne prostore; niti ovih procesa rade u neprivilegiranom procesorskom načinu (koji se naziva korisnički način), ne mogu izvršavati privilegirane procesorske naredbe, imaju ograničen i neizravan pristup sistemskim podacima i sistemskom adresnom prostoru i nemaju izravan pristup hardveru. Istina, tijekom svog rada niti ovih procesa, pozivajući sistemske servise, prelaze u način rada jezgre, ali u tom slučaju potpuno gube kontrolu nad njihovim izvršavanjem do povratka natrag u korisnički način.
Procesi korisničkog načina rada smatraju se potencijalno opasnima sa stajališta stabilnosti sustava. Njihova prava su ograničena. A svaki pokušaj da se izađe izvan okvira tih ograničenja oštro se suzbija.
Komponente jezgre dijele jedan adresni prostor, izvršavaju se u povlaštenom procesorskom načinu (koji se naziva način jezgre), mogu izvršavati sve procesorske instrukcije, uključujući one povlaštene, imaju neograničen i izravan pristup sistemskim podacima i kodu te izravan ili putem HAL-a pristup oprema.
Kod kernela (zapravo, ovo je sam sustav) smatra se potpuno pouzdanim. Stoga, jednom kada se učita u adresni prostor sustava, upravljački program postaje dio sustava i ne podliježe nikakvim ograničenjima.
Time su korisničke aplikacije odvojene od samog operativnog sustava. Ako krenete pisati bilo koju ozbiljnu aplikaciju koja zahtijeva pristup internim funkcijama ili strukturama podataka sustava, naići ćete na mnoga ograničenja koja se mogu prevladati samo postavljanjem vašeg koda u adresni prostor sustava. Postoji samo jedan dokumentirani način za to - instalirajte upravljački program uređaja. Ova metoda je relativno jednostavna, pouzdana i, što je najvažnije, u potpunosti podržava sam operativni sustav.
Windows 2000 upravljački programi
Windows 2000 podržava mnoge vrste upravljačkih programa uređaja.
Dvije su osnovne koje imaju svoje predstavnike:
- Upravljački programi korisničkog načina rada:
- Virtualni upravljački programi (VDD) - koriste se za podršku MS-DOS programima (ne brkati s VxD upravljačkim programima u Windowsima 95/98 - to su potpuno različite stvari, iako imaju isto ime);
- Upravljački programi pisača.
- Upravljački programi u načinu rada jezgre:
- Upravljački programi sustava datoteka - implementirajte I/O na lokalne i mrežne pogone;
- Legacy Drivers - napisani za prethodne verzije Windows NT;
- Upravljački programi video adaptera (Video Drivers) - implementiraju grafičke operacije;
- Streaming Driveri - implementirajte video i audio ulaz/izlaz;
- WDM upravljački programi (Windows Driver Model, WDM) - podržavaju Plug and Play tehnologiju i upravljanje napajanjem. Njihova posebnost je kompatibilnost na razini izvornog koda između Windows 98, Windows ME i Windows 2000.
U različitim izvorima možete naići na klasifikaciju malo drugačiju od gore navedene, to nije važno. Bitno je da vozači koje ćemo napisati ne potpadaju ni pod jednu točku ove klasifikacije. Ovo nisu ni upravljački programi datotečnog sustava, ni stari upravljački programi, ni upravljački programi video adaptera ili zvučne kartice, niti upravljački programi WDM, jer ne podržavaju Plag"n"Play i upravljanje napajanjem. Ovo nisu upravljački programi korisničkog načina (to uopće nije zanimljivo). Zapravo, vrag zna što je, jer... sam sustav vam omogućuje da lako i jednostavno dodate sami sebi kod za nepoznati uređaj, i radite s njim što god želite! Kao da vam je potpuni stranac noću pokucao na vrata, a vi ste ga bez riječi pustili da prenoći, pa čak i stavili u svoj krevet! Međutim, ovo nije neka vrsta buga ili sigurnosne rupe. Sustav jednostavno radi kako radi. Ne može biti drugačije, jer... u interakciji s okolinom, sustav je prisiljen osigurati pristup sebi. A da nije tako, onda bi to bio potpuno zatvoren, a time i beskoristan sustav.
Kao što samo ime govori, upravljački program uređaja je program dizajniran za upravljanje nekim uređajem, a taj uređaj ne mora nužno biti fizički. Može biti logična ili, kao u našem slučaju, virtualna.
Po svojoj strukturi, upravljački program uređaja nije ništa drugo do datoteka u PE formatu (Portable Executable, PE). Isto kao obični exe i dll. Samo se učitava i radi prema drugačijim pravilima. Upravljački programi se mogu smatrati DLL-ovima u načinu rada jezgre dizajniranim za obavljanje zadataka koji se ne mogu izvršiti u korisničkom načinu rada. Temeljna razlika ovdje (ne računajući razinu privilegija) je u tome što nećemo moći izravno pristupiti upravljačkom programu, niti njegovom kodu niti njegovim podacima, već ćemo koristiti poseban mehanizam koji osigurava Input/Output Manager. I/O upravitelj osigurava okruženje za rad pogonitelja i također osigurava mehanizme za njihovo učitavanje, istovar i upravljanje njima.
Kada počnete razvijati upravljačke programe kernel moda, osjećat ćete se kao potpuni početnik jer... sva prethodna iskustva s korištenjem API-ja ovdje neće pomoći - kernel pruža potpuno drugačiji skup funkcija. Također ćete morati koristiti loše dokumentirane (definirane samo u datotekama zaglavlja) ili potpuno nedokumentirane funkcije i strukture podataka.
Jednostruki i višerazinski upravljački programi
Većina upravljačkih programa koji upravljaju fizičkim uređajima su slojeviti upravljački programi. Obrada I/O zahtjeva dijeli se između više upravljačkih programa. Svatko radi svoj dio posla. Na primjer, zahtjev za čitanje datoteke šalje se upravljačkom programu datotečnog sustava, koji ga nakon izvođenja nekih operacija (na primjer, dijeljenja zahtjeva na nekoliko dijelova) prosljeđuje "nizvodno" upravljačkom programu diska, koji zauzvrat, šalje zahtjev vozaču autobusa. Osim toga, između ovih upravljačkih programa možete dodati bilo koji broj upravljačkih programa filtera (na primjer, šifriranje podataka). Nakon izvršenja zahtjeva, upravljački program niže razine prosljeđuje svoje rezultate "gore" upravljačkom programu više razine. No, na sreću, sve će nam biti puno jednostavnije. Naši upravljački programi uvijek će biti monolitni upravljački programi, što će uvelike pojednostaviti cijeli proces pisanja i otklanjanja pogrešaka.
Kontekst niti
Budući da, u većini slučajeva, imamo samo jedan procesor, a postoji mnogo aplikacija koje treba izvršiti, prirodno je da, kako bi se stvorila iluzija njihovog istovremenog izvršavanja, te aplikacije moraju biti povezane sekvencijalno na procesor, i vrlo brzo. Taj se postupak naziva prebacivanje konteksta niti. Ako sustav prebacuje kontekst niti koje pripadaju istom procesu, tada je potrebno spremiti vrijednost registara procesora odspojene niti, te učitati prethodno spremljene vrijednosti registara procesora spojene niti. I ažurirati neke strukture podataka. Ako spojena dretva pripada nekom drugom procesu, tada je potrebno učitati pokazivač na direktorij stranica procesa u CR3 registar procesora. Budući da je svakom korisničkom procesu osiguran zatvoreni adresni prostor, različiti procesi imaju različite projekcije adresnih prostora, a time i različite direktorije stranica i skupove tablica stranica kroz koje procesor prevodi virtualne adrese u fizičke. Sve to nije izravno povezano s programiranjem upravljačkih programa. Ali podsjećam vas na ovo u vezi s ovim. Budući da prebacivanje konteksta nije najbrža operacija, upravljački programi, zbog boljih performansi, obično ne stvaraju vlastite niti. No kod vozača još treba izvršiti. Stoga, kako bi uštedjeli vrijeme na prebacivanju konteksta, upravljački programi pokreću se u načinu rada jezgre u jednom od tri konteksta:
- u kontekstu korisničke niti koja je pokrenula I/O zahtjev;
- u kontekstu sistemske niti kernel moda (ove niti pripadaju procesu System);
- kao rezultat prekida (i stoga ne u kontekstu bilo kojeg procesa ili niti koja je bila pokrenuta u vrijeme prekida).
Ne razumijem baš kako možete učiniti nešto "ne u kontekstu bilo kojeg procesa ili niti", ali s obzirom na autoritet ljudi koji su ovo napisali (D. Solomon i M. Russinovich), kao i činjenicu da ne ovo mi ne treba jer . Nećemo obrađivati niti softverske, niti hardverske prekide, treći slučaj možemo odmah zaboraviti. Prve dvije opcije ostaju. Ako je I/O zahtjev pokrenut, tada se nalazimo u kontekstu niti koja je pokrenula ovaj zahtjev, te stoga možemo izravno pristupiti adresnom prostoru procesa kojem ova nit pripada. Ako se nalazimo u kontekstu sistemske niti, tada ne možemo izravno pristupiti nijednom korisničkom procesu, ali uvijek možemo pristupiti sustavskom. Ako iz drajvera trebate vidjeti što neki proces ima na toj i toj adresi, morat ćete ili sami promijeniti kontekst ili prevesti adrese pomoću tablica stranica.
Razine zahtjeva za prekid
Prekid je sastavni dio svakog operativnog sustava. Prekid zahtijeva obradu, tako da se izvršavanje trenutnog koda zaustavlja i kontrola se prenosi na rukovatelja prekidima. Postoje i hardverski i softverski prekidi. Prekidi se servisiraju prema svom prioritetu. Windows 2000 koristi shemu prioriteta prekida poznatu kao razine zahtjeva za prekid (IRQL). Postoje ukupno 32 razine, od 0 (pasivna), koja ima najniži prioritet, do 31 (visoki), koja ima najviši prioritet. Štoviše, prekidi od IRQL=0 (pasivno) do IRQL=2 (DPC\dispatch) su softverski, a prekidi od IRQL=3 (uređaj 1) do IRQL=31 (visoki) su hardverski. Nemojte brkati razine prioriteta prekida s razinama prioriteta niti - to su potpuno različite stvari. Prekid s razinom IRQL=0, strogo govoreći, nije prekid, jer ne može prekinuti rad bilo kojeg koda (uostalom, da bi to učinio, ovaj se kod mora izvršiti na još nižoj razini prekida, ali takva razina ne postoji). Niti korisničkog načina rada izvršavaju se na ovom IRQL-u. I naš upravljački kod također će se izvoditi na ovom IRQL-u. To ne znači da se kod pokretača uvijek izvršava na "pasivnoj" razini. Samo što mi nećemo rješavati ni softverske ni, pogotovo, hardverske prekide. A iz toga slijede barem dva vrlo važna zaključka.
Prvo: rad naših upravljačkih programa može se prekinuti u bilo kojem trenutku kako bi se obradio prekid s višim prioritetom (na primjer, iz mjerača vremena, kada planer smatra da naša nit već ima procesor dovoljno dugo i da je vrijeme da se odmor). Stoga je u tom smislu kod naših pokretačkih programa prekidiv i preemptibilan (procesor se daje drugoj niti), baš kao i šifra bilo koje korisničke niti. Postoje funkcije jezgre koje vam omogućuju da saznate trenutnu razinu prekida, kao i da je povisite ili smanjite.
Druga važna točka: na razini pasivnog prekida možete pozvati bilo koju funkciju jezgre (u DDK-u opis svake funkcije mora naznačiti na kojoj se razini prekida može pozvati), a također i pristupiti stranicama memorije ispranim u swap datoteku. Na višim razinama prekida (DPC/dispath i više), pokušaj pristupa stranici koja nije u fizičkoj memoriji dovodi do pada sustava, jer Upravitelj memorije ne može obraditi pogrešku stranice.
"Plavi ekran smrti"
Mislim da je svatko, barem jednom, vidio uzbudljivu sliku pod nazivom "Blue Screen Of Death" (BSOD). Vjerojatno nema potrebe objašnjavati što je to i zašto se javlja. Ovdje je važna stvar da kada počnete razvijati upravljačke programe kernel moda, pripremite se na činjenicu da će se BSOD često pojavljivati na zaslonu vašeg monitora.
U trećem prstenu sve je bilo jednostavno: skicirao sam približni kod, stavio int3 gdje je potrebno, pokrenuo ga i... u debuggeru već razumijete što je što. Ako nešto nije u redu, popravio sam, ispravio greške, rekompilirao... i tako sve dok kod ne radi kako treba. Kada programirate upravljačke programe, možete zaboraviti na ovu tehniku. Ovdje "saper" jednom pogriješi. Jedan pogrešan pokret... i možete se zavaliti i opustiti na minutu.
Kako biste što rjeđe vidjeli BSOD, trebali biste se pridržavati jednog vrlo jednostavnog pravila: “Sedam puta izmjeri – jednom presijeci”... u smislu “Sedam puta provjeri – jednom trči”. To je naravno lako reći, ali mnogo teže učiniti. Ali u pravilu, s obzirom da je struktura upravljačkih programa koje ćete napisati (nakon čitanja ovih članaka) relativno jednostavna, možete se pozabaviti pogreškama prije nego što se pojavi BSOD. Ako vam se uporno pojavljuje pred očima, a ne možete razumjeti razlog, mogući način da razjasnite situaciju je analiza crash dumpa. O tome što je to, kako ga napraviti i analizirati možete pročitati u članku Marka Russinovicha “Analiza ispisa memorije pri padu” http://www.osp.ru/win2000/2001/03/025.htm. Ova stvar (analiza) je jako teška, ali mislim da do toga neće doći.
Ja sam užasan teoretičar, tako da sve gore navedeno možete smatrati vrlo osnovnim informacijama o principima koje je apsolutno neophodno razumjeti. Ne možete započeti s razvojem upravljačkih programa načina rada jezgre bez razumijevanja konteksta niti, razina prekida i prioriteta niti, načina rada kernela/korisnika itd. i tako dalje. Ako se ne osjećate sigurni u vezi s nekim problemom - popis referenci je ispod.
Sada pokrijmo neke praktičnije stvari (postat će vrlo praktične u sljedećim člancima), naime, što nam je potrebno da svu ovu teoriju pretvorimo u praksu.
Komplet za razvoj upravljačkih programa
Prvi je, naravno, Device Driver Development Kit (Windows 2000 Driver Development Kit, 2KDDK), koji se može besplatno preuzeti s Microsoftove web stranice (u svakom slučaju, ja sam ga potpuno besplatno preuzeo odavde: http:// www.microsoft.com/ddk/). Ovaj paket uključuje dokumentaciju koja je bogat izvor informacija o internim strukturama podataka i funkcijama cijelog sustava koje koriste upravljački programi uređaja.
Osim dokumentacije, DDK uključuje skup datoteka knjižnice (*.lib) koje će biti apsolutno potrebne prilikom povezivanja. DDK uključuje dva skupa ovih datoteka: za konačnu verziju sustava Windows (zvanu besplatna verzija); i za razvoj (naziva se provjerena izgradnja). Te se datoteke nalaze u direktorijima %ddk%\libfre\i386 i %ddk%\libchk\i386. Verzija za otklanjanje pogrešaka ima strožu provjeru pogrešaka. Morate koristiti datoteke koje odgovaraju vašoj verziji sustava tako da ih smjestite u direktorij \masm32\lib\w2k.
Uključene datoteke
Također ćemo trebati uključiti (*.inc) datoteke s definicijama prototipa funkcija. I njih ćemo mi (točnije ja) također morati napraviti sami. Isprobao sam mnogo različitih uslužnih programa koji pretvaraju *.lib -> *.inc, oba uključena u paket masm32 by hutch, i onih koje sam u različita vremena procurio s golemih prostranstava Interneta. Od svih koje imam, samo je protoize.exe by f0dder uspio sa svojim zadatkom i praktički nisam morao ništa uređivati ručno. Ovaj prekrasan alat nalazit će se u direktoriju \tools\protoize. Web stranica autora: http://f0dder.didjitalyphrozen.com/. Ali tamo ga nećete naći. f0dder je objavio ovaj pomoćni program nekoliko puta na http://board.win32asmcommunity.net/ konferenciji. Includes će se nalaziti u direktoriju \include\w2k. Treba ih smjestiti u direktorij \masm32\include\w2k. Za konverziju smo koristili *.lib za besplatno izdanje Windowsa 2000, budući da je to verzija koju ja imam (a vjerojatno i vi).
Sljedeći problem je ozbiljniji. Ovo je gotovo potpuni izostanak uključenih datoteka s definicijama potrebnih struktura, simboličkih konstanti i makronaredbi. Malo je vjerojatno da ćete moći pronaći nešto korisno na Internetu - ovo je previše egzotična aktivnost - pisanje upravljačkih programa kernel moda u asembleru. Neki se mogu pronaći na EliCZ http://www.anticracking.sk/EliCZ/. Nešto od Y0da http://mitglied.lycos.de/yoda2k/index.htm (djelomično napravio on, djelomično preuzeto iz istog EliCZ-a). Ali to je učinjeno izuzetno loše (uz sve moje duboko poštovanje prema našim slovačkim i njemačkim kolegama): imena članova mnogih struktura razlikuju se od onih definiranih u izvornim datotekama zaglavlja iz DDK-a; ugniježđene strukture i unije nemaju imena; iako su u originalu imenovani. I općenito, sve je u nekom neredu, a gledano ostavlja depresivan dojam. Samo je ntstatus.inc dobro napravljen. To je djelomično zbog činjenice da je EliCZ počeo stvarati svoje inkluzije čak i bez DDK (kako sam kaže). U svakom slučaju, ne savjetujem vam da ih koristite, barem bez pažljivog testiranja. Nešto je, svojedobno, bljesnulo na http://board.win32asmcommunity.net/ konferenciji, ali kvaliteta također nije osobito impresivna. Ukratko, jedino ispravno rješenje u ovoj situaciji je da sve napravite sami, i to ručno, budući da mi nisu poznati alati koji vam omogućuju automatizaciju ovog procesa. Ako iznenada naiđete na nešto vrijedno truda i ne mislite da je to previše problema, javite mi.
Otklanjanje pogrešaka upravljačkih programa
Također nam je potreban program za ispravljanje pogrešaka, a budući da ćemo morati ispravljati kod kernel moda, potreban nam je odgovarajući program za ispravljanje pogrešaka. Najbolji izbor bi bio SoftICE. Ili možete koristiti Kernel Debugger uključen u DDK. Ovaj debugger zahtijeva dva računala - master i slave, što si ne može svatko priuštiti. Mark Russinovich (http://www.sysinternals.com/) napisao je uslužni program pod nazivom LiveKd, koji vam omogućuje korištenje Kernel Debuggera bez spajanja drugog računala. Ne znam da li je na stranici (nisam provjerio), ali je na disku za knjigu "Interni uređaji Microsoft Windows 2000." Ovaj program za ispravljanje pogrešaka također je iznimno koristan za ispitivanje unutrašnjosti sustava, pod uvjetom da imate instalirane simbole za ispravljanje pogrešaka, koji se mogu (ili mogu) besplatno preuzeti s Microsoftove web stranice.
David Solomon, Mark Russinovich, "Internals of Microsoft Windows 2000", ed. "Petar", 2001. (monografija). Iako ova knjiga ne sadrži niti jedan redak izvornog koda, prvenstveno je namijenjena programerima.
Sven Schreiber, "Nedokumentirane značajke sustava Windows 2000", ur. "Petar", 2002. Čisto praktična knjiga koja otkriva mnoge tajne Windowsa 2000.
Walter Oney, "Programming the Microsoft Driver Model", Microsoft Press, 1999 U ovoj knjizi naglasak je na Plag"n"Play drajverima, ali to ni na koji način ne umanjuje njegove prednosti, jer Osnovni principi razvoja vozača su univerzalni.
Jeffrey Richter, "Windows za profesionalce: Izrada moćnih Win32 aplikacija sa specifičnostima 64-bitnih Windowsa", ur. "Petar", 2000. Ova knjiga nema izravne veze s programiranjem upravljačkih programa, ali je također vrlo zanimljiva ;-)
Ovaj popis nipošto nije potpun. Mnogo toga, pogotovo na engleskom, može se pronaći na internetu (osim Schreibera, sve knjige su dostupne u elektroničkom obliku). Što se tiče knjiga, također želim reći da su sve one “must have”. Vidite - kupujte bez gledanja. Svi osim Waltera Oneya prevedeni su na naš "veliki i moćni".
I još nešto za kraj. Nisam veliki stručnjak u području razvoja drajvera, tako da su pogreške ili netočnosti, kako u ovom tako iu svim sljedećim člancima, vrlo vjerojatne. Ako nađete, slobodno gurnite nos. Reći ću ti hvala.
Microsoft pridaje veliku pozornost sigurnosti u Windows 10 operativnom sustavu. Jedan od važnih elemenata sustava je Windows Defender, no on se ne može nositi sa svim prijetnjama. Konkretno, nedavno su posebno rašireni Ransomware virusi, čije su najpoznatije reinkarnacije Petya i . Microsoft je u Windows 10 uveo značajke izolacije kernela i integriteta memorije koje su usmjerene na borbu protiv Ransomware virusa. Prema zadanim postavkama one su onemogućene.
Sadržaj:Što je izolacija kernela i integritet memorije
Izolacija kernela je dodatni zaštitni proces koji se osigurava metodom izolacije računalnih procesa od operativnog sustava i uređaja. Zbog ovih radnji moguće je izbjeći podrivanje rada operativnog sustava kada virusi uđu u računalo.
Integritet pamćenja- Ovo je zaštitna funkcija koja prati izolaciju kernela, čiji je cilj ograničiti pristup nepoznatih potencijalno opasnih programa procesima s visokom razinom sigurnosti.
Važno: Funkcija izolacije kernela može raditi samo ako za to postoje dovoljni uvjeti iz hardvera računala. U postavkama BIOS-a tehnologija virtualizacije mora biti aktivna, zbog čega računalo sa sustavom Windows 10 može pokrenuti različite aplikacije u virtualnom spremniku, ograničavajući im pristup iz ključnih komponenti sustava.
Kako omogućiti izolaciju kernela i integritet memorije
Postavke operativnog sustava Windows 10 omogućuju vam potpunu kontrolu sigurnosnih značajki na vašem računalu. Putem postavki sustava Windows 10 možete omogućiti izolaciju kernela i integritet memorije na sljedeći način:
Kao što je gore navedeno, ako hardver računala ne podržava virtualizaciju, ova funkcija neće raditi. Kada je uključeno, korisnik će u donjem desnom kutu vidjeti poruku “Nije moguće osigurati integritet memorije. Moguća nekompatibilnost." Ako se pojavi ova poruka, preporuča se otići u BIOS i vidjeti je li omogućena funkcija Secure Boot (Boot Mode).
Kako onemogućiti izolaciju kernela i integritet memorije
Nove značajke u operativnom sustavu koje ozbiljno utječu na njegov rad uvijek nose rizik od prouzročenja problema s radom računala. Funkcija izolacije kernela nije iznimka. Korisnici koji su ga već isprobali bilježe na Microsoftovim forumima da nailaze na probleme pri pokretanju niza igara i programa. Jedini način da se riješi ovaj problem je onemogućiti izolaciju kernela i integritet memorije. Možda će programeri aplikacija ili Microsoft ispraviti ovu nekompatibilnost u budućim ažuriranjima.
Postoje 3 načina da onemogućite izolaciju kernela i integritet memorije:
U mom glavnom prijenosnom računalu često se pojavljuju različiti problemi s napajanjem, što se može objasniti radom u insajderskim verzijama. Međutim, čak iu stabilnoj verziji 1803, primijetio sam da je moj sustav prestao ići u stanje mirovanja. U ovom slučaju, monitor se isključio nakon određenog vremenskog perioda, što je nagovijestilo da je sustav ispravno odredio stanje neaktivnosti.
Postavio sam kratko razdoblje prijelaza u spavanje, 1-2 minute, i započeo dijagnostiku.
Provjera zahtjeva podsustavu napajanja iz aplikacija i upravljačkih programa
Prvo što trebate učiniti je pogledati powercfg, koji sprječava da OS ode u stanje mirovanja. Procesi i upravljački programi koji pristupaju podsustavu napajanja mogu se vidjeti u naredbenom retku kao administrator:
Powercfg-zahtjevi
Odmah je jasno da zahtjev SUSTAVU dolazi od VOZAČA - u ovom slučaju Realtek koristi audio stream.
WebRTC iz Chromea također može biti prisutan na popisu, a odmah nakon ponovnog pokretanja sustava možete vidjeti zahtjeve za optimizaciju preuzimanja i indeks pretraživanja, ali oni brzo nestaju. Možete dodati proces ili upravljački program na popis izuzetaka i to ga neće spriječiti da ode u stanje mirovanja.
Powercfg -requestsoverride Upravljački program "Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)" SUSTAV
Naredba glasi "zanemari zahtjev od VOZAČA [puno ime upravljačkog programa] prema SUSTAVU."
Popis iznimaka pohranjen je u ključu registra
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerRequestOverride
a izlazi naredbom
Powercfg -nadjačavanje zahtjeva
Ponovno sam pokrenuo sustav da budem siguran, ali sustav je odbio prijeći u stanje mirovanja. Nakon provjere iznimaka i popisa upita, otkrio sam da je Realtek upravljački program nastavio koristiti audio stream iako je bio uključen u iznimke.
Malo sam plesao oko iznimaka, ali nisam bio uspješan. Brzi Google potvrdio je da u nekim slučajevima ne rade. Ovo je tipično za naslijeđene zahtjeve, ali bio je još jedan slučaj, a ja nisam prvi koji se susreo s tim.
Na kraju sam maknuo Realtek s popisa. Možete izbrisati unose u uređivaču registra ili konzoli. Naredba je gotovo ista kao kod dodavanja, samo ne pokazuje gdje ide zahtjev, tj. u ovom slučaju na kraju naredbe nema SUSTAVA:
Powercfg -requestsoverride DRIVER "Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)"
Ići ćemo drugim putem
Izračunajte proces koji koristi audio podsustav
Poznato je da Realtek driver obavlja prljavi posao. Očito, učitava se pri pokretanju sustava, tako da je naziv datoteke lako saznati pomoću Autoruns.
Tri unosa odnose se na dvije datoteke, od kojih je jedna upravljačka ploča, sudeći po nazivu. Stoga je predmet interesa postao ravbg64.exe.