Микроядро: Операциялық жүйенің негізгі құрылымы

Кіріспе

Дәстүрлі ядроға қарағанда аз қызметтер ұсынатын ядро. Компьютерлік ғылымда микроядро (көбінесе μ ядро деп қысқартылады) – операциялық жүйені (ОЖ) іске асыру үшін қажетті механизмдерді қамтамасыз ететін ең аз көлемдегі бағдарламалық жасақтама. Бұл механизмдерге төменгі деңгейдегі жад кеңістігін басқару, процестерді басқару және процестер аралық байланыс (IPC) жатады. Аппараттық құралда бірнеше сақина немесе процессор режимдері болса, микроядро ең жоғары привилегия деңгейінде орындалатын жалғыз бағдарламалық жасақтама болуы мүмкін, бұл әдетте қадағалаушы немесе ядролық режим деп аталады. Құрылғы драйверлері, протокол жиынтықтары және файлдық жүйелер сияқты операциялық жүйенің дәстүрлі функциялары әдетте микроядродан шығарылып, пайдаланушы кеңістігінде орындалады. Көрсету кодының көлемі бойынша микроядролар монолиттік ядролардан көбінесе кіші болады. Мысалы, MINIX 3 микроядросы шамамен 12 000 код жолынан тұрады.

Тарих

