451–460 of 460 posts
Also create a boot please that rivals w10's almost instant boot process. I just hate the current slow/non parallel boot process.
As you might know windows is kind of cheating with the "instant boot" by creating an hibernate snapshot of the OS before login. 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.
It's something you can do since a lot of years. I used to do so 10 years ago, when I've got the first motherboard with UEFI. But is it useful? It saves a minimal time in the boot sequence, but at what cost? The bootloader (being it grub, or something more simple as systemd-boot) is useful to me for a couple of reasons: - it allows to dual-boot with Windows easily: motherboard boot menu is often not easy to access, yo…
Earlier quoted context omitted.
Anytime something (i.e., stack layer, software component, software layer, blob -- in this case, initialization/boot code for hardware which was first simple BIOS'es whcih became larger and more complex BIOS'es which later became still more complex UEFI -- a much larger attack surface by size) in technology is replaced by something new and complex which is touted as "more secure" -- it's usually less secure (bugs and…
Older BIOSes are much simpler, and also offer no security boundary at all - nobody talks about BIOS vulnerabilities because it wouldn't give you anything you don't already have!
...but if so, is that asserted "security boundary" really an actual security boundary(?)
If the security boundary or "security boundary" -- is opaque in how it functions; if it is a "black box": (https://en.wikipedia.org/wiki/Black_box); if no one (other than potentially a few people who work for the manufacturer, or exist at the company subcontracting to build their Smart Key component (if the Smart Key is subcontracted/outsourced)) understands exactly how it works, then is it really "secure"?
(If so, then that sounds eerily similar to the "obscurity is good" (aka "transparency bad") side of the "Security Through Obscurity" debate that the Internet had, like 5, 10, 20+ years ago: https://en.wikipedia.org/wiki/Security_through_obscurity#Cri...)
Why not read the following:
"Gone in 20 seconds: how ‘smart keys’ have fuelled a new wave of car crime":
https://www.theguardian.com/money/2024/feb/24/smart-keys-car...
And you tell me?
My conclusion:
Perhaps less "security" (less of an asserted "security boundary") -- is actually more actual security -- at least in some cases -- at least in the case of the Ford Model-T...
Earlier quoted context omitted.
It probably was, but UEFI was not a good answer. I'd have preferred CoreBoot or OpenFirmware, but the PC industry was too slow to move and let Intel -- still smarting from Microsoft forcing it to adopt AMD's 64-bit x86 extensions -- take control of the firmware.
UEFI btw is late 1990s thing, with work starting because BIOS was unwieldy chimeara that didn't match anything in hardware, and supporting things like network booting by hooking into "boot BASIC program from Cassette" subroutine was problematic.
https://web.archive.org/web/20100105051711/http://www.intel....
It was originally called Intel Boot Initiative, IBI.
https://www.afterdawn.com/glossary/term.cfm/intel_boot_initi...
You're right, work started in the late 1990s, but AFAIK nothing shipped until the 21st century: 2001.
Earlier quoted context omitted.
Both the suggestions I gave were designed and built to be FOSS and work with any OS. UEFI is more restrictive -- and tightly controlled by large industry vendors, not the community -- than either of them. So, no, I totally disagree on all points.
OpenFirmware is similar level of complexity as UEFI, to be quite honest, and lacks certain mechanisms that were designed into ACPI (and inherited by UEFI) precisely to support multiple different operating systems without requiring the OS to be have specialty drivers for every little bit. Sure, in the happy path, you can depend on OpenFirmware giving you parameters like locations and addresses and "this device is comp…
However, ISTM that relying on a magic partition on a fixed disk is a poor design, and while other types of firmware are not radically simpler, there are or were alternatives, and some of them are noticeably more FOSS. UEFI is EFI for x86-64, broadly, and EFI was proprietary. That is not a good thing, in my book. Something more cross-platform and less vendor-dependent would have been preferable, even if of comparable complexity.
Earlier quoted context omitted.
Sure, but whether that GRUB entry is remembered as the default is up to the UEFI not GRUB. If you pick another entry GRUB is powerless to effect it.
The GRUB_DEFAULT and GRUB_SAVE_DEFAULT settings don't affect the UEFI settings, they only affect the default boot option in GRUB's boot menu. From the UEFI configuration perspective, the boot option never changes and it's always set as the drive with GRUB installed on it.
Earlier quoted context omitted.
UEFI btw is late 1990s thing, with work starting because BIOS was unwieldy chimeara that didn't match anything in hardware, and supporting things like network booting by hooking into "boot BASIC program from Cassette" subroutine was problematic.
UEFI is a development of EFI, the proprietary firmware for the Intel Itanium. https://web.archive.org/web/20100105051711/http://www.intel.... It was originally called Intel Boot Initiative, IBI. https://www.afterdawn.com/glossary/term.cfm/intel_boot_initi... You're right, work started in the late 1990s, but AFAIK nothing shipped until the 21st century: 2001.
For reference, it was possible to run it on x86 (and even the ICC with EBC was provided!) ~2001, including DUET which I ran from a floppy. There was close to same level of source access as today with TianoCore, though probably with different license.
Then someone at intel got a bright idea to close access to source and until the direction got reversed (which got us TianoCore) it was fully proprietary.
Earlier quoted context omitted.
OpenFirmware is similar level of complexity as UEFI, to be quite honest, and lacks certain mechanisms that were designed into ACPI (and inherited by UEFI) precisely to support multiple different operating systems without requiring the OS to be have specialty drivers for every little bit. Sure, in the happy path, you can depend on OpenFirmware giving you parameters like locations and addresses and "this device is comp…
Nothing is perfect, and you are probably right that any firmware for potentially SMP computers with multiple types of boot device is unavoidably complex. However, ISTM that relying on a magic partition on a fixed disk is a poor design, and while other types of firmware are not radically simpler, there are or were alternatives, and some of them are noticeably more FOSS. UEFI is EFI for x86-64, broadly, and EFI was pro…
UEFI mandates certain, user and developer and admin UX nice, minimums regarding boot process. You can fully expand on supported filesystems, or even non-FS sources to boot from. Even from paper tape if you want to. You're not bound to magic partition on a fixed disk[1] anymore than you're with OpenFirmware (and decidedly less than IBM PC BIOS compatibles).
None of the comparable alternatives were really FLOSS (by the time OFW went open source, EFI was shipping on x86 and amd64[2]), coreboot/uboot/redboot/etc were too limited, by themselves being e-waste framework unless paired with upper layer to provide open platform for users and developers.
EFI was available, back in 1.1 timeline, as open source code for x86 and IA-64 (the IA-64 specific bits were called "SAL" IIRC), then some bright mind at Intel decided to close it down. Fortunately they open sourced it back as TianoCore and we now have FLOSS solution (it's as proprietary as OFW at this point in time, and it's more of an open platform than uboot/coreboot/etc).
The available "less proprietary" options all created closed platforms, where you need excessive porting to boot anything the vendor didn't ship for you. It's trivial to make firmware so flossy it will make RMS shed tears of nostalgia for KA-10, but it's not going to be useful for majority if they ever want to run something not provided by vendor. Minicomputer/workstation complex firmware monitors etc. happened because diagnostics were often needed, and some required at least some compatibility with third party hardware, but them - including origins of OpenFirmware - implicitly accepted a closed platform where vendor would need to ship a special "hardware enabling" OS update or ship entire OS version to match new platform.
UEFI might have proprietary roots, but it (and ACPI) is designed specifically to provide for the case of freedom of end owner to run whatever crap they want, including older version of OS they already got used to.
[1] Unless the hardware is too cheap, like Qualcomm ARM systems with UEFI where various critical services are patched in windows drivers to be handled through magic files on ESP, or in permissible CHRP OpenFirmware variants where magic partition on fixed disk is explicitly mentioned as an option.
[2] EFI based firmwares started shipping by 2005~2008 timeframe on x86 and amd64, mainly due to DXE providing way easier method to integrate 3rd party code. It was also from start designed to handle multiple platforms, partially thanks to having IA-32 and IA-64 code simultaneously as early as EFI 1.0, which made it easier option to handle future 64bit platforms.
Earlier quoted context omitted.
UEFI is a development of EFI, the proprietary firmware for the Intel Itanium. https://web.archive.org/web/20100105051711/http://www.intel.... It was originally called Intel Boot Initiative, IBI. https://www.afterdawn.com/glossary/term.cfm/intel_boot_initi... You're right, work started in the late 1990s, but AFAIK nothing shipped until the 21st century: 2001.
It's more that Itanium was the one system where it originally shipped, and that for no obvious reasons Intel closed-sourced it at some point. The Itanium proprietary firmware was, IIRC, "SAL" (somewhat related to modern UEFI's PEI layer). For reference, it was possible to run it on x86 (and even the ICC with EBC was provided!) ~2001, including DUET which I ran from a floppy. There was close to same level of source ac…
Earlier quoted context omitted.
you seem to be saying that they are using two separate kernels, one for the bootloader and one for the final boot target the title text says 'Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target' which sounds like they're not talking about using two separate kernels, one for the bootloa…
> It's just that the bootloader is itself using the Linux kernel This sentence does not say "the bootloader is itself another, separate, Linux kernel", so I'm not seeing him saying what you're saying he seems to be saying.