Skip to content

Instantly share code, notes, and snippets.

@allquixotic
Last active March 6, 2020 18:26
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save allquixotic/92caea9070b451b4db833c7ab0161361 to your computer and use it in GitHub Desktop.
Save allquixotic/92caea9070b451b4db833c7ab0161361 to your computer and use it in GitHub Desktop.
Duty Calls

https://xkcd.com/386/

RE: https://superuser.com/a/1311054/144607

Thanks for the detailed information, but I want to address the fact this is "mis-information" and I do not agree with your stance on this topic. I disagree with the advice given to this individual.I am not sure whether it is because you are an avid supporter of UEFI, or you have no experience working with the partition on a developer level. It is one thing to regurgitate information, but give people the real-world experience information.

  1. UEFI was designed to stop virus injections into the standard bios. This is not true. The public is being misled to believe they can have their bios flashed by a virus. In the number of years, I have worked in this industry I have yet to see a system infected with a bios virus.

Just because you've never seen a BIOS virus does not mean they are impossible, or that none have ever been developed and used against people. Both pre-UEFI BIOSen and modern UEFI firmwares have an optional firmware "lock" switch that you can enable in the settings to prevent the operating system from overwriting the BIOS or firmware code. This is usually disabled by default, to allow people to update their BIOS using a Windows-based tool. Unfortunately, when the protect switch is disabled, both UEFI and legacy BIOS can be updated with malicious code running on the user's operating system, provided that the code is running as an elevated user (e.g. root or Administrator).

So the reality is that UEFI / BIOS viruses do exist, and no amount of individual experience can invalidate that fact. You are just one person working on, at most, a couple thousand systems in your lifetime. There are hundreds of billons of computers out there used by billions of people.

You're right about one thing, however: the way UEFI is implemented on most systems, UEFI is not very good at securing itself against viruses. Secure Boot and that switch I mentioned that prevents firmware updates from the OS are pretty effective countermeasures, but in the majority of products I've seen, they are disabled by default, which defeats the purpose.

  1. Even though the claim is that the bootloader is faster, it is not. I have seen no difference in performance because MS is just plain bloatware. They have adopted the UEFI standard for two reasons.