Микроядролар өз тамырларын даттық компьютер пионері Пер Бринч Хансенге және оның даттық компьютерлік компания Regnecentralen-дегі қызметіне дейін жатқызады, онда ол RC 4000 компьютері үшін бағдарламалық жасақтаманы әзірлеуді басқарды. 1967 жылы Regnecentralen RC 4000 прототипін Польшадағы Zakłady Azotowe Puławy тыңайтқыш зауытына орнатты. Компьютер зауыттың қажеттіліктеріне бейімделген кішкентай нақты уақыт операциялық жүйені қолданды. Бринч Хансен және оның командасы RC 4000 жүйесінің жалпыламалығы мен қайта пайдалану мүмкіндігінің жетіспеуіне алаңдады. Олар әр орнату үшін әртүрлі операциялық жүйе қажет болады деп қорқып, RC 4000 үшін бағдарламалық жасақтама құрудың жаңа және жалпылама тәсілдерін зерттеуді бастады. 1969 жылы олардың күш-жігері RC 4000 көп бағдарламалық жүйесін аяқтаумен аяқталды. Оның ядросы 23-ке дейін артықшылықтары жоқ процестер арасындағы байланысты хабар алмасу арқылы қамтамасыз етті, олардың 8-і бір уақытта бір-бірінен қорғалды. Бұл сонымен қатар бағдарламалардың қатар орындалу уақыт тілімдерін жоспарлауды, басқа жұмыс істеп тұрған бағдарламалардың сұрауы бойынша бағдарлама орындалуын бастау және басқаруды, сондай-ақ перифериялық құрылғыларға немесе олардан деректерді беруді жүзеге асырды. Осы қарапайым механизмдерден басқа, бағдарлама орындау және ресурстарды бөлу стратегиясы болған жоқ. Бұл стратегияны бағдарламаларды орындау иерархиясы арқылы жүзеге асыру жоспарланған, онда басты процестер бала процестерді толық бақылауда ұстап, олардың операциялық жүйелері ретінде әрекет ететін еді. Бринч Хансеннің жұмысынан кейін 1970 жылдардан бері микроядролар жасалып келеді. Микроядро термині алғаш рет 1981 жылдан кешірек пайда болған жоқ. Микроядролар компьютер әлеміндегі өзгерістерге жауап ретінде және осы жаңа жүйелерге қолданыстағы «моноядроларды» бейімдеудегі бірнеше қиындықтарға жауап ретінде ойластырылды. Жаңа құрылғы драйверлері, протоколдар жиынтығы, файлдық жүйелер және басқа да төменгі деңгейдегі жүйелер үнемі жасалып жатты. Бұл код әдетте монолиттік ядрода орналасқандықтан, онымен жұмыс істеу үшін көп еңбек пен мұқият кодты басқару қажет болды. Микроядролар осы қызметтердің барлығын кез келген басқа бағдарлама сияқты пайдаланушы кеңістігіндегі бағдарламалар ретінде жүзеге асыру идеясымен жасалды, бұл олармен монолиттік түрде жұмыс істеуге және кез келген басқа бағдарлама сияқты іске қосуға және тоқтатуға мүмкіндік берді. Бұл осы қызметтермен оңай жұмыс істеуге ғана емес, сонымен қатар ядролық кодты бөліп, қарама-қарсы салдарлар туралы уайымдамай оны жақсырақ реттеуге мүмкіндік берді. Сонымен қатар, бұл операциялық жүйелерді жалпы ядроға «құруға» мүмкіндік береді, бұл операциялық жүйелерді зерттеуге көмектеседі. Микроядролар 1980-ші жылдары, алғашқы жергілікті желілер енгізілген кезде өте танымал тақырып болды. AmigaOS Exec ядросы 1986 жылы ұсынылған және салыстырмалы коммерциялық сәттілікке ие болған ПК-де қолданылған алғашқы мысал болды. Басқа жағынан кемшілік деп есептелген жадты қорғаудың болмауы, бұл ядроға өте жоғары хабар алмасу өнімділігіне ие болуға мүмкіндік берді, өйткені пайдаланушы кеңістігіндегі бағдарламалар арасында хабар алмасу кезінде деректерді көшірудің қажеті болмады. Ядроны пайдаланушы кеңістігіне таратуға мүмкіндік берген механизмдер жүйеге желілік байланыстар арқылы таралуға мүмкіндік берді. Алғашқы микроядролар, әсіресе Ричард Рашид жасаған Mach, көңілі толмаған өнімділік көрсетті, бірақ оның ішкі артықшылықтары соншалықты зор болды, бұл 1990-шы жылдардың соңына дейін зерттеудің маңызды бағыты болды. Алайда, осы уақыт ішінде компьютерлердің жылдамдығы желілік жүйелерге қатысты күрт өсті, ал өнімділіктегі кемшіліктер даму тұрғысынан артықшылықтарды басып тастады. Қолданыстағы жүйелерді жақсырақ өнімділікке бейімдеуге көптеген әрекеттер жасалды, бірақ үстіңгі жұмыс әрқашан едәуір болды және осы әрекеттердің көпшілігі пайдаланушы кеңістігіндегі бағдарламаларды ядроға қайтаруды талап етті. 2000 жылға қарай Mach ядросының көптеген ірі масштабты күш-жігері аяқталды, бірақ Apple-дің 2001 жылы шыққан macOS әлі де XNU деп аталатын гибридті ядроны қолданады, ол OSF/1-дің Mach ядросын (OSFMK 7.3 ядросы) қатты өзгерткен (гибридті) кодымен BSD UNIX кодымен біріктіреді, және бұл ядро iOS, tvOS және watchOS-та да қолданылады. Windows NT, NT 3.1 бастап Windows 11-ге дейін гибридті ядролық дизайнды қолданады. 2012 жылдан бастап Mach негізіндегі GNU Hurd да жұмыс істейді және Arch Linux және Debian сынақ нұсқаларына қосылған. Микроядролар бойынша маңызды жұмыстар көбінесе аяқталған болса да, тәжірибешілер оларды дамытуды жалғастырды. Кейіннен бұрынғы дизайнның өнімділік проблемаларының көпшілігі түсінікке қатысты фундаменталды шектеу емес, керісінше, дизайнерлердің көптеген қызметтерді жүзеге асыру үшін бір мақсатты жүйелерді пайдалануға деген ұмтылысынан туындады екені көрсетілді. Проблемаға көбірек прагматикалық көзқарас қолданып, құрастыру кодын пайдалану және әдетте бағдарламалық жасақтамада қолдау көрсетілетін ұғымдарды күшейту үшін процессорға сүйену арқылы жақсартылған өнімділікке ие микроядролардың жаңа сериясы құрылды. Микроядролар экзоядролармен тығыз байланысты. Олар гипервизорлармен де көп ортақ нәрселері бар, бірақ соңғылары минималдыққа таласпайды және виртуалды машиналарды қолдауға маманданған; L4 микроядросы көбінесе гипервизор ретінде қолданылады.

