BIOS boot vs UEFI boot

Kaminar said:
It wasn’t so long ago that some users preferred BIOS boot over UEFI boot for its robustness and lack of issues. I’d like to know what the situation looks like today. What would you choose for a system on which only FreeBSD is installed? Is BIOS boot still considered less problematic than UEFI boot?
Click to expand...

I install each FreeBSD in BIOS+UEFI setting after choosing Auto (ZFS) option - but these times I mostly (like 95%) boot with UEFI - I just keep BIOS option as fallback ... not sure if that helps.
 
vermaden said:
I install each FreeBSD in BIOS+UEFI setting after choosing Auto (ZFS) option - but these times I mostly (like 95%) boot with UEFI - I just keep BIOS option as fallback ... not sure if that helps.
Click to expand...
I had BIOS+UEFI configuration, too, for several installations for testing UEFI boot codes (first smh@'s and later Naomichi Nonaka's) for emergency legacy BIOS boots. And I'm still using the latter (my variant), now with UEFI-only configuration.
 
_martin said:
But coreboot is a firmware, i.e. it replaces the old firmware, either legacy BIOS or newer UEFI. Coreboot's payload can be UEFI.
Click to expand...
It can be, but its not. If AMI bios is flashed, system becomes UEFI with the ability to switch on CSM. If core boot is flash, system is legacy mode only. And this is by design.
T-Aoki said:
PCs having legacy BIOS is decreasing.
Click to expand...
That doesnt bother me at all as i have no plans to upgrade my desktop system any longer. Im too old for this shit. This is my last system before i die.
T-Aoki said:
And I've heared that some of recent PCs with UEFI stop providing CSM at all.
Click to expand...
That is correct. I saw several laptops that are full UEFI mode with no CSM option. It was few years ago to be honest.
T-Aoki said:
Maybe it would become harder and harder as time goes by to find PCs with legacy BIOS.
Click to expand...
This is why i run legacy hardware with open source firmware.
T-Aoki said:
Me, too.
Click to expand...
Me too. Both TPM and secure boot are disabled.
 
All that to read that even reticent people use or will use UEFI because there will be no choice.
As I said about another unrelated subject, if there were huge problems with UEFI, it naturally disappeared. Here, we can clearly see, it's not a trend, but a progress and no one will go back.

Still, there are people who want to teach me what is protected mode or how an OS is starting, just to insinuate there are right...
 
loveydovey said:
Notably, UEFI mode is the only mode that allows you to boot with graphics on a bhyve VM without using remote desktop software.
Click to expand...
... "worsly", I were not able to boot bhyve VM using BIOS. The package with BIOS boot support is no longer supported. Only UEFI. Obviously for a VM is a minor aspect.
 
kpedersen said:
Neither UEFI or BIOS will be around in ~20 years. The home PC is rapidly entering a legacy use-case.
Click to expand...
What will be the substitute of home PC? The android smartphone?

With BIOS I have no problem with PXE boot, with UEFI seems to be more complicated ...
 
loveydovey said:
Notably, UEFI mode is the only mode that allows you to boot with graphics on a bhyve VM without using remote desktop software.
Click to expand...
Maybe by this commit?
As seen in the commit message, this is a trade-off as of the quite strict restriction in size of boot codes for legacy BIOS.

See the unit described. Kilobytes, NOT megabytes nor gigabytes!

And for (p)MBR at boot sector, the restriction is more strict, in bytes, even not kilobytes!
 
Emrion said:
That said, I don't use anymore BIOS booting for bhyve VM, it's so easier with UEFI and, as already mentioned, you can have a graphical output (without 'passthru' a graphic card).
Click to expand...
Can you (or loveydovey ) elaborate more? Up to date, I'm using the built-in VNC support with bhyve, but it is not much fast, and net/waypipe that is rather fast, and I like it. My GPU is rather old, so I cannot use virtual passthrough GPU (i.e. sharing a GPU with multiple VM). If there are other approaches, I'm curious.
 
hruodr said:
What will be the substitute of home PC? The android smartphone?
Click to expand...
Sadly, yes. Locked down, custom boot systems like ChromeOS, iOS, Android are looking more and more likely for consumer devices. Many households don't own a PC anymore and the last consumer holdouts seem to be Steam DRM Platform gamers. If Valve gets them to migrate to Steam Machines, then that will be a landmark moment.

(A real tragic eye opener is that there are basically only a handful of companies that even sell retail x86_64 motherboards anymore)

If I am optimistic and x86_64 becomes legacy as we move to RISC-V, then much of that is u-boot anyway. We may well see BIOS hardware outliving UEFI hardware purely for legacy industrial use-case.

Either way, probably won't be in our lifespan. BIOS abstractions will also very likely hold out until then in workstation hardware for those who need it.
 
OpenFreeNet said:
Can you (or loveydovey ) elaborate more? Up to date, I'm using the built-in VNC support with bhyve, but it is not much fast, and net/waypipe that is rather fast, and I like it. My GPU is rather old, so I cannot use virtual passthrough GPU (i.e. sharing a GPU with multiple VM). If there are other approaches, I'm curious.
Click to expand...
Yes. it's just a framebuffer, but this last is a feature of UEFI. I don't know waypipe, and to be honest, I didn't even look on the wayland side. I should.

