BIOS boot vs UEFI boot

Kaminar

Kaminar

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?
 
For a dedicated machine, my opinion is "not much difference".
I think the "problems" around uefi are more related to updating loader, but I believe the process is well documented.
uefi is the better choice for multi-boot systems
 
UEFI is the present and the future.
BIOS is the present and the past.

There is no reason to stay on BIOS if your machine works with UEFI.
FreeBSD offers to have hybrid starting, if you fear some problems with UEFI.

In the years to come, you will have less and less support and tests for BIOS starting.

Don't listen people that are frightened by the progress. Future is unavoidable.
 
BIOS boot mode is here to stay. Ignore these "UEFI is the future nonsense". Some open source BIOS-es like core boot on protectli vault FW series is legacy mode only. And thats by design. And this was done for security reasons. Its just baffling to me that people are pushing these "new technologies" just because they are new. It was shown many times in the past that UEFI is vastly inferior solution when it comes to security. Unfortunately there are drawbacks with BIOS mode only like the lack of resizable bar support for instance and many more. But if security and privacy is your priority, legacy mode is only way to go. And modern systems still support it.
 
MrBSD said:
BIOS boot mode is here to stay. Ignore these "UEFI is the future nonsense". Some open source BIOS-es like core boot on protectli vault FW series is legacy mode only. And thats by design. And this was done for security reasons. Its just baffling to me that people are pushing these "new technologies" just because they are new. It was shown many times in the past that UEFI is vastly inferior solution when it comes to security. Unfortunately there are drawbacks with BIOS mode only like the lack of resizable bar support for instance and many more. But if security and privacy is your priority, legacy mode is only way to go. And modern systems still support it.
Click to expand...
Seriously... UEFI starts in protected mode. It should be sufficient to understand the advantages.
Yes, new technology, new security flaws. That's always been like it. But, tell me, BIOS is top secure?
Have you forgot the boot viruses?

There's no way back.
 
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...
Newer systems that have come out have better UEFI implementations. Though I do note that manufacturers still seem hesitant to strip BIOS emulation for a number of reasons. That by itself is quite telling.

Emrion said:
Seriously... UEFI starts in protected mode. It should be sufficient to understand the advantages.
Click to expand...
Protected mode is not what you think it is. For example, Windows 95 ran in protected mode.

Emrion said:
Yes, new technology, new security flaws. That's always been like it. But, tell me, BIOS is top secure?
Have you forgot the boot viruses?
Click to expand...
UEFI's flawed lack of isolation opens it up to a larger surface area for issues. Have a read up on this.

Emrion said:
Don't listen people that are frightened by the progress. Future is unavoidable
Click to expand...
Neither UEFI or BIOS will be around in ~20 years. The home PC is rapidly entering a legacy use-case.
 
Emrion said:
Seriously... UEFI starts in protected mode. It should be sufficient to understand the advantages.
Yes, new technology, new security flaws. That's always been like it. But, tell me, BIOS is top secure?
Have you forgot the boot viruses?

There's no way back.
Click to expand...
This assumes that the physical operator of the machine should have less permissions than the controlling software of the manufacturer. All security measures against physiccal abuse are only limitations.

What's the risk of a computer with no BIOS, UEFI or any other wannabe ROM but actually just software at all and just starts reading and executing the storage device from position 0? It can get the same required data anyway. I don't think it has to be artificially separated from all other software on the system.
 
If the computer has UEFI and you are booting it in CSM BIOS mode, then you are literally running UEFI that just simulates BIOS mode. Might as well use UEFI then?
 
kpedersen said:
Protected mode is not what you think it is.


UEFI can also be flawed. Have a read up on this.


Neither UEFI or BIOS will be around in ~20 years. The home PC is rapidly entering a legacy use-case.
Click to expand...
I wasn't expecting you on this.

You don't know what I think of protected mode. That's for sure. You think I'm an idiot. That's fine for me.

You think you are right. You know so much than all of us.
 
loveydovey said:
If the computer has UEFI and you are booting it in CSM BIOS mode, then you are literally running UEFI that just simulates BIOS mode. Might as well use UEFI then?
Click to expand...
The two situations I have seen where BIOS fallback (i.e emulation) was needed were both on server graphics hardware:
  • Some graphics drivers require the BAR address which can only be done from real mode.
  • The EFI framebuffer conflicted with the intel drm driver causing the latter to fail to initialize
The latter was very likely a bug (maybe caused by some bitrot?) but this is why options are good.
 
Emrion said:
Seriously... UEFI starts in protected mode. It should be sufficient to understand the advantages.
Yes, new technology, new security flaws. That's always been like it. But, tell me, BIOS is top secure?
Have you forgot the boot viruses?

There's no way back.
Click to expand...
Im not going to argue with you.
 
Pros and cons of UEFI boots would be...
Pros:
  • Faster boots.
  • Allows much larger boot codes (loader.efi in ESP is possible).