Microkernels trace their roots back to Danish computer pioneer Per Brinch Hansen and his tenure in Danish computer company Regnecentralen where he led software development efforts for the RC 4000 computer. In 1967, Regnecentralen was installing a RC 4000 prototype in the Zakłady Azotowe Puławy fertilizer plant in Poland. The computer used a small real time operating system tailored for the needs of the plant. Brinch Hansen and his team became concerned with the lack of generality and reusability of the RC 4000 system. They feared that each installation would require a different operating system so they started to investigate novel and more general ways of creating software for the RC 4000. In 1969, their effort resulted in the completion of the RC 4000 Multiprogramming System. Its nucleus provided inter process communication based on message passing for up to 23 unprivileged processes, out of which 8 at a time were protected from one another. It further implemented scheduling of time slices of programs executed in parallel, initiation and control of program execution at the request of other running programs, and initiation of data transfers to or from peripherals. Besides these elementary mechanisms, it had no built in strategy for program execution and resource allocation. This strategy was to be implemented by a hierarchy of running programs in which parent processes had complete control over child processes and acted as their operating systems. Following Brinch Hansen's work, microkernels have been developed since the 1970s. The term microkernel itself first appeared no later than 1981. Microkernels were meant as a response to changes in the computer world, and to several challenges adapting existing "mono kernels" to these new systems. New device drivers, protocol stacks, file systems and other low level systems were being developed all the time. This code was normally located in the monolithic kernel, and thus required considerable work and careful code management to work on. Microkernels were developed with the idea that all of these services would be implemented as user space programs, like any other, allowing them to be worked on monolithically and started and stopped like any other program. This would not only allow these services to be more easily worked on, but also separated the kernel code to allow it to be finely tuned without worrying about unintended side effects. Moreover, it would allow entirely new operating systems to be "built up" on a common core, aiding OS research. Microkernels were a very hot topic in the 1980s when the first usable local area networks were being introduced The AmigaOS Exec kernel was an early example, introduced in 1986 and used in a PC with relative commercial success. The lack of memory protection, considered in other respects a flaw, allowed this kernel to have very high message passing performance because it did not need to copy data while exchanging messages between user space programs. The same mechanisms that allowed the kernel to be distributed into user space also allowed the system to be distributed across network links. The first microkernels, notably Mach created by Richard Rashid, proved to have disappointing performance, but the inherent advantages appeared so great that it was a major line of research into the late 1990s. However, during this time the speed of computers grew greatly in relation to networking systems, and the disadvantages in performance came to overwhelm the advantages in development terms. Many attempts were made to adapt the existing systems to have better performance, but the overhead was always considerable and most of these efforts required the user space programs to be moved back into the kernel. By 2000, most large scale Mach kernel efforts had ended, although Apple's macOS, released in 2001, still uses a hybrid kernel called XNU, which combines a heavily modified (hybrid) OSF/1's Mach kernel (OSFMK 7.3 kernel) with code from BSD UNIX, and this kernel is also used in iOS, tvOS, and watchOS. Windows NT, starting with NT 3.1 and continuing with Windows 11, uses a hybrid kernel design. as of 2012, the Mach based GNU Hurd is also functional and included in testing versions of Arch Linux and Debian. Although major work on microkernels had largely ended, experimenters continued development. It has since been shown that many of the performance problems of earlier designs were not a fundamental limitation of the concept, but instead due to the designer's desire to use single purpose systems to implement as many of these services as possible. Using a more pragmatic approach to the problem, including assembly code and relying on the processor to enforce concepts normally supported in software led to a new series of microkernels with dramatically improved performance. Microkernels are closely related to exokernels. They also have much in common with hypervisors, but the latter make no claim to minimality and are specialized to supporting virtual machines; the L4 microkernel frequently finds use in a hypervisor capacity.

Кіріспе

Операциялық жүйелердің алғашқы ядролары салыстырмалы түрде кішкентай болды, себебі компьютер жады шектеулі болды. Компьютерлердің мүмкіндіктері арта келе, ядро басқаруға тиіс құрылғылардың саны да көбейді. Unix тарихының басында ядролар әдетте кішкентай болды, тіпті олардың құрамында түрлі құрылғы драйверлері мен файлдық жүйелер болғанмен де. Адрестік кеңістік 16 биттен 32 битке дейін ұлғайғанда, ядро дизайны енді аппараттық архитектурамен шектелмеді және ядролар үлкейе бастады. Unix-тің Беркли дистрибуциясы (BSD) үлкен ядролар дәуірін басталды. CPU, дискілер және принтерлерден тұратын негізгі жүйені іске қосумен қатар, BSD толық TCP/IP желілік жүйесін және бірқатар «виртуалды» құрылғыларды қосты, бұл қолданыстағы бағдарламаларға желіде «көрінбейтін» жұмыс істеуге мүмкіндік берді. Бұл өсім көп жылдар бойы жалғасып, нәтижесінде миллиондаған код жолдарынан тұратын ядролар пайда болды. Осы өсімге байланысты ядроларда қателер жиі кездесе бастады және оларды күтіп ұстау қиын болды. Микроядроның мақсаты – ядролардың өсуіне және осыған байланысты туындайтын қиындықтарды шешу болды. Теория бойынша, микроядро дизайны кодты пайдаланушы кеңістігіндегі қызметтерге бөлу арқасында басқаруды жеңілдетеді. Бұл сондай-ақ ядролық режимде жұмыс істейтін код мөлшерінің азаюынан туындайтын қауіпсіздік пен тұрақтылықты арттыруға мүмкіндік береді. Мысалы, егер желілік қызмет буферлік ағыннан зардап шексе, тек желілік қызметтің жады зақымдалады, ал жүйенің қалған бөлігі жұмыс істей береді.

