Izolarea kernelului este o tehnologie de securitate bazată pe virtualizare care oferă un nivel suplimentar de protecție împotriva atacurilor inteligente. Integritatea memoriei face parte din tehnologia de izolare a nucleului, o caracteristică concepută pentru a preveni inserarea codului rău intenționat în procesele extrem de sigure. Protecția este asigurată de faptul că pagina de memorie virtuală a nucleului începe să fie executată numai după trecerea cu succes a unei verificări de integritate.
Să ne uităm la cum să activați funcția de integritate a memoriei în Actualizarea Windows 10 aprilie 2018 pentru a consolida securitatea computerului.
Activarea integrității memoriei
- Deschideți Centrul de securitate Windows Defender.
- Selectați secțiunea „Securitate dispozitiv”.
- În secțiunea „Izolare kernel”, faceți clic pe link-ul „Detalii izolare nucleu”.
- Mutați comutatorul „Integritate memorie” în poziția activă.
După parcurgerea acestor pași, trebuie să reporniți computerul pentru ca modificările să intre în vigoare.
Notă: Pentru ca această caracteristică să funcționeze, procesorul dvs. trebuie să accepte tehnologii de virtualizare. În plus, virtualizarea trebuie să fie activată în BIOS sau UEFI. În caz contrar, funcția nu va fi disponibilă.
Remedierea problemelor de izolare a nucleului
În unele cazuri, este posibil să întâmpinați probleme de compatibilitate în unele aplicații dacă izolarea nucleului este activată. Pentru a remedia problema, va trebui să dezactivați funcția.
Dacă încercați să dezactivați integritatea memoriei în Centrul de securitate Windows Defender, dar opțiunea devine gri și vedeți mesajul „Această setare este controlată de administratorul dvs.”, puteți dezactiva în continuare funcția folosind registry.
Notă: Modificarea incorect a registrului poate cauza probleme serioase. Se recomandă să faceți o copie de rezervă a registrului Windows înainte de a efectua acești pași. Din meniul Registry Editor, selectați Fișier > Export pentru a salva o copie de rezervă.
- Apăsați combinația de taste Windows + R pentru a deschide fereastra Run.
- Tastați regedit și faceți clic pe OK pentru a lansa Editorul de registru.
- Mergeți pe următoarea cale:
- Faceți dublu clic pe intrare Activat.
- Modificați valoarea de la 1 la 0.
- Faceți clic pe OK.
Pentru a dezactiva, puteți folosi și cele gata făcute
Managerul de energie urmărește utilizarea energiei în întregul sistem. Din punct de vedere istoric, managementul alimentării a constat în oprirea monitorului și oprirea învârtirii unităților de disc. Dar această problemă devine rapid mai complexă - datorită cerințelor pentru o durată de viață mai lungă a bateriei la laptopuri, precum și a considerațiilor de conservare a energiei pe computerele desktop (care sunt lăsate tot timpul pornite) și a costului ridicat al energiei consumate de fermele de servere.
Noile funcții de gestionare a energiei includ reducerea consumului de energie al componentelor atunci când sistemul nu este utilizat prin comutarea dispozitivelor individuale într-o stare redundantă sau chiar oprirea lor completă (folosind comutatorul de alimentare). Sistemele multiprocesor dezactivează procesoarele individuale atunci când nu sunt necesare și pot chiar reduce viteza de ceas a procesoarelor (pentru a reduce consumul de energie). Când procesorul este inactiv, consumul său de energie este, de asemenea, redus, deoarece nu trebuie să facă altceva decât să aștepte să apară o întrerupere.
Windows acceptă un mod special de oprire numit hibernare, care copiază toată memoria fizică pe disc și apoi reduce consumul de energie la minimum (laptopurile pot funcționa săptămâni în hibernare) cu consumul minim de baterie. Deoarece întreaga stare de memorie este scrisă pe disc, puteți chiar înlocui bateria laptopului (în timp ce acesta este în hibernare). Când sistemul reia din hibernare, restabilește starea memoriei salvate (și reinițializează dispozitivele). Acest lucru pune computerul în aceeași stare în care era înainte de hibernare (fără a fi nevoie să se reînregistreze și să pornească toate aplicațiile și serviciile care rulau. Windows încearcă să optimizeze acest proces ignorând paginile nemodificate (cele pentru care se face backup pe disc) și comprimă paginile de memorie rămase pentru a reduce volumul de I/O necesar. Algoritmul de hibernare echilibrează automat I/O de sistem și lățimea de bandă a procesorului pentru a reduce nevoia de lățime de bandă de I/E a sistemului, dar, în același timp, este mai eficientă Lățimea de bandă I/O vă permite să evitați compresia atunci când intrați în modul hibernare Cu cea mai recentă generație de multiprocesoare, intrarea și ieșirea din starea de hibernare poate dura doar câteva secunde, chiar dacă sistemul are o cantitate mare de RAM.
O alternativă la hibernare este un mod de așteptare, în care managerul de energie comută întregul sistem într-o stare de consum mai scăzut de energie (folosind doar suficientă energie pentru a regenera starea memoriei dinamice). Deoarece memoria nu trebuie copiată pe disc, intrarea în această stare este mai rapidă decât hibernarea pe unele sisteme.
În ciuda disponibilității stărilor de hibernare și de așteptare, mulți utilizatori nu au scăpat de obiceiul de a-și opri computerul personal după ce au terminat lucrul.
Hibernarea este folosită în Windows pentru a efectua o pseudo-închidere de pornire numită HiberBoot, care este mult mai rapidă decât o închidere și pornire normală. Când utilizatorul comandă oprirea sistemului, HiberBoot îl deconectează din sistem și apoi pune sistemul în hibernare într-un punct în care sistemul poate fi reconectat în mod normal. Mai târziu, când utilizatorul repornește sistemul, HiberBoot va relua sistemul din punctul de conectare al utilizatorului. Pentru utilizator, totul se simte ca o închidere foarte rapidă, deoarece majoritatea pașilor de inițializare a sistemului sunt săriți. Desigur, uneori sistemul trebuie să fie închis pentru a remedia problemele sau pentru a instala o actualizare a nucleului. Dacă sistemul este comandat să repornească mai degrabă decât să se închidă, acesta suferă o închidere adevărată și efectuează o pornire normală.
Dispozitivele de calcul de pe telefoane și tablete, precum și noile generații de laptopuri, sunt de așteptat să consume întotdeauna o cantitate mică de energie. Pentru a oferi acest mod, Windows modern implementează o versiune specială de management al energiei numită CS (connected standby). CS este posibil pe sistemele cu hardware dedicat pentru conectivitate la rețea care pot monitoriza traficul printr-un set mic de conexiuni folosind mult mai puțină energie decât rularea unui CPU. Se pare că sistemul CS este întotdeauna pornit, CS este ieșit imediat de îndată ce utilizatorul pornește ecranul. Modul de repaus în modul conectat este diferit de modul de repaus normal, deoarece sistemul CS se va trezi și atunci când primește un pachet de la o conexiune monitorizată. Odată ce bateria începe să se descarce, sistemul CS intră într-o stare de hibernare pentru a evita consumarea completă a bateriei și posibila pierdere a datelor utilizatorului.
Obținerea unei durate lungi de viață a bateriei necesită mai mult decât doar oprirea procesorului cât mai des posibil. De asemenea, este important să țineți procesorul oprit cât mai mult timp posibil. Hardware-ul de rețea al sistemului CS permite procesoarelor să rămână oprite până la sosirea datelor, dar alte evenimente pot determina repornirea procesorului. Driverele de dispozitiv Windows bazate pe NT, serviciile de sistem și aplicațiile în sine pornesc adesea fără un motiv anume, doar pentru a verifica starea lucrurilor. Această activitate de sondare se bazează de obicei pe setarea temporizatoarelor pentru a rula periodic codul pe un sistem sau aplicație. Sondajul bazat pe semnalele temporizatorului poate confunda evenimentele implicate de procesor. Pentru a evita acest lucru, Windows modern cere ca astfel de temporizatoare să specifice o marjă de eroare care să permită sistemului de operare să cumuleze evenimentele temporizatorului și să reducă numărul de timpi de declanșare separati pentru procesor. Windows definește, de asemenea, condițiile în care o aplicație care nu rulează activ poate executa cod în fundal. Operațiuni precum verificarea actualizărilor sau reîmprospătarea conținutului nu pot fi efectuate numai atunci când vi se solicită să ruleze după expirarea unui temporizator. Aplicația trebuie să se apropie de sistemul de operare în ceea ce privește o astfel de activitate de fundal. De exemplu, verificarea actualizărilor ar trebui să aibă loc doar o dată pe zi sau data viitoare când dispozitivul are o încărcare a bateriei. Un set de proxy de sistem oferă diverse condiții care pot fi utilizate pentru a restricționa activitatea de fundal. Dacă o sarcină de fundal necesită acces la rețea la costuri reduse sau permisiuni de utilizator, proxy-urile nu vor executa sarcina până când nu vor exista condițiile necesare.
Astăzi, multe aplicații sunt implementate atât cu cod local, cât și cu servicii situate în cloud. Windows furnizează Serviciul de notificare Windows (WNS), care permite serviciilor terțelor părți să împingă notificări către un dispozitiv Windows în CS fără a necesita hardware-ul de rețea CS să asculte în mod specific pachetele de la servere terțe. Notificările WNS vă pot avertiza cu privire la evenimente critice, cum ar fi sosirea unui mesaj text sau a unui apel VoIP. Când sosește un pachet WNS, procesorul va trebui să pornească pentru a-l procesa, dar hardware-ul de rețea CS are capacitatea de a diferenția traficul de la diferite conexiuni, ceea ce înseamnă că procesorul nu trebuie să pornească ca răspuns la fiecare pachet aleatoriu. provenind din interfața de rețea.
Drivere pentru modul Kernel: Partea 1: Concepte de bază - Arhiva WASM.RU
Privire de ansamblu asupra arhitecturii
Lumea interioară a Windows 2000 este împărțită în două părți cu limite clar definite, atât în ceea ce privește spațiul de adrese, cât și în ceea ce privește drepturile și responsabilitățile codului care rulează în acel spațiu de adrese.
Cu divizarea spațiului de adrese, totul este surprinzător de simplu. Toți cei patru gigaocteți disponibili în arhitectura pe 32 de biți sunt împărțiți în două părți egale (omit 4GT RAM Tuning și Physical Address Extension ca exotice). Jumătatea inferioară este dedicată proceselor în modul utilizator, jumătatea superioară aparține nucleului.
Împărțirea drepturilor și responsabilităților este puțin mai complicată.
Următoarele procese sunt considerate procese utilizator:
- Procese de suport de sistem - de exemplu, procesul de conectare Winlogon (implementat în \%SystemRoot%\System32\Winlogon.exe);
- Procese de service - de exemplu, un spooler de imprimare;
- Aplicații utilizator - Există cinci tipuri: Win32, Windows 3.1, MS-DOS, POSIX și OS/2;
- Subsisteme de mediu - sunt acceptate trei subsisteme de mediu: Win32 (implementat în \%SystemRoot%\System32\Csrss.exe), POSIX (implementat în \%SystemRoot%\System32\Psxss.exe), OS/2 (implementat în \%SystemRoot %\System32\os2ss.exe).
Nucleul este format din următoarele componente:
Sistem executiv - managementul memoriei, procese și fire etc.;
- Kernel - programarea firelor de execuție, întreruperile de expediere și excepții etc. (implementat în \%SystemRoot%\System32\Ntoskrnl.exe);
- Drivere de dispozitiv - drivere de dispozitiv hardware, drivere de rețea, drivere de sistem de fișiere;
- Hardware Abstraction Layer (HAL) - izolează cele trei componente de mai sus de diferențele dintre arhitecturile hardware (implementat în \%SystemRoot%\System32\Hal.dll);
- Windowing And Graphics System - Funcții de interfață grafică cu utilizatorul (GUI) (implementate în \%SystemRoot%\System32\Win32k.sys).
Orez. 1-1. Diagrama simplificată a arhitecturii Windows 2000
Modul utilizator și modul kernel
Deși familia de procesoare Intel x86 acceptă patru niveluri de privilegii (numite inele de protecție), Windows folosește doar două: 0 pentru modul kernel și 3 pentru modul utilizator. Acest lucru se datorează suportului altor procesoare (alpha, mips), în care sunt implementate doar două niveluri de privilegii. Versiunile anterioare ale Windows NT au suportat aceste arhitecturi, dar Windows 2000 a rămas doar x86.
Componentele din modul utilizator au propriile lor spații de adrese protejate firele de execuție ale acestor procese rulează în modul procesor neprivilegiat (numit mod utilizator), nu pot executa comenzi de procesor privilegiat, au acces limitat și indirect la datele de sistem și la spațiul de adrese de sistem și nu au acces direct la hardware. Adevărat, în timpul lucrului lor, firele de execuție ale acestor procese, care apelează servicii de sistem, trec în modul kernel, dar în acest caz își pierd complet controlul asupra execuției până la revenirea în modul utilizator.
Procesele în modul utilizator sunt considerate potențial periculoase din punct de vedere al stabilității sistemului. Drepturile lor sunt limitate. Și orice încercare de a depăși aceste restricții sunt aspru suprimate.
Componentele kernelului partajează un singur spațiu de adresă, se execută în modul procesor privilegiat (numit mod kernel), pot executa toate instrucțiunile procesorului, inclusiv pe cele privilegiate, au acces direct și nerestricționat la datele și codul sistemului și au acces direct sau prin HAL la echipamentul.
Codul nucleului (de fapt, acesta este sistemul în sine) este considerat complet de încredere. Prin urmare, odată încărcat în spațiul de adrese ale sistemului, driverul devine parte a sistemului și nu este supus niciunei restricții.
Astfel, aplicațiile utilizatorului sunt separate de sistemul de operare în sine. Dacă ți-ai propus să scrii orice aplicație serioasă care necesită acces la funcțiile interne sau structurile de date ale sistemului, vei întâlni multe limitări care pot fi depășite doar prin plasarea codului tău în spațiul de adrese ale sistemului. Există o singură modalitate documentată de a face acest lucru - instalați driverul dispozitivului. Această metodă este relativ simplă, fiabilă și, cel mai important, este pe deplin susținută de sistemul de operare în sine.
Drivere Windows 2000
Windows 2000 acceptă multe tipuri de drivere de dispozitiv.
Există două de bază care au reprezentanții lor:
- Drivere pentru modul utilizator:
- Virtual Device Drivers (VDD) - utilizate pentru a suporta programe MS-DOS (a nu se confunda cu driverele VxD din Windows 95/98 - acestea sunt lucruri complet diferite, deși au același nume);
- Drivere de imprimantă.
- Drivere pentru modul Kernel:
- Drivere de sistem de fișiere - implementați I/O pe unitățile locale și de rețea;
- Drivere vechi - scrise pentru versiunile anterioare de Windows NT;
- Drivere de adaptoare video (Video Drivers) - implementează operații grafice;
- Drivere de streaming - implementează intrare/ieșire video și audio;
- Drivere WDM (Model de driver Windows, WDM) - acceptă tehnologia Plug and Play și gestionarea energiei. Caracteristica lor distinctivă este compatibilitatea la nivel de cod sursă între Windows 98, Windows ME și Windows 2000.
În diferite surse s-ar putea să întâlniți o clasificare ușor diferită de cea dată mai sus, acest lucru nu este important. Important este că piloții pe care îi vom scrie nu se încadrează în niciunul dintre punctele din acest clasament. Acestea nu sunt nici drivere de sistem de fișiere, nici drivere vechi, nici drivere pentru adaptoare video sau plăci de sunet, nici drivere WDM, deoarece nu acceptă Plag"n"Play și gestionarea energiei. Acestea nu sunt drivere pentru modul utilizator (asta nu este deloc interesant). De fapt, doar diavolul știe ce este, pentru că... sistemul în sine vă permite să adăugați cu ușurință și pur și simplu cod pentru un dispozitiv necunoscut și să faceți ce doriți cu el! E ca și cum un complet străin ți-ar fi bătut la ușă noaptea și, fără să spui un cuvânt, l-ai lăsat să intre peste noapte și chiar l-ai pus în patul tău! Cu toate acestea, acesta nu este un fel de bug sau gaură de securitate. Sistemul funcționează așa cum o face. Nu poate fi altfel, pentru că... interacționând cu mediul înconjurător, sistemul este forțat să ofere acces la sine. Și dacă nu ar fi așa, atunci ar fi un sistem complet închis și, prin urmare, inutil.
După cum sugerează și numele, un driver de dispozitiv este un program conceput pentru a controla un dispozitiv, iar acest dispozitiv nu trebuie să fie neapărat fizic. Poate fi logic sau, ca în cazul nostru, virtual.
În structura sa, un driver de dispozitiv nu este altceva decât un fișier în format PE (Portable Executable, PE). La fel ca exe și dll obișnuite. Se încarcă și funcționează conform diferitelor reguli. Driverele pot fi considerate ca DLL-uri în modul kernel concepute pentru a îndeplini sarcini care nu pot fi efectuate în modul utilizator. Diferența fundamentală aici (fără a socoti nivelul de privilegii) este că nu vom putea accesa direct driverul, nici codul și nici datele acestuia, ci vom folosi un mecanism special furnizat de Managerul de Input/Output. Managerul I/O oferă mediul de funcționare a driverelor și oferă, de asemenea, mecanisme de încărcare, descărcare și gestionare a acestora.
Când începeți să dezvoltați drivere pentru modul kernel, vă veți simți ca un începător complet, deoarece... Toată experiența anterioară de utilizare a API-ului nu va ajuta aici - nucleul oferă un set complet diferit de funcții. De asemenea, va trebui să utilizați funcții și structuri de date slab documentate (definite doar în fișierele antet) sau complet nedocumentate.
Drivere cu un singur și mai multe niveluri
Majoritatea driverelor care controlează dispozitivele fizice sunt drivere stratificate. Procesarea unei cereri I/O este partajată între mai mulți drivere. Fiecare își face partea lui din treabă. De exemplu, o solicitare de citire a unui fișier este trimisă la driverul sistemului de fișiere, care, după efectuarea unor operațiuni (de exemplu, împărțirea cererii în mai multe părți), o transmite „în aval” driverului de disc, care, la rândul său, trimite cererea șoferului de autobuz. În plus, între aceste drivere puteți adăuga orice număr de drivere de filtru (de exemplu, criptarea datelor). După ce a executat o solicitare, driverul de nivel inferior își transmite rezultatele „în sus” șoferului de nivel superior. Dar, din fericire, totul va fi mult mai simplu pentru noi. Driverele noastre vor fi întotdeauna drivere monolitice, ceea ce va simplifica foarte mult întregul proces de scriere și depanare a acestora.
Contextul firului
Întrucât, în cele mai multe cazuri, avem un singur procesor, și sunt multe aplicații care trebuie executate, este firesc ca pentru a crea iluzia execuției lor simultane, aceste aplicații trebuie conectate secvențial la procesor, și foarte repede. Această procedură se numește schimbarea contextului firelor. Dacă sistemul comută contextul firelor care aparțin aceluiași proces, atunci este necesar să salvați valoarea registrelor procesorului firului deconectat și să încărcați valorile salvate anterior ale registrelor procesorului ale firului conectat. Și actualizați unele structuri de date. Dacă firul de execuție conectat aparține unui alt proces, atunci este necesar să încărcați indicatorul către directorul de pagină al procesului în registrul CR3 al procesorului. Deoarece fiecare proces utilizator este prevăzut cu un spațiu de adrese închis, diferite procese au proiecții diferite ale spațiilor de adrese și, prin urmare, diferite directoare de pagini și seturi de tabele de pagini prin care procesorul traduce adresele virtuale în adrese fizice. Toate acestea nu sunt direct legate de programarea driverului. Dar vă reamintesc acest lucru în legătură cu aceasta. Deoarece schimbarea contextului nu este cea mai rapidă operațiune, driverele, din motive de performanță mai bună, de obicei nu își creează propriile fire. Dar codul driverului trebuie încă executat. Prin urmare, pentru a economisi timp la schimbarea contextului, driverele rulează în modul kernel în unul dintre cele trei contexte:
- în contextul firului de utilizare care a inițiat cererea I/O;
- în contextul unui fir de sistem în modul kernel (aceste fire aparțin procesului System);
- ca urmare a unei întreruperi (și, prin urmare, nu în contextul vreunui proces sau fir care rula în momentul întreruperii).
Nu prea înțeleg cum poți face ceva „nu în contextul niciunui proces sau fir”, dar având în vedere autoritatea oamenilor care au scris acest lucru (D. Solomon și M. Russinovici), precum și faptul că nu Nu am nevoie de asta, pentru că. Nu vom procesa nici întreruperile software, nici mai ales hardware, puteți uita imediat de cel de-al treilea caz. Primele două variante rămân. Dacă se inițiază o solicitare I/O, atunci ne aflăm în contextul firului de execuție care a inițiat această solicitare și, prin urmare, putem accesa direct spațiul de adrese al procesului căruia îi aparține acest thread. Dacă ne aflăm în contextul unui thread de sistem, atunci nu putem accesa direct niciun proces utilizator, dar putem accesa întotdeauna unul de sistem. Dacă trebuie să vedeți din driver ce are un proces la o astfel de adresă, va trebui fie să schimbați singur contextul, fie să traduceți adresele folosind tabelele de pagini.
Niveluri de solicitare de întrerupere
Întreruperea este o parte integrantă a oricărui sistem de operare. O întrerupere necesită procesare, astfel încât execuția codului curent se oprește și controlul este transferat la manipulatorul de întreruperi. Există atât întreruperi hardware, cât și software. Întreruperile sunt deservite în funcție de prioritatea lor. Windows 2000 utilizează o schemă de prioritate de întrerupere cunoscută sub numele de niveluri de solicitare de întrerupere (IRQL). Există 32 de niveluri în total, de la 0 (pasiv), care are cea mai mică prioritate, până la 31 (high), care are cea mai mare prioritate. Mai mult, întreruperile de la IRQL=0 (pasiv) la IRQL=2 (DPC\dispatch) sunt software, iar întreruperile de la IRQL=3 (dispozitiv 1) la IRQL=31 (high) sunt hardware. Nu confundați nivelurile de prioritate de întrerupere cu nivelurile de prioritate ale firelor - sunt lucruri complet diferite. O întrerupere cu nivelul IRQL=0, strict vorbind, nu este o întrerupere, deoarece nu poate întrerupe funcționarea niciunui cod (la urma urmei, pentru a face acest lucru, acest cod trebuie să fie executat la un nivel de întrerupere și mai mic, dar nu există un astfel de nivel). Firele în modul utilizator se execută pe acest IRQL. Și codul nostru de driver va rula și pe acest IRQL. Acest lucru nu înseamnă că orice cod de driver este întotdeauna executat la nivel „pasiv”. Doar că nu ne vom ocupa nici de întreruperile software sau, mai ales, de hardware. Și de aici rezultă cel puțin două concluzii foarte importante.
În primul rând: munca driverelor noastre poate fi întreruptă oricând pentru a procesa o întrerupere cu o prioritate mai mare (de exemplu, de la un cronometru, când planificatorul consideră că thread-ul nostru are deja procesorul de mult timp și este timpul ca acesta să fie odihnă). Prin urmare, în acest sens, codul driverelor noastre este întreruptibil și preemptibil (procesorul este dat unui alt thread), la fel ca codul oricărui thread de utilizator. Există funcții ale nucleului care vă permit să aflați nivelul actual de întrerupere, precum și să îl ridicați sau să îl reduceți.
Al doilea punct important: la nivel de întrerupere pasivă, puteți apela orice funcții ale nucleului (în DDK, descrierea fiecărei funcții trebuie să indice la ce nivel de întrerupere poate fi apelată) și, de asemenea, să accesați paginile de memorie șterse în fișierul swap. La niveluri de întrerupere mai mari (DPC/dispath și mai mari), o încercare de a accesa o pagină care nu se află în memoria fizică duce la o blocare a sistemului, deoarece Managerul de memorie nu poate gestiona o eroare de pagină.
"Ecranul albastru al morții"
Cred că toată lumea, cel puțin o dată, a văzut o imagine captivantă numită „Ecranul albastru al morții” (BSOD). Probabil că nu este nevoie să explici ce este și de ce apare. Lucrul important aici este că atunci când începeți să dezvoltați drivere pentru modul kernel, pregătiți-vă pentru faptul că BSOD va apărea destul de des pe ecranul monitorului.
În al treilea inel, totul a fost simplu: am schițat codul aproximativ, am plasat int3 acolo unde a fost necesar, l-am lansat și... în depanator înțelegi deja ce este. Dacă ceva nu este în regulă, l-am reparat, am corectat erori, am recompilat... și așa mai departe până când codul funcționează așa cum trebuie. Când programați drivere, puteți uita de această tehnică. Aici „saperul” greșește o dată. O mișcare greșită... și poți să stai pe spate și să te relaxezi un minut.
Pentru a vedea BSOD cât mai rar posibil, ar trebui să respectați o regulă foarte simplă: „Măsurați de șapte ori - tăiați o dată”... în sensul „Verificați de șapte ori - rulați o dată”. Desigur, acest lucru este ușor de spus, dar mult mai dificil de făcut. Dar, de regulă, având în vedere că structura driverelor pe care le veți scrie (după ce citiți aceste articole) este relativ simplă, puteți face față erorilor înainte de apariția BSOD-ului. Dacă apare în mod persistent în fața ochilor tăi și nu poți înțelege motivul, o posibilă modalitate de a clarifica situația este analizarea depozitului de accident. Puteți citi despre ce este, cum să o faceți și să o analizați în articolul lui Mark Russinovici „Analiza depozitelor de memorie de blocare” http://www.osp.ru/win2000/2001/03/025.htm. Această chestiune (analiza) este foarte dificilă, dar cred că nu se va ajunge la asta.
Sunt un teoretician teribil, așa că puteți considera toate cele de mai sus drept informații de bază despre principiile care sunt absolut necesare pentru a le înțelege. Nu puteți începe să dezvoltați drivere pentru modul kernel fără a înțelege ce este contextul unui fir, nivelurile de întrerupere și prioritățile firului, modul kernel/utilizator etc. și așa mai departe. Dacă nu sunteți sigur de o problemă - lista de referințe este mai jos.
Acum să acoperim câteva lucruri mai practice (vor deveni foarte practice în articolele următoare), și anume, de ce avem nevoie pentru a transforma toată această teorie în practică.
Kit de dezvoltare a driverului
Primul este, desigur, Device Driver Development Kit (Windows 2000 Driver Development Kit, 2KDDK), care poate fi descărcat gratuit de pe site-ul Microsoft (în orice caz, l-am descărcat complet gratuit de aici: http:// www.microsoft.com/ddk/). Acest pachet include documentație care este o sursă bogată de informații despre structurile de date interne și funcțiile la nivel de sistem utilizate de driverele de dispozitiv.
În plus față de documentație, DDK include un set de fișiere de bibliotecă (*.lib) care vor fi absolut necesare la conectarea. DDK include două seturi de aceste fișiere: pentru versiunea finală de Windows (numită versiune gratuită); și pentru dezvoltare (numită build verificată). Aceste fișiere sunt localizate în directoarele %ddk%\libfre\i386 și, respectiv, %ddk%\libchk\i386. Versiunea de depanare are o verificare mai strictă a erorilor. Trebuie să utilizați fișierele corespunzătoare versiunii sistemului dvs., plasându-le în directorul \masm32\lib\w2k.
Fișiere incluse
De asemenea, vom avea nevoie să includem fișiere (*.inc) cu definiții de prototip de funcție. Noi (mai precis, eu) va trebui să le facem și noi. Am încercat multe utilități diferite care convertesc *.lib -> *.inc, ambele incluse în pachetul masm32 by hutch, și cele pe care le-am scurs în momente diferite din vastele întinderi ale Internetului. Dintre toate cele pe care le am, doar protoize.exe de la f0dder a făcut față sarcinii sale și practic nu a trebuit să editez nimic manual. Acest instrument minunat va fi localizat în directorul \tools\protoize. Site-ul autorului: http://f0dder.didjitalyphrozen.com/. Dar nu o vei găsi acolo. f0dder a postat acest utilitar de mai multe ori în cadrul conferinței http://board.win32asmcommunity.net/. Includes vor fi localizate în directorul \include\w2k. Acestea ar trebui să fie plasate în directorul \masm32\include\w2k. Pentru conversie, am folosit *.lib pentru lansarea gratuită a Windows 2000, deoarece aceasta este versiunea pe care o am (și probabil și tu).
Următoarea problemă este mai gravă. Aceasta este o absență aproape completă a fișierelor include cu definiții ale structurilor necesare, constantelor simbolice și macrocomenzi. Este puțin probabil să găsiți ceva util pe Internet - aceasta este o activitate prea exotică - să scrieți drivere pentru modul kernel în assembler. Unele pot fi găsite la EliCZ http://www.anticracking.sk/EliCZ/. Ceva de pe Y0da http://mitglied.lycos.de/yoda2k/index.htm (parțial făcut de el, parțial preluat din același EliCZ). Dar acest lucru a fost făcut extrem de prost (cu tot respectul meu profund pentru colegii noștri slovaci și germani): numele membrilor multor structuri diferă de cele definite în fișierele de antet originale din DDK; structurile imbricate și uniunile nu au nume; deşi în original sunt denumite. Și, în general, totul este într-o oarecare dezordine, iar atunci când este privit, dă o impresie deprimantă. Doar ntstatus.inc este bine făcut. Acest lucru se datorează parțial faptului că EliCZ a început să-și creeze incluziunile chiar și fără DDK (cum spune el însuși). În orice caz, nu vă sfătuiesc să le folosiți, cel puțin fără o testare atentă. La un moment dat, a apărut ceva în conferința http://board.win32asmcommunity.net/, dar nici calitatea nu este deosebit de impresionantă. Pe scurt, singura soluție corectă în această situație este să faceți totul singur și manual, deoarece nu cunosc niciun instrument care vă permite să automatizați acest proces. Dacă dai brusc peste ceva care merită și nu crezi că este prea multă problemă, anunțați-mă.
Depanare drivere
Avem nevoie și de un depanator și, deoarece va trebui să depanăm codul modului kernel, avem nevoie de un depanator adecvat. Cea mai bună alegere ar fi SoftICE. Sau puteți utiliza Kernel Debugger-ul inclus în DDK. Acest depanator necesită două computere - un master și un slave, pe care nu și le poate permite toată lumea. Mark Russinovich (http://www.sysinternals.com/) a scris un utilitar numit LiveKd, care vă permite să utilizați Kernel Debugger fără a conecta un al doilea computer. Nu știu dacă este pe site (nu am verificat), dar este pe disc pentru cartea „Dispozitive interne ale Microsoft Windows 2000”. Acest depanator este, de asemenea, extrem de util pentru examinarea elementelor interne ale unui sistem, cu condiția să aveți instalate simboluri de depanare, care pot (sau ar putea) fi descărcate gratuit de pe site-ul Microsoft.
David Solomon, Mark Russinovich, „The Internals of Microsoft Windows 2000”, ed. „Petru”, 2001. Deși această carte nu conține o singură linie de cod sursă, este în primul rând pentru programatori.
Sven Schreiber, „Caracteristicile nedocumentate ale Windows 2000”, ed. „Petru”, 2002. O carte pur practică care dezvăluie multe dintre secretele Windows 2000.
Walter Oney, „Programarea modelului de driver Microsoft”, Microsoft Press, 1999 În această carte, accentul este pus pe driverele Plag"n"Play, dar acest lucru nu îi diminuează în niciun fel meritele, deoarece Principiile de bază ale dezvoltării șoferului sunt universale.
Jeffrey Richter, „Windows for Professionals: Building Powerful Win32 Applications with Specifics of 64-Bit Windows”, ed. „Petru”, 2000. Această carte nu are nicio legătură directă cu programarea driverelor, dar este și foarte interesantă ;-)
Această listă nu se dorește în niciun caz să fie completă. Multe, mai ales în limba engleză, pot fi găsite pe Internet (cu excepția lui Schreiber, toate cărțile sunt disponibile în format electronic). În ceea ce privește cărțile, aș vrea să spun și că toate sunt „must have”. Vezi tu - cumpără fără să te uiți. Toate, cu excepția lui Walter Oney, sunt traduse în „mare și puternic”.
Și un ultim lucru. Nu sunt un mare expert în domeniul dezvoltării driverelor, așa că erorile sau inexactitățile, atât în acest articol, cât și în toate articolele ulterioare, sunt foarte probabile. Dacă îl găsești, nu ezita să-ți bagi nasul. Îți voi spune mulțumesc.
Microsoft acordă o mare atenție securității în sistemul de operare Windows 10. Unul dintre elementele importante ale sistemului este Windows Defender, dar nu este capabil să facă față tuturor amenințărilor. În special, virușii ransomware s-au răspândit recent în mod deosebit, dintre care cele mai faimoase reîncarnări sunt Petya și . Microsoft a introdus funcții de izolare a nucleului și de integritate a memoriei în Windows 10, care au ca scop combaterea virușilor ransomware. În mod implicit, acestea sunt dezactivate.
Cuprins:Ce este izolarea nucleului și integritatea memoriei
Izolarea nucleului este un proces suplimentar de protecție care este furnizat printr-o metodă de izolare a proceselor computerului de sistemul de operare și dispozitiv. Datorită acestor acțiuni, este posibil să se evite subminarea funcționării sistemului de operare atunci când virușii intră în computer.
Integritatea memoriei- Aceasta este o funcție de protecție care însoțește izolarea nucleului, care are ca scop limitarea accesului programelor necunoscute potențial periculoase la procese cu un nivel ridicat de securitate.
Important: Funcția de izolare a nucleului poate funcționa numai dacă există condiții suficiente pentru aceasta din hardware-ul computerului. În setările BIOS, tehnologia de virtualizare trebuie să fie activă, datorită căreia un computer care rulează Windows 10 poate rula diverse aplicații într-un container virtual, limitând accesul acestora de la componentele cheie ale sistemului.
Cum să activați izolarea nucleului și integritatea memoriei
Setările sistemului de operare Windows 10 vă permit să controlați pe deplin funcțiile de securitate de pe computer. Prin setările Windows 10, puteți activa izolarea nucleului și integritatea memoriei după cum urmează:
După cum sa menționat mai sus, dacă hardware-ul computerului nu acceptă virtualizarea, această funcție nu va funcționa. Când este pornit, utilizatorul va vedea în colțul din dreapta jos mesajul „Integritatea memoriei nu poate fi asigurată. Posibilă incompatibilitate.” Dacă apare acest mesaj, este recomandat să mergeți la BIOS și să vedeți dacă funcția Secure Boot (Boot Mode) este activată.
Cum să dezactivați izolarea nucleului și integritatea memoriei
Caracteristicile noi ale sistemului de operare care îi afectează grav funcționarea riscă întotdeauna să provoace probleme cu funcționarea computerului. Funcția de izolare a nucleului nu face excepție. Utilizatorii care l-au încercat deja notează pe forumurile Microsoft că întâmpină probleme la lansarea unui număr de jocuri și programe. Singura modalitate de a rezolva această problemă este să dezactivați izolarea nucleului și integritatea memoriei. Poate dezvoltatorii de aplicații sau Microsoft vor corecta această incompatibilitate în actualizările viitoare.
Există 3 moduri de a dezactiva izolarea nucleului și integritatea memoriei:
În laptopul meu principal, apar frecvent diverse probleme de alimentare, care pot fi explicate lucrând în versiuni interne. Cu toate acestea, chiar și în versiunea stabilă 1803, am observat că sistemul meu a încetat să intre în somn. În acest caz, monitorul s-a oprit după o anumită perioadă de timp, ceea ce a sugerat că sistemul determină corect starea de inactivitate.
Am stabilit o scurtă perioadă de tranziție la somn, 1-2 minute, și am început diagnosticarea.
Verificarea cererilor către subsistemul de alimentare de la aplicații și drivere
Primul lucru pe care trebuie să-l faci este să te uiți la powercfg, care împiedică sistemul de operare să intre în repaus. Procesele și driverele care accesează subsistemul de alimentare pot fi văzute în promptul de comandă ca administrator:
Powercfg-cereri
Este imediat clar că solicitarea către SYSTEM vine de la DRIVER - în acest caz, Realtek folosește un flux audio.
WebRTC din Chrome poate fi prezent și în listă, iar imediat după ce sistemul este repornit, puteți vedea solicitările de optimizare a descărcarii și un index de căutare, dar acestea dispar rapid. Puteți adăuga un proces sau un driver la lista de excepții și nu îl va împiedica să intre în repaus.
Powercfg -requestsoverride DRIVER „Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)”
Comanda citește „ignora cererea de la DRIVER [numele complet al driverului] către SYSTEM”.
Lista excepțiilor este stocată în cheia de registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerRequestOverride
și este scos de comandă
Powercfg -requestsoverride
Am repornit pentru a fi sigur, dar sistemul a refuzat să intre în somn. După ce am verificat excepțiile și lista de interogări, am constatat că driverul Realtek a continuat să folosească fluxul audio, chiar dacă a fost inclus în excepții.
Am dansat puțin în jurul excepțiilor, dar nu am avut succes. Un Google rapid a confirmat că în unele cazuri nu funcționează. Acest lucru este tipic pentru solicitările vechi, dar a existat un alt caz și nu sunt primul care a întâlnit acest lucru.
Am ajuns să elimin Realtek din listă. Puteți șterge intrări în Editorul Registrului sau în Consolă. Comanda este aproape aceeași ca și atunci când adăugați, pur și simplu nu indică unde merge cererea, adică. în acest caz, nu există SISTEM la sfârșitul comenzii:
Powercfg -requestsoverride DRIVER „Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)”
Vom merge pe alt drum
Calculați un proces care utilizează subsistemul audio
Se știe că driverul Realtek face treaba murdară. Evident, este încărcat la pornirea sistemului, așa că numele fișierului este ușor de aflat folosind Autoruns.
Trei intrări se referă la două fișiere, dintre care unul este un panou de control, judecând după nume. Prin urmare, obiectul de interes a devenit ravbg64.exe.