Well, I don't use VMs with a graphical view, it just helps at installation time (or in case of network problem inside the VM). After what, I disable VNC support because it's a huge security issue.
 
OpenFreeNet said:
... "worsly", I were not able to boot bhyve VM using BIOS
Click to expand...
To boot a bhyve VM using legacy CSM (booting via bhyveload) instead of UEFI firmware, you must perform two main changes:

1. Pre-load the Kernel using bhyveload​

Unlike UEFI (which uses BHYVE_UEFI.fd to handle the boot process inside the VM), CSM/Legacy boot requires running the bhyveload utility first to load the FreeBSD loader into memory before launching the bhyve process.

Run this command before starting bhyve:

bhyveload -m 4G -d /path/to/disk.img my-vm

2. Update the bhyve Command​

Do not use the -l bootrom,... line in your bhyve command. Otherwise, just use your bhyve launch script normally. As mentioned earlier, you will NOT get a framebuffer this way, just serial access.
 
Whattteva said:
I've heard this and "Year of the Linux Desktop" for like the last 2 decades. Both predictions have been wrong every year and have become memes at this point.
Click to expand...
What's a legacy use-case?
It's not looking bad, though. We still have to poke a mainboard manufacturer to trash IME and trusted computing. Secure boot is made irrelevant. What we have to watch out for is UEFI/BIOS systems trying to connect en download things. If that becomes a standard we're done. They will use it to block everything they don't like, like particular operating systems.
 
Whattteva said:
I've heard this and "Year of the Linux Desktop" for like the last 2 decades. Both predictions have been wrong every year and have become memes at this point.
Click to expand...
Kind of, kind of not. In many ways its already happened. As I mentioned above, home PCs just don't really exist any more. Casual users (i.e not you or I discussing on a FreeBSD forums) overwhelmingly use their phones.
  • Workstations (work, photoshop, etc)
  • Retro
  • Gaming
Are basically the last holdouts. None of those are really your typical home PCs.

Edit: Thought this sort of stuff should have some decent data by now. Some of it is OK, some is weak.
#1, #2

Perhaps the most interesting point is:
In 2020, the desktop PC penetration rate in the UK fell to 24%, from 88% in 2018.
Click to expand...
Though whether that includes laptops and/or the use-cases above, is not disclosed
 
Both have their pro's and con's and both are here to stay.

For example, from a security perspective (I am very surprised that people throw words like "legacy", and what not around but totally manage to ignore this bit?)... alas: from a security perspective I'd rather have a code block stored directly on my storage media but without making it too obvious where everything is.

Everyone knows about partitions (which, IMO, is also why UEFI became one) but not many know that YES, you can use CPU machine code to tell your PC that it should continue execution by reading more code contents at "another" location. Aka: "good luck script kiddies who know about the BIOS boot sector but not its inner workings".

Encrypted filesystems mean absolutely nothing when you can just power up the machine and the OS (+ its keys) get loaded and you gain full control. But they mean even less when those keys are stored on "default" or "recognizable" locations. ... which sometimes happens with UEFI.

Then again, why bother with all this hassle when working with environments where the physical hardware is already physically locked away and you need ease of use? Then UEFI is the GOAT because if you need to replace bootcode... you mount and copy. Quick, saves time and we all know that time is money.

This whole "one vs. other" mindset is getting tiresome IMO.
 
ShelLuser said:
This whole "one vs. other" mindset is getting tiresome IMO.
Click to expand...
Ha.
My version of English is better than yours (British vs American).
In case it's not clear the previous sentence is a joke/observation, because I found the quoted bit funny.

but circle back to the OP/title of the thread:
Does it really matter?
 
The focus on unauthorized physical access like UEFI isn't realistic and limits end-user authority on the actual machine. It's not about security.

Long ago all PC motherboards refused to boot from USB. This is the same fight, against local non-commercial software installation and full local permissions without the need of a commercial party. I believe the digital ID / age verification politics are from the same house. That's a step further on this road.
 
"BIOS" booting is there until it gets in a way of any modern feature. Then, it will be dumped. But since it is a compatibility feature of UEFI firmware I don't think that is coming soon.

There is absolutely no pros for BIOS. It is year 1980 legacy. If you use MBRs and BIOS boot on a modern machine you're emulating things that went along magnetic flux drives and PC BIOS 13h disk interrupt services. There is no head to position on a starting sector to get the boot code out. The modern disk is accessed like memory, even the control boards on the modern spinning drives interface it as such because of relatively huge linear caches they have on them.

It is not an alternative. Kpedersen has answered it - it is there because there are still a lot of legacy software, maybe not Money 97 ;) But definitely industrial control OSes and management software running atop of DOS. Do you know IBM actually has a DOS version that supports FAT32 and very large drives but it has been left for "embedded" application in the 2000s and 2010s?

Security? Points given in the thread are all over the place. For example autodecypting filesystems is a showstopper for copying, not for access, and it was always so, and nobody in security trade ever felt differently. The TPM chip releases the keys only if the platform was not intruded, e.g. case opened, or even USB stick inserted. Encrypting via TPM allows you to sell a product where the hardware is commodity but software is custom. BIOS has no security benefit over UEFI. UEFI runs and kicks something in long mode. BIOS runs in real mode, but it can kick off something that will switch to long mode to get ring0 access to the entire platform. There are no benefits.
 
You must log in or register to reply here.
Back
Top