Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux boot partitions and how to set them up

0pointer.net

Post reply on HN
Print view View original

151–160 of 184 posts

Re: Linux boot partitions and how to set them up

#151

Post by theandrewbailey »

effie wrote: post #149

> In a trusted boot world, the two file systems for the ESP and the /boot/ partition should be considered untrusted: any code or essential data read from them must be authenticated cryptographically before use. In the real world, my ESP and boot partition are trusted, since I've installed them and control them and can check them for malware, and the firmware is not trusted since there is no possibility of control, it…

How often do you check your unauthenticated ESP and /boot for malware? Only when you suspect malware is already there? If so, it's too late. Locking them down as suggested helps to prevent the issue altogether. Yes, firmware should not be trusted, but reducing attack surfaces is a good thing.

As far as your last point, the vast majority of people aren't competent computer owners or users. They don't know what to do on a technical level with malware in their boot process.

Re: Linux boot partitions and how to set them up

#152

Post by [deleted] »

iam-TJ wrote: post #130
hyperupcall wrote: post #65

This is excellent! Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously, dd'd USB images for distro installing _required_ the creation of a /boot partition) The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable. It's been somewhat frustr…

One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails AND it can take quite some time and effort to recover even if you're technically familiar with the boot process since there are no standardised procedures for duplicating the ESP or its content. A second issue is that since…

[deleted]

Re: Linux boot partitions and how to set them up

#153

Post by effie »

theandrewbailey wrote: post #151
effie wrote: post #149

> In a trusted boot world, the two file systems for the ESP and the /boot/ partition should be considered untrusted: any code or essential data read from them must be authenticated cryptographically before use. In the real world, my ESP and boot partition are trusted, since I've installed them and control them and can check them for malware, and the firmware is not trusted since there is no possibility of control, it…

How often do you check your unauthenticated ESP and /boot for malware? Only when you suspect malware is already there? If so, it's too late. Locking them down as suggested helps to prevent the issue altogether. Yes, firmware should not be trusted, but reducing attack surfaces is a good thing. As far as your last point, the vast majority of people aren't competent computer owners or users. They don't know what to do o…

> How often do you check your unauthenticated ESP and /boot for malware?

I don't, because it's not something I so far cared about. But if I started caring about these sorts of attacks, I would not rely on board firmware to check software on my disks:)

> vast majority of people aren't competent computer owners or users.

Vast majority of people don't read HN and are not interested in the boot process. Those that do are more relevant, and I suspect many of them don't welcome Mr. Poettering's agenda.

> They don't know what to do on a technical level with malware in their boot process.

I'm not suggesting they should. But Mr. Poettering does not discuss origins and possible ways to solve this problem, e.g. using free software from reliable sources only and auditing software and hardware we use. He presents his (an the secure boot complex's) preferred solution to a problem that is complex and probably will try to "gently push it" on distributions like he did with systemd (his words).

Re: Linux boot partitions and how to set them up

#154

Post by effie »

iam-TJ wrote: post #150
effie wrote: post #140

Earlier quoted context omitted.

> One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails It is possible to make ESP part of MDRAID array of level 1 with metadata v1. True, the boot starts with single disk and only later Linux activates the array. So if your boot fails before that happens, reboot and try the o…

"don't set up MDRAID array for ESP, just have the ESP mirrored on all disks. " Isn't that the entire point of utilising MD RAID-1 in the first place? I've done as you suggest in years gone by with either metadata v0.9 or v1.0 (not v1.1 or v1.2) where the metadata is not at the start of the block device and therefore does not confuse a non-MDRAID-aware firmware or other OS.

> I've done as you suggest in years gone by with either metadata v0.9 or v1.0

Then why did you wrote

> it is not possible to make it part of a software RAID device

You are saying it is both not possible and that you've done it.

Re: Linux boot partitions and how to set them up

#155

Post by effie »

tinglymintyfrsh wrote: post #105

No mention of zfs, btrfs, xfs, lvm, or fde volumes from the makers of excessive-complexity cancers of systemd and pulseaudio.

Didn't you read the article, we're supposed to use vfat only and prepare for firmware checking our disks and revoking our boot rights on keyring and denylist updates.(LOL)

Re: Linux boot partitions and how to set them up

#156

Post by effie »

superkuh wrote: post #100

I still use MBR. No need for extra boot partitions or all that bloated UEFI jazz. MBR on GPT disks works just fine in compatibility mode.

Indeed. UEFI brings "solutions" to problems we don't have, but corporations would like those solutions for some reason.

Re: Linux boot partitions and how to set them up

#157

Post by effie »

einpoklum wrote: post #70

This blog post talks about systemd a lot. Why would I want to use systemd to set up boot partitions? I don't even have it installed on Linux distribution.