This is half right. UEFI, when configured properly, can initialize itself faster than a legacy BIOS, but the difference is small compared to the time it takes the OS to boot up - especially on a HDD. So, it might take UEFI 1 second to initialize whereas a BIOS takes 4 seconds to POST; but this savings of 3 seconds is insignificant compared to the 1 to 2 minutes it takes for your operating system to load up and be ready for use. The difference would be more noticeable if your OS starts up faster, which might be the case with a Mac or Linux system running an SSD (I've seen total boot times from power-on to desktop of around 5 to 8 seconds with Mac/Linux + UEFI + SSD, or around 10-12 seconds with BIOS).

 (a1.) This is so they can secure their licensing keys better since the UEFI boot table is inaccessible using standard methods. This

means they can secure their product licenses better. It all boils down to money.

Nah, Windows' license key isn't stored in UEFI. Retail product licensing for Windows 10 is now based on your CPU's unique identifier, which is hard-coded into the CPU. This has nothing to do with the motherboard's firmware.

Also, unless you have Secure Boot enabled (which most users don't), you can easily boot up from other devices with UEFI, just like you would with a BIOS, so I'm not sure what you mean when you say the UEFI boot table is "inaccessible using standard methods".

 (b2.) UEFI will support partitions beyond 1 Tera bytes. This was a plus because if you notice. Most systems being sold only have 1 tera

byte drives or less right now. It is because of the MBR limitations for drive sizes.

Boy, for a post complaining about misinformation, there's a lot of misinformation in this post. Where do I start:

  • The number is 2 TiB, not 1 TiB (and it's Terabyte, not "Tera byte"). That's the limit of a partition size in the Master Boot Record (MBR) partition table, which has nothing at all to do with BIOS or UEFI, except for the fact that most BIOS implementations only supported MBR and not GPT.
  • Technically, you could code up a BIOS that also supports the GPT partition layout, and due to it using wider integers to represent the extent of a partition, that BIOS would be able to boot partitions greater than 2 TiB. You'd probably be violating some de facto BIOS standard by doing so, but you could still do it.
  • The reason most consumer-grade computers only have 1 TiB drives is several-fold, but it has absolutely nothing to do with the 2 TiB MBR limitation. Rather:
    • Manufacturers want to offer the superior performance of SSDs, which cost more money per gigabyte of storage (and this cost increases approximately with the square of the SSD's capacity beyond a certain point).
    • Since consumers are only willing to pay so much for their system, manufacturers are not offering extremely high capacity SSDs (4 TB and up), because those SSDs would cost many thousands of dollars to produce. Selling a computer where all the components except the SSD cost $1000, and the SSD costs $3000, is not going to be economically viable for 99% of consumers, and the system won't sell well.
    • You can still customize most desktops and laptops to include a Hard Disk Drive (HDD) instead of an SSD, or in addition to an SSD. In this case, you can almost always, affordably, install a 4 TB or larger HDD. It's just that the default configuration in most cases is to ship a small-ish SSD (like you said, 1 TB or smaller).
    • Since most desktops and laptops are now shipping with UEFI and running Windows 10, there are no software or firmware limitations preventing you from booting from a partition larger than 2 TB. If you buy a laptop with a 4 TB HDD, you can install Windows 10 on it (or it'll be installed out of the box), boot it up, and it'll work just fine, with a single 4 TB partition. The only reason typical capacities are lower is to keep the cost down while still selling fast SSDs.
    • If you want to pay $2000 for a 4 TB SSD, several vendors offer them as a premium upgrade option. You can install your OS on those and boot from them, too, no problem.
  1. UEFI is NOT compatible with all systems. Where MBR is. This is why bios manufactures have not removed the legacy option.

What? This doesn't make any sense. UEFI (and BIOS) are both pieces of software -- they're firmware code that gets installed on the motherboard by the manufacturer. The motherboard's designers typically start with a general purpose UEFI or BIOS implementation, then customize it by filling in data for the particulars of that hardware -- for example, by telling it how to access USB devices, by installing drivers in the UEFI (or BIOS) implementation to work with the hardware on the motherboard.

Firmware programmers working for motherboard OEMs have the specific job of making UEFI (or a legacy BIOS) compatible with the motherboard they're developing for. There is no such thing as an all-purpose UEFI or BIOS implementation that you can download that will "just work", unmodified, for 100% of motherboards out there. Both have to be customized, by editing data, code, or both, to work with the motherboard/CPU and other components of the system, like the Platform Controller Hub (PCH).

UEFI and BIOS are just software; they're even stored in Flash memory on modern BIOSes, so it's really like having a mini "pre-boot OS" on your motherboard that helps you bootstrap yourself into a real OS like Windows or Linux by having just enough code to interact with your I/O devices over their respective protocol, like SATA, NVMe, etc.

The "legacy option" in modern UEFI implementations is called the Compatibility Support Module (CSM), an optional part of the UEFI standard that allows backwards compatibility with devices and boot drives that were designed for the BIOS standards. This legacy option is actually part of UEFI and runs within your UEFI firmware, so you're not somehow running a BIOS -- you're booting from UEFI either way. The difference is whether your UEFI pretends to be a BIOS to enable some legacy device -- for example, a partition formatted with MBR -- to boot.

The CSM also allows add-in cards to load a so-called "Option ROM", which is part of the BIOS standard, and allows PCI or PCIe cards to access basic input/output and run their own initialization code at boot-time. Typically the main users of Option ROMs are RAID cards and enterprise-grade network cards (which support PXE boot via Option ROM).

  1. Bios is the wrong term for this UEFI partition. It is a boot partition and NOT a bios. It bothers me to think people who have been in the industry over 10 years or more are calling this "boot partition" a bios.

Any partition on a hard disk or solid state drive is not called a "BIOS" or a "UEFI" - that I'll agree with. The partition where your operating system installs its boot loader for UEFI to invoke at boot-time is called the EFI System Partition (ESP). BIOS does not have a concept similar to the ESP, because BIOS always boots from the first sector of the disk.

A true bios controls how the computer works and functions. You have other options, such as, adjusting cache, clocking the memory and CPU, changing boot order and such. UEFI WILL NOT give you this type of control over your hardware. A true bios allows you to configure the hardware of your system and not just the hard drive

Actually, most UEFI PCs do offer plenty of hardware parameter tweaking in the options/settings pane at boot-time. Z-series Intel motherboards (Z97, Z170, Z270, Z370, etc.) even let you overclock/overvolt your CPU and RAM. Both BIOS and UEFI implementations are not required by the standards to offer this sort of customizability in a settings app at boot time, and some implementations don't offer it (for example, Macs don't really have a UEFI settings screen).

You should not be under the impression that it's the UEFI standard (vs. the BIOS standards) that do or do not allow the user the ability to tune or customize their hardware settings. This is up to the programmers of the BIOS or UEFI implementation in question, and they are free to allow or restrict customization as much as they want.

  1. When you format a flash drive to UEFI it will only boot on the system where it was created.

This is just plain wrong.

I have installed several UEFI boot flash drives now and they will only boot on the system they were made on. MS is forcing OS manufactures to adopt this new UEFI standard for their own selfish gain. I see nothing that UEFI brings to the table other than more time to configure, less control over hardware and also putting systems at risk that were manageable without UEFI.

You must be doing something wrong, then.

Yes, I will agree, it has broken past the 1 tera byte limit for hard drives, but the amount of time and energy required to maintain a server and other systems is not worth the switch. I currently develop software with a 500 gig drive and store everything to a 8 tera byte USB drive. Most people do not need more space than this and if they do they will plug in a USB drive to break past the 1 tera byte limit.

It's harder to manage free space between multiple devices than to have everything on one single device, so there are some benefits of having a large boot device, especially on Windows, where tools for managing free space across multiple devices are somewhat limited.

  1. I have found, through personal experience, and working with product development we have made a companywide decision NOT to adopt or use UEFI because of how it has impeded work flow for our company. When UEFI adopts a more universal standard that "WORKS WITH ALL OS's and ALL systems" and we are NOT forced to do a complete reinstall to recover a system that is when we will use UEFI.

Sounds like you're not a "product developer" but have actually made a very ignorant, very poor decision based on a couple of problems you've encountered and were unable to resolve. You seem to be suffering from the "Dunning-Kruger" effect -- you think you know a lot about a subject, but your actual knowledge is quite limited. You know just enough to have some really misguided ideas.

Conclusion: We have used and tested many packages in the course of a month trying to establish a stable standard for our company and customers. "Rufus, EaseUS, easy 2 boot, etc. This is just a short list. The other issue we have discovered with UEFI partitions is cloning and ghosting the UEFI flash drives.

This is never going to happen and even using DD to make an ISO image of a working system and using Rufus our tests have shown (testing the cloned images on over 10 different systems from different manufactures) the disk will not boot in UEFI mode (only on the system it was created on.)

Could it be, perhaps, that you're trying to boot a UEFI-formatted flash drive on a system that does not have UEFI firmware? Obviously, this won't work.

Until you are really into the development and server configuration side of UEFI you will never know what real issues are with UEFI. This new method is causing headaches for many software manufactures like our company.

Not all UEFI implementations are perfect. Some have serious flaws; I'll admit that. A lot of vendors shipping UEFI firmwares are just testing a couple of very specific use cases, and not supporting the entire standard. That's unfortunate, but it's really no different from the status quo when BIOS was the standard. Buggy BIOSen were the rule, not the exception. Welcome to computer hardware, where lazy manufacturers up against tight deadlines do the minimum to ship a viable product while cutting as many corners as possible.

Lastly, UEFI will not allow you to make a universal bootable flash drive with a fully working OS. You can get it to work on a single system, and only on the computer it was created on, but to have it universally boot on other systems even with legacy mode turned, this is a nightmare. Many companies for these reasons have refused to adopt this new UEFI method because of the amount of time to troubleshoot and create a universal bootloader which is not cost effective.

Wrong, wrong, wrong. Ubuntu has been doing this for years. They have a single ISO image that will boot equally well on BIOS and UEFI computers. You can burn the ISO to a CD/DVD, or you can dd it out to a flash drive, and it'll boot equally well in either mode, again for UEFI or BIOS alike.

You must either be using a really broken UEFI implementation (which, if that's the case, I feel sorry for you), or you're just doing it wrong.

To sum it up, the amount of time we as a company have spent trying to create a "universal" UEFI boot flash drive for the products we are developing for our customers is not worth the time. We have abandoned the idea that one can be made and have decided to continue in the the older methods. The number of hours we have spent trying to support our customers with this new UEFI standard was one of the many reasons we do NOT support it.

Well, this is a bad business decision IMO. You're very likely to go out of business soon. There are very few new computers being produced with a legacy BIOS outside of certain types of server and special-purpose embedded systems. Almost all consumer laptops and desktops now have a UEFI firmware on board. Additionally, the Compatibility Support Module for BIOS backwards compatibility will eventually be disabled by default, and later on, removed entirely.

It's never a good idea to say "The new way is giving us problems, so we're just going to entrench ourselves in the old way." As more and more problems crop up with the old way, and as fewer and fewer systems support it, your product will eventually fade into irrelevance. Get with the times or go bankrupt -- your choice.

@djsmiley2k
Copy link

Amen!.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment