Talk:UEFI/Archive 2

Archive 1

Archive 2

Intellectual property

The section about intellectual property should either be removed or cleaned-up, as it is totally not NPOV, and makes false claims:

According to Ron Minnich, the lead developer for LinuxBIOS

Is the 'lead developer for LinuxBIOS' an authority on this case? I would say he would be pretty biased. Why would I (or anyone seeking EFI information) want to know his opinion?

one of the stated goals of EFI is to “protect hardware vendors’ intellectual property”.

Good, so we have hearsay here. Nowhere on the UEFI website can this 'stated goal' be found.

This raises security concerns

For whom? Who is doing the raising? Weasel word alert!

and notably makes creating a free software implementation impossible.

Why? Can a free software implementor not sign the "the UEFI Adopters' Agreement"? Since the specs are free to read, why would an implementation not be distributable by BSD license?

Note: you can't implement UEFI firmware without signing the UEFI Adopters' Agreement (it goes against the conditions you agree to before viewing the specification). However, nothing in the UEFI Adopters' Agreement prevents your implementation from being open source, and anyone can sign the agreement without paying fees, etc. In addition, Intel and UEFI already supply a large part of the code needed for UEFI firmware (AFAIK it includes everything except chipset specific parts) that is distributed under the BSD licence (see http://tianocore.org). Despite what Ronald Minnich said, a firmware manufacturer could easily attach open source chipset specific code (which is beyond the scope of UEFI) to the open source Tiano code (instead of attaching "binary-only BIOS code provided by a vendor"). —Preceding unsigned comment added by 124.182.118.112 (talk) 12:29, 10 December 2007 (UTC)

EFI could be used to create a “DRM BIOS”

Sure, but so could any BIOS implementation. Modern non-EFI BIOSes contain SMM code that can do stuf without the OS knowing, including simulating or blocking devices. Has nothing to with EFI whatsoever.

thus letting vendors build computers which limit what the user can do.

Damn, I really want to play the latest 3D games on my old P1 266MHz with a Tseng ET4000. What do you say? Not possible? Has anyone limited what I can do? Really, even without the sarcasm, that's a sorry sentence...

EFI is not open source.

EFI is a specification, not source code. EFI is not a car either. Or a gorilla. Do we really need to state the obvious here?

Its specification is not publicly viewable

This is downright false, see http://www.uefi.org/specs/

Since changed to http://www.uefi.org/specifications/ Vaughan Pratt (talk) 12:54, 4 May 2014 (UTC)

and EFI site suggests that it is a supporter of the Trust Computing Group.

Which is a well-known El-Qaeda affiliate? And where does it 'suggest' (weasel word alert!) Come on people, NPOV please!

Ok, I'll stop ranting. If anyone wants to clean up the section, please do so. If noone does, I'll do it, but then don't start wining it's non to your liking. Jalwikip (talk) 10:11, 10 December 2007 (UTC)

Ok, based on reading the interview with Minnich and the comments of the anonymous user above, I decided to remove the entire section. Minnich did not claim there were 'stated goals' but says he heard it from not mentioned persons. Also, the discussion about the security issue was condensed to much in the section, and has on top of that not much to do with the 'intellectual property' of the section header. Jalwikip (talk) 15:04, 7 January 2008 (UTC)

UEFI-bashing is a phenomena 2ndary siources note = controversy = notableNotable/RS'd any thoughts?

I am thinking the encyclopedia can give WP:NPOV account of the controversial nature of Windows in general and Secure Boot in particular. Here is a great WP:RS for starters http://www.dedoimedo.com/computers/uefi-drama.html any thoughts?Wikidgood (talk) 02:36, 21 October 2014 (UTC)

Independent of any other FAT file system specification

Hard to understand that thesis. --Itu (talk) 11:41, 14 June 2015 (UTC)

Hello! Well, it's rather simple, as visible from the references UEFI maintains its own file system specification that at some point in time may divert from the original FAT file system. Regarding "any", it's about the FAT16, FAT32, etc. — Dsimic (talk | contribs) 11:52, 14 June 2015 (UTC)

EFI: BIOS replacement?

I don't see the point here, EFI has nothing to do with the statment:

(EFI) is a system developed by Intel to replace the BIOS..

EFI is only a specification aimed to put a new standard in the Interface of the system Firmware; i.e: how a Specific software like an Operating System should deal with system Firmware functions, It has nothing to do with 'BIOS replacement'

It is not clear, with Windows 10, does that mean some UEFI will no longer support CSM or Legacy BIOS at all?! — Preceding unsigned comment added by 74.113.59.36 (talk) 18:08, 29 June 2015 (UTC)

Compatibility Support Module (CSM) is a feature of the UEFI itself, and as such has nothing to do directly with Windows 10. — Dsimic (talk | contribs) 05:34, 30 June 2015 (UTC)