Процестер арасындағы байланыс

Процестер аралық байланыс (IPC) – жеке процестерге бір-бірімен қарым-қатынас жасауға мүмкіндік беретін кез келген механизм, әдетте хабарламалар жіберу арқылы. Ортақ жад, қатаң түрде анықталғанда, процестер аралық байланыс механизмі болып табылады, бірақ IPC аббревиатурасы көбінесе тек хабарлама алмасуға қатысты, және осы соңғысы микроядролар үшін ерекше маңызды. IPC операциялық жүйені серверлер деп аталатын кішірек бағдарламалардан құруға мүмкіндік береді, олар жүйедегі басқа бағдарламалармен IPC арқылы шақырылады. Перифериялық аппараттық құралдардың көп бөлігі осылай басқарылады, құрылғы драйверлері, желілік протоколдар жиынтығы, файлдық жүйелер, графика және т.б. үшін серверлер қолданылады. IPC синхронды немесе асинхронды болуы мүмкін. Асинхронды IPC желілік байланысқа ұқсас: жіберуші хабарлама жібереді және орындауды жалғастырады. Алушы хабарламаның қолжетімділігін тексереді (сауалдайды) немесе белгілі бір хабарлама механизмі арқылы ескертіледі. Асинхронды IPC ядроның хабарламалар үшін буферлер мен кезектерді сақтауын және буфердің толып кетуін қамтамасыз етуін қажет етеді; сонымен қатар хабарламаларды екі рет көшіруді қажет етеді (жіберушіден ядроға және ядродан алушыға). Синхронды IPC-де бірінші тарап (жіберуші немесе алушы) екінші тарап IPC-ні орындауға дайын болғанға дейін тоқтатылады. Бұл буферлеуді немесе бірнеше көшірмелерді қажет етпейді, бірақ жасырын кездесу бағдарламалауды қиындатады. Көптеген бағдарламашылар асинхронды жіберуді және синхронды қабылдауды артық көреді. Бірінші буын микроядролары әдетте синхронды және асинхронды IPC-ні қолдады және IPC-нің нашар өнімділігінен зардап шекті. Йохан Лидтке IPC механизмдерін жобалау мен іске асыру осы нашар өнімділіктің түпкі себебі деп санайды. Ол өзінің L4 микроядросында IPC шығындарын шамамен бір рет азайтатын әдістерді енгізді. Бұған жіберу және қабылдау операцияларын қолдайтын IPC жүйелік шақыру кіреді, барлық IPC-ні синхронды етеді және мүмкіндігінше көп деректерді тіркелімдерде жібереді. Сонымен қатар, Лидтке тікелей процесс ауысуы тұжырымын енгізді, онда IPC орындалу кезінде (толық емес) контексттік ауысу жіберушіден тікелей алушыға жүзеге асырылады. Егер L4-те хабардың бір бөлігі немесе барлығы тіркелімдерде берілсе, бұл хабардың тіркелімдік бөлігін көшірмелеусіз өткізеді. Сонымен қатар, жоспарлаушыны шақырудың қосымша шығындары болдырмайды; бұл RPC (қашықтан процедуралық шақыру) түрінде серверді шақыратын клиент үшін өте пайдалы. Тағы бір оңтайландыру, жалқау жоспарлау деп аталады, IPC кезінде жоспарлау кезектерін қараудан аулақтайды, IPC кезінде тоқтатылатын жіптерді дайын кезекте қалдырады. Жоспарлаушы шақырылғаннан кейін, ол осындай жіптерді тиісті күту кезекке жылжытады. Көп жағдайда жіп келесі жоспарлаушы шақырудан бұрын тоқтатылмайды, сондықтан бұл тәсіл маңызды жұмысты үнемдейді. Осыған ұқсас тәсілдер QNX және MINIX 3 қолданды. Бірқатар эксперименттер барысында Чен мен Бершад монолиттік Ultrix-тің нұсқаулық бойынша жад циклдерін (MCPI) пайдаланушы кеңістігінде жұмыс істейтін 4.3BSD Unix серверімен біріктірілген микроядро Mach-пен салыстырды. Олардың нәтижелері Mach-тың нашар өнімділігін жоғары MCPI арқылы түсіндірді және IPC ғана жүйелік шығындардың көп бөлігіне жауапты емес екенін көрсетті, бұл тек IPC-ге бағытталған оңтайландырулар шектеулі әсер етеді. Лидтке кейіннен Чен мен Бершадтың нәтижелерін Ultrix пен Mach MCPI арасындағы айырмашылықтың басым бөлігі сыйымдылық кэшінің жоғалуынан туындағанын байқап, микроядроның кэш жұмыс жиынтығын күрт азайту мәселені шешеді деген қорытындыға келді. Клиент-сервер жүйесінде, тіпті асинхронды примитивтерді қолданған кезде де, қарым-қатынастың көпшілігі негізінен синхронды, өйткені әдеттегі операция - клиент серверді шақырып, содан кейін жауап күту. Ол өзін тиімді іске асыруға мүмкіндік беретіндіктен, көптеген микроядролар L4 нұсқасын ұстанды және тек синхронды IPC примитивін ұсынды. Асинхронды IPC көмекші жіптерді пайдалану арқылы үстіңгі жағында іске асырылуы мүмкін. Алайда тәжірибеде синхронды IPC-нің пайдалылығы күмәнді екені көрініп тұр: синхронды IPC көп жіпті дизайнды басқаша қарапайым жүйелерге мәжбүрлейді, нәтижесінде синхрондастырудың күрделіліктері туындайды. Сонымен қатар, RPC сияқты серверді шақыру клиентті және серверді реттеп отырады, егер олар бөлек өзектерде жұмыс істесе, олардан аулақ болу керек. Сондықтан коммерциялық өнімдерде қолданылатын L4 нұсқаларына асинхронды байланысты жақсырақ қолдау үшін асинхронды хабарлама механизмін қосу қажет болды. Бұл сигнал сияқты механизм деректерді тасымалдамайды және сондықтан ядродан буферлеуді қажет етпейді. Екі түрлі IPC-ге ие болу арқылы олар, дегенмен, минимализм принципін бұзды. L4-тің басқа нұсқалары толығымен асинхронды IPC-ге көшті. Синхронды IPC бірінші тарапты екінші тарап дайын болғанға дейін тоқтататындықтан, шексіз пайдалану оңай шатасуға әкелуі мүмкін. Сонымен қатар, клиент серверге сұрау жіберіп, жауапты алуға тырыспау арқылы қызметтен бас тарту шабуылын оңай ұйымдастыра алады. Сондықтан синхронды IPC шексіз тоқтатуды болдырмау құралын ұсынуы керек. Көптеген микроядролар IPC шақыруларына уақыт шектеуін қояды, бұл тоқтату уақытын шектейді. Іс жүзінде, мағыналы уақыт шектеуін таңдау қиын, және жүйелер клиенттер үшін шексіз уақыт шектеуін және серверлер үшін нөлдік уақыт шектеуін қолдануы әдеттегідей. Нәтижесінде, тренд кез келген уақыт шектеуін ұсынбауға, егер серік дайын болмаса IPC сәтсіз аяқталуын көрсететін флагты ұсынуға қарайды. Бұл тәсіл тиімді түрде нөл және шексіз уақыт шектеулерінің екеуінің арасында таңдау жасауға мүмкіндік береді. L4 және MINIX-тің соңғы нұсқалары осы жолға түсті (L4-тің ескі нұсқалары уақыт шектеуін қолданды). QNX мәселені шешеді, клиент хабарлама жіберу шақыруының бөлігі ретінде жауап буферін көрсетуді талап етеді. Сервер жауап берген кезде ядро деректерді клиенттің буферіне көшіреді, клиент жауапты нақты қабылдауды күтудің қажеті болмайды.

