Perfect! I've worked with a lot of C kernel security devs and I don't think I've ever seen one of them write something not Cish, like python/ruby/go/etc. So, w

Perfect! I've worked with a lot of C kernel security devs and I don't think I've ever seen one of them write something not Cish, like python/ruby/go/etc. So, what exactly happens here - you need to write a kernel in some super fast low level language like C. I THINK The kernel that you write is probably talking to, for instance an Intel/AMD CPU, Motherboard, GPU, etc API to access the hardware. Is this close/wrong? If I made a completely new kernel how do I boot it? Does the kernel have its own API that the BIOS calls? Does the BIOS have anything to do with the kernel but instead something starts Windows and that loads the kernel? I think the kernel mounts/becomes aware of all of the hardware (apis?) potentially by the motherboard telling it what's on it. Does the BIOS just start any C app you point it at and they're just C apps that start the kernel? Maybe it goes through the motherboard for most of it.. Maybe it accesses every piece of hardware directly without an API somehow? This may be stupid questions but hopefully they make sense.. And thanks if you or anyone has input! edit: There's a Boot processing of linux Wiki [1] thats pretty good > After being loaded into RAM, bootloader (also called first-stage bootloader or primary bootloader) will execute to load the second-stage bootloader[2] (also called secondary bootloader).[6] The second-stage bootloader will load the kernel image into memory, decompress and initialize it then pass control to this kernel image.[2] Second-stage bootloader also performs several operation on the system such as system hardware check, mounting the root device, loading the necessary kernel modules,...[2] Finally, the very first user-space process (init process) starts, and other high-level system initializations are performed (which involve with startup scripts).[2] > For each of these stages and components, there are different variations and approaches; for example, GRUB, coreboot or Das U-Boot can be used as bootloaders (historical examples are LILO, SYSLINUX or Loadlin), while the startup scripts can be either traditional init-style, or the system configuration can be performed through modern alternatives such as systemd or Upstart. > The intermediate stage loader (stage1.5, usually core.img) is loaded and executed by the stage1 loader. The second-stage loader (stage2, the /boot/grub/ files) is loaded by the stage1.5 and displays the GRUB startup menu that allows the user to choose an operating system or examine and edit startup parameters. After a menu entry is chosen and optional parameters are given, GRUB loads the linux kernel into memory and passes control to it. GRUB 2 is also capable of chain-loading of another bootloader. In UEFI systems, the stage1 and stage1.5 usually are the same UEFI application file (such as grubx64.efi for x64 UEFI systems). [1] - https://en.wikipedia.org/wiki/Booting_process_of_Linux#:~:text=After%20being%20loaded%20into%20RAM,control%20to%20this%20kernel%20image https://en.wikipedia.org/wiki/Booting_process_of_Linux#:~:te.... [2] - https://www.gnu.org/software/grub/manual/grub/html_node/Images.html https://www.gnu.org/software/grub/manual/grub/html_node/Imag... [3] - Potentially how systemd starts installing the kernel https://github.com/ivandavidov/systemd-boot/blob/master/project/src/kernel-install/kernel-install https://github.com/ivandavidov/systemd-boot/blob/master/proj... [4] - This looks like it's a TPM authentication shim that sits between the EFI and Kernel - https://github.com/ivandavidov/systemd-boot/blob/5521e37e77ac8bd1cff5d8f15d6533c815e7974b/project/src/sd-boot/shim.c#L125 https://github.com/ivandavidov/systemd-boot/blob/5521e37e77a... [5] - Ok this is super helpful, a project on writing a minimal kernel - https://www.codeproject.com/Articles/1225196/Create-Your-Own-Kernel-In-C-2 https://www.codeproject.com/Articles/1225196/Create-Your-Own... [6] - And wow the GNU bootloader spec is rough - https://www.gnu.org/software/grub/manual/multiboot/multiboot.pdf https://www.gnu.org/software/grub/manual/multiboot/multiboot...