อินเทอร์เฟซเฟิร์มแวร์แบบขยายได้รวม
คำย่อ	ยูอีเอฟไอ
สถานะ	ที่ตีพิมพ์
ปีเริ่มต้น	2549 [ก]
เวอร์ชั่นล่าสุด	2.11 [ 1 ] 16 ธันวาคม 2024
องค์กร	ฟอรัม UEFI
มาตรฐานที่เกี่ยวข้อง	เอซีพีไอ การเริ่มต้นแพลตฟอร์ม UEFI
ผู้มาก่อน	BIOSบนคอมพิวเตอร์ที่เข้ากันได้กับ IBM PC [ b ]
โดเมน	เฟิร์มแวร์
เว็บไซต์	uefi.org​

Unified Extensible Firmware InterfaceหรือUEFI ^{[ c ] [ d ]}เป็นข้อกำหนดสำหรับสถาปัตยกรรม เฟิร์มแวร์ ของแพลตฟอร์มคอมพิวเตอร์ เมื่อ เปิดเครื่องคอมพิวเตอร์ การ ใช้ งาน UEFI มักจะทำงานก่อน ก่อนที่ระบบปฏิบัติการหรือโปรแกรมอื่นใดจะถูกโหลด ตัวอย่างเช่นAMI Aptio , Phoenix SecureCore , TianoCore EDK IIและInsydeH2O

UEFI แทนที่BIOSที่มีอยู่ในROM บูตของคอมพิวเตอร์ส่วนบุคคล ทั้งหมด ที่เข้ากันได้กับ IBM PC ^{[ 3 ] [ 4 ]}แม้ว่าจะสามารถให้ความเข้ากันได้แบบย้อนหลังกับ BIOS โดยใช้การบูต CSMก็ตาม ต่างจาก BIOS ซึ่งเดิมทีพัฒนาโดย IBM ในฐานะสถาปัตยกรรมที่เป็นกรรมสิทธิ์ ข้อกำหนด UEFI นั้นได้รับการจัดการโดยกลุ่มอุตสาหกรรม การใช้งานเฟิร์มแวร์ส่วนใหญ่ในเชิงพาณิชย์สำหรับทั้งสองยังคงเป็นกรรมสิทธิ์

Intel เป็นผู้พัฒนามาตรฐาน Extensible Firmware Interface ( EFI ) ดั้งเดิมโดยเวอร์ชัน EFI สุดท้ายของ Intel คือเวอร์ชัน 1.10 ที่วางจำหน่ายในปี 2548 เวอร์ชันต่อมาได้รับการพัฒนาเป็น UEFI โดยUEFI Forum

UEFI เป็นอิสระจากแพลตฟอร์มและภาษาโปรแกรม แต่ภาษา Cถูกใช้สำหรับการใช้งานอ้างอิง TianoCore EDKII

แรงจูงใจดั้งเดิมของ EFI เกิดขึ้นในช่วงการพัฒนาระบบ Intel–HP Itanium รุ่นแรก ในช่วงกลางทศวรรษ 1990 ข้อจำกัด ของ BIOSกลายเป็นข้อจำกัดที่เข้มงวดเกินไปสำหรับแพลตฟอร์มเซิร์ฟเวอร์ขนาดใหญ่ที่ Itanium มุ่งเป้าไป^{[ 5 ]}ความพยายามในการแก้ไขปัญหาเหล่านี้เริ่มต้นขึ้นในปี 1998 และในตอนแรกเรียกว่าIntel Boot Initiative [ ^{6 ] ต่อ}มาได้เปลี่ยนชื่อเป็นExtensible Firmware Interface (EFI) ^{[ 7 ] [ 6 ]}

Tiano ซึ่งเป็นการใช้งาน UEFI แบบโอเพนซอร์สตัวแรกเปิดตัวโดย Intel ในปี 2547 ต่อมา Tiano ก็ถูกแทนที่ด้วย EDK ^{[ 8 ]}และEDK II ^{[ 9 ]}และปัจจุบันได้รับการดูแลโดยชุมชน TianoCore ^{[ 10 ]}

ในเดือนกรกฎาคม พ.ศ. 2551 Intel ได้ยุติการพัฒนาข้อกำหนด EFI ที่เวอร์ชัน 1.10 และส่งมอบให้กับUnified EFI Forumซึ่งได้พัฒนาข้อกำหนดดังกล่าวเป็นUnified Extensible Firmware Interface (UEFI) ข้อกำหนด EFI ดั้งเดิมยังคงเป็นกรรมสิทธิ์ของ Intel ซึ่งเป็นผู้ให้สิทธิ์ใช้งานเฉพาะผลิตภัณฑ์ที่ใช้ EFI เท่านั้น แต่ข้อกำหนด UEFI เป็นกรรมสิทธิ์ของ UEFI Forum ^{[ 5 ] [ 11 ]}

ข้อกำหนด UEFI เวอร์ชัน 2.0 ได้รับการเผยแพร่เมื่อวันที่ 31 มกราคม 2549 โดยได้เพิ่มการเข้ารหัสและการรักษาความปลอดภัย เข้ามา

ข้อกำหนด UEFI เวอร์ชัน 2.1 ได้รับการเผยแพร่เมื่อวันที่ 7 มกราคม 2550 โดยได้เพิ่มการตรวจสอบสิทธิ์เครือข่ายและ สถาปัตยกรรม ส่วนติดต่อผู้ใช้ ("โครงสร้างพื้นฐานส่วนติดต่อผู้ใช้" ใน UEFI)

ข้อกำหนด UEFI เวอร์ชัน 2.3.1 ได้รับการเผยแพร่เมื่อวันที่ 6 เมษายน 2554 โดยเพิ่มฟังก์ชัน Secure Boot และการรองรับ สถาปัตยกรรม ARM

ในเดือนตุลาคม 2018 Arm ได้เปิดตัว Arm ServerReady ซึ่งเป็นโปรแกรมรับรองการปฏิบัติตามมาตรฐานที่มุ่งรับรองว่าระบบปฏิบัติการและไฮเปอร์ไวเซอร์มาตรฐานสามารถทำงานบนเซิร์ฟเวอร์ที่ใช้ Arm ได้ โปรแกรมนี้กำหนดให้เฟิร์มแวร์ของระบบต้องเป็นไปตามข้อกำหนด Server Base Boot Requirements (SBBR) ซึ่ง SBBR กำหนดให้ต้องเป็นไปตามมาตรฐาน UEFI, ACPIและSMBIOSในเดือนตุลาคม 2020 Arm ได้ประกาศขยายโปรแกรมไปยัง ตลาด EdgeและIoTโดยใช้ชื่อโปรแกรมใหม่ว่าArm SystemReady Arm SystemReady ได้กำหนดข้อกำหนด Base Boot Requirements ( BBR ) ซึ่งปัจจุบันมีสูตรอยู่สามสูตร โดยสองสูตรเกี่ยวข้องกับ UEFI ได้แก่ 1) SBBR: ซึ่งกำหนดให้ต้องเป็นไปตามมาตรฐาน UEFI, ACPI และ SMBIOS เหมาะสำหรับสภาพแวดล้อมการทำงานระดับองค์กร เช่น Windows, Red Hat Enterprise Linux และ VMware ESXi และ 2) EBBR: ซึ่งกำหนดให้ต้องเป็นไปตามชุดอินเทอร์เฟซ UEFI ตามที่กำหนดไว้ใน Embedded Base Boot Requirements ( EBBR ) เหมาะสำหรับสภาพแวดล้อมแบบฝังตัว เช่น Yocto ระบบปฏิบัติการ Linux และ BSD หลายตัวสามารถรองรับทั้งสองสูตรได้

ในเดือนธันวาคม พ.ศ. 2561 ไมโครซอฟต์ประกาศโครงการ Mu ซึ่งเป็นการแยกย่อยของ TianoCore EDK II ที่ใช้ใน ผลิตภัณฑ์ Microsoft SurfaceและHyper-Vโครงการนี้รวมเอาโมเดลการส่งมอบเฟิร์มแวร์ตามบริการไว้ด้วย^{[ 12 ]}

ข้อกำหนด UEFI เวอร์ชันล่าสุด เวอร์ชัน 2.11 ได้รับการเผยแพร่ในเดือนธันวาคม พ.ศ. 2567 ^{[ 13 ]}

UEFI รองรับสถาปัตยกรรมโปรเซสเซอร์ 32 บิตขึ้นไป อย่างไรก็ตามรองรับเฉพาะโปรเซสเซอร์ที่มีโหมดlittle-endian เท่านั้น ^{[ 13 ] : ส่วนที่ 1.9.1} ข้อกำหนด UEFI เวอร์ชัน 2.11 มีเอกสารอย่างเป็นทางการสำหรับสถาปัตยกรรมโปรเซสเซอร์ต่อไปนี้: ^{[ 13 ] : ส่วนที่ 3.5.1.1}

• x86 ( IA-32 , x86-64 )
• อิทาเนียม ( IA-64 )
• อาร์เอ็ม ( AArch32 , AArch64 )
• RISC-V (32 บิต, 64 บิต, 128 บิต)
• LoongArch (32 บิต, 64 บิต)

การสนับสนุน UEFI อย่างไม่เป็นทางการกำลังอยู่ระหว่างการพัฒนาสำหรับPOWERPC64โดยการใช้งานTianoCore EDK IIบน OPAL ^{[ 14 ]}ซึ่งเป็นเลเยอร์นามธรรมของ OpenPOWER ที่ทำงานในโหมด little-endian ^{[ 15 ]}สำหรับMIPSก็มีโครงการที่ไม่เป็นทางการเช่นกัน โดยอิงจาก EDK ดั้งเดิม^{[ 16 ] [ 17 ]}อย่างไรก็ตาม ทั้งสองโครงการได้ถูกยกเลิกไปแล้วตั้งแต่เดือนพฤศจิกายน 2016 และกันยายน 2015 ตามลำดับ

UEFI อนุญาตให้เรียกใช้แอปพลิเคชัน UEFI ที่ตรงกับความกว้างบิตของเฟิร์มแวร์เท่านั้น แม้ว่าโปรเซสเซอร์จะรองรับความกว้างบิตที่เล็กกว่าหรือใหญ่กว่าก็ตาม ตัวอย่างเช่น เฟิร์มแวร์ UEFI 64 บิต อาจเรียกใช้แอปพลิเคชัน UEFI 64 บิตเท่านั้น แม้ว่าโปรเซสเซอร์จะมีโหมดโปรเซสเซอร์ 32 บิตก็ตาม^{[ 13 ] : ส่วนที่ 2.3.2 และ 2.3.4} คอมพิวเตอร์ระดับล่างบางเครื่องถูกจัดส่งมาพร้อมกับเฟิร์มแวร์ UEFI 32 บิตที่ทำงานบน CPU 64 บิต^{[ 18 ]}เมื่อแอปพลิเคชัน UEFI สิ้นสุดบริการบูตและได้รับสิทธิ์ควบคุมระบบอย่างเต็มที่แล้ว ก็จะสามารถเปลี่ยนโหมดการทำงานของโปรเซสเซอร์ได้^{[ 13 ] : ส่วนที่ 2.3.2 และ 2.3.4} อย่างไรก็ตาม การเรียกใช้บริการรันไทม์จำเป็นต้องเปลี่ยนกลับไปเป็นโหมดโปรเซสเซอร์เดิมในไม่ช้า^{[ 19 ]}เนื่องจากบริการรันไทม์สามารถเรียกใช้ได้จากโหมดโปรเซสเซอร์เดียวกันกับการใช้งานเฟิร์มแวร์เท่านั้น^{[ 13 ] : ส่วนที่ 2.3.2 และ 2.3.4}

