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

LinuxBoot: Linux as Firmware

linuxboot.org

Post reply on HN
Print view View original

101–110 of 187 posts

Re: LinuxBoot: Linux as Firmware

#101

Post by johncolanduoni »

chriswarbo wrote: post #67
johncolanduoni wrote: post #63

Earlier quoted context omitted.

> These "hardware features", whether its [U]EFI or ME or whatever acronym, IMO is a land grab by hardware vendors over what we know as the "OS". Less computer owner control, more vendor control. What control did you have with an old PC BIOS that you now are missing with UEFI? Things like SMM and Intel ME that keep running after your actual OS has started existed and were pretty much ubiquitous before UEFI became comm…

> What control did you have with an old PC BIOS that you now are missing with UEFI? I had a PC with a BIOS once. It didn't seem as slick as the Kickstart I'd used for the previous decase on my Amigas. It was also much less configurable/programmable than the OpenFirmware that came on my subsequent PC. My current machine uses libreboot, which is fine but I much prefer OpenFirmware. tl;dr "BIOS vs EFI" is a false dichot…

The person I was responding to was claiming UEFI was restricting their choices and had "introduced" problems. I don't really see what OpenFirmware, libreboot, etc. has to do with this. I didn't say UEFI was the best boot system ever envisioned (I definitely think they could have done better) but claiming it's some anti-consumer conspiracy in a way PC BIOS wasn't makes no sense.

Re: LinuxBoot: Linux as Firmware

#103

Post by johncolanduoni »

ComputerGuru wrote: post #81
johncolanduoni wrote: post #64

Earlier quoted context omitted.

You can have multiple EFI system partitions on the same disk. The Windows installer does not like this, but it won't affect the actual boot process after it's installed. The Linux distros I've seen don't mind at all, since /boot/efi is usually mounted by UUID in your fstab.

No you really can't. There can only be one ESP and that's in the spec. You can have multiple partitions each assigned as /boot for a different OS, but there can only be one ESP which is used by the firmware to store its settings, etc. The EFI spec [0] is officially silent about the presence of multiple EFI system partitions on non-removable hard drives , but explicitly forbids multiple ESPs on removable disks, per §1…

From section §12.2.3.3 of the UEFI 2.0 spec:

> Hard drives may contain multiple partitions as defined in Section 12.2.2 on partition discovery. Any partition on the hard drive may contain a file system that the EFI firmware recognizes. Images that are to be booted must be stored under the EFI subdirectory as defined in Sections 12.2.1 and 12.2.2.

It definitely sounds like UEFI mandates support of it for internal drives (though I'm sure many implementations don't conform).

Empirically I've had this work with two ESPs (one Windows 10, installed first and one Linux, installed after). I've also done this with two Linux distributions with even less fanfare. I don't know if I just got lucky that my firmware supported it and I didn't have an Windows update that tried to mess with the loader or not.

I understand the difference between an ext2/3/4 /boot and FAT ESPs, thanks.

Re: LinuxBoot: Linux as Firmware

#104

Post by ComputerGuru »

johncolanduoni wrote: post #103
ComputerGuru wrote: post #81

Earlier quoted context omitted.

No you really can't. There can only be one ESP and that's in the spec. You can have multiple partitions each assigned as /boot for a different OS, but there can only be one ESP which is used by the firmware to store its settings, etc. The EFI spec [0] is officially silent about the presence of multiple EFI system partitions on non-removable hard drives , but explicitly forbids multiple ESPs on removable disks, per §1…

From section §12.2.3.3 of the UEFI 2.0 spec: > Hard drives may contain multiple partitions as defined in Section 12.2.2 on partition discovery. Any partition on the hard drive may contain a file system that the EFI firmware recognizes. Images that are to be booted must be stored under the EFI subdirectory as defined in Sections 12.2.1 and 12.2.2. It definitely sounds like UEFI mandates support of it for internal driv…

> It definitely sounds like UEFI mandates support of it for internal drive

I can see why you would interpret it that way, but the section you quoted doesn't say that.

The spec for the ESP is based off of FAT32, which means that in practice, all firmwares can read any FAT32 partition. While the ESP must be FAT32 (with the different filesystem GUID), any random FAT32 partition is not an ESP.

I really don't mean to overexplain this or belabor the point (forgive me if it comes across that way, but perhaps bear with me, too), but a FAT32 partition may be a boot partition without being the ESP (just as an ext4fs partition might be).

The parts of the spec you quoted are not referring explicitly to an ESP, but just "any recognized partition" which also includes non-ESP FAT32 partitions. In particular,

> Hard drives may contain multiple partitions as defined in Section 12.2.2 on partition discovery.

I just double-checked and §12.2.2 refers to generic discovery of all partitions, not just the ESP ("This specification requires the firmware to be able to parse the legacy master boot record(MBR) (see Section 5.2.1), GUID Partition Table (GPT)(see Section 5.3.2), and El Torito (see Section 12.2.2.1) logical device volumes.")

> Any partition on the hard drive may contain a file system that the EFI firmware recognizes

Already addressed, but also includes support for other filesystems so that a, say, consumer electronic with a custom filesystem load its OS from said device, is not out of spec.

