221–230 of 460 posts
I have programmed the ROM to instantaneously copy my ROM to RAM and run. The entire system is running instantly as soon as I power on. There is absolutely nothing else.
Because everything else is a big mess:
Intel ME, BIOS, UEFI, kernels are signed by companies with Microsoft's blessing, EFI, FAT, TPM, anything with the word "Secure" in it, ...
Meta: Can someone with Linux/bootloader knowledge tell me whether most of these comments are as clueless as they seem?
I don't understand the point of the thing described in the OP (I have not watched the talk, just skimmed the notes), myself. Linux kernels can EFI load themselves; if you want more flexibility than a precompiled kernel command line, or to load from ext4/other non-FAT filesystems, refind exists, fits on the ESP (kernel + initramfs can get big; I keep mine on the ESP but wanting to keep it on a larger ext4 filesystem is very understandable) and is very high quality.
Bootloaders are obsolete in this sense; every OS provides an EFI stub loader, except Linux where kernels are their own EFI stub; nevertheless, distros continue to install GRUB alongside themselves on UEFI systems out of inertia. If Red Hat wants to supplant it... okay, but it can be supplanted today with very good components, even if they weren't invented there.
An EFI stub that sets up multi-boot, kernel and initrd then jumps into it is pretty simple. I don't know why people really need to keep putting huge intermediate loaders in every default boot path. If you want to boot more than one OS, yes you need one of these, but if you don't then there's no need for yet another OS instance in the boot path. The mid-stage should be extremely small and simple. There's been so much…
Nope, you only need refind (a fancy menu, not a bootloader at all), and only then because of how impoverished the vendor's boot menu always is; if your configuration is simple enough you could just use that despite it sucking.
Earlier quoted context omitted.
What is your actual need here? You talk about confusing documentation for a low-level process which basically no user is expected to go through if they aren't exploring the foundations of a linux system, or a developer working on their own distribution, and then complain that this is a lack of "a decent installer process".
It’s in the post, can’t you read? Also, something being low-level has nothing to do with documentation.
Whenever you feel like attacking someone else's reading ability, perhaps take a deep breath and remember this HN guideline:
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
Energy might be better spent explaining/defending the points you made. Similar to what the person you're replying to has been doing.
What I want is for each OS to install its loader in a unique directory to that OS instance, not unique to the OS vendor. Multiple Debians etc will argue over who controls /debian. You also have to bless UEFI with magic NVRAM variables when it could just scan my EFI System Partitions for any file named “loader” and present that as a boot option.
Perhaps I should just chain from UEFI to something smarter that skips the UEFI-standard and does this smarter thing instead? Debianised GRUB tries to be smart at update-grub time in order to detect OSs but it would be neater if the loader did it.
Edit: In fact I see this is exactly the goal of rEFInd https://www.rodsbooks.com/refind/ …in particular it laments how “EFI implementations should provide boot managers [but] are often so poor as to be useless” so it tries to do a better job for you. I’ll give it a go.
Earlier quoted context omitted.
Isn't everything that GRUB reads only writable by root? Is the threat model that root is the attacker?
Or by anyone with physical access to your system, but also root isn't the same as the kernel - if your boot chain is fully verified then even root can't replace the component asking for your disk encryption key, and can't extract it from the kernel afterwards (assuming a secure kernel)
I have a bootloader signed with my own keys to boot my kernel. Nothing else will be able to boot the machine. I couldn't have this setup without a bootloader.
You absolutely can sign the kernel with your own keys. This would allow you to boot your machine into the first level kernel without the bootloader. Is this 'couldn't' a self imposed requirement or a technical one I can't think of ?
Probably not technical. There is another element, obtaining a HDD encryption key from the TPM. The idea that the HDD is encrypted outside of my laptop and nothing can boot on my laptop that isn't my signed OS to read it.
Thinking about it I probably could do everything in the kernel directly - why not? Well, because it would be extra work to write all that, but probably not a technical limitation.
You had the bootloader because first you needed executable code in the first sector of the partition, and you can't fit much in those 512 bytes. But moving to UEFI means you never execute that code anymore. Instead, you load a BOOT.EFI file off of a FAT16/FAT32 partition. If there's a restriction on size for that, then you proceed to a bootloader instead of the real kernel.
Also create a boot please that rivals w10's almost instant boot process. I just hate the current slow/non parallel boot process.
Otherwise, I while I would not describe the boot process of most of the linux I own as "instant" they are certainly booting quite faster that windows.
Earlier quoted context omitted.
Or by anyone with physical access to your system, but also root isn't the same as the kernel - if your boot chain is fully verified then even root can't replace the component asking for your disk encryption key, and can't extract it from the kernel afterwards (assuming a secure kernel)
Can't someone with physical access to my system also pull out the hard drive, edit it however they want, and change Secure Boot settings too? And I don't want there to be anything even root can't do, since then there's stuff I can't do to my own computer.
As a device owner you have the option to recompile your kernel to disable any of the root/kernel barriers - when we designed Shim we did so in a way that ensures that you're always able to disable secure boot. Or you can simply disable secure boot entirely (another feature offered by Shim) at which point the kernel will disable most of those features. But by default the kernel will still, for example, refuse to allow even root to mmap() address regions belonging to hardware - some of those restrictions are down to "This has a high risk of causing accidental data corruption" rather than anything nefarious.