เคอร์เนลLinuxเพิ่มการสนับสนุนการบูตเคอร์เนล 64 บิตบนเฟิร์มแวร์ UEFI 32 บิตที่มี ซีพียู x86-64ตั้งแต่เวอร์ชัน 3.15 โดยกำหนดให้ตัวโหลดบูต UEFI ต้องรองรับโปรโตคอลการส่งต่อ EFI ^{[ 20 ]}โปรโตคอลการส่งต่อ EFI อนุญาตให้ตัวโหลดบูต UEFI เลื่อนการเริ่มต้น UEFI ไปยังสตับบูต EFI ของเคอร์เนล เพื่อให้เคอร์เนลเท่านั้นที่ทำการเริ่มต้น UEFI ^{[ 21 ] [ 22 ] [ 23 ]}

นอกจากรูปแบบการแบ่งพาร์ติชั่นดิสก์พีซีมาตรฐานที่ใช้มาสเตอร์บูตเรคคอร์ด (MBR) แล้ว UEFI ยังทำงานร่วมกับ รูปแบบการแบ่งพาร์ติชั่น GUID Partition Table (GPT) ซึ่งปราศจากข้อจำกัดหลายประการของMBRโดยเฉพาะอย่างยิ่ง ข้อจำกัดของ MBR เกี่ยวกับจำนวนและขนาดของพาร์ติชั่นดิสก์ (สูงสุดสี่พาร์ติชั่นหลักต่อดิสก์ และสูงสุด 2  TB (2 × 2 ⁴⁰ ไบต์ )ต่อดิสก์) จะถูกผ่อนปรนลง โดยเฉพาะอย่างยิ่ง GPT อนุญาตให้มีขนาดดิสก์และพาร์ติชั่นสูงสุด 8  ZiB (8 × 2 ⁷⁰ไบต์)พร้อมเซกเตอร์ขนาด 512 ไบต์^{[ 24 ]}ข้อกำหนด UEFI รองรับเฉพาะ พาร์ติชั่น FAT12 / 16 / 32 ^{[ 13 ] : ส่วนที่ 13.3} ที่อยู่บนดิสก์ GPT หรือ MBR รวมถึงดิสก์ออปติคัลที่ฟอร์แมตด้วยEl Torito ^{[ 13 ] : ส่วนที่ 13.3.2} แม้ว่า GPT จะเป็นส่วนหนึ่งของมาตรฐาน UEFI แต่ก็อาจใช้งานได้โดยพีซี BIOS เพื่อบูตระบบปฏิบัติการ^{[ 24 ] [ 25 ]}

การสนับสนุน GPT ในLinuxเปิดใช้งานโดยการเปิดใช้งานตัวเลือกCONFIG_EFI_PARTITION(EFI GUID Partition Support) ระหว่างการกำหนดค่าเคอร์เนล^{[ 26 ]}ตัวเลือกนี้อนุญาตให้ Linux รับรู้และใช้ดิสก์ GPT หลังจากที่เฟิร์มแวร์ระบบส่งการควบคุมระบบไปยัง Linux

เพื่อความเข้ากันได้แบบย้อนกลับ Linux สามารถใช้ดิสก์ GPT ในระบบที่ใช้ BIOS สำหรับทั้งการจัดเก็บข้อมูลและการบูต เนื่องจากทั้งGRUB 2และ Linux ต่างก็รองรับ GPT การตั้งค่าดังกล่าวโดยทั่วไปเรียกว่าBIOS-GPTเนื่องจาก GPT รวม MBR ป้องกันไว้ คอมพิวเตอร์ที่ใช้ BIOS จึงสามารถบูตจากดิสก์ GPT โดยใช้บูตโหลดเดอร์ที่รองรับ GPT ซึ่งจัดเก็บไว้ในพื้นที่โค้ดบูตสแตรป ของ MBR ป้องกัน ^{[ 24 ]}ในกรณีของ GRUB การกำหนดค่าดังกล่าวต้องใช้พาร์ติชันบูต BIOS สำหรับ GRUB เพื่อฝังโค้ดขั้น ที่สอง เนื่องจากไม่มีช่องว่างหลัง MBR ในดิสก์ที่แบ่งพาร์ติชัน GPT (ซึ่งถูกแทนที่โดยส่วนหัวหลักและตารางพาร์ติชันหลัก ของ GPT ) โดยทั่วไป พาร์ติชั่นนี้มีขนาด1  MB และ ตัวระบุที่ไม่ซ้ำกันทั่วโลก (GUID) ในรูปแบบ GPT คือ21686148-6449-6E6F-744E-656564454649ซึ่ง GRUB จะใช้เฉพาะในการตั้งค่า BIOS-GPT เท่านั้น จากมุมมองของ GRUB จะไม่มีพาร์ติชั่นประเภทนี้ในกรณีของการแบ่งพาร์ติชั่นแบบ MBR พาร์ติชั่นนี้ไม่จำเป็นหากระบบเป็นแบบ UEFI เนื่องจากไม่จำเป็นต้องฝังโค้ดขั้นที่สองในกรณีนั้น^{[ 25 ] [ 24 ]}

ระบบ UEFI สามารถเข้าถึงดิสก์ GPT และบูตโดยตรงจากดิสก์เหล่านั้น ซึ่งทำให้ Linux สามารถใช้วิธีการบูต UEFI ได้ การบูต Linux จากดิสก์ GPT บนระบบ UEFI เกี่ยวข้องกับการสร้างพาร์ติชั่นระบบ EFI (ESP) ซึ่งประกอบด้วยแอปพลิเคชัน UEFI เช่น บูตโหลดเดอร์ เคอร์เนลระบบปฏิบัติการ และซอฟต์แวร์ยูทิลิตี้^{[ 27 ] [ 28 ]}การตั้งค่าดังกล่าวโดยทั่วไปเรียกว่าUEFI-GPTในขณะที่แนะนำให้ ESP มีขนาดอย่างน้อย 512 MB และฟอร์แมตด้วยระบบไฟล์ FAT32 เพื่อความเข้ากันได้สูงสุด^{[ 24 ]}

เพื่อความเข้ากันได้กับเวอร์ชันเก่าการใช้งาน UEFI บางระบบยังรองรับการบูตจากดิสก์ที่แบ่งพาร์ติชั่นแบบ MBR ผ่านโมดูลสนับสนุนความเข้ากันได้ (CSM) ซึ่งให้ความเข้ากันได้กับ BIOS รุ่นเก่า ในกรณีนั้น การบูต Linux บนระบบ UEFI จะเหมือนกับการบูตบนระบบที่ใช้ BIOS รุ่นเก่า

ระบบปฏิบัติการ Windows 11 , Windows Vista SP1/SP2 และ7เวอร์ชัน 64 บิต และ Windows 8 , 8.1และ10ทั้งเวอร์ชัน 32 บิตและ 64 บิตสามารถบูตจากดิสก์ GPT ที่มีขนาดใหญ่กว่า 2  TBได้

EFI กำหนดบริการไว้สองประเภท ได้แก่บริการบูตและบริการรันไทม์บริการบูตจะใช้งานได้เฉพาะในขณะที่เฟิร์มแวร์เป็นเจ้าของแพลตฟอร์ม (เช่น ก่อนExitBootServices()การเรียกใช้งาน) และรวมถึงคอนโซลข้อความและกราฟิกบนอุปกรณ์ต่างๆ ตลอดจนบริการบัส บล็อก และไฟล์ บริการรันไทม์ยังคงสามารถเข้าถึงได้ในขณะที่ระบบปฏิบัติการกำลังทำงานอยู่ ซึ่งรวมถึงบริการต่างๆ เช่น วันที่ เวลา และการเข้าถึง NVRAM

บริการโปรโตคอลเอาต์พุตกราฟิก (GOP)

โปรโตคอลเอาต์พุตกราฟิก (GOP) ให้บริการรันไทม์ ดู ส่วน คุณสมบัติกราฟิกด้านล่างด้วย ระบบปฏิบัติการได้รับอนุญาตให้เขียนโดยตรงไปยังเฟรมบัฟเฟอร์และบิตบลิตที่ GOP จัดเตรียมไว้ในระหว่างโหมดรันไทม์^{[ 29 ]}

บริการแผนที่หน่วยความจำ UEFI

บริการSMM

บริการACPI

บริการSMBIOS

บริการ Devicetree (สำหรับโปรเซสเซอร์ RISC)

บริการที่หลากหลาย

ตัวแปร UEFI เป็นวิธีในการจัดเก็บข้อมูล โดยเฉพาะข้อมูลที่ไม่ระเหย ตัวแปร UEFI บางตัวใช้ร่วมกันระหว่างเฟิร์มแวร์แพลตฟอร์มและระบบปฏิบัติการ เนมสเปซของตัวแปรจะถูกระบุด้วย GUID และตัวแปรเป็นคู่คีย์/ค่า ตัวอย่างเช่น ตัวแปร UEFI สามารถใช้เพื่อเก็บข้อความข้อผิดพลาดไว้ในNVRAMหลังจากเกิดข้อผิดพลาด เพื่อให้ระบบปฏิบัติการสามารถเรียกใช้ได้หลังจากการรีบูต^{[ 30 ]}

บริการเวลา

UEFI ให้บริการเวลา บริการเวลารวมถึงการสนับสนุนเขตเวลาและฟิลด์เวลาออมแสง ซึ่งช่วยให้ สามารถตั้ง ค่านาฬิกาเรียลไทม์ ของฮาร์ดแวร์ เป็นเวลาท้องถิ่นหรือ UTC ได้^{[ 13 ] : ส่วนที่ 8.3} บนเครื่องที่ใช้นาฬิกาเรียลไทม์ PC-AT โดยค่าเริ่มต้น นาฬิกาฮาร์ดแวร์ยังคงต้องตั้งค่าเป็นเวลาท้องถิ่นเพื่อความเข้ากันได้กับ Windows ที่ใช้ BIOS ^{[ 31 ]}เว้นแต่จะใช้เวอร์ชันล่าสุดและมีการตั้งค่ารายการในรีจิสทรีของ Windowsเพื่อระบุการใช้ UTC

ปฏิสัมพันธ์ระหว่างตัวจัดการบูต EFI และไดรเวอร์ EFI

UEFI เรียกใช้โปรแกรมอิสระที่เรียกว่าแอปพลิเคชัน UEFI ซึ่งจัดเก็บเป็นไฟล์ในพาร์ติชันระบบ EFI แอปพลิเคชันเหล่านี้สามารถเรียกใช้งานได้ผ่าน UEFI Shell, ตัวจัดการการบูตเฟิร์มแวร์ หรือแอปพลิเคชัน UEFI อื่นๆ และอาจได้รับการพัฒนาโดยอิสระจากผู้ผลิตอุปกรณ์ดั้งเดิม (OEM)

โปรแกรมบูตระบบปฏิบัติการประเภทหนึ่งคือ เช่นGRUB , rEFInd , systemd-bootและWindows Boot Managerซึ่งทำหน้าที่โหลดไฟล์ระบบปฏิบัติการบางไฟล์เข้าไปในหน่วยความจำและเรียกใช้งาน นอกจากนี้ โปรแกรมบูตระบบปฏิบัติการยังสามารถมีส่วนติดต่อผู้ใช้เพื่อให้สามารถเลือกเรียกใช้โปรแกรม UEFI อื่นๆ ได้อีกด้วย ยูทิลิตี้ต่างๆ เช่น UEFI Shell ก็เป็นโปรแกรม UEFI เช่นกัน

EFI กำหนดโปรโตคอลว่าเป็นชุดของอินเทอร์เฟซซอฟต์แวร์ที่ใช้สำหรับการสื่อสารระหว่างโมดูลไบนารีสองโมดูล ไดรเวอร์ EFI ทั้งหมดต้องให้บริการแก่ไดรเวอร์อื่นผ่านทางโปรโตคอล โปรโตคอล EFI คล้ายกับการเรียกใช้งานอินเตอร์รัปต์ของ BIOS

นอกเหนือจาก ไดรเวอร์อุปกรณ์เฉพาะ สถาปัตยกรรมชุดคำสั่ง มาตรฐาน (ISA) แล้ว EFI ยังมีไดรเวอร์อุปกรณ์ ที่ไม่ขึ้นกับ ISA ซึ่งจัดเก็บไว้ในหน่วยความจำแบบไม่ลบเลือนในรูปแบบไบต์โค้ด EFIหรือEBCเฟิร์มแวร์ของระบบมีตัวแปลสำหรับภาพ EBC ในแง่นั้น EBC จึงคล้ายคลึงกับOpen Firmwareซึ่งเป็นเฟิร์มแวร์ที่ไม่ขึ้นกับ ISA ที่ใช้ใน คอมพิวเตอร์ Apple Macintoshที่ใช้PowerPCและ คอมพิวเตอร์ Sun Microsystems SPARCเป็นต้น