Inter process communication (IPC) is any mechanism which allows separate processes to communicate with each other, usually by sending messages. Shared memory is, strictly defined, also an inter process communication mechanism, but the abbreviation IPC usually refers to message passing only, and it is the latter that is particularly relevant to microkernels. IPC allows the operating system to be built from a number of smaller programs called servers, which are used by other programs on the system, invoked via IPC. Most or all support for peripheral hardware is handled in this fashion, with servers for device drivers, network protocol stacks, file systems, graphics, etc. IPC can be synchronous or asynchronous. Asynchronous IPC is analogous to network communication: the sender dispatches a message and continues executing. The receiver checks (polls) for the availability of the message, or is alerted to it via some notification mechanism. Asynchronous IPC requires that the kernel maintains buffers and queues for messages, and deals with buffer overflows; it also requires double copying of messages (sender to kernel and kernel to receiver). In synchronous IPC, the first party (sender or receiver) blocks until the other party is ready to perform the IPC. It does not require buffering or multiple copies, but the implicit rendezvous can make programming tricky. Most programmers prefer asynchronous send and synchronous receive. First generation microkernels typically supported synchronous as well as asynchronous IPC, and suffered from poor IPC performance. Jochen Liedtke assumed the design and implementation of the IPC mechanisms to be the underlying reason for this poor performance. In his L4 microkernel he pioneered methods that lowered IPC costs by an order of magnitude. These include an IPC system call that supports a send as well as a receive operation, making all IPC synchronous, and passing as much data as possible in registers. Furthermore, Liedtke introduced the concept of the direct process switch, where during an IPC execution an (incomplete) context switch is performed from the sender directly to the receiver. If, as in L4, part or all of the message is passed in registers, this transfers the in register part of the message without any copying at all. Furthermore, the overhead of invoking the scheduler is avoided; this is especially beneficial in the common case where IPC is used in a remote procedure call (RPC) type fashion by a client invoking a server. Another optimization, called lazy scheduling, avoids traversing scheduling queues during IPC by leaving threads that block during IPC in the ready queue. Once the scheduler is invoked, it moves such threads to the appropriate waiting queue. As in many cases a thread gets unblocked before the next scheduler invocation, this approach saves significant work. Similar approaches have since been adopted by QNX and MINIX 3. In a series of experiments, Chen and Bershad compared memory cycles per instruction (MCPI) of monolithic Ultrix with those of microkernel Mach combined with a 4.3BSD Unix server running in user space. Their results explained Mach's poorer performance by higher MCPI and demonstrated that IPC alone is not responsible for much of the system overhead, suggesting that optimizations focused exclusively on IPC will have a limited effect. Liedtke later refined Chen and Bershad's results by making an observation that the bulk of the difference between Ultrix and Mach MCPI was caused by capacity cache misses and concluding that drastically reducing the cache working set of a microkernel will solve the problem. In a client server system, most communication is essentially synchronous, even if using asynchronous primitives, as the typical operation is a client invoking a server and then waiting for a reply. As it also lends itself to more efficient implementation, most microkernels generally followed L4's lead and only provided a synchronous IPC primitive. Asynchronous IPC could be implemented on top by using helper threads. However, experience has shown that the utility of synchronous IPC is dubious: synchronous IPC forces a multi threaded design onto otherwise simple systems, with the resulting synchronization complexities. Moreover, an RPC like server invocation sequentializes client and server, which should be avoided if they are running on separate cores. Versions of L4 deployed in commercial products have therefore found it necessary to add an asynchronous notification mechanism to better support asynchronous communication. This signal like mechanism does not carry data and therefore does not require buffering by the kernel. By having two forms of IPC, they have nonetheless violated the principle of minimality. Other versions of L4 have switched to asynchronous IPC completely. As synchronous IPC blocks the first party until the other is ready, unrestricted use could easily lead to deadlocks. Furthermore, a client could easily mount a denial of service attack on a server by sending a request and never attempting to receive the reply. Therefore, synchronous IPC must provide a means to prevent indefinite blocking. Many microkernels provide timeouts on IPC calls, which limit the blocking time. In practice, choosing sensible timeout values is difficult, and systems almost inevitably use infinite timeouts for clients and zero timeouts for servers. As a consequence, the trend is towards not providing arbitrary timeouts, but only a flag which indicates that the IPC should fail immediately if the partner is not ready. This approach effectively provides a choice of the two timeout values of zero and infinity. Recent versions of L4 and MINIX have gone down this path (older versions of L4 used timeouts). QNX avoids the problem by requiring the client to specify the reply buffer as part of the message send call. When the server replies the kernel copies the data to the client's buffer, without having to wait for the client to receive the response explicitly.

