From 191ad51eaad7cdc8279679c86881fb05abb32ab1 Mon Sep 17 00:00:00 2001 From: mintsuki Date: Mon, 6 Feb 2023 20:24:57 +0100 Subject: [PATCH] docs: Add PHILOSOPHY.md --- PHILOSOPHY.md | 32 ++++++++++++++++++++++++++++++++ README.md | 15 +++++++-------- 2 files changed, 39 insertions(+), 8 deletions(-) create mode 100644 PHILOSOPHY.md diff --git a/PHILOSOPHY.md b/PHILOSOPHY.md new file mode 100644 index 00000000..6bd5a52a --- /dev/null +++ b/PHILOSOPHY.md @@ -0,0 +1,32 @@ +# Limine's Design Philosophy + +### Why not support filesystem X or feature Y? (eg: LUKS, LVM) + +The idea with Limine is to remove the responsibility of parsing filesystems and formats, aside from the bare minimum necessities (eg: FAT*, ISO9660), +from the bootloader itself. +It is a needless duplication of efforts to have bootloaders support all possible filesystems and formats, and it leads to massive, bloated +bootloaders as a result (eg: GRUB2). +What is needed is to simply make sure the bootloader is capable of reading its own files, configuration, and be able to load kernel/module files +from disk. The kernel should be responsible for parsing everything else as it sees fit. + +### What about LUKS? What about security? Encrypt the kernel! + +Simply put, this is unnecessary. Putting the kernel/modules in a readable FAT32 partition and letting Limine know about their BLAKE2B checksums +in the config file provides as much security as encrypting the kernel does. + +### What? But what if someone modifies the config file! Ha! You clearly have not thought about that! + +We have. While this is a pointless effort on legacy x86 BIOS, it is a reasonable expectation on UEFI systems with Secure Boot. Limine provides a +way to modify its own EFI executable to bake in the BLAKE2B checksum of the config file itself. The EFI executable gets then enrolled or otherwise +verified by the Secure Boot loader through, eg., the shim project. This prevents modifications being done to the config file (and in turn the +checksums contained there) from going unnoticed. + +### What about ext2/3/4? Why is that supported then? + +Simply put, legacy. And because a lot of Linux users expect it to "work that way". It is not unreasonable for ext2/3/4 support to be eventually +dropped. + +### But I don't want to have a separate FAT boot partition! I don't want it!!! + +Well tough luck. It is `$year_following_2012` now and most PCs are equipped with UEFI and simply won't boot without a FAT EFI system partition +anyways. It is not unreasonable to share the EFI system partition with the OS's /boot and store kernels and initramfses there. diff --git a/README.md b/README.md index 0c0223be..baae898d 100644 --- a/README.md +++ b/README.md @@ -23,19 +23,18 @@ as the reference implementation for the [Limine boot protocol](/PROTOCOL.md). * Multiboot 2 * Chainloading +### Supported partitioning schemes +* MBR +* GPT +* Unpartitioned media + ### Supported filesystems * ext2/3/4 * FAT12/16/32 * ISO9660 (CDs/DVDs) -Even though these are the filesystems Limine supports directly, *any* -filesystem can be utilised by the kernel provided that the kernel (and any -needed modules) are on a directly supported filesystem. - -### Supported partitioning schemes -* MBR -* GPT -* Unpartitioned media +If your filesystem isn't listed here, please read [the philosophy](/PHILOSOPHY.md) first, especially before +opening issues or pull requests related to this. ### Minimum system requirements For 32-bit x86 systems, support is only ensured starting with those with