ไดรเวอร์ EFI เฉพาะสถาปัตยกรรม (ไม่ใช่ไบต์โค้ด EFI) สำหรับอุปกรณ์บางประเภทอาจมีอินเทอร์เฟซสำหรับระบบปฏิบัติการใช้งาน これにより ระบบปฏิบัติการจึงสามารถใช้ EFI สำหรับไดรเวอร์ในการทำงานด้านกราฟิกและเครือข่ายขั้นพื้นฐานได้ ก่อนและในกรณีที่ไดรเวอร์เฉพาะระบบปฏิบัติการถูกโหลด

ในกรณีอื่นๆ ไดรเวอร์ EFI อาจเป็นไดรเวอร์ระบบไฟล์ที่อนุญาตให้บูตจากไดรฟ์ประเภทอื่นๆ ตัวอย่างเช่นefifsสำหรับระบบไฟล์ 37 ระบบ (อิงตาม โค้ด GRUB2 ) ^{[ 32 ]} ซึ่ง Rufusใช้สำหรับการโหลด NTFS ESP แบบต่อเนื่อง^{[ 33 ]}

ข้อกำหนด EFI 1.0 กำหนดโปรโตคอล UGA (Universal Graphic Adapter) เป็นวิธีรองรับคุณสมบัติกราฟิก UEFI ไม่ได้รวม UGA ไว้และแทนที่ด้วยGOP (Graphics Output Protocol ) ^{[ 34 ]}

UEFI 2.1 ได้กำหนด "โครงสร้างพื้นฐานส่วนติดต่อผู้ใช้" (Human Interface Infrastructure หรือ HII) เพื่อจัดการข้อมูลที่ผู้ใช้ป้อน ข้อความที่แปลเป็นภาษาต่างๆ ฟอนต์ และแบบฟอร์ม (ในความหมายของHTML ) สิ่งเหล่านี้ช่วยให้ผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) หรือผู้จำหน่าย BIOS อิสระ (IBV) สามารถออกแบบส่วนติดต่อผู้ใช้แบบกราฟิกสำหรับการกำหนดค่าก่อนบูตได้ UEFI ใช้UTF-16ในการเข้ารหัสข้อความโดยค่าเริ่มต้น แต่ตั้งแต่ UEFI 2.4 เป็นต้นไป อนุญาตให้ใช้ASCIIในการเข้ารหัสข้อความที่เป็น ASCII เท่านั้นได้

เฟิร์มแวร์ UEFI รุ่นแรกๆ ส่วนใหญ่เป็นแบบใช้คอนโซล ปัจจุบันเฟิร์มแวร์ UEFI จำนวนมากเป็นแบบใช้ GUI

พาร์ติชั่นระบบ EFI ซึ่งมักย่อเป็น ESP คือ พาร์ติชั่น อุปกรณ์จัดเก็บข้อมูลที่ใช้ในคอมพิวเตอร์ที่ปฏิบัติตามข้อกำหนด UEFI เฟิร์มแวร์ UEFI จะเข้าถึงพาร์ติชั่นนี้เมื่อเปิดเครื่องคอมพิวเตอร์ โดยจะจัดเก็บแอปพลิเคชัน UEFI และไฟล์ที่แอปพลิเคชันเหล่านี้ต้องการในการทำงาน รวมถึงบูตโหลดเดอร์ ของระบบปฏิบัติการ รูป แบบตารางพาร์ติ ชั่น ที่รองรับได้แก่MBRและGPTรวมถึง วอลุ่ม El Toritoบนแผ่นดิสก์แบบออปติคอล^{[ 13 ] : ส่วนที่ 2.6.2} สำหรับการใช้งานบน ESP นั้น UEFI กำหนดเวอร์ชันเฉพาะของระบบไฟล์ FATซึ่งได้รับการดูแลรักษาเป็นส่วนหนึ่งของข้อกำหนด UEFI และเป็นอิสระจากข้อกำหนด FAT ดั้งเดิม โดยครอบคลุมระบบไฟล์FAT32 , FAT16และFAT12 ^{[ 13 ] : ส่วนที่ 13.3 [ 35 ]} ESP ยังมีพื้นที่สำหรับเซกเตอร์บูตเป็นส่วนหนึ่งของความเข้ากันได้ของ BIOS ย้อนหลัง

คอมพิวเตอร์จะเริ่มต้นทำงานด้วยกระบวนการที่เรียกว่าการบูต : คอมพิวเตอร์จะโหลดซอฟต์แวร์ระบบปฏิบัติการโดยใช้โปรแกรมขนาดเล็กมากที่ติดตั้งอยู่ในฮาร์ดแวร์ ซึ่งโดยทั่วไปแล้วจะโหลดโปรแกรมขนาดเล็กอีกโปรแกรมหนึ่งเพื่อโหลดและเริ่มต้นระบบปฏิบัติการ (OS)

แตกต่างจาก BIOS ของพีซีแบบดั้งเดิม UEFI ไม่ได้อาศัยเซกเตอร์บูตในหน่วยเก็บข้อมูลของคอมพิวเตอร์ แต่กำหนดตัวจัดการบูตเป็นส่วนหนึ่งของข้อกำหนด UEFI แทน เมื่อคอมพิวเตอร์เปิดเครื่อง ตัวจัดการบูตจะตรวจสอบการกำหนดค่าบูต และตามการตั้งค่าเหล่านั้น จะเรียกใช้ตัวโหลดบูต ระบบปฏิบัติการ หรือเคอร์เนลระบบปฏิบัติการ ที่กำหนดไว้ การกำหนดค่าบูตถูกกำหนดโดยตัวแปร ที่จัดเก็บไว้ในหน่วยเก็บข้อมูล NVRAMแบบถาวรของคอมพิวเตอร์รวมถึงตัวแปรที่ระบุเส้นทางระบบไฟล์ไปยังตัวโหลดระบบปฏิบัติการหรือเคอร์เนลระบบปฏิบัติการ

UEFI สามารถตรวจจับบูตโหลดเดอร์ของระบบปฏิบัติการได้โดยอัตโนมัติ ซึ่งช่วยให้บูตจากอุปกรณ์แบบถอดได้ เช่นแฟลชไดรฟ์ USB ได้ง่าย การตรวจจับอัตโนมัตินี้อาศัยเส้นทางไฟล์มาตรฐานไปยังบูตโหลดเดอร์ของระบบปฏิบัติการ โดยเส้นทางจะแตกต่างกันไปตามสถาปัตยกรรมของคอมพิวเตอร์รูปแบบของเส้นทางไฟล์ถูกกำหนดเป็น<EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFIตัวอย่างเช่น เส้นทางไฟล์ไปยังบูตโหลดเดอร์ของระบบปฏิบัติการบน^ระบบ x86-64คือ\efi\boot\bootx64.efi [ ^{13 ] : ส่วนที่ 3.5.1.1} และ\efi\boot\bootaa64.efiบนสถาปัตยกรรม ARM64

การบูตระบบ UEFI จากดิสก์ที่แบ่งพาร์ติชันแบบ GPT มักเรียกว่าการบูต UEFI-GPTแม้ว่าข้อกำหนด UEFI จะกำหนดให้ต้องรองรับตารางพาร์ติชัน MBR อย่างเต็มที่ก็ตาม^{[ 13 ] : ส่วนที่ 13.3.2} การใช้งานเฟิร์มแวร์ UEFI บางอย่างจะเปลี่ยนไปใช้การบูต CSM ที่ใช้ BIOS ทันที ขึ้นอยู่กับประเภทของตารางพาร์ติชันของดิสก์บูต ซึ่งจะป้องกันการบูต UEFI จากพาร์ติชันระบบ EFIบนดิสก์ที่แบ่งพาร์ติชันแบบ MBR ได้อย่างมีประสิทธิภาพ รูปแบบการบูตดังกล่าวโดยทั่วไปเรียกว่าUEFI- MBR

นอกจากนี้ ยังเป็นเรื่องปกติที่โปรแกรมจัดการการบูตจะมีส่วนติดต่อผู้ใช้แบบข้อความ เพื่อให้ผู้ใช้สามารถเลือก OS (หรือยูทิลิตี้การติดตั้ง) ที่ต้องการจากรายการตัวเลือกการบูตที่มีอยู่

ในแพลตฟอร์มพีซี เฟิร์มแวร์ที่รองรับการบูตแบบ UEFI มักถูกเรียกว่า "UEFI BIOS" แม้ว่าแพลตฟอร์ม x86 รุ่นใหม่บางรุ่นจะไม่รองรับ CSM เลยก็ตาม

เพื่อให้มั่นใจถึงความเข้ากันได้กับเวอร์ชันก่อนหน้า เฟิร์มแวร์ UEFI บนเครื่องพีซีอาจรองรับการบูตในโหมด BIOS แบบดั้งเดิมจากดิสก์ที่แบ่งพาร์ติชั่นแบบ MBR ผ่านโมดูลสนับสนุนความเข้ากันได้ (CSM) ซึ่งให้ความเข้ากันได้กับ BIOS แบบดั้งเดิม ในสถานการณ์นี้ การบูตจะดำเนินการในลักษณะเดียวกับระบบที่ใช้ BIOS แบบดั้งเดิม โดยไม่สนใจตารางพาร์ติชั่นและอาศัยเนื้อหาของเซกเตอร์บูตแทน

โมดูลสนับสนุนความเข้ากันได้ช่วยให้ระบบปฏิบัติการรุ่นเก่าและROM ตัวเลือกแบบ เก่าบางตัว ที่ไม่รองรับ UEFI ยังคงสามารถใช้งานได้^{[ 36 ]}นอกจากนี้ยังให้ ฟังก์ชัน โหมดการจัดการระบบ (SMM) แบบเก่าที่จำเป็น (CompatibilitySmm) นอกเหนือจากคุณสมบัติที่จัดให้โดย UEFI SMM ตัวอย่างของฟังก์ชัน SMM แบบเก่าดังกล่าวคือการให้การสนับสนุน USB แบบเก่าสำหรับคีย์บอร์ดและเมาส์ โดยการจำลองอุปกรณ์PS/2 แบบคลาสสิก ^{[ 36 ]}

ในเดือนพฤศจิกายน 2017 อินเทลประกาศว่ามีแผนจะทยอยยุติการสนับสนุน CSM สำหรับแพลตฟอร์มไคลเอ็นต์ภายในปี 2020 ^{[ 37 ]}

ในเดือนกรกฎาคม พ.ศ. 2565 Kaspersky Labs ได้เผยแพร่ข้อมูลเกี่ยวกับ Rootkit ที่ออกแบบมาเพื่อบูตโค้ดที่เป็นอันตรายบนเครื่องที่ใช้ชิปเซ็ต Intel H81 และโมดูลสนับสนุนความเข้ากันได้ของเมนบอร์ดที่ได้รับผลกระทบ^{[ 38 ]}

ในเดือนสิงหาคม พ.ศ. 2566 อินเทลประกาศว่ามีแผนจะยุติการสนับสนุน CSM สำหรับแพลตฟอร์มเซิร์ฟเวอร์ภายในปี พ.ศ. 2567 ^{[ 39 ]}

ข้อกำหนด UEFI รวมถึงการสนับสนุนการบูตผ่านเครือข่ายโดยใช้Preboot Execution Environment (PXE) โปรโตคอลเครือข่าย การบูต PXE ได้แก่Internet Protocol ( IPv4และIPv6 ), User Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP) และiSCSI ^{[ 13 ]} : ^{924–1509 [ 40 ]}

