this post was submitted on 11 Jul 2023
28 points (96.7% liked)

Linux

48254 readers
432 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

What are the broader implications when it comes to access, security, vulnerabilities, etc?

top 5 comments
sorted by: hot top controversial new old
[–] [email protected] 6 points 1 year ago (1 children)

coreboot isn't a UEFI implementation. It is comparable to the UEFI SEC+PEI phases. It then hands off control to a payload. If you want UEFI, that's going to still be edk2.

[–] [email protected] 1 points 1 year ago (1 children)

What is a typical real world application for tianocore/edk2? Like who is using this and where/why? Like is this for custom hardware projects, servers, hardware hackers, OEMs?

[–] [email protected] 6 points 1 year ago* (last edited 1 year ago)

All UEFI system firmware uses edk2. It's not just the reference implementation; Pragmatically, it's the only implementation. Independent BIOS vendors (IBVs) like AMI, Phoenix, and Insyde have built all their tooling for and around edk2. Companies like System76 and Purism use it as a UEFI payload for their coreboot based firmware.

[–] [email protected] 5 points 1 year ago

I’m not sure I completely understand the question.

But vendor / custom UEFI implementations could obviously pass around whatever structures they want.

The EFI RUNTIME services - for example - could expose custom functions in a proprietary UEFI implementation. Though in my experience this usually is not the case.

Grub should run as an EFI bootloader binary after core UEFI is done. Afaik there is no particular ring / exception level required here. It could vary depending on UEFI implantation.

on android arm32/64 devices I obviously don’t see grub, but core EFI handles and services are not modified much. If anything it’s just expanded to support the next bootloader stage and handle stuff like key combos to select next boot image

[–] [email protected] 3 points 1 year ago

ITT: ~~ELI5~~ ELIPhD

load more comments
view more: next ›