Серверлер

Микроядро серверлері, негізінен, басқа бағдарламалар сияқты демон бағдарламалары, бірақ ядро олардың кейбіреулеріне физикалық жадтың көптеген бағдарламаларға қол жеткізе алмайтын бөліктерімен өзара әрекеттесуге рұхсат береді. Бұл кейбір серверлерге, әсіресе құрылғы драйверлеріне, тікелей аппараттық құралдармен жұмыс істеуге мүмкіндік береді. Жалпы мақсаттағы микроядро үшін негізгі серверлер жиынтығына файлдық жүйе серверлері, құрылғы драйверлері серверлері, желілік серверлер, дисплей серверлері және пайдаланушы интерфейсі құрылғылары серверлері кіреді. Бұл серверлер жиынтығы (QNX-тен алынған) Unix монолитті ядросы ұсынатын қызметтерге ұқсас қызметтер жиынтығын қамтамасыз етеді. Қажетті серверлер жүйе іске қосылғанда іске қосылады және файлдарға, желіге және құрылғыларға қол жеткізу сияқты қызметтерді әдеттегі қолданба бағдарламаларына ұсынады. Мұндай серверлер пайдаланушы қолданбасының ортасында жұмыс істегендіктен, серверді әзірлеу ядроны әзірлеуге қажетті құрастыру және жүктеу процесіне қарағанда, әдеттегі қолданбаларды әзірлеуге ұқсас. Сонымен қатар, көптеген «ақаулар» серверді тоқтату және қайта іске қосу арқылы түзетілуі мүмкін. Дегенмен, ақаулы сервермен бірге жүйе күйінің бір бөлігі жоғалады, сондықтан бұл тәсіл бағдарламалардың ақаулықтарды өңдеуін қажет етеді. Жақсы мысал – TCP/IP қосылымдарына жауапты сервер: егер бұл сервер қайта іске қосылса, қолданбалар «жоғалған» қосылымды көреді, бұл желілік жүйедегі қалыпты жағдай. Басқа қызметтер үшін ақаулықтар сирек кездеседі және қолданба кодын өзгертуді қажет етуі мүмкін. QNX үшін қайта іске қосу мүмкіндігі QNX жоғары сенімділік құралдары жиынтығы ретінде ұсынылады.

Құрылғы драйверлері

Құрылғы драйверлері жиі тікелей жадқа кіруді (DMA) орындайды, сондықтан физикалық жадтың кез келген орнына, оның ішінде әртүрлі ядролық дерек құрылымдарына жазуға мүмкіндігі бар. Сондықтан мұндай драйверлерге сенім арту қажет. Олардың ядроның бір бөлігі болуы керек деген жалпы қате түсінік бар. Шындығында, драйвердің ядроның бір бөлігі болуы оның сенімділігін арттырмайды немесе кемітпейді. Құрылғы драйверін пайдаланушы кеңістігінде іске қосу, дұрыс жұмыс ілемейтін драйвердің келтіретін зиянды міндетті түрде азайта бермейді, бірақ практикада бұзушылыққа ұшыраған (жаман ниетті емес) драйверлердің болған жағдайында жүйе тұрақтылығын арттыруға көмектеседі: драйвер кодының (құрылғы емес) жадқа қол жеткізу бұзушылықтары жадты басқару аппараттық құралдарымен анықталуы мүмкін. Сонымен қатар, көптеген құрылғылар DMA мүмкіндігіне ие емес, олардың драйверлерін пайдаланушы кеңістігінде іске қосу арқылы сенімсіз етуге болады. Соңғы кезде көптеген компьютерлерде IOMMU пайда болып келеді, олардың көпшілігі құрылғының физикалық жадқа қол жеткізуін шектеу үшін қолданылады. Бұл пайдаланушы режиміндегі драйверлердің де сенімсіз болуына мүмкіндік береді. Пайдаланушы режиміндегі драйверлер микроядролардан ертерек пайда болған. 1967 жылы Мичигандық терминалдық жүйе (MTS) пайдаланушы кеңістігіндегі драйверлерді (оның ішінде файлдық жүйе қолдауын) қолдаған, бұл мүмкіндікпен жасалған алғашқы операциялық жүйе. Тарихи тұрғыдан алғанда, драйверлер үлкен мәселе тудырмады, себебі құрылғылардың саны аз болды және оларға сенім артылатын, сондықтан оларды ядроға енгізу дизайнды жеңілдетті және ықтимал өнімділік проблемаларын болдырмады. Осыдан Unix, Linux және Windows NT жүйелеріндегі дәстүрлі ядролық драйвер стилі пайда болды. Әртүрлі перифериялық құрылғылардың көбеюімен драйверлік кодтың көлемі артты және қазіргі операциялық жүйелерде код көлемі бойынша ядродан басып өтеді.