รูปภาพระบบปฏิบัติการสามารถจัดเก็บระยะไกลบนเครือข่ายพื้นที่จัดเก็บข้อมูล (SAN) โดยใช้Internet Small Computer System Interface (iSCSI) และFibre Channel over Ethernet (FCoE) เป็นโปรโตคอลที่รองรับสำหรับการเข้าถึง SAN ^{[ 13 ] [ 41 ] [ 42 ]}

ข้อกำหนด UEFI เวอร์ชัน 2.5 เพิ่มการสนับสนุนการเข้าถึงอิมเมจบูต^ผ่าน HTTP [ ^{43 ]}

ข้อกำหนด UEFI กำหนด Secure Boot ที่สามารถรักษาความปลอดภัยของกระบวนการบูตโดยป้องกันการโหลดไดรเวอร์ UEFI หรือตัวโหลดบูตระบบปฏิบัติการที่ไม่ได้ลงนามด้วยลายเซ็นดิจิทัล ที่ยอมรับได้ เมื่อเปิดใช้งาน Secure Boot ระบบจะอยู่ในโหมด "ตั้งค่า" ในขั้นต้น ซึ่งอนุญาตให้เขียนคีย์สาธารณะที่เรียกว่า "คีย์แพลตฟอร์ม" (PK) ลงในเฟิร์มแวร์ เมื่อเขียนคีย์แล้ว Secure Boot จะเข้าสู่โหมด "ผู้ใช้" ซึ่งเฟิร์มแวร์จะสามารถโหลดได้เฉพาะไดรเวอร์ UEFI และตัวโหลดบูตระบบปฏิบัติการที่ลงนามด้วยคีย์แพลตฟอร์มเท่านั้น สามารถเพิ่ม "คีย์แลกเปลี่ยน" (KEK) เพิ่มเติมลงในฐานข้อมูลที่จัดเก็บไว้ในหน่วยความจำเพื่ออนุญาตให้ใช้ใบรับรองอื่นได้ แต่ใบรับรองเหล่านั้นจะต้องยังคงเชื่อมต่อกับส่วนส่วนตัวของคีย์แพลตฟอร์ม^{[ 44 ]} Secure Boot ยังสามารถอยู่ในโหมด "กำหนดเอง" ซึ่งสามารถเพิ่มคีย์สาธารณะเพิ่มเติมลงในระบบที่ไม่ตรงกับคีย์ส่วนตัวได้^{[ 45 ]}

Secure Boot รองรับโดยWindows 8และ8.1 , Windows Server 2012และ 2012 R2, Windows 10 , Windows Server 2016 , 2019และ2022และWindows 11 , VMware vSphere 6.5 ^{[ 46 ]}และระบบปฏิบัติการ Linux หลายตัว รวมถึงFedora (ตั้งแต่เวอร์ชัน 18), openSUSE (ตั้งแต่เวอร์ชัน 12.3), RHEL (ตั้งแต่เวอร์ชัน 7), CentOS (ตั้งแต่เวอร์ชัน 7 ^{[ 47 ]} ), Debian (ตั้งแต่เวอร์ชัน 10) ^{[ 48 ]} Ubuntu (ตั้งแต่เวอร์ชัน 12.04.2), Linux Mint (ตั้งแต่เวอร์ชัน 21.3) ^{[ 49 ] [ 50 ]}และAlmaLinux OS (ตั้งแต่เวอร์ชัน 8.4 ^{[ 51 ]} ) ณ เดือนมกราคม 2025 การสนับสนุน FreeBSDอยู่ในขั้นตอนการวางแผน^{[ 52 ]}

UEFI มีสภาพแวดล้อมเชลล์ซึ่งสามารถใช้เพื่อเรียกใช้แอปพลิเคชัน UEFI อื่นๆ รวมถึงตัวโหลดบูต UEFI นอกจากนั้น คำสั่งที่มีอยู่ในเชลล์ UEFI ยังสามารถใช้เพื่อรับข้อมูลต่างๆ เกี่ยวกับระบบหรือเฟิร์มแวร์ได้อีกด้วย เช่น การรับแผนที่หน่วยความจำ ( memmap) การแก้ไขตัวแปรตัวจัดการบูต ( bcfg) การเรียกใช้โปรแกรมแบ่งพาร์ติชัน ( diskpart) การโหลดไดรเวอร์ UEFI และการแก้ไขไฟล์ข้อความ ( edit) ^{[ 53 ] [ 54 ]}

สามารถดาวน์โหลดซอร์สโค้ดสำหรับเชลล์ UEFI ได้จาก โครงการ TianoCore UDK/EDK2 ของIntel ^{[ 55 ]}นอกจากนี้ยังมี ShellBinPkg ที่สร้างไว้ล่วงหน้า^{[ 56 ]} Shell v2 ทำงานได้ดีที่สุดในระบบ UEFI 2.3 ขึ้นไป และแนะนำให้ใช้ Shell v2 แทน Shell v1 ในระบบเหล่านั้น Shell v1 ควรใช้งานได้ในระบบ UEFI ทุกระบบ^{[ 57 ] [ 58 ]}

วิธีการที่ใช้ในการเรียกใช้ UEFI shell ขึ้นอยู่กับผู้ผลิตและรุ่นของเมนบอร์ด ของระบบ บางระบบมีตัวเลือกโดยตรงในการตั้งค่าเฟิร์มแวร์สำหรับการเรียกใช้ เช่น ต้องมีเวอร์ชัน x86-64 ของ shell ที่คอมไพล์แล้วให้ใช้งานได้<EFI_SYSTEM_PARTITION>/SHELLX64.EFIบางระบบมี UEFI shell ที่ฝังอยู่แล้วซึ่งสามารถเรียกใช้ได้โดยการกดปุ่มผสมที่เหมาะสม^{[ 59 ]}bcfg สำหรับระบบอื่นๆ วิธีแก้ปัญหาคือการสร้างแฟลชไดรฟ์ USB ที่เหมาะสมหรือเพิ่ม ตัวเลือกการบูตที่เกี่ยวข้องกับเวอร์ชันของ shell ที่คอมไพล์แล้วด้วยตนเอง^{[ 54 ]}

ต่อไปนี้เป็นรายการคำสั่งที่รองรับโดยเชลล์ EFI ^{[ 53 ]}

ส่วนขยายของ UEFI สามารถโหลดได้จาก อุปกรณ์จัดเก็บข้อมูล แบบไม่ลบเลือน แทบทุกชนิด ที่เชื่อมต่อกับคอมพิวเตอร์ ตัวอย่างเช่นผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) สามารถจัดจำหน่ายระบบที่มีพาร์ติชั่นระบบ EFI บนฮาร์ดไดรฟ์ ซึ่งจะเพิ่มฟังก์ชันเพิ่มเติมให้กับเฟิร์มแวร์ UEFI มาตรฐานที่จัดเก็บไว้ใน ROMของ เมนบอร์ด

UEFI Capsule กำหนดอินเทอร์เฟซการอัปเดตเฟิร์มแวร์จากเฟิร์มแวร์ไปยังระบบปฏิบัติการ^{[ 60 ]} Windows 8 , Windows 8.1 , Windows 10 [ ^{61 ] และ} Fwupd สำหรับ Linux ต่างก็รองรับ UEFI Capsule

เช่นเดียวกับBIOS , UEFI จะเริ่มต้นและทดสอบส่วนประกอบฮาร์ดแวร์ของระบบ จากนั้นโหลดบูตโหลดเดอร์จากอุปกรณ์จัดเก็บข้อมูลขนาดใหญ่หรือผ่านการเชื่อมต่อเครือข่ายใน ระบบ x86เฟิร์มแวร์ UEFI มักจะถูกจัด เก็บไว้ในชิป NOR flashของเมนบอร์ด และกระบวนการบูตจะซับซ้อนกว่า เช่นการตรวจจับและการเริ่มต้นอุปกรณ์PCI Express ^{[ 62 ] [ 63 ]}ในอุปกรณ์ Android และ Windows Phone ที่ใช้ ARM บางรุ่น บูตโหลดเดอร์ UEFI จะถูกจัดเก็บไว้ในหน่วยความจำแฟลช eMMCหรือeUFS

เครื่อง UEFI สามารถมีคลาสใดคลาสหนึ่งต่อไปนี้ ซึ่งใช้เพื่อช่วยให้การเปลี่ยนไปใช้ UEFI ง่ายขึ้น: ^{[ 64 ]}

• คลาส 0: BIOS แบบดั้งเดิม
• คลาส 1: UEFI ที่มีอินเทอร์เฟซ CSM และไม่มีอินเทอร์เฟซ UEFI ภายนอก อินเทอร์เฟซ UEFI เพียงอย่างเดียวคืออินเทอร์เฟซภายในเฟิร์มแวร์
• คลาส 2: UEFI ที่มี CSM และอินเทอร์เฟซ UEFI ภายนอก เช่น UEFI Boot
• คลาส 3: UEFI ที่ไม่มีอินเทอร์เฟซ CSM และมีอินเทอร์เฟซ UEFI ภายนอก
• คลาส 3+: UEFI คลาส 3 ที่เปิดใช้งาน Secure Boot ^{[ 65 ]}

ตั้งแต่ซีพียู Intel Core เจนเนอเรชั่นที่ 10 เป็นต้นไป Intel จะไม่ให้ Legacy Video BIOSสำหรับ iGPU ( Intel Graphics Technology ) อีกต่อไป การบูตแบบ Legacy บนซีพียูเหล่านั้นจำเป็นต้องใช้ Legacy Video BIOS ซึ่งยังคงสามารถจัดหาได้จากตัวการ์ดจอ

นี่คือขั้นตอนแรกของการบูต UEFI แต่ขั้นตอนนี้อาจมีโค้ดไบนารีเฉพาะแพลตฟอร์มที่มาก่อนหน้านี้ (เช่นIntel ME , AMD PSP , ไมโครโค้ด CPU ) ขั้นตอนนี้ประกอบด้วยโค้ดขั้นต่ำที่เขียนด้วยภาษาแอสเซมบลีสำหรับสถาปัตยกรรมเฉพาะ มันจะเริ่มต้นหน่วยความจำชั่วคราว (มักจะเป็นแคชแบบ RAM ของ CPU (CAR) หรือโปรเซสเซอร์บูต บนชิป SoC ) และทำหน้าที่เป็นรากฐานความเชื่อถือของซอฟต์แวร์ของระบบ โดยมีตัวเลือกในการตรวจสอบ PEI ก่อนการส่งต่อ

• กำลังเริ่มต้นหน่วยความจำชั่วคราวสำหรับขั้นตอนถัดไป PEI
• รากฐานของความไว้วางใจ โดยการตรวจสอบความถูกต้องของ PEI
• ส่งต่อข้อมูลการส่งต่อให้กับมูลนิธิ PEI ข้อมูลดังกล่าวประกอบด้วยตำแหน่งและขนาดของหน่วยความจำชั่วคราว ตำแหน่งและขนาดของสแต็ก และสถานะของแพลตฟอร์ม

ขั้นตอนที่สองของการบูต UEFI ประกอบด้วยตัวจัดการที่คำนึงถึงการพึ่งพาซึ่งโหลดและเรียกใช้โมดูล PEI (PEIM) เพื่อจัดการงานเริ่มต้นฮาร์ดแวร์เบื้องต้น เช่น การเริ่มต้น หน่วยความจำหลัก (เริ่มต้นตัวควบคุมหน่วยความจำและDRAM ) และการดำเนินการกู้คืนเฟิร์มแวร์ นอกจากนี้ ยังมีหน้าที่ในการค้นหาโหมดบูตปัจจุบันและจัดการการดำเนินการ ACPI S3 จำนวนมาก ในกรณีของการกลับมาทำงานต่อด้วย ACPI S3 จะมีหน้าในการกู้คืนรีจิสเตอร์ฮาร์ดแวร์จำนวนมากให้กลับสู่สถานะก่อนการนอนหลับ PEI ยังใช้ CAR ด้วย การเริ่มต้นในขั้นตอนนี้เกี่ยวข้องกับการสร้างโครงสร้างข้อมูลในหน่วยความจำและการกำหนดค่าเริ่มต้นภายในโครงสร้างเหล่านี้^{[ 2 ]}