Re: LinuxBoot: Linux as Firmware

#105

Post by peterwwillis »

gatmne wrote: post #102
peterwwillis wrote: post #53

Does anyone else find The Linux Foundation to be creepy as hell?

I don't. Should I? Why?

It's now hosting this project, and seems to have created this page and reformed the project a bit. And have you seen the foundation's website?

They have a tiered sponsor page to act as badge of honor for the tech companies with the most money. Their board of directors are 22 of some of the most powerful tech companies in the world. They "host" an amalgam of different tech products (actually working in legal entities to control the projects, it seems, under their LLC). They sponsor conferences, seemingly just to decide the future of the industry with a bunch of connected higher-ups and project leads. They don't appear to have a lot of transparency in terms of where their money is going, what guides the organization, why it exists, what it is doing, etc.

The most annoying thing about it to me is how a bunch of open source projects are actually just product placement for corporations, with press blurbs regurgitating bullshit business speak about something like logging formats.

It used to be that we used the best tool for the job. Now we use whatever tool has the most buzzwords and corporate sponsorship. This foundation appears to be spookily pushing that agenda, under the badge of Linux, for whatever reason. It's creepy.

Re: LinuxBoot: Linux as Firmware

#106

Post by igravious »

dogma1138 wrote: post #98
cmurf wrote: post #66

Earlier quoted context omitted.

Right. I think it exchanged problems we know, for problems we don't know. And now we're learning about those problems. Or re-learning. With respect to NVRAM boot entries, Apple has been doing this for ~30 years and across all of that hardware (three CPU architectures, at least three firmware and three or four filesystems) they have a single method of resetting the NVRAM called "zapping the PRAM" with command+option/a…

NVRAM on PC/server main boards is cleared with the RTCRST (Real Time Clock Reset) jumper. On laptops it’s a combination of keys usually some older ones would require removing the battery for a specific amount of time.

Great, but what magic key combo–or combos?

Re: LinuxBoot: Linux as Firmware

#108

Post by igravious »

peterwwillis wrote: post #105
gatmne wrote: post #102

Earlier quoted context omitted.

I don't. Should I? Why?

It's now hosting this project, and seems to have created this page and reformed the project a bit. And have you seen the foundation's website? They have a tiered sponsor page to act as badge of honor for the tech companies with the most money. Their board of directors are 22 of some of the most powerful tech companies in the world. They "host" an amalgam of different tech products (actually working in legal entities…

You haven't a clue what you're talking about.

The Linux Foundation is one way in which corporations subsidize key open source projects that benefit them all. There's nothing creepy at all about corporate sponsorship of key open source technologies. The Linux Foundation started with Linux and has expanded from there, so what? None of their projects http://www.linuxfoundation.org/projects/ are in any way sinister. You do realise that it is possible to work for a corporation and and also be into open source and also not sell your soul to the devil. What hyperbole, give us a break.

Re: LinuxBoot: Linux as Firmware

#109

Post by johncolanduoni »

Sephr wrote: post #71
johncolanduoni wrote: post #57

Earlier quoted context omitted.

A big one is GPU passthrough. Before graphics cards supported UEFI the old VGA BIOS was a nightmare to get working with virtualization. Now with a tiny bit of configuration you can get consumer GPUs to work just fine in virtual machines.

Maybe for AMD GPUs, but getting consumer Nvidia GPUs working with VT-d on Nvidia's drivers is a little difficult. GPU passthrough is not something Nvidia wants to support on consumer GPUs. Edit: s/very/a little/

I've had no problem using consumer Nvidia GPUs with QEMU/KVM for this. All I needed to do was (1) use kvm=off (this does not turn off KVM, it just sort of hides it from the NVidia driver) and (2) on Windows, edit the registry to force enable Message Signaled Interrupts. When I tried it with an AMD card it would periodically crash the host when it was assigned to a Linux guest.

Re: LinuxBoot: Linux as Firmware

#110

Post by thudson »

ComputerGuru wrote: post #99
nickwinlund wrote: post #3

Wonderful! I detest the UEFI/secure boot schema in use on post-Windows 8 systems

This doesn't really have anything to do with Windows, recent Linux and FreeBSD release prefer to use UEFI and Secure Boot if available. While UEFI is platform/OS-agnostic, it's too early to tell if this LinuxBoot will be as open (even if better designed). Additionally, there are benefits that Secure Boot brings to the table (notable with regards to security and integrity verification) that you should not be so hasty…

The threat model that LinuxBoot is addressing is different form SecureBoot and it can use the well known, normal Linux tools rather than the unconventional UEFI ones.

The Heads runtime can do things like use TPMTOTP to attest to the user that the firmware is unaltered and includes gnupg to verify the kernel and root filesystem signatures with the user's own key.

For cloud systems a LinuxBoot runtime can use the TPM or other trusted hardware to remotely attest to the client's own provisioning server that the configuration is unchanged, and since it is reproducibly built, that the firmware is what the user expects. This is significantly more trustworthy than the binary blobs and non-reproducible UEFI firmware on most servers.

Post reply on HN