Kernel Loader
Contents
Functions
KernelLdr is called immediately by the Kernel’s crt0 (after it deprivileges from EL2 to EL1, if required), with the following signature:
KernelLdr_Main
Next, it applies relocations to itself and calls its init array.
[9.0.0+] Then it clears TPIDR_EL1 to 0, and sets VBAR_EL1.
Then, it calls the function which relocates the kernel, and jumps back to the kernel entrypoint.
KernelLdr_ApplyRelocations
Then it does the following two loops to apply R_AARCH64_RELATIVE relocations:
KernelLdr_libc_init_array()
KernelLdr_LoadKernel
First, it backs up the original kernel base, and then relocates the kernel physically to the upper half of DRAM if enough memory is available.
Then it checks all of the kernel map’s offsets (and the kernel base) for page alignment.
Next, it relocates the INI1 to its appropriate load address.
Next, it initializes the MMU with a basic identity mapping for Kernel + KernelLdr.
Next, it generates a random KASLR slide for the Kernel.
Then, it maps the kernel at the final virtual address.
Finally, it returns the difference between the kernel’s original physical base address and the relocated kaslr’d virtual base address.
KernelLdr_MapInitialIdentityMapping
First, this creates a new page table (eventually ends up in TTBR0_EL1), and adds identity mappings for Kernel, KernelLdr, and the Page Table region to it.
Next, this sets some system registers.
Next, the cache is flushed, to ensure that page tables will be successfully read once the MMU is enabled.
Finally, SCTLR is written to, enabling the MMU.
KernelLdr_RelocateKernelPhysically
This retrieves memory layout information from the secure monitor, and adjusts the kernel’s physical location if necessary.
KernelLdr_GetAdjustedKernelPhysicalBase
This sees how much more memory is available than expected, and relocates the kernel accordingly.
Note: Panic (infloop) happens on any smc call error, this isn’t depicted in pseudocode for brevity reasons.
KernelLdr_ShouldReserveAdditionalKernelData
This just gets a flag from the KernelConfiguration.
Note: Panic (infloop) happens on any smc call error, this isn’t depicted in pseudocode for brevity reasons.
KernelLdr_GenerateRandomRange
This uses entropy from the secure monitor to generate a random value in a range (inclusive).
KernelLdr_EnsureCacheFlushed
Note: this is inlined, however it uses instructions that no compiler has intrinsics for (and looks like hand-written asm), so it’s presumably its own thing.
KernelLdr_InvalidateCacheLocal
Standard ARM cache clean code, uses LoUIS + LoC from CLIDR_EL1.
KernelLdr_InvalidateCacheShared
Standard ARM cache clean code, uses LoUIS from CLIDR_EL1.
KernelLdr_ExceptionTable
Standard aarch64 exception table, only function that doesn’t infinite loop is synchronous exception from same EL (synch_spx_exception)
synch_spx_exception does the following:
KernelLdr_SaveRegistersToTpidrEl1
This saves X19-X30 + SP to an input pointer, and moves the pointer into TPIDR_EL1.
KernelLdr_VerifyTpidrEl1
This just verifies that TPIDR_EL1 is equal to an input argument, and clears it.
KInitialPageAllocator::KInitialPageAllocator
This sets the allocator’s next address to 0 (guessed, since this is done statically in KernelLoader).
KInitialPageAllocator::Initialize
This sets the allocator’s next address (function inferred as it is (presumably) inlined and next_address is (presumably) private).
KInitialPageAllocator::Finalize
This just clears the allocator’s next address.
KInitialPageAllocator::Allocate
This linearly allocates a page.
KInitialPageAllocator::Free
This frees a page (implemented as noop in KernelLoader)
KInitialPageTable::KInitialPageTable
NOTE: This constructor is inferred.
KInitialPageTable::Map
This is just standard aarch64 page table mapping code. New L2/L3 pages are allocated via allocator->Allocate() when needed.
KInitialPageTable::IsFree
This is just standard aarch64 page table code. Walks the page table, verifying that all entries it would map for size + range are free.
KInitialPageTable::ReprotectToReadOnly
This is just standard aarch64 page table code. Walks the page table, reprotects the read-write pages in the specified region as read-only.
This is probably a compiler-optimized version of a function that does an arbitrary reprotection.
KInitialPageTable::GetL1Table
This is an inferred getter for a (presumably) private member.
Structures
KernelMap
| Offset | Size | Description |
|---|---|---|
| 0x0 | 4 | .text offset |
| 0x4 | 4 | .text end offset |
| 0x8 | 4 | .rodata end offset |
| 0xC | 4 | .rodata end offset |
| 0x10 | 4 | .rwdata offset |
| 0x14 | 4 | .rwdata end offset |
| 0x18 | 4 | .bss offset |
| 0x1C | 4 | .bss end offset |
| 0x20 | 4 | INI1 end offset |
| 0x24 | 4 | .dynamic end offset |
| 0x28 | 4 | .init_array end offset |
| 0x2C | 4 | .init_array end offset |
KInitialPageAllocator
KInitialPageAllocator is just a simple linear allocator.
| Offset | Size | Description |
|---|---|---|
| 0x0 | 8 | vtable; |
| 0x8 | 8 | Next Address; |
KInitialPageAllocator::vtable
| Offset | Size | Description |
|---|---|---|
| 0x0 | 8 | void *(*Allocate)(KInitialPageAllocator *this); |
| 0x8 | 8 | void (*Free)(KInitialPageAllocator *this, void *address); |
KInitialPageTable
KInitialPageTable is a very, very stripped-down KPageTable.
Compared to pre-KernelLoader KInitialPageTable, it has slightly reduced memory footprint.
Долгая загрузка системы
Startup finished in 14.244s (firmware) + 4.856s (loader) + 1.638s (kernel) + 1.371s (initrd) + 3.140s (userspace) = 25.250s
и тоже SSD.
при том 14.244s (firmware) + 4.856s (loader) это считается реально со старта компа (подачи питания или ресета), там задержки, POST и др.
nixxx
Startup finished in 11.667s (firmware) + 100ms (loader) + 6.785s (kernel) + 21.083s (userspace) = 39.636s
nafanja
21 сек. это графическая оболочка грузится
graphical.target @20.185s
└─sddm.service @20.183s
The time when unit became active or started is printed after the «@» character
не НА, а ЗА.
НА какой секунде стартанул видно только из графика загрузки.
вот я это проэмулировал, на этапе загрузчика, долго не выбирал пункт с которого грузится.
Startup finished in 6.622s (firmware) + 56.346s (loader) + 1.865s (kernel) + 1.345s (initrd) + 3.178s (userspace) = 1min 9.357s
получилось так что загрузчик стартонул и ждал 56 сек. пока я не выбрал пункт.
А если серъезно, то поддержу indeviral
indeviral
Что значит долго? Меньше 5 минут значит нормально.
Ерундой занимаетесь…
Без UEFI у Вас не учитывается 9.229s (firmware) + 15.766s (loader) инициализация биоса и загрузчик(время выбора в загрузчике пункта)
считайте после загрузчика
мой 2.823s (kernel) + 3.896s (userspace)
нафанин 1.865s (kernel) + 1.345s (initrd) + 3.178s (userspace)
vs220
долгая загрузка обычно показатель каких то неполадок
Что такое KERNEL.EXE? Это безопасно или вирус? Как удалить или исправить это
Что такое KERNEL.EXE?
kERNEL.EXE это исполняемый файл, который является частью Windows разработанный Microsoft, Версия программного обеспечения для Windows: 1.0.0.0 обычно 56960 в байтах, но у вас может отличаться версия.
KERNEL.EXE безопасен, или это вирус или вредоносная программа?
Первое, что поможет вам определить, является ли тот или иной файл законным процессом Windows или вирусом, это местоположение самого исполняемого файла. Например, для KERNEL.EXE его путь будет примерно таким: C: \ Program Files \ Microsoft \ Windows \ KERNEL.EXE.
Если статус процесса «Проверенная подписывающая сторона» указан как «Невозможно проверить», вам следует взглянуть на процесс. Не все хорошие процессы Windows имеют метку проверенной подписи, но ни один из плохих.
Наиболее важные факты о KERNEL.EXE:
Если у вас возникли какие-либо трудности с этим исполняемым файлом, вы должны определить, заслуживает ли он доверия, прежде чем удалять KERNEL.EXE. Для этого найдите этот процесс в диспетчере задач.
Найти его местоположение и сравнить размер и т. Д. С приведенными выше фактами
Если вы подозреваете, что можете быть заражены вирусом, вы должны немедленно попытаться это исправить. Чтобы удалить вирус KERNEL.EXE, необходимо скачайте и установите приложение полной безопасности, как это, Обратите внимание, что не все инструменты могут обнаружить все типы вредоносных программ, поэтому вам может потребоваться попробовать несколько вариантов, прежде чем вы добьетесь успеха.
Могу ли я удалить или удалить KERNEL.EXE?
Не следует удалять безопасный исполняемый файл без уважительной причины, так как это может повлиять на производительность любых связанных программ, использующих этот файл. Не забывайте регулярно обновлять программное обеспечение и программы, чтобы избежать будущих проблем, вызванных поврежденными файлами. Что касается проблем с функциональностью программного обеспечения, проверяйте обновления драйверов и программного обеспечения чаще, чтобы избежать или вообще не возникало таких проблем.
Однако, если это не вирус, и вам нужно удалить KERNEL.EXE, вы можете удалить Windows с вашего компьютера, используя программу удаления. Если вы не можете найти его деинсталлятор, то вам может понадобиться удалить Windows, чтобы полностью удалить KERNEL.EXE. Вы можете использовать функцию «Установка и удаление программ» на панели управления Windows.
Распространенные сообщения об ошибках в KERNEL.EXE
Наиболее распространенные ошибки KERNEL.EXE, которые могут возникнуть:
• «Ошибка приложения KERNEL.EXE».
• «Ошибка KERNEL.EXE».
• «KERNEL.EXE столкнулся с проблемой и будет закрыт. Приносим извинения за неудобства».
• «KERNEL.EXE не является допустимым приложением Win32».
• «KERNEL.EXE не запущен».
• «KERNEL.EXE не найден».
• «Не удается найти KERNEL.EXE».
• «Ошибка запуска программы: KERNEL.EXE.»
• «Неверный путь к приложению: KERNEL.EXE.»
Как исправить KERNEL.EXE
Если у вас возникла более серьезная проблема, постарайтесь запомнить последнее, что вы сделали, или последнее, что вы установили перед проблемой. Использовать resmon Команда для определения процессов, вызывающих вашу проблему. Даже в случае серьезных проблем вместо переустановки Windows вы должны попытаться восстановить вашу установку или, в случае Windows 8, выполнив команду DISM.exe / Online / Очистка-изображение / Восстановить здоровье, Это позволяет восстановить операционную систему без потери данных.
Чтобы помочь вам проанализировать процесс KERNEL.EXE на вашем компьютере, вам могут пригодиться следующие программы: Менеджер задач безопасности отображает все запущенные задачи Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записи автозапуска. Единый рейтинг риска безопасности указывает на вероятность того, что это шпионское ПО, вредоносное ПО или потенциальный троянский конь. Это антивирус обнаруживает и удаляет со своего жесткого диска шпионское и рекламное ПО, трояны, кейлоггеры, вредоносное ПО и трекеры.
Обновлен декабрь 2021:
Мы рекомендуем вам попробовать этот новый инструмент. Он исправляет множество компьютерных ошибок, а также защищает от таких вещей, как потеря файлов, вредоносное ПО, сбои оборудования и оптимизирует ваш компьютер для максимальной производительности. Это исправило наш компьютер быстрее, чем делать это вручную:
Загрузите или переустановите KERNEL.EXE
Вход в музей Мадам Тюссо не рекомендуется загружать файлы замены exe с любых сайтов загрузки, так как они могут сами содержать вирусы и т. д. Если вам нужно скачать или переустановить KERNEL.EXE, то мы рекомендуем переустановить основное приложение, связанное с ним Windows.
Основными функциями Windows 7 являются:
Информация об операционной системе
Ошибки KERNEL.EXE могут появляться в любых из нижеперечисленных операционных систем Microsoft Windows:
Linux kernel development для самых маленьких
Любой программист знает, что теоретически он может внести свой посильный вклад в развитие Linux ядра. С другой стороны, подавляющее большинство уверено, что занимаются этим исключительно небожители, а процесс контрибьюта в ядро настолько сложен и запутан, что обычному человеку разобраться в нём нет никакой возможности. А значит, и надобности.
Сегодня мы попробуем развеять эту легенду и покажем, как абсолютно любой инженер при наличии достойной идеи, воплощённой в коде, может предложить ее на рассмотрение Linux community для включения в ядро.
0. Подготовка
Как и перед любой инженерной операцией, всё начинается с подготовки своего рабочего места. И первейшее здесь действие — это завести себе аккаунт с адекватным именем. В идеальном мире это будет просто транскрипция имени и фамилии. Если за учётку вроде MamkinC0d$r или Developer31337 в других местах пальцем в вас тыкать не будут, то правила LKC (Linux kernel community) такое прямо запрещают — инкогнито контрибьютить в ядро не принято.
Далее вам понадобится место на локальной машине. Сама папка Linux со скачанными исходниками весит чуть меньше 3-х гигов. Но если ядро пробовать собирать, то вместе с модулями займёт все 30 GB.
Захотелось собрать несколько веток? Умножаем 30 на число веток.
И помним — скорость сборки прямо связана с количеством доступных ядер! Больше ядер — быстрее соберётся. Так что не стесняйтесь выделять под это самую мощную машину.
1. Mail
Самый спорный и поэтому регулярно вызывающий споры момент — это канал коммуникации с LKC. Он безальтернативно один. Почта. Причём сообщения отправляются по классике через smtp.
Вокруг необходимости делать всё через плейнтекст в почте есть масса споров. Недавно в сети была очередная громкая статья на эту тему. Суть материала: письма — это, конечно, здорово, но пихать туда всё, включая куски кода — это вам (т.е. LKC) популярности не добавляет и даже наоборот, отпугивает новичков. С одной стороны вроде и да, если ты не можешь спокойно и структурировано изложить свои мысли в голом тексте, то в низкоуровневой разработке ловить будет особо нечего. С другой стороны, слать в письмах сорсы патчей — это даже архаизмом назвать уже сложно.
Но, как принято в уютном мирке ядра, Линус хлопнул кулаком по столу — и все пишут письма. Возможно, буквально завтра это изменится, но на момент выхода статьи это письма и только письма.
Какой email-client выбрать — есть рекомендации. Самым рекомендуемым почтовым агентом для LKC остаётся mutt. Да, тот самый текстовый почтовый клиент, от которого сводит олдскулы. Для начала mutt нужно поставить (я думаю, со своим пакетным менеджером вы и сами справитесь), а потом задать параметры в файле
Но почты недостаточно. Без Git никуда.
2. Git
Прежде чем что-то делать с исходниками ядра, нужно настроить Git. Можно конфигурировать файлы напрямую, но есть упрощающая жизнь утилита git config, через которую можно регулировать все аспекты работы Git’a.
Глобальные настройки хранятся в /etc/gitconfig, настройки пользователя в
В общем случае будет достаточно законфигурировать файл для пользователя
signOff обязателен, чтоб в коммитах была информация об авторе. По идее, надо бы, чтобы коммиты подписывались. Была тут недавно статья на эту тему.
Отправка патча выполняется командой git send-email. У git send-email есть несколько параметров с участием smtp, которые можно (и нужно) переопределить.
Итак, окно в большой мир прорубили. Можно переходить к воплощению своей грандиозной идеи в коде.
3. Coding
Итак, мы готовы сделать первый шаг непосредственно в разработке — склонировать к себе репозиторий. Советую делать это сразу с указанием ветки, которая будет создана. Также отмечу, что работать лучше не над текущим состоянием в master, а над стабильной версией или кандидатом на релиз. Так вы будете более уверены, что ядро соберётся и будет как-то работать, не вызовет неожиданных конфликтов из-за изменений в других подсистемах. Поэтому всегда внимательно смотрите тэги.
И — опять же — имя своей ветке постарайтесь дать чёткое и лаконичное. В идеальном мире оно даже может отображать суть вносимых изменений. Если вы исправляете известный баг, то хорошим тоном считается включить в название ветки номер issue.
Операция довольно долгая, так что смело можно идти за кофе или на обед. А если попробовать ускорить процесс, отказавшись от истории, то работать с «этим» будет невозможно.
Итак, мы получили ветку, в которой можно начинать свою разработку. Здесь всё очевидно: пишем код, собираем, тестируем, исправляем баги — и так до получения нужного результата. О том, как собирать ядро и проводить отладку, информации в сети море, так что подробно описывать весь процесс я не буду. Лишь вкратце пробежимся по нему чуть позже. Единственный нюанс, который добавлю от себя прямо сейчас: перед сборкой проверьте наличие всех необходимых программ из этого списка и их минимальные версии.
Если бродить вслепую по гуглу не хочется, то вся максимально полезная информация по ядру сконцентрирована тут. Прочитать стоит действительно всё. Особенно правильно будет начать с How To о том, как правильно коммуницировать. Потому что мейнтейнеры, как правило, люди весьма занятые, и вникать в невнятно составленные письма им никакого интереса. Да и вам будет обидно, если из-за плохого описание ваше детище не примут в апстрим.
После того, как пройдёт первое удивление и вы доустановите необходимые компоненты для python2 типа ply и git (который у меня так и не установился), наступит чудесное время исправления ошибок и ворнингов. По результатам которых вы а) поймёте, что красивый код писать вы не умеете б) потеряете всякое желание что-то куда-то отправлять. Ведь даже если отбросить все шутки, ещё можно как-то смириться с тем, что длина строк ограничена 100 символами (это начиная с версии 5.7, раньше так было вообще 80). Но вот такие места оставляют неизгладимое впечатление:
Для .h файлов строка с информацией о лицензии должна быть в ремарках / * */, а для *.c файлов должна быть в ремарках //. Такое запросто выбьет кого угодно из душевного равновесия. Вопрос: «Зачем?!» до сих пор болтается в моей голове, хотя есть вера в то, что это не просто ошибка в скриптах.
Кстати, чтобы просто проверить один файл достаточно вызвать
Можно прикрутить этот вызов к git, чтобы автоматически запускался этот скрипт при попытке что-то зачекинить.
4. Kernel build
Несмотря на то, что процесс описан в других статьях тут и тут, я все же повторюсь.
По шагам процесс сборки ядра довольно прост, если не вдаваться в детали. Для начала ставим необходимые пакеты (использовался Debian 10):
Это без компилятора и обычного для С/С++ разработчика набора программ.
Запускаем конфигурацию:
Тут есть интересный аспект: в качестве шаблона будет браться config ядра от вашего боевого ядра, которое, скорее всего, подготовлено дистрибьютером. Для Debian 10 сборка проходит успешно, если в конфиге потереть информацию о встраиваемых в ядро сертификатах.
Перед попыткой собрать проверьте, что нужные программы уже установлены. Список тут. Чтобы собрать само ядро:
Этого достаточно для проверки собираемости, но недостаточно для запуска ядра в системе, так как без модулей ядро на реальной системе практически беспомощно.
Если какой-то модуль не собирается, просто вырубите его в ближайшем Makefile-е (если 100% уверены, что не пытались в нём что-то улучшить). Наверняка он вам не пригодится, и тратить время на исправления смысла нет.
Теперь можно деплоить то, что получилось, на эту же систему.
Хотя, конечно, экспериментировать с ядром на той же машине, где ведётся разработка — дело рискованное.
Поэтому как минимум нужно снять снапшот, сделать резервную копию или лучше вообще выполнять отладку на другой (лучше виртуальной) машине. Но как это делать, я пока не разбирался. Если у кого есть такой опыт — пишите в комменты, добавлю в статью.
На моей системе загрузчик после установки ядра автоматически обновился. Если у вас этого не произошло, то это делается это на Debian-подобных системах командой:
Update: Как верно заметил gavk, ядро давно уже умеет собирать пакеты, причём как для deb, так и для rpm.
Команда
выводит весь ассортимент. Так что команда
должна собрать пакет с ядром.
5. Patches
Вот теперь мы действительно подготовили код для отправки. Лучше всего, чтобы это был единственный коммит. Так проще делать ревью и так быстрее вам ответят. Всё проверив, наконец-то делаем коммит.
Ещё можно комментарии к коммиту дополнить в человеческом текстовом редакторе.
И теперь его можно оформить в виде того самого письма. Правила хорошего тона, или best practice, если угодно — это 75 символов на строку.
В результате получите два файла. В первом 000-cover-letter.patch нужно указать заголовок письма «Subject» и основное описание патча. В описании патча пишем, для чего он создавался, кому он сделает жизнь на нашей планете лучше и каким образом. Только не словоблудим про космические корабли в Большом театре, а пишем лаконично и по делу. И не в коем случае не пишите корпоративную лабуду а-ля «Без этого патча мой бизнес встанет, меня уволят, а дети мои умрут от голода». Нет, строго по существу: «Увидел вот такую проблему вот тут, починить решил вот таким образом, исходники патча прилагаю». Всё, вы восхитительны! А если не превысили 75 символов на строку, то восхитительны в квадрате.
позволит узнать, кому письмо отправлять.
И вот он, момент отправления письма, ради которого всё и затевалось:
Дальше остаётся только сидеть и ждать ответного письма, где вам скорее всего скажут, что всё здорово, но надо ещё сделать вот это и поправить вот здесь. Возможно, придётся доказывать, что ваш функционал действительно новый и не создаёт дублирования. Хотя могут и сразу всё принять, сказав большое спасибо (шутка :-).
После того, как ваш патч был принят, крайне желательно удалить свою ветку.
6. Debuging
И чуть-чуть про отладку. Бонус «на сладкое» для начинающих разработчиков ядра, так сказать.
Как правило, при ошибке вы получаете лог с calltrace-ом. Там указываются имена функций и смещения. Примерно вот так:
Так вот, чтобы понять, в каком месте функции произошла ошибка, достаточно запустить дебагер с подгруженным в него модулем:
Важно, чтобы в модуле сохранились символы (stripped модуль вам тут не поможет).
Выполнив команду list
вы увидите строку кода, приведшую к ошибке. В случае передачи управления по неверному адресу, вы увидите следующую за ошибкой строку.
И на этом позвольте откланяться.
Буду рад вопросам и замечаниям в комментариях.