It's a P.R. effort to prepare the "community" for more bad and harmful solutions from Mr. Poettering and his employer Microsoft. It does not solve any real problem users have.

Re: Linux boot partitions and how to set them up

#158

Post by csdvrx »

yrro wrote: post #124
csdvrx wrote: post #93

Earlier quoted context omitted.

>Also it would be nice to be able to interact with the boot loader on a modern laptop display without having to get out a magnifying glass. Another problem that is deigned to be the fault of the firmware. > I think it's a shame that systemd-boot will cause regression here. If you use grub2, yes you need the magnifying glass. Meanwhile, I just press F12 and use the BIOS (which selects a readable font) and pick the UEF…

Can't edit kernel parameters from the firmware's own boot selector though can you. Or see it on an external monitor (at least on the laptop I'm using right now, which normally lives hidden out of sight attached to a dock). My recollection was that GRUB when in graphical mode looks readable. Maybe I'm misremembering. The systemd-boot menu was definitely far too small and there was bug that was basically closed with "i…

> Can't edit kernel parameters from the firmware's own boot selector though can you.

Yes you could, if the firmware did let you change the Unicode string (some firmwares let you do crazy things)

> UEFI has effectively replaced all that with a proprietary boot process. The vendor is now in complete control; want a usable text console, or to access the firmware via an external monitor? Vendor doesn't give a shit. Want to access the boot loader via the serial console? Oh you must be an enterprise, let me direct you to our sales staff who won't give you the time of day unless you've got £thousands to drop into their pocket.

You are over dramatizing the current situation. Just boot to a UEFI shell and you can do all that. There are many.

If all you need is to edit the cmdline parameters, add an initrd containing a busybox + kexec to show the currently entered parameters and either keep booting as is, or edit them and kexec the kernel with the new parameters.

It's something a bit like what zfsbootmenu does to let you select the root filesystem you want, and it's much more powerful than a UEFI shell since you get the wide set of drivers linux suppors, and the even wider set of tools you can run on the commandline.

> Don't get me wrong, I'd love to replace GRUB with systemd-boot, but these are very real impediments to me ever doing so.

The #1 impediment seems to be your lack of desire to reclaim freedom, something easy to do if you spend a few hours learning about UEFI payloads, initrd, kexec etc.

Get in touch by email and I'll help you.

Re: Linux boot partitions and how to set them up

#159

Post by iam-TJ »

effie wrote: post #154
iam-TJ wrote: post #150

Earlier quoted context omitted.

"don't set up MDRAID array for ESP, just have the ESP mirrored on all disks. " Isn't that the entire point of utilising MD RAID-1 in the first place? I've done as you suggest in years gone by with either metadata v0.9 or v1.0 (not v1.1 or v1.2) where the metadata is not at the start of the block device and therefore does not confuse a non-MDRAID-aware firmware or other OS.

> I've done as you suggest in years gone by with either metadata v0.9 or v1.0 Then why did you wrote > it is not possible to make it part of a software RAID device You are saying it is both not possible and that you've done it.

It is NOT possible to have the UEFI access the RAID device so that if one of the mirrors is broken it can continue to boot in degraded mode.

It requires manual intervention of a knowledgable person to boot a UEFI system into the default OS if the ESP is broken or missing.

Re: Linux boot partitions and how to set them up

#160

Post by usr1106 »

Vogtinator wrote: post #120
usr1106 wrote: post #113

Earlier quoted context omitted.

So what's your "conspiracy" here? What is secure boot-only? Secure boot with systemd-boot has been possible for years. Just that the typical setup has not been very secure because the initrd and the kernel command line where already unsigned. I see no problems with secure boot from a freedom perspective as long as the owner of the computer can install their own trusted public keys. There might be industry players tha…

> Secure boot with systemd-boot has been possible for years. It was not, ironically because of Microsoft. Shim is by policy effectively only allowed to boot grub2. So systemd-boot can't be used OOTB on secure boot enabled systems, you'd have to enroll your own key.

> It was not,

It has been possible for years. I have used it for 4 years myself and I was not the first adopter.

> Shim is by policy

I am not talking about shim, you don't have to use it.

Here's how to do it:

1. You erase the whole key database from UEFI (That possibility was some agreement between antitrust authorities and Intel and/or Microsoft that such possibility must be provided because Wintel was in a a dominating marketing position. On Arm devices it is often not possible, Windows / ARM is not in a dominating position and antitrust was not relevant.)

2. You generate your own key pairs.

3. The public ones you install into the secure boot database of UEFI.

4. You sign your UEFI application with your private key.

I have done that with `systemd-boot` and with the Linux kernel (containing the UEFI stub). Works in both cases. I used the instructions from https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Inst... 4 years ago and still do it the same way today.

Post reply on HN