ขั้นตอนนี้ประกอบด้วยหลายส่วน ได้แก่ มูลนิธิ PEI, PEIMs และ PPI เนื่องจากมีทรัพยากรจำกัดในขั้นตอนนี้ ขั้นตอนนี้จึงต้องดำเนินการให้น้อยที่สุดและเตรียมการให้น้อยที่สุดสำหรับขั้นตอนต่อไปคือ DXE ซึ่งมีทรัพยากรมากกว่า

หลังจากขั้นตอนการส่งมอบงานของ SEC เสร็จสิ้นลง ความรับผิดชอบของแพลตฟอร์มจะตกเป็นของมูลนิธิ PEI ซึ่งมีหน้าที่ดังต่อไปนี้:

• การส่งโมดูล PEIM (pre-EFI initialization modules) สำเร็จแล้ว
• กำลังเริ่มต้นใช้งานหน่วยความจำถาวร (RAM)
• ส่งต่อไปยังขั้นตอนต่อไป DXE ครับ
• อำนวยความสะดวกในการสื่อสารของ PEIMs ที่เรียกว่า PPI

ส่วนประกอบนี้มีหน้าที่ในการเรียกใช้ PEIM และจัดการความสัมพันธ์ระหว่างส่วนประกอบเหล่านั้น

นี่คือไดรเวอร์ PEI ขั้นต่ำที่รับผิดชอบในการเริ่มต้นการทำงานของส่วนประกอบฮาร์ดแวร์ เช่น หน่วยความจำถาวร CPU ชิปเซ็ต และเมนบอร์ด ไดรเวอร์ PEI แต่ละตัวมีหน้าที่รับผิดชอบเพียงอย่างเดียวและมุ่งเน้นไปที่การเริ่มต้นการทำงานเพียงอย่างเดียว ไดรเวอร์เหล่านี้มาจากผู้ผลิตหลายราย

นี่คือโครงสร้างข้อมูลที่ประกอบด้วยคู่ GUID ของตัวชี้ PPIs ถูกค้นพบโดย PEIMs ผ่านบริการ PEI

หลังจากเริ่มต้นระบบ DXE ขั้นต่ำแล้ว มูลนิธิ PEI จะค้นหาและส่งการควบคุมไปยัง DXE มูลนิธิ PEI จะสั่งการให้มูลนิธิ DXE ทำงานผ่าน PPI พิเศษที่เรียกว่า IPL (Initial Program Load)

ขั้นตอนนี้ประกอบด้วยโมดูล C และตัวจัดการการพึ่งพา เมื่อหน่วยความจำหลักพร้อมใช้งานแล้ว CPU ชิปเซ็ต เมนบอร์ด และอุปกรณ์ I/O อื่นๆ จะได้รับการเริ่มต้นใน DXE และ BDS การเริ่มต้นในขั้นตอนนี้เกี่ยวข้องกับการกำหนดเส้นทางอุปกรณ์ EFI ให้กับฮาร์ดแวร์ที่เชื่อมต่อกับเมนบอร์ด และการถ่ายโอนข้อมูลการกำหนดค่าไปยังฮาร์ดแวร์^{[ 2 ]}

BDS เป็นส่วนหนึ่งของ DXE ^{[ 66 ] [ 67 ]}ในขั้นตอนนี้ อุปกรณ์บูตจะถูกเริ่มต้น ไดรเวอร์ UEFI หรือOption ROMของอุปกรณ์ PCI จะถูกเรียกใช้ตามตัวแปรที่กำหนดทางสถาปัตยกรรมที่เรียกว่าNVRAMและตัวโหลดบูต ระบบปฏิบัติการ (เช่นWindows Boot Manager ) จะเริ่มต้นขึ้น

นี่คือขั้นตอนระหว่างการเลือกอุปกรณ์บูตและการส่งต่อไปยังระบบปฏิบัติการ ในขั้นตอนนี้ ผู้ใช้สามารถเข้าสู่เชลล์ UEFI หรือเรียกใช้แอปพลิเคชัน UEFI เช่น ตัวโหลดบูตของระบบปฏิบัติการได้

UEFI จะส่งต่อการทำงานไปยังระบบปฏิบัติการ (OS) หลังจากที่ExitBootServices()ถูกเรียกใช้งาน ระบบปฏิบัติการที่เข้ากันได้กับ UEFI จะรับผิดชอบในการออกจากบริการบูต ซึ่งจะกระตุ้นให้เฟิร์มแวร์ยกเลิกการโหลดโค้ดและข้อมูลที่ไม่จำเป็นทั้งหมด เหลือไว้เพียงโค้ด/ข้อมูลบริการรันไทม์ เช่นSMMและACPI ^{[ 68 ]} ระบบปฏิบัติการสมัยใหม่ทั่วไปมักจะเลือกใช้ โปรแกรมของตนเอง (เช่นไดรเวอร์เคอร์เนล ) เพื่อควบคุมอุปกรณ์ฮาร์ดแวร์

เมื่อใช้ระบบปฏิบัติการรุ่นเก่า CSM จะจัดการการเรียกใช้งานนี้เพื่อให้แน่ใจว่าระบบเข้ากันได้กับข้อกำหนดของ BIOS รุ่นเก่า

การใช้งาน EFI ของ Intel คือIntel Platform Innovation Frameworkซึ่งมีชื่อรหัสว่าTiano Tiano ทำงานบน โปรเซสเซอร์ XScale , Itanium , IA-32และx86-64 ของ Intel และเป็นซอฟต์แวร์ที่เป็นกรรมสิทธิ์ แม้ว่าส่วนหนึ่งของโค้ดจะได้รับการเผยแพร่ภายใต้ใบอนุญาต BSDหรือEclipse Public License (EPL) ในชื่อTianoCore EDK II TianoCore สามารถใช้เป็นเพย์โหลดสำหรับcorebootได้^{[ 69 ]}

การใช้งาน UEFI ของPhoenix Technologies ได้รับการตั้งชื่อว่า SecureCore Technology (SCT) ^{[ 70 ]} American Megatrendsนำเสนอการใช้งานเฟิร์มแวร์ UEFI ของตนเองที่เรียกว่า Aptio ^{[ 71 ]}ในขณะที่Insyde Softwareนำเสนอ InsydeH2O ^{[ 72 ]}และ Byosoft นำเสนอ ByoCore

ในเดือนธันวาคม 2018 ไมโครซอฟต์ได้ปล่อยเวอร์ชันโอเพนซอร์สของการใช้งาน UEFI ที่ใช้ TianoCore EDK2 จากผลิตภัณฑ์Surface ซึ่งก็คือ Project Mu ^{[ 73 ]}

การใช้งาน API ของ UEFI ได้ถูกนำมาใช้ใน Universal Boot Loader ( Das U-Boot ) ในปี 2017 ^{[ 74 ]}บนสถาปัตยกรรมARMv8 การแจกจ่าย Linuxใช้การใช้งาน UEFI ของ U-Boot ร่วมกับGNU GRUBสำหรับการบูต (เช่นSUSE Linux ^{[ 75 ]} ) เช่นเดียวกับ OpenBSD ^{[ 76 ]}สำหรับการบูตจาก iSCSI สามารถใช้ iPXEเป็นแอปพลิเคชัน UEFI ที่โหลดโดย U-Boot ได้^{[ 77 ]}

เวิร์กสเตชันและเซิร์ฟเวอร์ Itaniumรุ่นแรกของIntelซึ่งวางจำหน่ายในปี 2000 ได้นำ EFI 1.02 มาใช้

ระบบ Itanium 2รุ่นแรกของHewlett-Packardที่วางจำหน่ายในปี 2002 ใช้ EFI 1.10 ระบบเหล่านี้สามารถบูตระบบปฏิบัติการWindows , Linux , FreeBSDและHP-UX ได้ ส่วนOpenVMSเพิ่มความสามารถ UEFI ในเดือนมิถุนายน 2003

ในเดือนมกราคม พ.ศ. 2549 Apple Inc. ได้จัดส่ง คอมพิวเตอร์ Macintosh ที่ใช้ Intel เครื่องแรกระบบเหล่านี้ใช้ EFI แทนOpen Firmwareซึ่งเคยใช้ในระบบ PowerPC รุ่นก่อนหน้า^{[ 78 ]}ในวันที่ 5 เมษายน พ.ศ. 2549 Apple ได้เปิดตัวBoot Camp เป็นครั้งแรก ซึ่งสร้างดิสก์ไดรเวอร์ Windows และเครื่องมือแบ่งพาร์ติชั่นแบบไม่ทำลายข้อมูล เพื่อให้สามารถติดตั้ง Windows XP หรือ Vista ได้โดยไม่ต้องติดตั้ง Mac OS X (ปัจจุบันคือ macOS) ใหม่ นอกจากนี้ยังมีการอัปเดตเฟิร์มแวร์ที่เพิ่มความเข้ากันได้กับ BIOS ในการใช้งาน EFI รุ่น Macintosh รุ่นต่อมาจึงจัดส่งพร้อมเฟิร์มแวร์เวอร์ชันใหม่กว่า^{[ 79 ]}

ในปี 2548 ระบบ Intel มากกว่าหนึ่งล้านเครื่องถูกจัดส่งโดยใช้การใช้งาน UEFI ของ Intel ^{[ 80 ]}ผลิตภัณฑ์มือถือ เดสก์ท็อป และเซิร์ฟเวอร์ใหม่ที่ใช้การใช้งาน UEFI ของ Intel เริ่มจัดส่งในปี 2549 ตัวอย่างเช่น เมนบอร์ดที่ใช้ชิปเซ็ต Intel 945 ซีรีส์ใช้เฟิร์มแวร์ UEFI ของ Intel

ตั้งแต่ปี พ.ศ. 2548 EFI ยังถูกนำไปใช้กับสถาปัตยกรรมที่ไม่ใช่พีซี เช่นระบบฝังตัวที่ใช้คอร์XScale ^{[ 80 ]}

EDK (EFI Developer Kit) ประกอบด้วยเป้าหมาย NT32 ซึ่งช่วยให้เฟิร์มแวร์ EFI และแอปพลิเคชัน EFI สามารถทำงานภายใน แอปพลิเคชัน Windowsได้ อย่างไรก็ตาม EDK NT32 ไม่อนุญาตให้เข้าถึงฮาร์ดแวร์โดยตรง ซึ่งหมายความว่ามีเพียงแอปพลิเคชันและไดรเวอร์ EFI บางส่วนเท่านั้นที่สามารถทำงานได้ผ่านเป้าหมาย EDK NT32

ในปี 2008 ระบบ x86-64 จำนวนมากขึ้นได้นำ UEFI มาใช้ ในขณะที่ระบบเหล่านี้จำนวนมากยังคงอนุญาตให้บูตเฉพาะระบบปฏิบัติการที่ใช้ BIOS ผ่านโมดูลสนับสนุนความเข้ากันได้ (CSM) (ซึ่งทำให้ผู้ใช้ไม่เห็นว่าเป็นระบบที่ใช้ UEFI) แต่ระบบอื่นๆ ก็เริ่มอนุญาตให้บูตระบบปฏิบัติการที่ใช้ UEFI ได้แล้ว ตัวอย่างเช่น เซิร์ฟเวอร์ IBM x3450 เมนบอร์ด MSIที่ใช้ ClickBIOS และโน้ตบุ๊ก HP EliteBook

ในปี 2552 IBM ได้จัดส่ง เครื่อง System x (x3550 M2, x3650 M2, iDataPlex dx360 M2) และBladeCenter HS22 ที่มีคุณสมบัติ UEFI Dell ได้จัดส่งเซิร์ฟเวอร์ PowerEdge T610, R610, R710, M610 และ M710 ที่มีคุณสมบัติ UEFI ระบบที่วางจำหน่ายในเชิงพาณิชย์เพิ่มเติมได้ถูกกล่าวถึงในเอกสารไวท์เปเปอร์ UEFI ^{[ 81 ]}

