Ядро оқшаулау – интеллектуалды шабуылдардан қорғаудың қосымша қабатын қамтамасыз ететін виртуализацияға негізделген қауіпсіздік технологиясы. Жадтың тұтастығы ядроны оқшаулау технологиясының бөлігі болып табылады, бұл мүмкіндік зиянды кодтың жоғары қауіпсіз процестерге енгізілуін болдырмауға арналған. Қорғау ядроның виртуалды жады беті тұтастығын тексеруден сәтті өткеннен кейін ғана орындала бастайтындығымен қамтамасыз етіледі.
Компьютеріңіздің қауіпсіздігін күшейту үшін Windows 10 2018 жылғы сәуір жаңартуында жад тұтастығы мүмкіндігін қосу жолын қарастырайық.
Жад тұтастығын қосу
- Windows Defender қауіпсіздік орталығын ашыңыз.
- «Құрылғы қауіпсіздігі» бөлімін таңдаңыз.
- «Ядро оқшаулау» бөлімінде «Ядро оқшаулау мәліметтері» сілтемесін басыңыз.
- «Жад тұтастығы» қосқышын белсенді күйге жылжытыңыз.
Осы қадамдарды орындағаннан кейін өзгертулер күшіне енуі үшін компьютерді қайта іске қосу керек.
Ескерту: Бұл мүмкіндік жұмыс істеуі үшін процессорыңыз виртуализация технологияларын қолдауы керек. Сонымен қатар, виртуализация BIOS немесе UEFI жүйесінде қосылуы керек. Әйтпесе, функция қол жетімді болмайды.
Ядроды оқшаулау мәселелерін шешу
Кейбір жағдайларда, ядро оқшаулауы қосылған болса, кейбір қолданбаларда үйлесімділік мәселелеріне тап болуыңыз мүмкін. Мәселені шешу үшін функцияны өшіру керек.
Windows Defender қауіпсіздік орталығында жад тұтастығын өшіруге әрекеттенсеңіз, бірақ опция сұр түске боялып, «Бұл параметрді әкімшіңіз басқарады» хабарын көрсеңіз, тізілім арқылы мүмкіндікті өшіре аласыз.
Ескерту: Тізілімді қате өзгерту күрделі мәселелерге әкелуі мүмкін. Осы қадамдарды орындамас бұрын Windows тізілімінің сақтық көшірмесін жасау ұсынылады. Сақтық көшірмені сақтау үшін Тізбе өңдегіші мәзірінен Файл > Экспорттау тармағын таңдаңыз.
- Іске қосу терезесін ашу үшін Windows + R пернелер тіркесімін басыңыз.
- Registry редакторын іске қосу үшін regedit деп теріп, OK түймесін басыңыз.
- Келесі жолға өтіңіз:
- Жазбаны екі рет басыңыз Қосылған.
- Мәнді 1-ден 0-ге өзгертіңіз.
- OK түймесін басыңыз.
Өшіру үшін сіз дайынды да пайдалана аласыз
Қуат менеджері бүкіл жүйеде қуат тұтынуды қадағалайды. Тарихи түрде қуатты басқару мониторды өшіру және диск жетектерінің айналуын тоқтатудан тұрды. Бірақ бұл мәселе тез арада күрделене түсуде – ноутбуктердегі батареяның ұзағырақ қызмет ету мерзіміне қойылатын талаптарға, сондай-ақ жұмыс үстелі компьютерлеріндегі энергияны үнемдеуге қатысты ойларға (олар үнемі қосылып тұрады) және сервер фермалары тұтынатын қуаттың жоғары құнына байланысты.
Қуатты басқарудың жаңа мүмкіндіктері жеке құрылғыларды артық күйге ауыстыру немесе тіпті оларды толығымен өшіру (қуат қосқышын пайдалану) арқылы жүйе пайдаланылмаған кезде құрамдас қуат тұтынуды азайтуды қамтиды. Мультипроцессорлық жүйелер жеке процессорларды қажетсіз жағдайда өшіреді, тіпті процессорлардың тактілік жиілігін азайтады (қуатты тұтынуды азайту үшін). Процессор жұмыс істемей тұрғанда, оның қуат тұтынуы да азаяды, өйткені оған үзіліс болғанша күтуден басқа ештеңе істеудің қажеті жоқ.
Windows жүйесі күту күйі деп аталатын арнайы өшіру режимін қолдайды, ол барлық физикалық жадты дискіге көшіреді, содан кейін батареяны аз зарядтаумен қуат тұтынуды минимумға дейін азайтады (ноутбуктер күту күйінде апта бойы жұмыс істей алады). Бүкіл жад күйі дискіге жазылғандықтан, тіпті ноутбуктың батареясын ауыстыруға болады (ол күту күйінде болғанда). Жүйе күту күйінен шыққанда, ол сақталған жад күйін қалпына келтіреді (және құрылғыларды қайта инициализациялайды). Бұл компьютерді күту күйіне дейінгі күйге қояды (жұмыс істеп тұрған барлық қолданбалар мен қызметтерді қайта тіркеп, іске қоспай-ақ. Windows өзгертілмеген беттерді (дискіде сақтық көшірмесі жасалған)) елемеу арқылы бұл процесті оңтайландыруға тырысады. және қажетті енгізу/шығару көлемін азайту үшін қалған жад беттерін қысады. Күту күйі алгоритмі жүйенің енгізу/шығару өткізу қабілетіне қажеттілікті азайту үшін жүйенің өткізу қабілетін автоматты түрде теңестіреді, бірақ сонымен бірге деректерді қысу: жеткілікті Енгізу/шығару өткізу қабілеттілігі күту режиміне кіру кезінде қысуды болдырмауға мүмкіндік береді. Мультипроцессорлардың соңғы буынында күту күйіне кіру және шығу, тіпті жүйеде оперативті жадының үлкен көлемі болса да, бірнеше секундты алады.
Күту күйіне балама қуат реттеушісі бүкіл жүйені төменірек қуат тұтыну күйіне ауыстыратын күту режимі болып табылады (динамикалық жад күйін қалпына келтіру үшін жеткілікті қуатты пайдаланады). Жадты дискіге көшірудің қажеті жоқ болғандықтан, бұл күйге кіру кейбір жүйелердегі күту күйіне қарағанда жылдамырақ.
Күту және күту күйлерінің болуына қарамастан, көптеген пайдаланушылар жұмысты аяқтағаннан кейін дербес компьютерді өшіру әдетінен арыла қойған жоқ.
Күту күйі Windows жүйесінде HiberBoot деп аталатын жалған іске қосуды өшіруді орындау үшін пайдаланылады, ол қалыпты өшіру мен іске қосудан әлдеқайда жылдамырақ. Пайдаланушы жүйені өшіруге пәрмен бергенде, HiberBoot пайдаланушыны жүйеден шығарады, содан кейін жүйені қалыпты түрде қайта кіруге болатын жерде күту күйіне қояды. Кейінірек, пайдаланушы жүйені қайта қосқанда, HiberBoot жүйені пайдаланушының кіру нүктесінен жалғастырады. Пайдаланушы үшін мұның бәрі өте жылдам өшіру сияқты сезіледі, өйткені жүйені инициализациялау қадамдарының көпшілігі өткізілмейді. Әрине, кейде ақауларды жою немесе ядро жаңартуын орнату үшін жүйені шынымен өшіру қажет. Жүйеге өшіру орнына қайта іске қосу пәрмені берілсе, ол шынайы өшіруге шыдайды және қалыпты жүктеуді орындайды.
Телефондар мен планшеттердегі есептеу құрылғылары, сондай-ақ ноутбуктердің жаңа буындары әрқашан қуатты аз мөлшерде тұтынады деп күтілуде. Бұл режимді қамтамасыз ету үшін заманауи Windows жүйесі CS (қосылған күту режимі) деп аталатын қуатты басқарудың арнайы нұсқасын жүзеге асырады. CS процессорды іске қосуға қарағанда әлдеқайда аз қуатты пайдаланып қосылымдардың шағын жиынтығы бойынша трафикті бақылай алатын арнайы желілік қосылым аппаратурасы бар жүйелерде мүмкін. CS жүйесі үнемі қосулы болады, CS пайдаланушы экранды қосқанда бірден шығады. Қосылған режимдегі ұйқы қалыпты ұйқы режимінен ерекшеленеді, себебі CS жүйесі бақыланатын қосылымнан пакетті алған кезде де оянады. Батарея заряды таусыла бастағанда, CS жүйесі батареяның толық бітуін және пайдаланушы деректерінің ықтимал жоғалуын болдырмау үшін күту күйіне өтеді.
Батареяның ұзақ қызмет ету мерзіміне қол жеткізу процессорды мүмкіндігінше жиі өшіріп қана қоймайды. Сондай-ақ процессорды мүмкіндігінше ұзақ уақыт өшіру маңызды. CS жүйесінің желілік жабдығы процессорларға деректер келгенше өшірулі күйінде тұруға мүмкіндік береді, бірақ басқа оқиғалар процессордың қайта қосылуына себеп болуы мүмкін. NT негізіндегі Windows құрылғы драйверлерінің, жүйелік қызметтерінің және қолданбаларының өзі көбінесе ешбір себепсіз, жай заттардың күйін тексеру үшін іске қосылады. Бұл сұрау әрекеті әдетте жүйеде немесе қолданбада кодты мерзімді түрде іске қосу үшін таймерлерді орнатуға негізделген. Таймер сигналдарына негізделген сұрау процессорға қатысты оқиғаларды шатастыруы мүмкін. Бұған жол бермеу үшін қазіргі заманғы Windows операциялық жүйеге таймер оқиғаларын біріктіруге және процессор үшін бөлек іске қосу уақыттарының санын азайтуға мүмкіндік беретін қателер шегін көрсету үшін осындай таймерлерді талап етеді. Windows сонымен қатар белсенді жұмыс істемейтін бағдарлама фондық режимде кодты орындай алатын шарттарды анықтайды. Жаңартуларды тексеру немесе мазмұнды жаңарту сияқты әрекеттерді тек таймердің мерзімі өткеннен кейін іске қосу сұралғанда орындау мүмкін емес. Қолданба мұндай фондық әрекетке қатысты операциялық жүйеге кейінге қалдыруы керек. Мысалы, жаңартуларды тексеру күніне бір рет немесе құрылғының батарея заряды келесі жолы болуы керек. Жүйе прокси-серверлерінің жинағы фондық әрекетті шектеу үшін пайдаланылуы мүмкін әртүрлі шарттарды қамтамасыз етеді. Фондық тапсырма арзан желіге кіруді немесе пайдаланушы рұқсаттарын талап етсе, қажетті шарттар болғанша прокси-серверлер тапсырманы орындамайды.
Бүгінгі таңда көптеген қосымшалар жергілікті кодпен де, бұлтта орналасқан қызметтермен де жүзеге асырылады. Windows жүйесі Windows хабарландыру қызметін (WNS) қамтамасыз етеді, ол үшінші тарап қызметтеріне үшінші тарап серверлерінен пакеттерді арнайы тыңдау үшін CS желілік аппаратурасын қажет етпестен CS жүйесіндегі Windows құрылғысына хабарландыруларды жіберуге мүмкіндік береді. WNS хабарландырулары мәтіндік хабардың немесе VoIP қоңырауының келуі сияқты уақытты қажет ететін маңызды оқиғалар туралы ескертеді. WNS пакеті келгенде, процессор оны өңдеу үшін қосылуы керек, бірақ CS желілік аппаратурасы әртүрлі қосылымдардан трафикті ажырату мүмкіндігіне ие, яғни процессор әрбір кездейсоқ пакетке жауап ретінде қосылуы қажет емес. желі интерфейсінен келеді.
Ядро режимінің драйверлері: 1-бөлім: Негізгі түсініктер - WASM.RU мұрағаты
Архитектураға шолу
Windows 2000 жүйесінің ішкі әлемі адрестік кеңістік тұрғысынан да, сол мекенжай кеңістігінде жұмыс істейтін кодтың құқықтары мен міндеттері бойынша да нақты анықталған шекаралары бар екі бөлікке бөлінген.
Мекенжай кеңістігін бөлу арқылы бәрі таңқаларлық қарапайым. 32 биттік архитектурада қол жетімді барлық төрт гигабайт екі тең бөлікке бөлінген (мен экзотикалық ретінде 4GT RAM баптауын және физикалық мекенжай кеңейтімін өткізбеймін). Төменгі жартысы пайдаланушы режимінің процестеріне арналған, жоғарғы жартысы ядроға жатады.
Құқықтар мен міндеттерді бөлу сәл күрделірек.
Келесі процестер пайдаланушы процестері болып саналады:
- Жүйені қолдау процестері - мысалы, Winlogon жүйеге кіру процесі (\%SystemRoot%\System32\Winlogon.exe ішінде жүзеге асырылады);
- Қызметтік процестер – мысалы, басып шығару спулері;
- Пайдаланушы қолданбалары - бес түрі бар: Win32, Windows 3.1, MS-DOS, POSIX және OS/2;
- Қоршаған ортаның ішкі жүйелері - үш ортаның ішкі жүйелеріне қолдау көрсетіледі: Win32 (\%SystemRoot%\System32\Csrss.exe ішінде енгізілген), POSIX (\%SystemRoot%\System32\Psxss.exe ішінде енгізілген), OS/2 (\%SystemRo жүйесінде енгізілген %\System32\os2ss.exe).
Ядро келесі компоненттерден тұрады:
Атқарушы жүйе – жадты басқару, процестер мен ағындар және т.б.;
- Ядро – ағындарды жоспарлау, үзілістерді және ерекше жағдайларды жіберу және т.б. (\%SystemRoot%\System32\Ntoskrnl.exe ішінде жүзеге асырылады);
- Құрылғы драйверлері – аппараттық құрылғы драйверлері, желі драйверлері, файлдық жүйе драйверлері;
- Аппараттық абстракциялық деңгей (HAL) – жоғарыда аталған үш құрамдас бөлікті аппараттық архитектуралар арасындағы айырмашылықтардан оқшаулайды (\%SystemRoot%\System32\Hal.dll ішінде жүзеге асырылады);
- Терезе және графикалық жүйе - графикалық пайдаланушы интерфейсі (GUI) функциялары (\%SystemRoot%\System32\Win32k.sys ішінде жүзеге асырылады).
Күріш. 1-1. Windows 2000 архитектурасының жеңілдетілген диаграммасы
Пайдаланушы режимі және ядро режимі
Intel x86 процессорларының отбасы төрт артықшылық деңгейін (қорғау сақиналары деп аталады) қолдаса да, Windows тек екеуін пайдаланады: ядро режимі үшін 0 және пайдаланушы режимі үшін 3. Бұл артықшылықтардың тек екі деңгейі жүзеге асырылатын басқа процессорларды (альфа, мипс) қолдауына байланысты. Windows NT жүйесінің алдыңғы шығарылымдары бұл архитектураларды қолдады, бірақ Windows 2000 тек x86 болып қалды.
Пайдаланушы режимінің құрамдас бөліктерінің өздерінің қорғалған адрестік кеңістіктері бар, бұл процестердің ағындары артықшылықсыз процессор режимінде (пайдаланушы режимі деп аталады) жұмыс істейді, артықшылықты процессор командаларын орындай алмайды, жүйелік деректерге және жүйенің мекенжай кеңістігіне шектеулі және жанама қол жеткізе алады және жоқ. аппараттық құралдарға тікелей қол жеткізу. Рас, олардың жұмысы кезінде жүйелік қызметтерді шақыратын осы процестердің ағындары ядро режиміне ауысады, бірақ бұл жағдайда олар пайдаланушы режиміне оралғанша олардың орындалуын бақылауды толығымен жоғалтады.
Жүйе тұрақтылығы тұрғысынан пайдаланушы режимінің процестері ықтимал қауіпті болып саналады. Олардың құқықтары шектелген. Және бұл шектеулерден шығудың кез келген әрекеті қатаң түрде басылады.
Ядро компоненттері бір мекенжай кеңістігін бөліседі, артықшылықты процессор режимінде орындалады (ядро режимі деп аталады), артықшылықты қоса алғанда, процессордың барлық нұсқауларын орындай алады, жүйе деректері мен кодына шектеусіз және тікелей қол жеткізе алады және тікелей немесе HAL арқылы қол жеткізе алады. жабдық.
Ядро коды (шын мәнінде бұл жүйенің өзі) толығымен сенімді болып саналады. Демек, жүйенің мекенжай кеңістігіне жүктелгеннен кейін драйвер жүйенің бір бөлігіне айналады және ешқандай шектеулерге ұшырамайды.
Осылайша, пайдаланушы қолданбалары операциялық жүйенің өзінен бөлінген. Жүйенің ішкі функцияларына немесе деректер құрылымдарына кіруді қажет ететін кез келген маңызды қолданбаны жазуды жоспарласаңыз, кодты жүйенің мекенжай кеңістігіне орналастыру арқылы ғана еңсеруге болатын көптеген шектеулерге тап боласыз. Мұны істеудің бір ғана құжатталған жолы бар - құрылғы драйверін орнату. Бұл әдіс салыстырмалы түрде қарапайым, сенімді және ең бастысы, операциялық жүйенің өзімен толығымен қолдау көрсетеді.
Windows 2000 драйверлері
Windows 2000 құрылғы драйверлерінің көптеген түрлерін қолдайды.
Өз өкілдері бар екі негізгі бар:
- Пайдаланушы режимінің драйверлері:
- Виртуалды құрылғы драйверлері (VDD) - MS-DOS бағдарламаларын қолдау үшін қолданылады (Windows 95/98 жүйесіндегі VxD драйверлерімен шатастырмау керек - бұл атаулары бірдей болса да, мүлдем басқа нәрселер);
- Принтер драйверлері.
- Ядро режимінің драйверлері:
- Файлдық жүйе драйверлері – жергілікті және желілік дискілерге енгізу/шығаруды жүзеге асыру;
- Legacy Drivers – Windows NT жүйесінің алдыңғы нұсқалары үшін жазылған;
- Бейне адаптер драйверлері (Video Drivers) – графикалық операцияларды жүзеге асыру;
- Streaming Drivers – бейне және аудио енгізу/шығаруды жүзеге асыру;
- WDM драйверлері (Windows Driver Model, WDM) - Plug and Play технологиясын және қуатты басқаруды қолдайды. Олардың айрықша ерекшелігі - Windows 98, Windows ME және Windows 2000 арасындағы бастапқы код деңгейінде үйлесімділік.
Әртүрлі дереккөздерде сіз жоғарыда берілгеннен сәл өзгеше классификацияны кездестіруіңіз мүмкін, бұл маңызды емес. Ең бастысы, біз жазатын драйверлер осы классификациядағы тармақтардың ешқайсысына жатпайды. Бұл файлдық жүйе драйверлері де, ескі драйверлер де, бейне адаптер немесе дыбыс картасы драйверлері де, WDM драйверлері де емес, себебі Plag"n"Play және қуатты басқаруды қолдамайды. Бұл пайдаланушы режимінің драйверлері емес (бұл мүлдем қызық емес). Негізі оның не екенін бір Құдай біледі, өйткені... жүйенің өзі сізге белгісіз құрылғының кодын оңай және оңай қосуға және онымен қалағаныңызды жасауға мүмкіндік береді! Түнде бейтаныс адам есігіңізді қағып, бірдеңе айтпастан оны түнімен ішке кіргізіп, тіпті төсегіңізге жатқызған сияқтысыз! Дегенмен, бұл қате немесе қауіпсіздік тесігі емес. Жүйе дәл солай жұмыс істейді. Басқаша болуы мүмкін емес, өйткені... қоршаған ортамен әрекеттесе отырып, жүйе өзіне қол жеткізуді қамтамасыз етуге мәжбүр. Ал егер бұлай болмаса, онда ол толығымен жабық, демек, пайдасыз жүйе болар еді.
Атауының өзі айтып тұрғандай, құрылғы драйвері кейбір құрылғыны басқаруға арналған бағдарлама және бұл құрылғының физикалық болуы міндетті емес. Бұл логикалық немесе біздің жағдайымыздағыдай виртуалды болуы мүмкін.
Құрылымында құрылғы драйвері PE форматындағы файлдан басқа ештеңе емес (Portable Executable, PE). Кәдімгі exe және dll сияқты. Ол әртүрлі ережелерге сәйкес жүктеледі және жұмыс істейді. Драйверлерді пайдаланушы режимінде орындалмайтын тапсырмаларды орындауға арналған ядро режимінің DLL файлдары ретінде қарастыруға болады. Мұндағы түбегейлі айырмашылық (артықшылықтар деңгейін есептемегенде) біз драйверге оның кодын да, деректерін де тікелей ала алмаймыз, бірақ енгізу/шығару менеджері ұсынған арнайы механизмді қолданамыз. Енгізу/шығару менеджері драйверлердің жұмыс істеу ортасын қамтамасыз етеді, сонымен қатар оларды жүктеу, түсіру және басқару механизмдерін қамтамасыз етеді.
Ядро режимі драйверлерін әзірлеуді бастағанда, сіз өзіңізді толық бастаушы ретінде сезінесіз, өйткені... API пайдаланудың барлық алдыңғы тәжірибесі мұнда көмектеспейді - ядро функциялардың мүлдем басқа жиынтығын қамтамасыз етеді. Сондай-ақ нашар құжатталған (тек тақырып файлдарында анықталған) немесе толығымен құжатталмаған функциялар мен деректер құрылымдарын пайдалануға тура келеді.
Бір және көп деңгейлі драйверлер
Физикалық құрылғыларды басқаратын көптеген драйверлер деңгейлі драйверлер болып табылады. Енгізу/шығару сұрауын өңдеу бірнеше драйверлер арасында ортақ. Әркім өз жұмысын атқарады. Мысалы, файлды оқуға сұраныс файлдық жүйе драйверіне жіберіледі, ол кейбір әрекеттерді орындағаннан кейін (мысалы, сұрауды бірнеше бөлікке бөлу) оны диск драйверіне «төмен ағынға» жібереді, бұл өз кезегінде сұранысты автобус жүргізушісіне жібереді. Сонымен қатар, осы драйверлер арасында сүзгі драйверлерінің кез келген санын қосуға болады (мысалы, деректерді шифрлау). Сұранысты орындағаннан кейін төменгі деңгейдегі драйвер оның нәтижелерін жоғары деңгейлі драйверге «жоғары» береді. Бірақ, бақытымызға орай, біз үшін бәрі әлдеқайда қарапайым болады. Біздің драйверлер әрқашан монолитті драйверлер болады, бұл оларды жазу және жөндеудің бүкіл процесін айтарлықтай жеңілдетеді.
Тақырып мәтінмәні
Көп жағдайда бізде бір ғана процессор болғандықтан және оларды орындауды қажет ететін көптеген қосымшалар болғандықтан, олардың бір уақытта орындалу елесін жасау үшін бұл қолданбалар процессорға дәйекті түрде қосылуы керек және өте табиғи нәрсе. тез. Бұл процедура ағынды контекстті ауыстыру деп аталады. Егер жүйе бір процеске жататын ағындардың контекстін ауыстырса, онда ажыратылған ағынның процессор регистрлерінің мәнін сақтау және қосылған ағынның процессор регистрлерінің бұрын сақталған мәндерін жүктеу қажет. Кейбір деректер құрылымдарын жаңартыңыз. Егер қосылған ағын басқа процеске жататын болса, онда процессордың CR3 регистріне процестің бет каталогына көрсеткішті жүктеу қажет. Әрбір пайдаланушы процесі жабық мекенжай кеңістігімен қамтамасыз етілгендіктен, әртүрлі процестерде мекенжай кеңістігінің әртүрлі проекциялары болады, сондықтан процессор виртуалды мекенжайларды физикалық мекенжайларға аударатын әртүрлі бет каталогтары мен бет кестелерінің жиыны. Мұның бәрі драйверлерді бағдарламалауға тікелей қатысты емес. Бірақ осыған байланысты мынаны еске саламын. Мәтінмәнді ауыстыру ең жылдам әрекет болмағандықтан, драйверлер жақсы өнімділік себептері бойынша әдетте өздерінің ағындарын жасамайды. Бірақ драйвер кодын әлі де орындау керек. Сондықтан контекстті ауыстыруға уақытты үнемдеу үшін драйверлер үш контексттің бірінде ядро режимінде жұмыс істейді:
- енгізу/шығару сұрауын бастаған пайдаланушы ағынының контекстінде;
- ядро режимі жүйелік ағынының контексінде (бұл ағындар Жүйе процесіне жатады);
- үзіліс нәтижесінде (сондықтан үзіліс кезінде жұмыс істеп тұрған кез келген процестің немесе ағынның контекстінде емес).
Мен мұны жазған адамдардың (Д. Соломон мен М. Руссинович) беделін, сондай-ақ біз оны «кез келген процестің немесе ағынның контекстінде емес» қалай жасауға болатынын түсінбеймін. бұл қажет емес, өйткені. Біз бағдарламалық құралды да, әсіресе аппараттық үзілістерді де өңдемейміз, сіз үшінші жағдайды бірден ұмыта аласыз. Алғашқы екі нұсқа қалды. Енгізу/шығару сұрауы іске қосылса, біз осы сұрауды бастаған ағынның контекстінде боламыз, сондықтан біз осы ағын жататын процестің мекенжай кеңістігіне тікелей қол жеткізе аламыз. Егер біз жүйелік ағынның контекстінде болсақ, онда біз кез келген пайдаланушы процесіне тікелей қол жеткізе алмаймыз, бірақ біз әрқашан жүйеге қол жеткізе аламыз. Драйверден осындай және осындай мекенжайда қандай да бір процесс бар екенін көру қажет болса, контекстті өзіңіз ауыстыруға немесе бет кестелерін пайдаланып мекенжайларды аударуға тура келеді.
Үзіліс сұрау деңгейлері
Үзіліс кез келген операциялық жүйенің ажырамас бөлігі болып табылады. Үзіліс өңдеуді қажет етеді, сондықтан ағымдағы кодтың орындалуы тоқтатылады және басқару үзіліс өңдеушісіне беріледі. Аппараттық және бағдарламалық қамтамасыз ету үзілістері бар. Үзілулерге олардың басымдылығы бойынша қызмет көрсетіледі. Windows 2000 үзу сұрауының деңгейлері (IRQL) деп аталатын үзу басымдылық схемасын пайдаланады. Ең төменгі басымдыққа ие 0 (пассивті) мен ең жоғары басымдылығы бар 31 (жоғары) деңгейіне дейін барлығы 32 деңгей бар. Сонымен қатар, IRQL=0 (пассивті) бастап IRQL=2 (DPC\dispatch) аралығындағы үзулер бағдарламалық құрал, ал IRQL=3 (құрылғы 1) мен IRQL=31 (жоғары) аралығындағы үзілістер аппараттық құрал болып табылады. Үзіліс басымдылық деңгейлерін ағын басымдылық деңгейлерімен шатастырмаңыз - олар мүлдем басқа нәрселер. IRQL=0 деңгейіндегі үзіліс, нақты айтқанда, үзіліс емес, өйткені ол кез келген кодтың жұмысын тоқтата алмайды (бұл үшін бұл код одан да төмен үзу деңгейінде орындалуы керек, бірақ ондай деңгей жоқ). Пайдаланушы режимінің ағындары осы IRQL-де орындалады. Біздің драйвер коды да осы IRQL-де жұмыс істейді. Бұл кез келген драйвер коды әрқашан «пассивті» деңгейде орындалады дегенді білдірмейді. Біз бағдарламалық жасақтаманы да, әсіресе аппараттық үзілістерді де өңдемейміз. Осыдан кем дегенде екі өте маңызды қорытынды шығады.
Біріншіден: біздің драйверлеріміздің жұмысын жоғары басымдықпен үзуді өңдеу үшін кез келген уақытта үзілуі мүмкін (мысалы, таймерден, жоспарлаушы біздің ағында процессор жеткілікті ұзақ болды деп есептесе және оның уақыты келді. демалыс). Сондықтан, бұл мағынада біздің драйверлердің коды кез келген пайдаланушы ағынының коды сияқты үзілмейтін және басым (процессор басқа ағынға берілген). Ағымдағы үзу деңгейін білуге, сондай-ақ оны көтеруге немесе төмендетуге мүмкіндік беретін ядро функциялары бар.
Екінші маңызды сәт: пассивті үзіліс деңгейінде ядроның кез келген функцияларын шақыруға болады (DDK-де әрбір функцияның сипаттамасы оны қандай үзу деңгейінде шақыруға болатынын көрсетуі керек), сонымен қатар своп файлына тазартылған жад беттеріне қол жеткізуге болады. Үзілістің жоғары деңгейлерінде (DPC/диспат және одан жоғары) физикалық жадта жоқ бетке кіру әрекеті жүйенің бұзылуына әкеледі, себебі Жад менеджері бет ақауын өңдей алмайды.
«Өлімнің көк экраны»
Менің ойымша, барлығы кем дегенде бір рет «Өлімнің көк экраны» (BSOD) деп аталатын қызықты суретті көрді. Мұның не екенін және неге пайда болғанын түсіндірудің қажеті жоқ шығар. Мұнда маңызды нәрсе ядро режимі драйверлерін әзірлеуді бастағанда, BSOD монитор экранында жиі пайда болатынына дайын болыңыз.
Үшінші сақинада бәрі қарапайым болды: мен шамамен кодты сыздым, қажет жерде int3-ті орналастырдым, оны іске қостым және... отладчикте не екенін түсіндіңіз. Егер бірдеңе дұрыс емес болса, мен оны түзеттім, қателерді түзеттім, қайта құрастырдым... және т.б. код дұрыс жұмыс істегенше. Драйверлерді бағдарламалау кезінде сіз бұл техниканы ұмыта аласыз. Мұнда «сапер» бір рет қателеседі. Бір дұрыс емес қозғалыс... және сіз бір минутқа отыруға және демалуға болады.
BSOD мүмкіндігінше сирек көру үшін сіз бір қарапайым ережені ұстануыңыз керек: «Жеті рет өлшеңіз - бір рет кесіңіз»... «Жеті рет тексеру - бір рет іске қосу» мағынасында. Бұл, әрине, айтуға оңай, бірақ орындау әлдеқайда қиын. Бірақ, әдетте, сіз жазатын драйверлердің құрылымы (осы мақалаларды оқығаннан кейін) салыстырмалы түрде қарапайым екенін ескере отырып, BSOD пайда болғанға дейін қателермен күресуге болады. Егер ол сіздің көз алдыңызда үнемі пайда болса және себебін түсіне алмасаңыз, жағдайды түсіндірудің ықтимал жолы апат қоқысын талдау болып табылады. Бұл не екенін, оны қалай жасау керектігін және оны талдау туралы Марк Руссиновичтің http://www.osp.ru/win2000/2001/03/025.htm «Талдау жадының апаттық қалдықтарын талдау» мақаласынан оқи аласыз. Бұл мәселе (талдау) өте қиын, бірақ менің ойымша, олай болмайды.
Мен қорқынышты теоретикпін, сондықтан сіз жоғарыда айтылғандардың барлығын түсіну үшін өте қажет принциптер туралы өте негізгі ақпарат ретінде қарастыра аласыз. Сіз ағын контекстінің не екенін, үзу деңгейлері мен ағын басымдықтарын, ядро/пайдаланушы режимін, т.б. түсінбей, ядро режимінің драйверлерін әзірлеуді бастай алмайсыз. және т.б. Егер сіз қандай да бір мәселе бойынша сенімсіз болсаңыз - сілтемелер тізімі төменде берілген.
Енді тағы бірнеше практикалық нәрселерді қарастырайық (олар келесі мақалаларда өте практикалық болады), атап айтқанда, осы теорияның барлығын тәжірибеге айналдыру үшін не қажет.
Драйверді дамыту жинағы
Біріншісі, әрине, Microsoft веб-сайтынан тегін жүктеп алуға болатын Device Driver Development Kit (Windows 2000 Driver Development Kit, 2KDDK) (кез келген жағдайда мен оны осы жерден толығымен тегін жүктеп алдым: http:// www.microsoft.com/ddk/). Бұл бума құрылғы драйверлері пайдаланатын ішкі деректер құрылымдары мен жалпы жүйелік функциялар туралы ақпараттың бай көзі болып табылатын құжаттаманы қамтиды.
Құжаттамадан басқа, DDK сілтеме жасау кезінде өте қажет болатын кітапхана файлдарының жинағын (*.lib) қамтиды. DDK осы файлдардың екі жинағын қамтиды: Windows жүйесінің соңғы нұсқасы үшін (тегін құрастыру деп аталады); және әзірлеу үшін (тексерілген құрастыру деп аталады). Бұл файлдар сәйкесінше %ddk%\libfre\i386 және %ddk%\libchk\i386 каталогтарында орналасқан. Түзету нұсқасында қателерді тексеру қатаңырақ болады. Жүйе нұсқасына сәйкес файлдарды \masm32\lib\w2k каталогына орналастыру арқылы пайдалану керек.
Қосылған файлдар
Бізге функция прототипінің анықтамалары бар (*.inc) файлдарды қосу қажет. Біз де (дәлірек айтсам, мен) оларды өзіміз жасауымыз керек. Мен masm32 by hutch бумасына кіретін *.lib -> *.inc түрлендіретін көптеген әртүрлі утилиталарды қолданып көрдім және әртүрлі уақытта Интернеттің кең ауқымынан ағып кеткенім. Менде барлардың ішінде тек f0dder ұсынған protoize.exe ғана өз міндетін орындады, мен ештеңені қолмен өңдеудің қажеті болмады. Бұл тамаша құрал \tools\protoize каталогында орналасады. Автордың веб-сайты: http://f0dder.didjitalyphrozen.com/. Тек сіз оны ол жерден таба алмайсыз. f0dder бұл қызметтік бағдарламаны http://board.win32asmcommunity.net/ конференциясында бірнеше рет жариялады. Include \include\w2k каталогында орналасады. Оларды \masm32\include\w2k каталогында орналастыру керек. Түрлендіру үшін біз Windows 2000 тегін шығарылымы үшін *.lib қолдандық, өйткені менде бұл опция бар (сізде де солай болуы мүмкін).
Келесі мәселе күрделірек. Бұл қажетті құрылымдардың, символдық константалардың және макростардың анықтамалары бар файлдарды қосудың толық дерлік болмауы. Сіз Интернетте пайдалы нәрсені таба алмайсыз - бұл тым экзотикалық әрекет - ассемблерде ядро режимінің драйверлерін жазу. Кейбіреулерін EliCZ http://www.anticracking.sk/EliCZ/ сайтынан табуға болады. Y0da http://mitglied.lycos.de/yoda2k/index.htm сайтынан бір нәрсе (жартылай ол жасаған, ішінара сол EliCZ-ден алынған). Бірақ бұл өте нашар орындалды (словакиялық және неміс әріптестерімізге деген терең құрметіммен): көптеген құрылымдардың мүшелерінің аттары DDK-дан бастапқы тақырып файлдарында анықталғандардан ерекшеленеді; кірістірілген құрылымдар мен бірлестіктердің атаулары жоқ; түпнұсқада олар аталғанымен. Ал, жалпы алғанда, бәрі аздап тәртіпсіздікке ұшырайды және ол қараған кезде көңілсіз әсер қалдырады. Тек ntstatus.inc жақсы жасалған. Бұл ішінара EliCZ өзінің қосындыларын DDK-сыз жасай бастағандығына байланысты (өзі айтқандай). Қалай болғанда да, мен оларды кем дегенде мұқият тестілеусіз пайдалануға кеңес бермеймін. Бір уақытта http://board.win32asmcommunity.net/ конференциясында бір нәрсе жарқ етті, бірақ сапасы да ерекше әсер қалдырмайды. Қысқаша айтқанда, бұл жағдайда жалғыз дұрыс шешім - бәрін өзіңіз және қолмен жасау, өйткені мен бұл процесті автоматтандыруға мүмкіндік беретін ешқандай құралдарды білмеймін. Егер сіз кенеттен құнды нәрсеге тап болсаңыз және оны тым қиын деп ойламасаңыз, маған хабарлаңыз.
Драйверлерді жөндеу
Бізге сондай-ақ отладчик қажет және ядро режимінің кодын жөндеуге тура келетіндіктен, бізге сәйкес түзетуші қажет. Ең жақсы таңдау SoftICE болар еді. Немесе DDK құрамына кіретін ядроны түзету құралын пайдалануға болады. Бұл отладчик екі компьютерді қажет етеді - мастер және құл, оны әркім сатып ала алмайды. Марк Руссинович (http://www.sysinternals.com/) LiveKd деп аталатын утилита жазды, ол екінші компьютерді қоспай-ақ Kernel Debugger-ді пайдалануға мүмкіндік береді. Мен оның сайтта бар-жоғын білмеймін (тексерген жоқпын), бірақ ол «Microsoft Windows 2000 ішкі құрылғылары» кітабына арналған дискіде. Бұл отладчик сонымен қатар Microsoft веб-сайтынан еркін жүктеп алуға болатын (немесе мүмкін) жөндеу таңбалары орнатылған жағдайда жүйенің ішкі бөліктерін тексеру үшін өте пайдалы.
Дэвид Соломон, Марк Руссинович, «Microsoft Windows 2000 ішкі жүйесі», ред. «Питер», 2001 ж. Бұл кітапта бастапқы кодтың бір жолы болмаса да, ол ең алдымен бағдарламашыларға арналған.
Свен Шрайбер, «Windows 2000 құжатталмаған мүмкіндіктері», ред. «Питер», 2002 ж. Windows 2000 жүйесінің көптеген құпияларын ашатын таза практикалық кітап.
Уолтер Оней, «Microsoft драйвер үлгісін бағдарламалау», Microsoft Press, 1999 ж Бұл кітапта Plag"n"Play драйверлеріне баса назар аударылады, бірақ бұл оның артықшылықтарын ешбір жағдайда төмендетпейді, өйткені Драйверді дамытудың негізгі принциптері әмбебап болып табылады.
Джеффри Рихтер, «Кәсіби мамандарға арналған Windows: 64 разрядтық Windows ерекшеліктерімен қуатты Win32 қосымшаларын құру», ред. «Питер», 2000 ж. Бұл кітаптың драйверлерді бағдарламалауға тікелей қатысы жоқ, бірақ ол өте қызықты ;-)
Бұл тізім толық болуға арналмаған. Көп нәрсені, әсіресе ағылшын тілінде Интернеттен табуға болады (Шрайберден басқа барлық кітаптар электронды түрде қолжетімді). Кітаптарға келетін болсақ, олардың барлығы «болуға тиіс» санаттағы екенін айтқым келеді. Көріп тұрсыз - қарамай сатып алыңыз. Уолтер Онейден басқаның бәрі біздің «ұлы және құдіретті» деп аударылған.
Және соңғы бір нәрсе. Мен драйверлерді дамыту саласындағы үлкен сарапшы емеспін, сондықтан осы және кейінгі барлық мақалалардағы қателер немесе дәлсіздіктер өте ықтимал. Егер сіз оны тапсаңыз, мұрныңызды шұқылауға болады. Мен рахмет айтамын.
Microsoft Windows 10 операциялық жүйесінде қауіпсіздікке үлкен көңіл бөледі. Жүйенің маңызды элементтерінің бірі - Windows Defender, бірақ ол барлық қауіптерді жеңе алмайды. Атап айтқанда, Ransomware вирустары жақында әсіресе кең тарады, олардың ең танымал реинкарнациялары Петя және . Microsoft корпорациясы Ransomware вирустарымен күресуге бағытталған Windows 10 жүйесінде ядроны оқшаулау және жад тұтастығы мүмкіндіктерін енгізді. Әдепкі бойынша олар өшірілген.
Мазмұны:Ядроның оқшаулануы және жадының тұтастығы дегеніміз не
Ядро оқшаулауоперациялық жүйе мен құрылғыдан компьютерлік процестерді оқшаулау әдісімен қамтамасыз етілетін қосымша қорғау процесі болып табылады. Осы әрекеттердің арқасында компьютерге вирустар енген кезде операциялық жүйенің жұмысына нұқсан келтірмеуге болады.
Жадтың тұтастығы- Бұл ядролық оқшаулаумен бірге жүретін қорғаныс функциясы, ол қауіпсіздік деңгейі жоғары процестерге белгісіз ықтимал қауіпті бағдарламалардың қол жеткізуін шектеуге бағытталған.
Маңызды: ядроны оқшаулау функциясы компьютердің аппараттық құралында бұл үшін жеткілікті шарттар болған жағдайда ғана жұмыс істей алады. BIOS параметрлерінде виртуалдандыру технологиясы белсенді болуы керек, соның арқасында Windows 10 операциялық жүйесімен жұмыс істейтін компьютер виртуалды контейнерде әртүрлі қолданбаларды іске қосып, олардың негізгі жүйе құрамдастарынан қол жеткізуді шектей алады.
Ядроның оқшаулануын және жадтың тұтастығын қалай қосуға болады
Windows 10 амалдық жүйесінің параметрлері компьютердегі қауіпсіздік мүмкіндіктерін толығымен басқаруға мүмкіндік береді. Windows 10 параметрлері арқылы ядроның оқшаулануын және жад тұтастығын келесідей қосуға болады:
Жоғарыда айтылғандай, егер компьютерлік жабдық виртуалдандыруды қолдамаса, бұл функция жұмыс істемейді. Қосылған кезде пайдаланушы төменгі оң жақ бұрышта «Жадтың тұтастығын қамтамасыз ету мүмкін емес. Ықтимал сәйкессіздік». Бұл хабар пайда болса, BIOS жүйесіне өтіп, Secure Boot (Жүктеу режимі) функциясы қосылғанын көру ұсынылады.
Ядроның оқшаулануын және жадтың тұтастығын қалай өшіруге болады
Операциялық жүйенің жұмысына елеулі әсер ететін жаңа мүмкіндіктер әрқашан компьютердің жұмысында ақаулық тудыруы мүмкін. Ядроны оқшаулау функциясы ерекшелік емес. Оны әлдеқашан қолданып көрген пайдаланушылар Microsoft форумдарында бірқатар ойындар мен бағдарламаларды іске қосқан кезде қиындықтарға тап болатынын атап өтеді. Бұл мәселені шешудің жалғыз жолы - ядроның оқшаулануын және жадтың тұтастығын өшіру. Мүмкін қолданба әзірлеушілері немесе Microsoft корпорациясы болашақ жаңартуларда бұл сәйкессіздікті түзететін шығар.
Ядроның оқшаулануын және жадтың тұтастығын өшірудің 3 жолы бар:
Менің негізгі ноутбугымда әртүрлі қуат беру проблемалары жиі туындайды, мұны инсайдерлік құрылымдарда жұмыс істеу арқылы түсіндіруге болады. Дегенмен, 1803 тұрақты нұсқасында да мен жүйенің ұйқы режимін тоқтатқанын байқадым. Бұл жағдайда монитор белгілі бір уақыт кезеңінен кейін өшеді, бұл жүйенің әрекетсіздік күйін дұрыс анықтайтынын көрсетеді.
Мен ұйқыға өтудің қысқа кезеңін, 1-2 минутты белгілеп, диагностиканы бастадым.
Қосымшалар мен драйверлерден қуат ішкі жүйесіне сұрауларды тексеру
Сізге бірінші кезекте қарау керек powercfg, бұл ОЖ-ны ұйқыға жіберуден сақтайды. Қуат ішкі жүйесіне қатынасатын процестер мен драйверлерді әкімші ретінде пәрмен жолында көруге болады:
Powercfg-сұраулары
ЖҮЙЕ сұрауы Драйверден келетіні бірден түсінікті - бұл жағдайда Realtek аудио ағынын пайдаланады.
Тізімде Chrome ұсынған WebRTC де болуы мүмкін және жүйе қайта іске қосылғаннан кейін бірден жүктеуді оңтайландыру сұраулары мен іздеу индексін көруге болады, бірақ олар тез жоғалады. Процесті немесе драйверді ерекше жағдайлар тізіміне қосуға болады және ол оның ұйқы режиміне өтуіне кедергі болмайды.
Powercfg -requestsoverride DRIVER "Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)" ЖҮЙЕСІ
Пәрменде "DRIVER [драйвердің толық атауы] ЖҮЙЕ сұрауын елемеу" деп оқылады.
Ерекшеліктер тізімі тізілім кілтінде сақталады
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerRequestOverride
және пәрмен арқылы шығарылады
Powercfg -сұраныстарды қайта анықтау
Мен сенімді болу үшін қайта жүктедім, бірақ жүйе ұйқыға өтуден бас тартты. Ерекшеліктер мен сұраулар тізімін тексергеннен кейін мен Realtek драйвері ерекше жағдайларға енгізілгеніне қарамастан, аудио ағынды пайдалануды жалғастырғанын білдім.
Мен ерекше жағдайлардың айналасында аздап биледім, бірақ сәтті болмады. Жылдам Google кейбір жағдайларда олардың жұмыс істемейтінін растады. Бұл бұрынғы сұрауларға тән, бірақ басқа жағдай болды, мен бұны бірінші рет кездестірген жоқпын.
Мен Realtek-ті тізімнен алып тастадым. Жазбаларды тізілім өңдегішінде немесе консольде жоюға болады. Пәрмен қосу кезіндегідей дерлік, ол жай ғана сұраудың қайда кететінін көрсетпейді, яғни. бұл жағдайда пәрменнің соңында ЖҮЙЕ жоқ:
Powercfg -requestsoverride DRIVER "Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)"
Біз басқа жолмен барамыз
Дыбыстық ішкі жүйені пайдаланатын процесті есептеңіз
Лас жұмысты Realtek жүргізушісі жасайтыны белгілі. Әлбетте, ол жүйені іске қосқан кезде жүктеледі, сондықтан файл атауын Autoruns көмегімен білу оңай.
Үш жазба екі файлға сілтеме жасайды, олардың біреуі атына қарай басқару тақтасы. Сондықтан қызығушылық объектісі болды ravbg64.exe.