Security and Trojans surviving reformats through UEFI

I couldn't find anything addressing this topic and I think it is very important to alert people this is even a possibility. UEFI has some serious security holes that allows a malicious party to install malicious software on the UEFI, meaning that the software would survive a full reformat and OS reinstallation.

The security company Hacking_Team has recently had a major leak, one image of which shows their exploitation of these security holes to do exactly what I just described, as seen in this screenshot: [1] 81.104.217.234 (talk) 15:40, 8 July 2015 (UTC)

Hello! That isn't something radically new to UEFI, as pretty much any firmware is vulnerable to such attacks. Even hard disk drives can be compromised that way, see this article, for example. — Dsimic (talk | contribs) 15:48, 8 July 2015 (UTC)

Apple Macintosh, no EFI setup edit EFI settings function and the bootcamp with Windows 8

I think this article should have some text about the quality issues of EFT use, in various environments.

I have so far never been able to edit the vt-x setting in my Minimac for bootcamp Windows 8.1 use.

The amazing thing is that the vt-x EFI setting is on booting in OSX and off booting in Windows 8.1 (noticeable for instance in the Android Studio HAX virtual debugging feature. Same app demanding vt-x works in OSX but not in Win8.1 in the same machine, real odd. What I understand from some googling in the net this is a very old issue for OSX users not being able to use vt-x even if it is there because it is switched off. It looks like Apple have later made a quick fix for their OSX users that really do not solve the issue the right way, but who knows what is wrong because this is closed science.

Moreover there is no EFT-setting edit feature in the OSX.10 operating system (as there is supposed to be in Windows 8.1) and it is not possible to reach from a bootcamp installation of Win8.1, by the Win8.1 EFT-settings feature. Moreover there has been third party fix-features available (it is an old problem for OSX users, now fixed by Apple in newer machines) but today is completely closed for loading solutions from else but iStore, and iStore don't have them.

Apple customers might think it is natural if they are just not allowed to use a feature available in the HW but not by the OS. Windows users have quite a demand of being masters of their machines being able to solve such issues by some private engineering.

I think we are at stage of politics where there are some real good reasons for some good agreements.

Running Windows on Apple x86-machines are normally working very well, they run like rockets and most likely just because of good quality, but reaching such issues like the impossibility to flip a EFI-settings byte makes using them as very questionable. So little for so much troubles just because of this culture issue?

One question is why can't there be a EFI-HW boot non-OS dependent setup feature as standard? Like how to edit the CMOS in the past? --Zzalpha (talk) 20:50, 17 July 2015 (UTC)

Hello! Regarding the article expansion you're proposing, that would be good if you could, please, provide some reliable sources on which we could base the expansion. Speaking about the UEFI configuration options, unfortunately I'm not sure what's the actual issue? All "regular" PC hardware provides UEFI setup utilities, and configuring various firmware parameters has never been fully available to the operating systems, not even in the BIOS era. — Dsimic (talk | contribs) 10:09, 14 August 2015 (UTC)

Is UEFI like USB? Eg. a sane replacement for incompatible BIOSes?

If you need a newer BIOS to be able to use new hardware, often times it's impossible to find a replacement. Does UEFI mean there is a universal standard, so that there is only one place to go to find a newer BIOS-like image if your system does UEFI? For example is there one place to download new versions of UEFI that will work on all UEFI based systems going forward? Because that would be truly useful.--184.63.132.236 (talk) 02:03, 22 August 2015 (UTC)

Please note that Wikipedia isn't a forum, but the answer to your question is no – all computer motherboards require and use manufacturer-specific UEFI implementations. — Dsimic (talk | contribs) 02:09, 22 August 2015 (UTC)

Obscure chart, should be edited or eliminated

The chart labeled "Interaction between the EFI boot manager and EFI drivers" fails to convey any meaning to me. It shows neither a comprehensible hierarchy, nor a flow of control. It's not clear on what principle it is based. It's also not clear what the terms "Application" and "Driver" mean in this context. It makes a distinction between "EFI binaries" in blue capsules and "Boot manager" in brown capsules, but I fail to see where those terms are defined either. I would like to see a chart that answers more questions than it brings up. Dlw20070716 (talk) 01:32, 26 August 2015 (UTC)

Hello! That's a good remark. Moved the chart to a section that describes the concepts shown on the chart, do you find it more usable now? — Dsimic (talk | contribs) 05:42, 26 August 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Unified Extensible Firmware Interface. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080724213607/http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_diffs/chapter_3_section_10.html to http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_diffs/chapter_3_section_10.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:49, 11 November 2016 (UTC)

article is fake

U-EFI is not hardware, it is a concocted acronym instead.

The forum / group in Washington state has no control over intel, suggesting they know what is coming - but are not those who engineer intel's EFI chip — Preceding unsigned comment added by 72.219.207.25 (talk) 23:02, 27 January 2017 (UTC)

Advantages is not time-sensitive, up-to-date, or most importantly unbaised

At the very least, we should remind the reader that this is the purported advantages from the people pushing the technology, not an unbaised assessment of what it does. To go further: — Preceding unsigned comment added by Tgeeky (talk • contribs) 04:35, 27 March 2017 (UTC)

The "Advantages" section (which is at the very top of the article) is currently as follows:

• Ability to boot from large disks (over 2 TB) with a GUID Partition Table (GPT)
• CPU-independent architecture
• CPU-independent drivers
• Flexible pre-OS environment, including network capability
• Modular design
• Backward and forward compatibility

I note that the citation ([12] on the original document) to Microsoft (a member of the UEFI forum) no longer lists these points, but instead lists:

Firmware that meets the UEFI 2.3.1 specifications provides the following benefits:

• Faster boot and resume times.
• Ability to use security features such as Secure Boot and factory encrypted drives that help prevent untrusted code from running before the operating system is loaded. For more information, see Secure Boot Overview and Factory Encrypted Drives.
• Ability to more easily support large hard drives (more than 2 terabytes) and drives with more than four partitions.
• Compatibility with legacy BIOS. Some UEFI-based PCs contain a Compatibility Support Module (CSM) that emulates earlier BIOS, providing more flexibility and compatibility for end users. To use the CSM, Secure Boot must be disabled.
• Support for multicast deployment, which allows PC manufacturers to broadcast a PC image that can be received by multiple PCs without overwhelming the network or image server.
• Support for UEFI firmware drivers, applications, and option ROMs.

I invite Wikipedia editors and interested parties to list all of the ways that this collection of benefits, as worded, are invalid factually or invalid logically. As far as I can tell, the only concrete advantages listed among all of the above are:

• Ability to boot from large disks (over 2 TB) with a GUID Partition Table (GPT)
• Faster boot and resume times.

I am sure that one could measure, quantify, and then debate the accuracy of the second point; but the first point is some combination of logical fallacies that I haven't yet been able to precisely define. Is it just false cause? At the time of UEFI proposals, but certainly at the time of > 2.2TB drive availability, OSX and 32- and 64-bit already supported drives larger than 2.2TB.

I am not a crusader against UEFI, but it never occurred to me until now to look at the history of its introduction. I think this section overall needs to be rewritten to account for this historical view (or the historical view section above needs to be improved, or merged, or something). Of the remaining reasons in the above lists, several of them were again -- already possible before UEFI:

• Multicast deployment was possible.
• Network boot was available.
• It goes without saying that Legacy BIOSes were available.
• (Can someone check if secure/encryption booting was available before UEFI?)
• Support for UEFI drivers, programs, etc -- is begging the question.
• Modular design is, until clarified, just buzzwords; correct?
• Backward and forward compatibility. (Is this "just" buzzwords or is why BIOSes were not this precisely defined?)
• (It seems like CPU independent drivers and CPU independent architecture are both also buzzards. Perhaps there is information to about CPU-independent drivers. Were there any BIOSes that worked on multiple CPUs?

Lead issues

As of Nov20, 2017 the lead contains the following:"The user [of a IBM PC-compatible computer] can enter a setup utility by pressing their manufacturers specific setup keys. Most common keys are Delete,F2, F12,esc etc." First and most obvious is "their manufacturers" lacks a hyphen and isn't clear about which component's manufacturer it is referring to (the keyboard? the CPU? the OS? the motherboard?). The second issue is the statement that "etc" is a common key; obviously it is not and listing common keys should not include an "etc." since there is no obvious way for a reader to generalize from the 4 keys listed. (IMHO "Esc" rather than "esc" is to be preferred for the Escape key.) The third issue is that the meaning of "a setup utility" is far from clear. What is it setting up? (My PC has several "setup utilities"). Finally, the setup utility can NOT be entered by pressing keys - except during boot (although I've had machines that allow alternative ways to enter these utilities, I'm not sure if they were UEFI). 174.130.48.109 (talk) 18:03, 20 November 2017 (UTC)

Pronunciation Suggestion

At one time this article said that UEFI is to be pronounced like the word unify, but without the n. However, my boss rhymes UEFI with goofy, that is, You pay the fee, but without pay the. The article should discuss this. Solo Owl 19:20, 30 November 2017 (UTC)

Does my PC have UEFI?

I came to this article to find out whether my PC has UEFI. More generally, which systems have UEFI.

This seems to me to be the most obvious thing people would want to know. But this article does not explain that.

Please somebody put an explanation of which systems have UEFI in this article. ---Dagme (talk) 17:25, 9 March 2018 (UTC)

It appears that Windows 7 systems are the earliest PCs to be able to support booting via UEFI, if you install Windows 7 SP1. The split appears to be with X64 systems (their boots are UEFI compatible) versus X86 (their boot relies on the MBR alone). So PCs which were manufactured with Windows 8, 8.1, and 10 are UEFI boot. PCs which were manufactured with Windows 7 pre SP1 appear to rely on MBR boot, it appears.

If you find a conflicting citation, you should add it here and edit this text, please.

PCs which replace the boot process with GRUB, etc use a parallel solution for booting, as in Linux.

It appears Macs utilize the EFI system partition, and also follow UEFI to load OS X. --Ancheta Wis   (talk | contribs) 22:31, 9 June 2018 (UTC)

Generally, a PC may have both: UEFI firmware and legacy BIOS, and one of them (commonly the first) is activated. The PC user may be able to change this setting. The way to determine which kind of PC firmware is current, depends on the operating system. For instance, Windows provides this information via the msinfo32 program, under Linux one can look for a folder /sys/firmware/efi (which is present if the system is using UEFI). Ed --79.242.71.111 (talk) 10:47, 9 May 2019 (UTC)

UEFI is not restricted to PCs as legacy PC BIOS was. There is no generic user method to determine if a PC has PC BIOS and/or UEFI system firmware. Most PC system firmwares have some sort of concept of a Setup utility that can be entered via keystroke during boot. From there one can normally configure features of the PC and often this will have some PC BIOS and/or UEFI specific options that may be useful in differentiating. 17.226.15.91 (talk) 17:55, 15 May 2019 (UTC)

How many *separate* implementations of UEFI are in use?

The section on implementations could maybe benefit from the following information, if anybody has them: As of 2019, is there more than one completely separate implementations of the UEFI specification in practical use (i.e. shipped in commercial, mass produced products)? Or do all the versions in practical use derive or branch off from a single common code base? If you know this (I don't as I came here to find out), please add the information. -- 194.39.218.10 (talk) 09:17, 9 August 2019 (UTC)

more corrections

UEFI requires the firmware and operating system loader (or kernel) to be size-matched; for example, a 64-bit UEFI firmware implementation can load only a 64-bit operating system (OS) boot loader or kernel (unless the CSM-based Legacy boot). After the system transitions from "Boot Services" to "Runtime Services", the operating system kernel takes over.

1. 1 that's just a stanza excusing FORCED HARDWARE UPGRADE which is terrible for consumers and usually involves chinese replacements of previously usa-made hardware (ie, HD). also the old way worked both ways there is no excuse for failure.

1. 2 it's not true UEFI should control the processor state

2a) It is (*#&*( clueless of Intel processor states (apple, win10, redhat, freebsd all use Intel processors differently and none of them completely strictly dictly correctly). It's impossible that UEFI would set the processor state and that the Kernel would follow the state of the UEFI. Whoever wrote the article is 100% clueless about processor states and their impact on stability and security and the finite state automaton which is DIFFERENT on every CPU really (hundreds of differences the Kernels supposedly lock and load but cannot completely handle).

suspicious removals

The old EFI article retained a discussion of FIRMWARE storage of boot images (which obviously only 1 OS can have mastered and others must follow), which have been removed.

Also - the fact Sun Microsystems and others had updatable firmware booting 30 years ago has been removed (also that flash-bios "with extra space for boot code" on Intel bases were a progenator of UEFI (if not the exact same thing) and that has been removed). That is: this is NOT a new technology and ... if you read the complaints section ... you'll see it has not been a cross-os or 32/64 consumer friendly thing either.

An article (I do not know which, or maybe something else?) is missing from this paragraph.

As is there is a paragraph that reads:

                     Booting UEFI systems from GPT-partitioned disks is commonly called UEFI-GPT booting.
                     Despite the fact that the UEFI specification requires MBR partition tables to be fully
                     supported,[31] some UEFI firmware implementations immediately switch to the BIOS-based
                     CSM booting depending on the type of boot disk's partition table, effectively
                     preventing UEFI booting to be performed from EFI System Partition on MBR-partitioned
                     disks.[44] Such a boot scheme is commonly called UEFI-MBR.

The 2nd sentence here omits an article that I would expect to qualify "EFI System Partition".

What it _says_ is that something is prevented.

What is unclear is whether that something is prevented from "_an_ EFI System Partition" (ESP) or from "_the_ ESP" or from "_any_ ESP".

Is an implementation/user/machine (somehow) restricted to only one ESP? That would mean "the" is missing from the above.

If multiple ESPs are possible/permitted/likely/... then "an" is missing.

If somehow all ways of doing an ESP boot are prevented, that would mean "any" is missing. — Preceding unsigned comment added by 2601:1C1:C100:9380:0:0:0:6886 (talk) 04:13, 23 June 2022 (UTC)