ในปี 2554 ผู้จำหน่ายรายใหญ่ (เช่นASRock , Asus , GigabyteและMSI ) ได้เปิดตัวเมนบอร์ดสำหรับผู้บริโภคหลายรุ่นที่ใช้ชิปเซ็ต Intel 6-series LGA 1155และชิปเซ็ต AMD 9 Series AM3+พร้อม UEFI ^{[ 82 ]}

เมื่อ Windows 8 วางจำหน่ายในเดือนตุลาคม 2012 ข้อกำหนดการรับรองของ Microsoft กำหนดให้คอมพิวเตอร์ต้องมีเฟิร์มแวร์ที่ใช้ข้อกำหนด UEFI นอกจากนี้ หากคอมพิวเตอร์รองรับคุณสมบัติ " Connected Standby " ของ Windows 8 (ซึ่งช่วยให้อุปกรณ์มีการจัดการพลังงานที่เทียบได้กับสมาร์ทโฟนโดยสามารถกลับจากโหมดสแตนด์บายได้เกือบจะในทันที) เฟิร์มแวร์จะไม่ได้รับอนุญาตให้มี Compatibility Support Module (CSM) ดังนั้น ระบบที่รองรับ Connected Standby จึงไม่สามารถบูตระบบปฏิบัติการ Legacy BIOS ได้^{[ 83 ] [ 84 ]}

ในเดือนตุลาคม พ.ศ. 2560 Intel ประกาศว่าจะยกเลิกการรองรับ BIOS ของพีซีแบบเดิมในผลิตภัณฑ์ทั้งหมดภายในปี พ.ศ. 2563 โดยหันมาใช้ UEFI Class 3 แทน^{[ 85 ]}ภายในปี พ.ศ. 2562 คอมพิวเตอร์ทั้งหมดที่ใช้แพลตฟอร์ม Intel จะไม่มีการรองรับ BIOS ของพีซีแบบเดิมอีกต่อไป

ระบบปฏิบัติการที่สามารถบูตจาก (U)EFI เรียกว่าระบบปฏิบัติการที่รองรับ (U)EFI ซึ่งกำหนดโดยข้อกำหนด (U)EFI ในที่นี้ คำว่าบูตจาก (U)EFIหมายถึงการบูตระบบโดยตรงโดยใช้ตัวโหลดระบบปฏิบัติการ (U)EFI ที่จัดเก็บไว้ในอุปกรณ์จัดเก็บข้อมูลใดๆ ตำแหน่งเริ่มต้นสำหรับตัวโหลดระบบปฏิบัติการคือ<EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFIโดยที่ชื่อย่อของประเภทเครื่องอาจเป็นIA32, X64, IA64, ARMหรือ^{[ 13 ] : ส่วนที่ 3.5.1.1} ผู้จำหน่ายระบบปฏิบัติการบางรายอาจมีตัวโหลดบูตของตนเอง พวกเขายังอาจเปลี่ยนตำแหน่งบูตเริ่มต้น AA64ได้

• เคอร์เนลLinuxสามารถใช้ EFI ในระหว่างการบูตได้ตั้งแต่ช่วงต้นปี 2000 ^{[ 86 ]}โดยใช้ ตัวโหลดบูต EFI eliloและเมื่อไม่นานมานี้ เวอร์ชัน EFI ของGRUB ^{[ 87 ]}หรือsystemd-boot Grub+Linux ยังรองรับการบูตจากตารางพาร์ติชัน GUID โดยไม่ต้องใช้ UEFI ^{[ 25 ]}ระบบปฏิบัติการUbuntuได้เพิ่มการสนับสนุน UEFI Secure Boot ตั้งแต่เวอร์ชัน 12.10 ^{[ 88 ]}เคอร์เนล Linux สามารถคอมไพล์ได้โดยมีตัวเลือกให้ทำงานเป็นตัวโหลดบูต EFI ด้วยตัวเองผ่านคุณสมบัติ EFI boot stub ในเคอร์เนล Linux สามารถใช้โปรโตคอล ACPI (โดยปกติใช้ในเครื่องที่เข้ากันได้กับพีซี) หรือ โปรโตคอล DeviceTree (โดยปกติใช้ในสมาร์ทโฟนและแท็บเล็ต) ร่วมกับ UEFI ได้^{[ 89 ]}
• ระบบ ปฏิบัติการ HP-UXใช้ (U)EFI เป็นกลไกการบูตบน ระบบ IA-64มาตั้งแต่ปี 2002
• OpenVMSใช้ EFI บน IA-64 ตั้งแต่การเผยแพร่เวอร์ชันทดลองครั้งแรกในเดือนธันวาคม พ.ศ. 2546 และสำหรับการเผยแพร่เวอร์ชันใช้งานจริงตั้งแต่เดือนมกราคม พ.ศ. 2548 ^{[ 90 ]} OpenVMS บน x86-64 ยังใช้ UEFI เพื่อบูตระบบปฏิบัติการอีกด้วย^{[ 91 ]}
• Appleใช้ EFI สำหรับ Mac ที่ ใช้Intel Mac OS X v10.4 Tiger และMac OS X v10.5 Leopard ใช้ EFI v1.10 ในโหมด 32 บิต แม้แต่บน CPU 64 บิต แต่การสนับสนุนอย่างเต็มรูปแบบมาพร้อมกับ^OS X v10.8 Mountain Lion [ ^{92 ]}
• Windows 2000เวอร์ชันItanium (Advanced Server Limited Edition และ Datacenter Server Limited Edition; อิงตามโค้ดเบส Windows Server 2003 รุ่นก่อนวางจำหน่าย) ได้นำ EFI 1.10 มาใช้ในปี 2002 Windows XP 64-bit Edition , Windows 2000 Advanced Server Limited Edition (Windows Server 2003 รุ่นก่อนวางจำหน่าย) และWindows Server 2003สำหรับIA-64ซึ่งทั้งหมดนี้ใช้สำหรับโปรเซสเซอร์ตระกูล Intel Itaniumได้นำ EFI มาใช้ ซึ่งเป็นข้อกำหนดของแพลตฟอร์มผ่านข้อกำหนดDIG64 ^{[ 93 ]}
• ไมโครซอฟต์ได้แนะนำ UEFI สำหรับระบบปฏิบัติการ Windows x64 ในWindows Vista SP1 ^{[ 94 ]}และWindows Server 2008 อย่างไรก็ตาม รองรับเฉพาะ UGA (Universal Graphic Adapter) 1.1 หรือ Legacy BIOS INT 10h เท่านั้น ไม่รองรับ Graphics Output Protocol (GOP) ดังนั้น พีซีที่ใช้ Windows Vista SP1 , Windows Vista SP2 , Windows 7 , Windows Server 2008และWindows Server 2008 R2 เวอร์ชัน 64 บิต จึง เข้ากันได้กับ UEFI Class 2 ^{[ 95 ] [ 96 ]}เดิมที UEFI 32 บิตไม่ได้รับการสนับสนุน เนื่องจากผู้ผลิตไม่มีความสนใจในการผลิตเฟิร์มแวร์ UEFI 32 บิตแบบเนทีฟ เนื่องจากสถานะหลักของการประมวลผล 64 บิต^{[ 97} ] ในที่สุด Windows 8ก็ได้แนะนำการปรับปรุงเพิ่มเติมสำหรับระบบ UEFI รวมถึงการสนับสนุน Graphics Output Protocol (GOP) ^{[ 98 ] การเริ่มต้นระบบที่เร็วขึ้น การ สนับสนุน} UEFI 32 บิต และการสนับสนุน Secure Boot ^{[ 99 ] [ 100 ]}ตั้งแต่Windows 8เป็นต้นมา เฟิร์มแวร์ UEFI ที่ใช้ โปรโตคอล ACPIเป็นข้อกำหนดบังคับสำหรับระบบปฏิบัติการ Microsoft Windows ที่ใช้ ARM Microsoft เริ่มกำหนดให้ต้องใช้ UEFI ในการรัน Windows ตั้งแต่Windows 11 ^{[ 101 ]}โดย Windows 11 รุ่น IoT Enterprise ตั้งแต่เวอร์ชัน 24H2 เป็นต้นไปได้รับการยกเว้นจากข้อกำหนดนี้^{[ 102 ]}
• เมื่อวันที่ 5 มีนาคม 2013 มูลนิธิ FreeBSDได้มอบทุนให้กับนักพัฒนาที่ต้องการเพิ่มการสนับสนุน UEFI ให้กับเคอร์เนลและบูตโหลดเดอร์ของ FreeBSD ^{[ 103 ]}การเปลี่ยนแปลงดังกล่าวถูกจัดเก็บไว้ในสาขาแยกต่างหากของซอร์สโค้ด FreeBSD ในตอนแรก แต่ได้ถูกรวมเข้ากับซอร์สโค้ดหลักเมื่อวันที่ 4 เมษายน 2014 (การแก้ไข 264095) การเปลี่ยนแปลงนี้รวมถึงการสนับสนุนในตัวติดตั้งด้วย^{[ 104 ]}การสนับสนุนการบูต UEFI สำหรับ amd64 ปรากฏครั้งแรกใน FreeBSD 10.1 และสำหรับ arm64 ใน FreeBSD 11.0 ^{[ 105 ]}
• NetBSDรองรับ UEFI ตั้งแต่เวอร์ชัน 8.0 ^{[ 106 ]}สำหรับสถาปัตยกรรม i386 และ amd64 รวมถึงบนแพลตฟอร์ม ARM ต่างๆ ตั้งแต่เวอร์ชัน 9.0 ^{[ 107 ]}
• Oracle Solaris 11.1 และเวอร์ชันที่ใหม่กว่ารองรับการบูต UEFI สำหรับระบบ x86 ที่มีเฟิร์มแวร์ UEFI เวอร์ชัน 2.1 หรือใหม่กว่า โดย ใช้ GRUB 2 เป็นตัวโหลดบูตบน x86 ^{[ 108 ]}
• OpenBSD 5.9 ^{[ 109 ]}ได้แนะนำการรองรับการบูต UEFI สำหรับระบบ x86 64 บิตโดยใช้ตัวโหลดแบบกำหนดเอง OpenBSD 6.0 ได้ขยายการรองรับดังกล่าวให้ครอบคลุมถึง ARMv7 ด้วย^{[ 110 ]}
• illumosเพิ่มการรองรับ UEFI ขั้นพื้นฐานในเดือนตุลาคม 2560 ^{[ 111 ]}
• ArcaOSรองรับการบูต UEFI ตั้งแต่เวอร์ชัน 5.1 ^{[ 112 ]}การสนับสนุน UEFI ของ ArcaOS จำลอง ฟังก์ชัน BIOS เฉพาะ ที่ระบบปฏิบัติการต้องพึ่งพา (โดยเฉพาะการขัดจังหวะINT 10HและINT 13H ) ^{[ 113 ] [ 114 ]}

• HP Integrity Virtual Machinesให้การบูตแบบ UEFI บนเซิร์ฟเวอร์ HP Integrity นอกจากนี้ยังให้สภาพแวดล้อม UEFI เสมือนจริงสำหรับระบบปฏิบัติการแขกที่รองรับ UEFI อีกด้วย
• Intel เป็นเจ้าของโครงการเฟิร์มแวร์เครื่องเสมือนแบบเปิดบน SourceForge ^{[ 115 ]}
• ซอฟต์แวร์ VMware Fusion 3 สำหรับ Mac OS X สามารถบูตเครื่องเสมือน Mac OS X Server โดยใช้ UEFI ได้
• VMware Workstationเวอร์ชันก่อน 11 รองรับ UEFI อย่างไม่เป็นทางการ แต่ต้องเปิดใช้งานด้วยตนเองโดยการแก้ไขไฟล์ .vmx ^{[ 116 ]} VMware Workstationเวอร์ชัน 11 ขึ้นไปรองรับ UEFI โดยไม่ขึ้นอยู่กับว่าระบบโฮสต์ทางกายภาพใช้ UEFI หรือไม่ VMware Workstation 14 (และ Fusion 10) เพิ่มการสนับสนุน คุณสมบัติ Secure Bootของ UEFI ^{[ 117 ] [ 118 ]}
• ไฮเปอร์ไวเซอร์ VMware ESXi 5.0 รองรับ UEFI อย่างเป็นทางการ เวอร์ชัน 6.5 เพิ่มการรองรับ Secure Boot ^{[ 119 ] [ 120 ]}
• VirtualBoxได้นำ UEFI มาใช้ตั้งแต่เวอร์ชัน 3.1 ^{[ 121 ]}แต่จำกัดเฉพาะระบบปฏิบัติการ Unix/Linux และ Windows 8 ขึ้นไป (ใช้งานไม่ได้กับ Windows Vista x64 และ Windows 7 x64) ^{[ 122 ] [ 123 ]}
• QEMU / KVMสามารถใช้งานร่วมกับ Open Virtual Machine Firmware (OVMF) ที่ TianoCore จัดหาให้ได้^{[ 124 ]}
• เครื่องเสมือน Microsoft Hyper-Vรุ่นที่สองรองรับ UEFI แบบเสมือน^{[ 125 ]}
• VM ที่ได้รับการปกป้องจาก Google Cloud Platformรองรับ UEFI เสมือนเพื่อเปิดใช้งาน Secure Boot ^{[ 126 ]}