Қауіпсіздік

Микроядролардың қауіпсіздік артықшылықтары жиі талқыланады. Қауіпсіздік тұрғысынан, микроядролардың минималдылық принципі, кейбіреулердің пікірінше, барлық кодқа қажетті функционалдылықты қамтамасыз ету үшін қажетті құқықтар ғана берілуі керек деген ең аз құқықтар қағидасының тікелей салдары болып табылады. Минималдылық жүйенің сенімді есептеу базасын (TCB) ең аз деңгейде ұстап тұруды талап етеді. Ядро (аспаптық жабдықтың артықшылықты режимінде орындалатын код), тексерілмеген деректерге қол жеткізе алады және осылайша олардың тұтастығын немесе құпиялылығын бұза алады, сондықтан ядро әрқашан TCB-ның бөлігі болып табылады. Қауіпсіздікке бағытталған жобалауда оны азайту табиғи. Осының салдарынан, микроядролық жобалар жоғары қауіпсіздікті талап ететін жүйелер үшін, соның ішінде KeyKOS, EROS және әскери жүйелер үшін қолданылды. Шындығында, ең жоғары сенімділік деңгейіндегі (Бағалаудың сенімділік деңгейі (EAL) 7) ортақ критерийлерде бағалау нысанының "қарапайым" болуы керек деген талап бар, бұл күрделі жүйеге нақты сенімділік орнатудың практикалық мүмкін еместігін мойындау. Бірақ "қарапайым" термині шатастырады және дұрыс анықталмаған. Кем дегенде, Қорғаныс министрлігінің Сенімді Компьютерлік Жүйелерді Бағалау Критерийлері B3/A1 сыныптарында біршама дәл тіл қолданды: text="ТКБ нақты анықталған семантикасы бар толық, түсініксіз қарапайым қорғау механизмдерін [іске асыруы] тиіс. Маңызды жүйелік инженерия ТКБ-ның күрделілігін азайтуға, сондай-ақ қорғау үшін маңызды емес модульдерді TКB-дан шығаруға бағытталған."|sign=|source=Қорғаныс министрлігінің Сенімді Компьютерлік Жүйелерді Бағалау Критерийлері

The security benefits of microkernels have been frequently discussed. In the context of security the minimality principle of microkernels is, some have argued, a direct consequence of the principle of least privilege, according to which all code should have only the privileges needed to provide required functionality. Minimality requires that a system's trusted computing base (TCB) should be kept minimal. As the kernel (the code that executes in the privileged mode of the hardware) has unvetted access to any data and can thus violate its integrity or confidentiality, the kernel is always part of the TCB. Minimizing it is natural in a security driven design. Consequently, microkernel designs have been used for systems designed for high security applications, including KeyKOS, EROS and military systems. In fact common criteria (CC) at the highest assurance level (Evaluation Assurance Level (EAL) 7) has an explicit requirement that the target of evaluation be "simple", an acknowledgment of the practical impossibility of establishing true trustworthiness for a complex system. Again, the term "simple" is misleading and ill defined. At least the Department of Defense Trusted Computer System Evaluation Criteria introduced somewhat more precise verbiage at the B3/A1 classes:

text="The TCB shall [implement] complete, conceptually simple protection mechanisms with precisely defined semantics. Significant system engineering shall be directed toward minimizing the complexity of the TCB, as well as excluding from the TCB those modules that are not protection critical. "|sign=|source=Department of Defense Trusted Computer System Evaluation Criteria

In 2018, a paper presented at the Asia Pacific Systems Conference claimed that microkernels were demonstrably safer than monolithic kernels by investigating all published critical CVEs for the Linux kernel at the time. The study concluded that 40% of the issues could not occur at all in a formally verified microkernel, and only 4% of the issues would remain entirely unmitigated in such a system.

2018 жылы Азия-Тынық мұхиты жүйелері конференциясында ұсынылған мақалада, сол кездегі Linux ядросы үшін жарияланған барлық маңызды CVE-лерді зерттеу арқылы микроядролар монолиттік ядролардан айқын түрде қауіпсіз екендігі көрсетілді. Зерттеу нәтижесінде, мәселелердің 40%-ы ресми тексерілген микроядрода мүлдем туындамайды, ал мәселелердің 4%-ы ғана осындай жүйеде толыққанды шешілмейді.