Cons:
  • Lack of physical text VRAM that disallows sc driver to run.
  • Screensaver on vty (requires sc driver) doesn't work.
Anyway, legacy BIOS boots alrady hits its mutual limitations in boot codes sizes and adding supports for new read-incompatible feature of ZFS should cause someting to be dropped. This is unignorable cons of legacy BIOS.

And if CSM is provided by UEFI firmware (optional, thus, not always provided), UEFI firmware can do legacy BIOS boots (becomes slow on boot) and mimic as if text VRAM exists.

Note that boot code for UEFI (boot1.efi) in quite early era had fatal issue that disallows rescue using installer media, but it was fixed.
And at least in some early UEFI firmwares, configurations with efibootmgr was NOT respected, but in most cases, workaround was available (use default name at default place for boot code, EFI/boot/bootx64.efi in ESP for amd64).
Maybe these memories make some people to choose legacy BIOS boots even recently.

Me? Using UEFI boots now.
 
T-Aoki said:
Pros and cons of UEFI boots would be...
Pros:
  • Faster boots.
  • Allows much larger boot codes (loader.efi in ESP is possible).
Cons:
  • Lack of physical text VRAM that disallows sc driver to run.
  • Screensaver on vty (requires sc driver) doesn't work.
Anyway, legacy BIOS boots alrady hits its mutual limitations in boot codes sizes and adding supports for new read-incompatible feature of ZFS should cause someting to be dropped. This is unignorable cons of legacy BIOS.

And if CSM is provided by UEFI firmware (optional, thus, not always provided), UEFI firmware can do legacy BIOS boots (becomes slow on boot) and mimic as if text VRAM exists.

Note that boot code for UEFI (boot1.efi) in quite early era had fatal issue that disallows rescue using installer media, but it was fixed.
And at least in some early UEFI firmwares, configurations with efibootmgr was NOT respected, but in most cases, workaround was available (use default name at default place for boot code, EFI/boot/bootx64.efi in ESP for amd64).
Maybe these memories make some people to choose legacy BIOS boots even recently.

Me? Using UEFI boots now.
Click to expand...
It's so obvious.

Well, some people here are harassing me and I don't speak of MrBSD who have its opinion and it's ok for me. I due respect to that. So, I leave the subject. Maybe we will talk on this in ten years, and we will see who were right.
 
kpedersen said:
  • Some graphics drivers require the BAR address which can only be done from real mode.
Click to expand...
Im actually the one that discovered this bug in RX9070 thread. It turns out the RBAR feature is not implemented in RDNA4 driver. Im sure this is going to get fixed.
T-Aoki said:
Me? Using UEFI boots now.
Click to expand...
Im using CSM on all my desktop machines, and true legacy boot on my firewalls because UEFI does not exist in firmware. Thats the way i like it.
Emrion said:
Well, some people here are harassing me and I don't speak of MrBSD who have its opinion and it's ok for me. I due respect to that. So, I leave the subject. Maybe we will talk on this in ten years, and we will saw who were right.
Click to expand...
No one is harassing you here. You are just not familiar with the matter.
 
My current build is a SuperMicro X9SRA introduced in 2012 with UEFI 2.3.1 and legacy support.

I refuse to use Secure Boot and TPM which is under Microsoft certificate control.

UEFI has evolved significantly since my 2012 version so I stick with MBR on this machine.

I firmly believe that user security lies with the user and not an operating system nanny, so no Secure Boot for me.

This is a very interesting thread.
 
Back in the day when PCs ran on 8080s, 8086, 80286 and the other early processors the CPU had 2 modes it ran in. Protected and Real. They described how the memory was accessed. One was flat linear addressing from 0 to all 1's for however many addressing bits there were. The other was segmented. If I'm remembering correctly the linear addressing was called real mode, the segmented was called protected.
I think that memory concept is still continued in current CPUs even though it is likely not needed.

Then we have the TPM stuff often called Secure Boot which I think a lot of UEFI systems are aware of; Windows seems to be requiring it.

I have no idea what others think of when they talk about protected mode, but to me, it's always about how the CPU addresses memory.
 
bgavin said:
I firmly believe that user security lies with the user and not an operating system nanny, so no Secure Boot for me.

This is a very interesting thread.
Click to expand...
That's a discussion and not just some believing. I never, never liked secure boot feature.

It's disabled on all my machines. It causes more problems than resolve them, and especially under a Unix system.

I'm okay with that. The user is the one that secures the system, not a foolish software.

I'm old enough to have run 8086 processors and saw their upcoming. I've seen many improvements since 80386 to now. I programmed them from assembly to C, from C to C++. And now, I 'm stuck to sh shell, what a forfeiture!

I don't forget. I won't listen that sad people. I will do the way people need it.
 
You must log in or register to reply here.
Back
Top