ข้อบกพร่องในการใช้งาน UEFI ได้ถูกใช้ประโยชน์เพื่อบรรลุการคงอยู่ ความสามารถในการรักษาการเข้าถึงที่เป็นอันตรายในระบบที่ถูกบุกรุกแม้หลังจากการรีบูตระบบ การติดตั้งระบบปฏิบัติการใหม่ และแม้กระทั่งการเปลี่ยนชิ้นส่วนทางกายภาพบางส่วน เช่น หน่วยเก็บข้อมูลแฟลชถาวร PCI ที่เสียหาย มีช่องโหว่ในปี 2023 แม้ว่าจะเปิดใช้งาน Secure Boot แล้วก็ตาม^{[ 127 ]}ในปี 2023 ไมโครซอฟต์ได้เผยแพร่คำเตือนเกี่ยวกับ มัลแวร์ BlackLotus UEFI ^{[ 128 ]}

ชุดพัฒนาแอปพลิเคชัน EDK2 (EADK) ทำให้สามารถใช้ ฟังก์ชัน ไลบรารี C มาตรฐานในแอปพลิเคชัน UEFI ได้ EADK สามารถดาวน์โหลดได้ฟรีจาก โครงการ Intel TianoCore UDK / EDK2 SourceForgeตัวอย่างเช่น พอร์ตของ ตัวแปลภาษา Pythonสามารถใช้งานได้ในรูปแบบแอปพลิเคชัน UEFI โดยใช้ EADK ^{[ 129 ]}การพัฒนาได้ย้ายไปที่ GitHub ตั้งแต่ .UDK2015 ^{[ 130 ]}

นักเคลื่อนไหวเพื่อสิทธิดิจิทัลจำนวนมากได้ประท้วง UEFI โรนัลด์ จี. มินนิชผู้ร่วมเขียนcorebootและคอรี ด็อกเตอร์โรว์นักเคลื่อนไหวเพื่อสิทธิดิจิทัล ได้วิพากษ์วิจารณ์ UEFI ว่าเป็นความพยายามที่จะลบความสามารถของผู้ใช้ในการควบคุมคอมพิวเตอร์อย่างแท้จริง^{[ 131 ] [ 132 ]}นักวิจารณ์ เช่น โรนัลด์ จี. มินนิช ผู้ร่วมเขียน coreboot โต้แย้งว่า UEFI ยังคงรักษารูปแบบเดิมที่ต้องใช้ไดรเวอร์แยกกันสองตัว คือตัวหนึ่งสำหรับเฟิร์มแวร์และอีกตัวหนึ่งสำหรับระบบปฏิบัติการ สำหรับฮาร์ดแวร์ส่วนใหญ่^{[ 133 ]}

โครงการโอเพนซอร์ส TianoCore ยังมี UEFI ด้วย^{[ 134 ]} TianoCore ขาดไดรเวอร์เฟิร์มแวร์และโมดูลเฉพาะที่ใช้ในการเริ่มต้นฟังก์ชันชิปเซ็ต แต่ TianoCore เป็นหนึ่งในตัวเลือกเพย์โหลดมากมายของcorebootการพัฒนา coreboot จำเป็นต้องได้รับความร่วมมือจากผู้ผลิตชิปเซ็ตเพื่อให้ข้อมูลจำเพาะที่จำเป็นในการพัฒนาไดรเวอร์เริ่มต้น

ในปี 2554 ไมโครซอฟต์ประกาศว่าคอมพิวเตอร์ที่ได้รับการรับรองให้ใช้งาน ระบบปฏิบัติการ Windows 8จะต้องจัดส่งพร้อมกับคีย์สาธารณะของไมโครซอฟต์ที่ลงทะเบียนไว้และเปิดใช้งาน Secure Boot ซึ่งหมายความว่าการใช้ UEFI เป็นข้อกำหนดสำหรับอุปกรณ์เหล่านี้^{[ 135 ] [ 136 ]}หลังจากการประกาศดังกล่าว นักวิจารณ์และผู้สนับสนุนซอฟต์แวร์เสรี/โอเพนซอร์ส รวมถึงมูลนิธิซอฟต์แวร์เสรี ได้แสดงความกังวลว่าไมโครซอฟต์อาจใช้ฟังก์ชัน Secure Boot ของ UEFI เพื่อจำกัดการติดตั้งระบบปฏิบัติการทางเลือก เช่น Linux ไมโครซอฟต์ปฏิเสธว่าข้อกำหนด Secure Boot มีเจตนาที่จะเป็นรูปแบบของการผูกขาดและชี้แจงข้อกำหนดโดยระบุว่าระบบที่ใช้สถาปัตยกรรม x86 ที่ได้รับการรับรองสำหรับ Windows 8 จะต้องอนุญาตให้ Secure Boot เข้าสู่โหมดกำหนดเองหรือปิดใช้งานได้ แต่ไม่ใช่ในระบบที่ใช้สถาปัตยกรรม ARM [ ^{45 ] [ 137 ] Windows} 10อนุญาตให้OEMตัดสินใจได้ว่าผู้ใช้ระบบ x86 ของตนสามารถจัดการ Secure Boot ได้หรือไม่^{[ 138 ]}

นักพัฒนาซอฟต์แวร์รายอื่น ๆ แสดงความกังวลเกี่ยวกับปัญหาทางกฎหมายและปัญหาในทางปฏิบัติของการนำการสนับสนุน Secure Boot มาใช้ในระบบ Linux โดยทั่วไปMatthew Garrett อดีต นักพัฒนา ซอฟต์แวร์ ของ Red Hatตั้งข้อสังเกตว่าเงื่อนไขในGNU General Public License เวอร์ชัน 3อาจป้องกันการใช้GNU Grand Unified Bootloaderหากนักพัฒนาซอฟต์แวร์ของดิสทริบิวชันไม่เปิดเผยคีย์ส่วนตัว (อย่างไรก็ตามมูลนิธิซอฟต์แวร์เสรีได้ชี้แจงจุดยืนของตนในภายหลัง โดยรับรองว่าความรับผิดชอบในการจัดหาคีย์นั้นเป็นของผู้ผลิตฮาร์ดแวร์) ^{[ 139 ] [ 88 ]}และยังเป็นเรื่องยากสำหรับผู้ใช้ขั้นสูงในการสร้างเคอร์เนล แบบกำหนดเอง ที่สามารถทำงานร่วมกับ Secure Boot ที่เปิดใช้งานได้โดยไม่ต้องลงนามด้วยตนเอง^{[ 137 ]}นักพัฒนาซอฟต์แวร์รายอื่น ๆ แนะนำว่าสามารถจัดหา Linux เวอร์ชันที่ลงนามด้วยคีย์อื่นได้ แต่ตั้งข้อสังเกตว่าจะเป็นเรื่องยากที่จะโน้มน้าวให้ OEM จัดส่งคอมพิวเตอร์ของตนพร้อมกับคีย์ที่จำเป็นควบคู่ไปกับคีย์ของ Microsoft ^{[ 4 ]}

ระบบปฏิบัติการ Linux หลักหลายระบบได้พัฒนาการใช้งาน Secure Boot ที่แตกต่างกัน Garrett เองได้พัฒนาบูตโหลดเดอร์ขั้นต่ำที่เรียกว่า shim ซึ่งเป็นบูตโหลดเดอร์ที่คอมไพล์และลงนามไว้ล่วงหน้า ซึ่งช่วยให้ผู้ใช้สามารถเชื่อถือคีย์ที่ระบบปฏิบัติการ Linux จัดหาให้ได้^{[ 140 ]} Ubuntu 12.10ใช้ shim เวอร์ชันเก่าที่กำหนดค่าไว้ล่วงหน้าสำหรับการใช้งานร่วมกับ คีย์ของ Canonicalเอง ซึ่งตรวจสอบเฉพาะบูตโหลดเดอร์และอนุญาตให้โหลดเคอร์เนลที่ไม่ได้ลงนาม นักพัฒนาเชื่อว่าการลงนามเฉพาะบูตโหลดเดอร์นั้นทำได้ง่ายกว่า เนื่องจากเคอร์เนลที่เชื่อถือได้มีประสิทธิภาพในการรักษาความปลอดภัยเฉพาะพื้นที่ผู้ใช้ เท่านั้น ไม่ใช่สถานะก่อนบูตซึ่ง Secure Boot ออกแบบมาเพื่อเพิ่มการป้องกัน นอกจากนี้ยังช่วยให้ผู้ใช้สามารถสร้างเคอร์เนลของตนเองและใช้โมดูลเคอร์เนล แบบกำหนดเอง ได้โดยไม่จำเป็นต้องกำหนดค่าระบบใหม่^{[ 88 ] [ 141 ] [ 142 ]} Canonical ยังคงรักษาคีย์ส่วนตัวของตนเองเพื่อลงนามการติดตั้ง Ubuntu ที่โหลดไว้ล่วงหน้าบนคอมพิวเตอร์ OEM ที่ได้รับการรับรองซึ่งใช้งานระบบปฏิบัติการ และยังวางแผนที่จะบังคับใช้ข้อกำหนด Secure Boot เช่นกัน โดยกำหนดให้ต้องมีทั้งคีย์ Canonical และคีย์ Microsoft (เพื่อเหตุผลด้านความเข้ากันได้) รวมอยู่ในเฟิร์มแวร์Fedoraก็ใช้ shim เช่นกัน แต่กำหนดให้ต้องลงนามทั้งเคอร์เนลและโมดูลด้วย^{[ 141 ]} shim มี Machine Owner Key (MOK) ที่สามารถใช้ลงนามเคอร์เนลที่คอมไพล์ในเครื่องและซอฟต์แวร์อื่นๆ ที่ไม่ได้ลงนามโดยผู้ดูแลการแจกจ่าย โดยไม่ต้องเปลี่ยนโหมด Secure Boot เป็นโหมดการตั้งค่า^{[ 143 ] [ 144 ]}

มีการถกเถียงกันว่าเคอร์เนลของระบบปฏิบัติการและโมดูลต่างๆ จะต้องได้รับการลงนามด้วยหรือไม่ แม้ว่าข้อกำหนดของ UEFI จะไม่กำหนดไว้ แต่ Microsoft ยืนยันว่าข้อกำหนดตามสัญญาของพวกเขากำหนดไว้ และสงวนสิทธิ์ที่จะเพิกถอนใบรับรองใดๆ ที่ใช้ในการลงนามโค้ดที่อาจนำไปใช้เพื่อบุกรุกความปลอดภัยของระบบ^{[ 142 ]}ใน Windows หากเปิดใช้งาน Secure Boot ไดรเวอร์เคอร์เนลทั้งหมดจะต้องได้รับการลงนามแบบดิจิทัล ไดรเวอร์ที่ไม่ใช่ WHQL อาจถูกปฏิเสธไม่ให้โหลด ในเดือนกุมภาพันธ์ 2013 นักพัฒนา Red Hat อีกคนหนึ่งพยายามส่งแพตช์ไปยังเคอร์เนล Linux ที่จะช่วยให้สามารถวิเคราะห์การลงนาม authenticode ของ Microsoft โดยใช้คีย์X.509หลักที่ฝังอยู่ใน ไฟล์ PEที่ลงนามโดย Microsoft อย่างไรก็ตาม ข้อเสนอดังกล่าวถูกวิพากษ์วิจารณ์โดย Linus Torvalds ผู้สร้าง Linux ซึ่งโต้แย้งว่า Red Hat กำลังยอมให้ Microsoft ควบคุมโครงสร้างพื้นฐานของ Secure Boot ^{[ 145 ]}

เมื่อวันที่ 26 มีนาคม 2556 กลุ่มพัฒนาซอฟต์แวร์เสรี Hispalinux ของสเปนได้ยื่นคำร้องอย่างเป็นทางการต่อคณะกรรมาธิการยุโรปโดยอ้างว่าข้อกำหนด Secure Boot ของ Microsoft บนระบบ OEM นั้น "ขัดขวาง" และเป็นการต่อต้านการแข่งขัน^{[ 146 ]}

ในการประชุม Black Hatในเดือนสิงหาคม 2556 กลุ่มนักวิจัยด้านความปลอดภัยได้นำเสนอช่องโหว่หลายชุดในการใช้งาน UEFI ของผู้จำหน่ายเฉพาะราย ซึ่งสามารถใช้เพื่อเจาะระบบ Secure Boot ได้^{[ 147 ]}

ในเดือนสิงหาคม พ.ศ. 2559 มีรายงานว่านักวิจัยด้านความปลอดภัยสองคนได้ค้นพบ "กุญแจทองคำ" ซึ่งเป็นกุญแจความปลอดภัยที่ Microsoft ใช้ในการลงนามระบบปฏิบัติการ^{[ 148 ]}ในทางเทคนิคแล้ว ไม่มีกุญแจใดถูกเปิดเผย แต่มีไบนารีที่สามารถใช้ประโยชน์ได้ซึ่งลงนามโดยกุญแจนั้น ซึ่งทำให้ซอฟต์แวร์สามารถทำงานได้ราวกับว่าได้รับการลงนามโดย Microsoft ก่อให้เกิดความเสี่ยงต่อ การโจมตี รูทคิตและบูทคิตนอกจากนี้ยังทำให้ความพยายามในการแก้ไขซับซ้อนขึ้น เนื่องจากแพทช์อาจถูกลดระดับลงโดยการแทนที่ด้วยไบนารีที่สามารถใช้ประโยชน์ได้ซึ่งลงนามแล้ว Microsoft ระบุว่าช่องโหว่นี้ส่งผลกระทบเฉพาะสถาปัตยกรรม ARMและ อุปกรณ์ Windows RT เท่านั้น และได้ออกการอัปเดตสองครั้ง อย่างไรก็ตาม รายงานระบุว่าการอัปเดตเหล่านี้ไม่ได้ป้องกันการใช้ประโยชน์อย่างสมบูรณ์ เนื่องจากการแก้ไขช่องโหว่อย่างสมบูรณ์จะต้องมีการแทนที่กุญแจในเฟิร์มแวร์ของผู้ใช้ปลายทาง

เมื่อวันที่ 1 มีนาคม 2023 นักวิจัยจาก ESET รายงานการค้นพบ "BlackLotus" ซึ่งอธิบายว่าเป็น UEFI bootkit ตัวแรกที่สามารถข้าม UEFI Secure Boot ได้โดยใช้ประโยชน์จากข้อจำกัดของการอัปเดตความปลอดภัยก่อนหน้านี้^{[ 149 ] [ 150 ]}

ในเดือนสิงหาคม พ.ศ. 2567 การอัปเดตความปลอดภัย ของ Windows 11และWindows 10ได้นำการตั้งค่า Secure Boot Advanced Targeting (SBAT) ไปใช้กับ UEFI NVRAM ของอุปกรณ์ ซึ่งทำให้ระบบปฏิบัติการ Linux บางรุ่นไม่สามารถโหลดได้ SBAT เป็นโปรโตคอลที่รองรับในWindows Boot Managerและ shim เวอร์ชันใหม่ ซึ่งปฏิเสธการโหลดบูตโหลดเดอร์ระดับกลางที่มีข้อบกพร่องหรือช่องโหว่ (โดยปกติจะเป็น Windows Boot Manager และGRUB เวอร์ชันเก่า ) ในกระบวนการบูต การเปลี่ยนแปลงนี้ถูกยกเลิกในเดือนถัดมา^{[ 151 ]}

ในเดือนมิถุนายน พ.ศ. 2568 LWN.netรายงานว่าใบรับรอง Microsoft UEFI CA 2011 จะหมดอายุในวันที่ 27 มิถุนายน พ.ศ. 2569 ซึ่งอาจทำให้ Linux บางระบบไม่สามารถโหลดได้หากเปิดใช้งาน Secure Boot ^{[ 152 ] [ 153 ]}อย่างไรก็ตาม ในTianoCore EDK IIรวมถึงการใช้งาน UEFI เชิงพาณิชย์หลายๆ ตัว (เช่น AMI Aptio) การตรวจสอบเวลา/วันที่สำหรับใบรับรอง Secure Boot มักจะถูกปิดใช้งานโดยค่าเริ่มต้น^{[ 153 ]}

ระบบปฏิบัติการ Linuxหลาย ระบบ รองรับ UEFI Secure Boot ตั้งแต่เดือนมกราคม 2025 เช่นRHEL (RHEL 7 และรุ่นที่ใหม่กว่า), CentOS (CentOS 7 และรุ่นที่ใหม่กว่า^{[ 154 ]} ), Ubuntu , Fedora , Debian (Debian 10 และรุ่นที่ใหม่กว่า^{[ 155 ]} ), OpenSUSEและSUSE Linux Enterprise ^{[ 156 ]}

มีการรายงานปัญหาทางเทคนิคหลายประการเกี่ยวกับการใช้งานเฟิร์มแวร์ UEFI เฉพาะในอุปกรณ์เชิงพาณิชย์^{[ 157 ]}

หลังจากการเปิดตัว Windows 8 ในเดือนตุลาคม พ.ศ. 2555 พบว่าคอมพิวเตอร์Lenovo บางรุ่นที่มี Secure Boot มี UEFI ที่ตรวจสอบการมีอยู่ของ " Windows Boot Manager " หรือ " Red Hat Enterprise Linux " ในสตริงคำอธิบายของระบบปฏิบัติการที่รองรับ UEFI มิฉะนั้นจะปฏิเสธการโหลด^{[ 158 ]} มีรายงานปัญหาการทำงานที่คล้ายกันเกี่ยวกับแล็ปท็อป Toshibaหลายรุ่นที่ขาดใบรับรองเฟิร์มแวร์เฉพาะที่จำเป็นสำหรับการทำงานของ Secure Boot ^{[ 157 ]}

ในเดือนมกราคม 2013 มีการเผยแพร่ปัญหาเฟิร์มแวร์เกี่ยวกับการใช้งาน UEFI ใน แล็ปท็อป Samsung บาง รุ่น ซึ่งทำให้เครื่องใช้งานไม่ได้เลยหลังจากติดตั้งระบบปฏิบัติการ Linux ในโหมด UEFI รายงานเบื้องต้นระบุว่าปัญหาเกิดจากความขัดแย้งกับโมดูลเคอร์เนลที่ออกแบบมาเพื่อเข้าถึงคุณสมบัติของระบบในแล็ปท็อป Samsung (ทำให้ผู้ดูแลเคอร์เนลต้องปิดใช้งานโมดูลดังกล่าวในระบบ UEFI เพื่อความปลอดภัย) แต่การวิเคราะห์โดย Matthew Garrett ชี้ให้เห็นว่าสภาวะดังกล่าวเกิดจากการจัดเก็บตัวแปร UEFI มากเกินไปในหน่วยความจำแบบไม่ลบเลือน ซึ่งเป็นพฤติกรรมที่อาจเกิดขึ้นได้ภายใต้เงื่อนไขเฉพาะบางอย่างใน Windows การวิเคราะห์ของเขาสรุปว่าโมดูลเคอร์เนลที่เกี่ยวข้องทำให้มีการเขียนข้อมูลดัมพ์ข้อความเคอร์เนลลงในพื้นที่จัดเก็บเฟิร์มแวร์ ทำให้เกิดสถานะล้มเหลว^{[ 30 ] [ 159 ] [ 160 ]}

• ACPI  – มาตรฐานอินเทอร์เฟซเฟิร์มแวร์คอมพิวเตอร์
• บูตโหลดเดอร์  – ซอฟต์แวร์ที่ทำหน้าที่เริ่มต้นการทำงานของคอมพิวเตอร์
• MoonBounce  – มัลแวร์ UEFI
• OpenBIOS  – ซอฟต์แวร์โอเพ่นเฟิร์มแวร์แบบโอเพ่นเฟิร์มแวร์ที่ใช้งานได้ฟรี
• ระบบจัดการ BIOS (SMBIOS)
• โมดูลแพลตฟอร์มที่เชื่อถือได้ (TPM)
• การเริ่มต้นแพลตฟอร์ม UEFI (UEFI PI)
• UEFITool  – โปรแกรมซอฟต์แวร์

• ซิมเมอร์, วินเซนต์; รอธแมน, ไมเคิล; เฮล, โรเบิร์ต (10 พฤษภาคม 2550) “สถาปัตยกรรม EFI” . บันทึกของดร.ด็อบบ์ . ยูบีเอ็ม. สืบค้นเมื่อ12 ตุลาคม 2555 .
• เดอ บอยน์ พอลลาร์ด, โจนาธา น(11 กรกฎาคม 2011). "กระบวนการบูต EFI"คำตอบที่พบบ่อย สืบค้นเมื่อ12 ตุลาคม 2012
• เดอ บอยน์ พอลลาร์ด, โจนาธา น(8 ธันวาคม 2011). "กระบวนการบูตของ Windows NT 6"คำตอบที่พบบ่อย สืบค้นเมื่อ12 ตุลาคม 2012
• Smith, Roderick W. (2011). "การแปลงจาก BIOS เป็น UEFI" . หน้าเว็บของ Roderick W. Smith . สืบค้นเมื่อ12 ตุลาคม 2012 .
• โคธารี, ราจิฟ (21 กันยายน 2011). "UEFI – มันสำคัญแค่ไหนกันแน่" . ความลับของฮาร์ดแวร์ . เก็บถาวรจากต้นฉบับเมื่อ 25 ตุลาคม 2012 . สืบค้นเมื่อ12 ตุลาคม 2012 .
• Fisher, Doug (2011). "UEFI Today: Bootstrapping the Continuum" . Intel Technology Journal . 15 (1). Intel. ISBN 9781934053430เก็บถาวรจากต้นฉบับเมื่อวันที่ 27 กันยายน 2556 เรียกดูเมื่อวันที่ 24 กันยายน 2556

วิกิมีเดียคอมมอนส์มีสื่อที่เกี่ยวข้องกับอินเทอร์เฟซเฟิร์มแวร์ที่ขยายได้ (Extensible Firmware Interface )

• เว็บไซต์อย่างเป็นทางการ
• ข้อมูลจำเพาะของ UEFI
• โครงการ EFI Framework แบบโอเพนซอร์สที่ได้รับการสนับสนุนจาก Intel
• พอร์ทัล Intel EFI/UEFI
• การรองรับ UEFI ของ Microsoft และข้อกำหนดสำหรับระบบปฏิบัติการ Windows
• วิธีใช้งานฟีเจอร์ Hybrid Shutdown / Fast Boot ใน Windows 8
• การรักษาความปลอดภัยกระบวนการบูตของ Windows 10
• LoJax: รูทคิต UEFI ตัวแรกที่ถูกค้นพบในโลกแห่งความเป็นจริง โดยกลุ่ม Sednit เป็นผู้รายงาน
• ตัวแปลภาษา Python สำหรับ UEFI Shell