(번역) UEFI

원문 보기: https://dawoum.duckdns.org/wiki/UEFI

Original article: w:UEFI

Unified Extensible Firmware Interface (UEFI, /ˈjuːɪfaɪ/ 또는 약어)는 컴퓨팅 플랫폼의 펌웨어 아키텍처에 대한 사양입니다. 컴퓨터가 켜질 때, UEFI-구현이 전형적으로 운영 시스템을 시작하기 전에 가장 먼저 실행됩니다. 예로는 AMI Aptio, Phoenix SecureCore, TianoCore EDK II, InsydeH2O가 있습니다.

UEFI는 IBM PC 호환되는 모든 개인용 컴퓨터의 부팅 ROM에 존재했던 BIOS를 대체하지만, 그것은 CSM 부팅을 사용하여 BIOS와의 후진-방향 호환성을 제공할 수 있습니다. 원래 IBM에 의해 독점 소프트웨어로 만든 사실상의 표준인 전임자, BIOS와 달리, UEFI는 산업 컨소시엄에 의해 유지 관리되는 열린 표준입니다.

인텔은 원래의 Extensible Firmware Interface (EFI) 사양을 개발했습니다. EFI의 마지막 인텔 버전은 2005년에 출시된 1.10이었습니다. 이후 버전은 통합 EFI 포럼에 의해 UEFI로 개발되었습니다.

UEFI는 플랫폼 및 프로그래밍 언어와 독립적이지만, C가 참조 구현 TianoCore EDKII에 대해 사용됩니다.

History

EFI에 대한 원래 동기는 1990년대-중반 최초의 Intel–HP Itanium 시스템을 초기 개발 동안 생겨났습니다. BIOS 제한 (16-비트 실제 모드, 1MB 주소 지정 가능 메모리 공간, 어셈블리 언어 프로그래밍, 및 PC AT 하드웨어 등)이 Itanium이 타겟으로 삼은 대형 서버 플랫폼에 너무 제한적이 되었습니다. 이들 문제를 해결하기 위한 노력은 1998년에 시작되었고 처음에는 Intel Boot Initiative라고 불렸습니다. 그것은 나중에 Extensible Firmware Interface (EFI)로 이름이 변경되었습니다.

첫 번째 오픈 소스 UEFI 구현, Tiano는 2004년 인텔에 의해 출시되었습니다. 그 이후 Tiano는 EDK 및 EDK I로 대체되었고 현재는 TianoCore 커뮤니티에 의해 유지 관리되고 있습니다.

2005년 7월, 인텔은 버전 1.10에서 EFI 사양 개발을 중단하고, 그것을 통합 EFI 포럼에 기여했으며, 이는 Unified Extensible Firmware Interface (UEFI)로 사용을 개발해 왔습니다. 원래 EFI 사양은 인텔에 의해 여전히 소유되고 있으며, 인텔은 EFI-기반 제품에 대한 라이선스를 독점적으로 제공하지만, UEFI 사양은 UEFI 포럼에 의해 소유되고 있습니다.

UEFI 사양의 버전 2.0은 2006년 1월 31일에 출시되었습니다. 여기에는 암호화와 보안이 추가되었습니다.

UEFI 사양의 버전 2.1은 2007년 1월 7일에 출시되었습니다. 여기에는 네트워크 인증과 사용자 인터페이스 아키텍처 (UEFI에서 '인간 인터페이스 인프라')가 추가되었습니다.

2018년 10월, Arm은 Arm-기반 서버에 일반적인 기성형(off-the-shelf) 운영 시스템과 하이퍼바이저를 도입하기 위한 규정 준수 인증 프로그램, Arm ServerReady를 발표했습니다. 그 프로그램에서는 시스템 펌웨어가 Server Base Boot Requirements (SBBR)를 준수해야 합니다. SBBR에는 UEFI, ACPI, 및 SMBIOS 규정 준수가 필요합니다. 2020년 10월, Arm은 그 프로그램을 edge 및 IoT 시장으로 확장한다고 발표했습니다. 새로운 프로그램 이름은 Arm SystemReady입니다. Arm SystemReady는 현재 세 가지 레시피를 제공하는 Base Boot Requirements (BBR) 사양을 정의했으며, 그 중 두 가지는 UEFI와 관련이 있습니다: 1) SBBR: Windows, Red Hat Enterprise Linux, 및 VMware ESXi와 같은 엔터프라이즈 수준 운영 환경에 적합한 UEFI, ACPI, 및 SMBIOS 규정 준수를 요구합니다; 그리고 2) EBBR: Yocto와 같은 임베디드 환경에 적합한 Embedded Base Boot Requirements (EBBR)에 정의된 UEFI 인터페이스의 모음을 준수해야 합니다. 많은 Linux 및 BSD 배포판은 두 가지 레시피를 모두 지원할 수 있습니다.

2018년 12월, Microsoft는 Microsoft Surface 및 Hyper-V 제품에 사용되는 TianoCore EDK II의 포크, Project Mu를 발표했습니다. 그 프로젝트는 서비스로서의 펌웨어라는 아이디어를 홍보합니다.

최신 UEFI 사양, 버전 2.10은 2022년 8월에 공개되었습니다.

Advantages

EFI 사양에 의해 정의된 인터페이스에는 플랫폼 정보를 포함하는 데이터 테이블과 OS 로더와 OS에서 사용할 수 있는 부팅과 런타임 서비스가 포함됩니다. UEFI 펌웨어는 BIOS에 비해 여러 가지 기술적 이점을 제공합니다:

GUID 파티션 테이블 (GPT)을 갖는 대용량 파티션 (2TB 이상)을 포함하는 디스크를 부팅하기 위한 기능
네트워크 기능, GUI, 다국어를 포함한 유연한 사전-OS 환경
32-비트 (예를 들어, IA-32, ARM32) 또는 64-비트 (예를 들어, x64, AArch64) 사전-OS 환경
C 언어 프로그래밍
UEFI 쉘을 위한 Python 인터프리터를 사용한 Python 프로그래밍
모듈러 설계
역방향 및 전방향 호환성

UEFI와 함께, Windows와 같은 운영 시스템을 위한 제품 키를 장치의 UEFI 펌웨어에 저장할 수 있습니다. UEFI는 Windows 8 이상이 설치된 장치의 보안 부팅에 대해 필요합니다.

운영 시스템이 UEFI 구성 데이터에 접근하는 것도 가능합니다.

Compatibility

Processor compatibility

버전 2.5 기준, Itanium, x86, x86-64, ARM (AArch32), 및 ARM64 (AArch64)에 대한 프로세서 바인딩이 존재합니다. 리틀-엔디언 프로세서만 지원될 수 있습니다. 비공식 UEFI 지원은 리틀-엔디언 모드에서 실행하는 OpenPOWER 추상화 계층, OPAL 위에 TianoCore를 구현함으로써 POWERPC64에 대해 개발 중입니다. MIPS 및 RISC-V에 대한 유사한 프로젝트가 있습니다. UEFI 2.7 기준, RISC-V 프로세서 바인딩이 32-비트, 64-비트, 및 128-비트 모드에 대해 공식적으로 확립되어 왔습니다.

표준 PC BIOS는 16-비트 프로세서 모드와 1MB의 주소 지정 가능 메모리 공간으로 제한되며, 이는 16-비트 Intel 8088 프로세서를 사용하는 IBM 5150를 기반한 설계의 결과입니다. 이에 비해, UEFI 환경에서 프로세서 모드는 32-비트 (IA-32, AArch32) 또는 64-비트 (x86-64, Itanium, 및 AArch64)가 될 수 있습니다.[ 64-비트 UEFI 펌웨어 구현은 롱 모드를 지원하며, 이를 통해 프리부트 환경에서 응용 프로그램은 64-비트 주소 지정을 사용하여 모든 기계의 메모리에 직접 접근할 수 있습니다.

UEFI는 펌웨어와 운영 시스템 로더 (또는 커널)가 크기가 일치하도록 요구합니다; 즉, 64-비트 UEFI 펌웨어 구현은 64-비트 운영 시스템 (OS) 부트 로더 또는 커널만 로드할 수 있고 (CSM-기반 레거시 부팅이 사용되지 않는 한), 같은 것이 32비트에도 적용됩니다. 시스템이 부팅 서비스에서 런타임 서비스로 전환된 후, 운영 시스템 커널이 인계합니다. 이 시점에서, 커널은 원하는 경우 프로세서 모드를 변경할 수 있지만, 이렇게 하면 런타임 서비스 사용이 차단됩니다 (커널이 다시 전환하지 않는 한). 3.15 버전 기준, 리눅스 커널은 x86-64 CPU에서 실행하는 32-비트 UEFI 펌웨어 구현에서 부팅되는 64-비트 커널을 지원하며, UEFI 부트 로더의 UEFI 핸드오버 지원이 요구 사항입니다. UEFI 핸드오버 프로토콜은 커널과 UEFI 부트 로더 사이에서 UEFI 초기화 코드 중복을 제거하고 리눅스 커널의 UEFI 부트 스텁에 의해서만 초기화를 수행하도록 합니다.

Disk device compatibility

마스터 부트 레코드 (MBR)을 사용하는 표준 PC 디스크 파티션 체계 외에도, UEFI는 MBR의 많은 제한이 없는 GUID 파티션 테이블 (GPT) 파티션 체계와도 작동합니다. 특히, 디스크 파티션의 수와 크기에 대한 MBR 제한 (디스크당 최대 4개의 주요 파티션, 및 디스크당 최대 2 TB (\(2 \times 2^{40}\) 바이트))이 완화됩니다. 보다 구체적으로, GPT는 최대 8 ZiB (\(8 \times 2^{70}\) 바이트)의 디스크와 파티션 크기를 허용합니다.

Linux

Microsoft Windows

일부 EFI 관행과 데이터 형식은 Microsoft Windows의 관행과 데이터 형식을 반영합니다.

Windows Vista SP1 이상의 64-비트 버전과 Windows 8, 8.1, 10, 및 11의 64-비트 버전은 2TB보다 큰 GPT 디스크에서 부팅할 수 있습니다.

Features

Services

EFI는 부트 서비스와 런타임 서비스라는 두 가지 유형의 서비스를 정의합니다. 부트 서비스는 펌웨어가 플랫폼을 소유하는 동안 (즉, ExitBootServices() 호출 전)만 사용할 수 있고, 그것들은 다양한 장치의 텍스트 콘솔과 그래픽 콘솔과 버스, 블록 및 파일 서비스를 포함합니다. 런타임 서비스는 운영 시스템이 실행하는 동안에도 계속 접근할 수 있습니다; 여기에는 날짜, 시간, 및 NVRAM 접근과 같은 서비스가 포함됩니다.

Graphics Output Protocol (GOP) services 그래픽 출력 프로토콜 (GOP)은 런타임 서비스를 제공합니다; 아래의 Graphics features 섹션도 참조하십시오. 운영 시스템은 런타임 모드 동안 GOP가 제공하는 프레임버퍼에 직접 쓸 수 있습니다. UEFI Memory map services SMM services ACPI services SMBIOS services Devicetree services (for RISC processors) Variable services UEFI 변수는 특히 비-휘발성 데이터인 데이터를 저장하는 방법을 제공합니다. 일부 UEFI 변수는 플랫폼 펌웨어와 운영 시스템 사이에 공유됩니다. 변수 이름공간은 GUID에 의해 식별되고, 변수는 키/값 쌍입니다. 예를 들어, UEFI 변수는 충돌 후 운영 시스템에 대해 재부팅 후 검색하기 위해 NVRAM에 충돌 메시지를 보관하기 위해 사용될 수 있습니다. Time services UEFI는 시간 서비스를 제공합니다. 시간 서비스에는 표준 시간대와 일광 절약 시간제 필드에 대한 지원이 포함되어 있어, 하드웨어 실시간 시계를 지역 시간 또는 UTC로 설정할 수 있습니다. PC-AT 실-시간 시계를 사용하는 컴퓨터에서, 기본적으로 하드웨어 시계를 BIOS-기반 Windows와 호환되도록 지역 시간으로 설정해야 합니다. 최신 버전을 사용하고 Windows 레지스트리에 UTC 사용을 나타내는 항목이 설정되어 있는 경우는 예외입니다.

Applications

OS를 로딩하는 것 외에도, UEFI는 EFI 시스템 파티션에 파일로 상주하는 UEFI 응용 프로그램을 실행할 수 있습니다. 그것들은 UEFI 쉘, 펌웨어 부트 관리자, 또는 다른 UEFI 응용 프로그램에서 실행될 수 있습니다. UEFI 응용 프로그램은 original equipment manufacturers (OEM)과 독립적으로 개발되고 설치될 수 있습니다.

UEFI 응용 프로그램의 한 유형은 GRUB, rEFInd, Gummiboot, 및 Windows Boot Manager와 같은 OS 부트 로더로, 일부 OS 파일을 메모리에 로드하여 실행합니다. 역시, OS 부트 로더는 다른 UEFI 응용 프로그램을 선택하여 실행할 수 있는 사용자 인터페이스를 제공할 수 있습니다. UEFI Shell과 같은 유틸리티도 UEFI 응용 프로그램입니다.

Protocols

EFI는 프로토콜을 두 개의 바이너리 모듈 사이의 통신에 대해 사용되는 소프트웨어 인터페이스의 모음으로 정의합니다. 모든 EFI 드라이버는 프로토콜을 통해 다른 드라이버에 서비스를 제공해야 합니다. EFI 프로토콜은 BIOS 인터럽트 호출과 유사합니다.

Device drivers

표준 명령어 모음 아키텍처-특정 장치 드라이버 외에도, EFI는 비-휘발성 메모리에 EFI 바이트 코드 또는 EBC로 저장된 ISA-독립 장치 드라이버를 제공합니다. 시스템 펌웨어에는 EBC 이미지에 대한 인터프리터가 있습니다. 그런 의미에서, EBC는 PowerPC-기반 Apple Macintosh 및 Sun Microsystems SPARC 컴퓨터, 등에서 사용되는 ISA-독립 펌웨어인 Open Firmware와 유사합니다.

일부 장치 유형에 대한 일부 아키텍처-지정 (비-EFI 바이트 코드) EFI 드라이버는 OS에 의한 사용에 대해 인터페이스를 가질 수 있습니다. 이를 통해 OS는 운영-시스템-지정 드라이버가 로드되기 전과 로드되면 드라이버에 대한 기본 그래픽 및 네트워크 기능을 수행하기 위해 EFI에 의존할 수 있습니다.

다른 경우에서, EFI 드라이버는 다른 유형의 디스크 볼륨에서 부팅을 허용하는 파일 시스템 드라이버가 될 수 있습니다. 예로는 NTFS ESP 체인-로딩에 대해 Rufus에 의해 사용되는 37개 파일 시스템 (GRUB2 코드 기반)에 대한 efif가 있습니다.

Graphics features

EFI 1.0 사양은 그래픽 기능을 지원하기 위한 하나의 방법으로 UGA (Universal Graphic Adapter) 프로토콜을 정의했습니다. UEFI는 UGA를 포함하지 않고 그것을 GOP (Graphics Output Protocol)로 대체했습니다.

UEFI 2.1은 사용자 입력, 지역화된 문자열, 글꼴, 및 양식 (HTML 의미)을 관리하기 위해 "Human Interface Infrastructure" (HII)를 정의했습니다. 이를 통해 original equipment manufacturers (OEM) 또는 independent BIOS vendors (IBV)는 부팅-전 구성을 위한 그래픽 인터페이스를 설계할 수 있습니다. UEFI는 기본적으로 UTF-16을 문자열을 인코딩하기 위해 사용합니다.

대부분의 초기 UEFI 펌웨어 구현은 콘솔-기반이었습니다. 오늘날 많은 UEFI 펌웨어 구현은 GUI-기반입니다.

EFI system partition

Main article: EFI system partition

EFI 시스템 파티션은, 종종 ESP로 약칭되며, UEFI 사양을 준수하는 컴퓨터에서 사용되는 데이터 스토리지 장치 파티션입니다. 컴퓨터의 전원이 켜질 때 UEFI 펌웨어에 의해 접근된, 그것은 UEFI 응용 프로그램과 이들 응용 프로그램이 실행하는 데 필요한 파일을 저장하며, 운영 시스템 부트 로더를 포함합니다. 지원되는 파티션 테이블 체계는 MBR 및 GPT와 광 디스크의 El Torito 볼륨을 포함합니다. ESP에서 사용하기 위해, UEFI는 UEFI 사양의 일부로 유지 관리되고 원래 FAT 사양과 독립적으로 FAT32, FAT16, 및 FAT12 파일 시스템을 포함하는 FAT 파일 시스템의 특정 버전을 정의합니다. ESP는 역시 역방향 BIOS와의 호환성의 일부로 부트 섹터에 대한 공간을 제공합니다.

Booting

UEFI booting

레거시 PC BIOS와 달리, UEFI는 부트 섹터에 의존하지 않고, 대신 UEFI 사양의 일부로 부트 관리자를 정의합니다. 컴퓨터가 켜질 때, 부트 관리자가 부트 구성을 확인하고, 그런-다음 설정에 기초하여 지정된 OS 부트 로더 또는 운영 시스템 커널 (보통 부트 로더)을 실행합니다. 부트 구성은 NVRAM에 저장된 변수에 의해 정의되며, 여기에는 OS 로더 또는 OS 커널에 대한 파일 시스템 경로를 나타내는 변수가 포함됩니다.

UEFI는 OS 부트 로더를 자동으로 감지할 수 있으며, 이를 통해 USB 플래시 드라이브와 같은 이동식 장치에서 쉽게 부팅할 수 있습니다. 이 자동 감지는 컴퓨터 아키텍처에 따라 경로가 달라지는 OS 부트 로더에 대한 표준화된 파일 경로에 의존합니다. 파일 경로의 형식은 <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI로 정의됩니다; 예를 들어, x86-64 시스템의 OS 로더에 대한 파일 경로는 \efi\boot\bootx64.efi이고, ARM64 아키텍처에서 \efi\boot\bootaa64.efi입니다.

GPT-파티션 디스크에서 UEFI 시스템을 부팅하는 것은 공통적으로 UEFI-GPT 부팅이라고 불립니다. UEFI 사양에서 MBR 파티션 테이블이 완벽하게 지원되어야 한다는 사실에도 불구하고, 일부 UEFI 펌웨어 구현은 부팅 디스크의 파티션 테이블 유형에 따라 BIOS-기반 CSM 부팅으로 즉시 전환하여, MBR-파티션 디스크에서 EFI 시스템 파티션에서 UEFI 부팅이 수행되는 것을 효과적으로 방지합니다. 그러한 부팅 구성은 공통적으로 UEFI-MBR이라고 불립니다.

부트 관리자에는 텍스트 사용자 인터페이스가 있으므로 사용자가 사용 가능한 부트 옵션 목록에서 원하는 OS (또는 설정 유틸리티)를 선택할 수 있는 것도 공통적입니다.

CSM booting

역방향 호환성을 보장하기 위해, PC-급 기계에서 UEFI 펌웨어 구현은 레거시 BIOS 호환성을 제공하는 호환성 지원 모듈 (CSM)을 통해 MBR-파티션 디스크에서 레거시 BIOS 모드로 부팅을 지원할 수 있습니다. 이 시나리오에서, 부팅은 파티션 테이블을 무시하고 부트 섹터의 컨텐츠에 의존함으로써 레거시 BIOS 기반 시스템에서와 같은 방식으로 수행됩니다.

MBR-파티션 디스크에서 BIOS 스타일 부팅을 하는 것은 공통적으로 BIOS-MBR이라고 하며, UEFI 또는 레거시 BIOS-기반 시스템에서 수행되는지 여부는 중요하지 않습니다. 게다가, GPT 디스크에서 레거시 BIOS-기반 시스템을 부팅하는 것도 가능하고, 그러한 부팅 체계는 공통적으로 BIOS-GPT라고 불립니다.

호환성 지원 모듈을 사용하면 UEFI를 지원하지 않는 레거시 운영 시스템과 일부 레거시 옵션 ROM을 계속 사용할 수 있습니다. 그것은 역시 UEFI SMM에 의해 제공되는 기능에 추가로 CompatibilitySmm이라고 불리는 필수 레거시 시스템 관리 모드 (SMM) 기능을 제공합니다. 그러한 레거시 SMM 기능의 예로는 클래식 PS/2 짝을 에뮬레이션함으로써 키보드와 마우스에 대한 USB 레거시 지원을 제공하는 것이 있습니다.

2017년 11월, 인텔은 2020년까지 클라이언트 플랫폼에 대한 CSM 지원을 단계적으로 중단할 계획이라고 발표했습니다.

2022년 7월, Kaspersky Labs는 Intel의 H81 칩셋과 영향을 받는 마더보드의 호환성 지원 모듈을 사용하는 컴퓨터에서 악성 코드를 체인 부팅하도록 설계된 루트킷과 관련된 정보를 공개했습니다.

2023년 8월에, 인텔은 2024년까지 서버 플랫폼에 대한 CSM 지원을 단계적으로 중단할 계획이라고 발표했습니다.

오늘 현재, 인텔 플랫폼을 기반으로 하는 모든 컴퓨터는 더 이상 CSM을 지원하지 않습니다.

Network booting

UEFI 사양은 Preboot eXecution Environment (PXE)를 통해 네트워크에 걸쳐 부팅헤 대한 지원을 포함하고 있습니다. PXE 부팅 네트워크 프로토콜은 인터넷 프로토콜 (IPv4 및 IPv6), 사용자 데이터그램 프로토콜 (UDP), 동적 호스트 구성 프로토콜 (DHCP), Trivial File Transfer Protocol (TFTP), 및 iSCSI를 포함합니다.

OS 이미지는 스토리지 영역 네트워크 (SAN)에 원격으로 저장될 수 있으며, SAN에 접근하기 위한 지원 프로토콜로 Internet Small Computer System Interface (iSCSI) 및 Fibre Channel over Ethernet (FCoE)를 사용할 수 있습니다.

UEFI 사양의 버전 2.5에서는 HTTP를 통한 부팅 이미지 접근 지원이 추가되었습니다.

Secure Boot

UEFI shell

UEFI는 UEFI 부트 로더를 포함한 다른 UEFI 응용 프로그램을 실행하기 위해 사용될 수 있는 쉘 환경을 제공합니다. 그 외에도, UEFI 쉘에서 사용될 수 있는 명령은 메모리 맵 가져오기 (memmap), 부트 관리자 변수 수정 (bcfg), 파티셔닝 프로그램 실행 (diskpart), UEFI 드라이버 로드, 및 텍스트 파일 편집 (edit)을 포함하여 시스템이나 펌웨어에 대한 다양한 다른 정보를 얻는 데 사용될 수 있습니다.

UEFI 쉘에 대한 소스 코드는 인텔의 TianoCore UDK/EDK2 프로젝트에서 다운로드할 수 있습니다. 사전-빌드된 ShellBinPkg도 사용할 수 있습니다. Shell v2는 UEFI 2.3+ 시스템에서 가장 잘 작동하고 해당 시스템에서 Shell v1보다 권장됩니다. Shell v1은 모든 UEFI 시스템에서 작동해야 합니다.

UEFI 쉘을 시작하는 데 사용되는 방법은 시스템 마더보드의 제조업체와 모델에 따라 다릅니다. 그 중 일부는 이미 펌웨어 설정에서 시작을 위한 직접 옵션을 제공합니다. 예를 들어, 컴파일된 x86-64 버전의 쉘은 <EFI_SYSTEM_PARTITION>/SHELLX64.EFI로 사용할 수 있도록 제공해야 합니다. 일부 다른 시스템에는 적절한 키 누르는 조합으로 시작될 수 있는 이미 삽입된 UEFI 쉘이 있습니다. 다른 시스템에 대해, 해결책은 적절한 USB 플래시 드라이브를 만들거나 컴파일된 버전의 쉘과 결합된 부팅 옵션을 수동으로 추가 (bcfg)하는 것입니다.

Commands

다음은 EFI 쉘에 의해 지원되는 명령어의 목록입니다.

alias
attrib
bcfg
cd
cls
comp
cp
date
dblk
dh
dmpstore
echo
Edd30
EddDebug
edit
err
guid
help
load
ls
map
mem
memmap
mkdir
mm
mode
mount
pause
pci
reset
rm
set
stall
time
type
unload
ver
vol

Extensions

UEFI로의 확장은 컴퓨터에 부착된 거의 임의의 비-휘발성 스토리지 장치에서 로드될 수 있습니다. 예를 들어, original equipment manufacturer (OEM)은 하드 드라이브에 EFI 시스템 파티션을 갖는 시스템을 배포할 수 있으며, 이는 마더보드의 ROM에 저장된 표준 UEFI 펌웨어에 추가적인 기능을 더합니다.

UEFI Capsule

UEFI Capsule은 현대적이고 안전한 것으로 마케팅되는 펌웨어-에서-OS 펌웨어 업데이트 인터페이스를 정의합니다. Windows 8, Windows 8.1, Windows 10, 및 리눅스에 대한 Fwupd는 각각 UEFI Capsule을 지원합니다.

Hardware

BIOS와 마찬가지로, UEFI는 시스템 하드웨어 구성 요소 (예를 들어, 메모리 교육, PCIe 링크 교육, 전형적인 x86 시스템의 USB 링크 교육)를 초기화하고 테스트하고, 그런-다음 대용량 스토리지 장치나 네트워크 연결을 통해 부트 로더를 로드합니다. x86 시스템에서, UEFI 펌웨어는 보통 마더보드의 NOR 플래시 칩에 저장됩니다. 일부 ARM-기반 Android 및 Windows Phone 장치에서, UEFI 부트 로더는 eMMC 또는 eUFSS 플래시 메모리에 저장됩니다.

Classes

UEFI 기계는 UEFI로의 쉬운 전환을 돕기 위해 사용되었던 다음 클래스 중 하나를 가질 수 있습니다:

Class 0: 레거시 BIOS
Class 1: CSM 인터페이스를 갖고 외부 UEFI 인터페이스가 없는 UEFI. 유일한 UEFI 인터페이스는 펌웨어 내부에 있습니다.
Class 2: CSM 및 외부 UEFI 인터페이스 (예를 들어, UEFI 부팅)를 갖는 UEFI.
Class 3: CSM 인터페이스가 없고 외부 UEFI 인터페이스를 갖는 UEFI.
Class 3+: 보안 부팅이 활성화된 UEFI 클래스 3.

10세대 Intel Core부터 시작하여, 인텔은 더 이상 iGPU (Intel Graphics Technology)에 대한 레거시 비디오 BIOS를 제공하지 않습니다. 그것들 CPU를 사용한 레거시 부팅에는 비디오 카드에서 여전히 제공할 수 있는 레거시 비디오 BIOS가 필요합니다.

Boot stages

SEC – Security Phase

이것은 UEFI 부팅의 첫 번째 단계이지만, 그 앞에 플랫폼 지정 바이너리 코드를 가질 수 있습니다 (예를 들어, Intel ME, AMD PSP, CPU 마이크로코드). 그것은 특정 아키텍처를 위해 어셈블리 언어로 작성된 최소한의 코드로 구성됩니다. 그것은 임시 메모리 (종종 CPU cache-as-RAM (CAR), 또는 SoC on-chip SRAM)를 초기화하고, 핸드-오프 전에 PEI를 확인하는 옵션을 갖는 시스템의 소프트웨어 신뢰 루트 역할을 합니다.

PEI – Pre-EFI Initialization

UEFI 부팅의 두 번째 단계는 종속성-인식 디스패처로 구성되어 있으며, PEI 모듈 (PEIM)을 로드하고 실행하여 주요 메모리 초기화 (메모리 컨트롤러 및 DRAM 초기화) 및 펌웨어 복구 작업과 같은 초기 하드웨어 초기화 작업을 처리합니다. 추가적으로, 현재 부팅 모드를 검색하고 많은 ACPI S3 연산을 처리합니다. ACPI S3 재개의 경우에서, 많은 하드웨어 레지스터를 절전 모드 이전 상태로 복원합니다. PEI는 역시 CAR을 사용합니다. 이 단계에서 초기화에는 메모리에 데이터 구조를 만들고 이들 구조 내에서 기본값을 설정하는 것이 포함됩니다.

DXE – Driver Execution Environment

이 단계는 C 모듈과 종속성 인식 디스패처로 구성됩니다. 이제 사용할 수 있는 주요 메모리와 함께, CPU, 칩셋, 메인보드, 및 기타 I/O 장치가 DXE 및 BDS에서 초기화됩니다. 이 단계에서 초기화에는 마더보드에 연결된 하드웨어에 EFI 장치 경로를 지정하고, 구성 데이터를 하드웨어로 전송하는 것이 포함됩니다.

BDS – Boot Device Select

BDS는 DXE의 일부입니다. 이 단계에서, 부팅 장치가 초기화되고, PCI 장치의 UEFI 드라이버 또는 옵션 ROM이 시스템 구성에 따라 실행되고, 부팅 옵션이 처리됩니다.

TSL – Transient System Load

이것은 부팅 장치 선택과 OS에 대한 핸드-오프 사이의 단계입니다. 이 시점에서, UEFI 쉘을 입력하거나, OS 부트 로더와 같은 UEFI 응용 프로그램을 실행할 수 있습니다.

RT – Runtime

UEFI는 ExitBootServices()가 실행된 후 운영 시스템 (OS)에 넘깁니다. UEFI 호환 OS는 이제 부팅 서비스를 종료하여 더 이상 필요하지 않은 모든 코드와 데이터를 언로드하고 예를 들어, SMM와 ACPI와 같은 런타임 서비스 코드/데이터만 남겨 둡니다. 전형적인 최신 OS는 하드웨어 장치를 제어하기 위해 자체 프로그램 (예를 들어, 커널 드라이버)을 사용하는 것을 선호합니다.

레거시 OS가 사용될 때, CSM이 이 호출을 처리하여 시스템이 레거시 BIOS 기대치와 호환되는지 확인합니다.

Usage

Implementations

인텔의 EFI 구현은 Intel Platform Innovation Framework로, 코드명은 Tiano입니다. Tiano는 인텔의 XScale, Itanium, IA-32, 및 x86-64 프로세서에서 실행되고, 독점 소프트웨어이지만, 코드 일부는 BSD 라이선스 또는 Eclipse Public License (EPL)에 따라 TianoCore EDK II로 출시되었습니다. TianoCore는 coreboot의 페이로드로 사용될 수 있습니다.

Phoenix Technologies의 UEFI 구현은 SecureCore Technology (SCT)로 브랜드화되었습니다. American Megatrends는 Aptio로 알려진 자체 UEFI 펌웨어 구현을 제공하고, 반면에 Insyde Software는 InsydeH2O를 제공하고, Byosoft는 ByoCore를 제공합니다.

2018년 12월, Microsoft는 Surface 라인의 TianoCore EDK2 기반 UEFI 구현인 Project Mu의 오픈 소스 버전을 출시했습니다.

UEFI API의 구현은 2017년에 Universal Boot Loader (Das U-Boot)에 도입되었습니다. ARMv8 아키텍처에서, Linux 배포판은 부팅을 위해 GNU GRUB와 함께 U-Boot UEFI 구현을 사용하며 (예를 들어, SUSE Linux), 이는 OpenBSD에도 해당합니다. iSCSI에서 부팅하는 것에 대해, iPXE는 U-Boot에 의해 로드된 UEFI 응용 프로그램으로 사용할 수 있습니다.

Platforms

2000년에 출시된 인텔의 첫 번째 Itanium 워크스테이션과 서버에는 EFI 1.02가 구현되었습니다.

2002년에 출시된 휴렛-팩커드의 첫 번째 Itanium 2 시스템은 EFI 1.10을 구현했습니다; 그것들은 Windows, Linux, FreeBSD, 및 HP-UX를 부팅할 수 있었습니다; OpenVMS는 2003년 6월에 UEFI 기능을 추가했습니다.

2006년 1월, Apple Inc.는 최초의 인텔-기반 Macintosh 컴퓨터를 출하했습니다. 이들 시스템은 이전 PowerPC-기반 시스템에서 사용했던 Open Firmware 대신 EFI를 사용했습니다. 2006년 4월 5일, Apple은 처음으로 Boot Camp를 출시했으며, 이는 Windows 드라이버 디스크와 비-파괴적 파티셔닝 도구를 제공하여 Mac OS X (현재 macOS)의 재설치 요구 없이도 Windows XP 또는 Vista를 설치할 수 있도록 합니다. EFI 구현에 BIOS 호환성을 추가하는 펌웨어 업데이트도 출시되었습니다. 이후의 Macintosh 모델은 더 새로운 펌웨어와 함께 출시되었습니다.

2005년 동안, 100만 대 이상의 Intel 시스템이 Intel의 UEFI 구현과 함께 출시되었습니다. Intel의 UEFI 구현을 사용하는 새로운 모바일, 데스크탑, 및 서버 제품이 2006년에 출시되기 시작했습니다. 예를 들어, Intel 945 칩셋 시리즈를 사용하는 보드는 Intel의 UEFI 펌웨어 구현을 사용합니다.

2005년부터, EFI는 XScale 코어를 기반으로 하는 임베디드 시스템과 같은 비-PC 아키텍처에도 구현되었습니다.

EDK (EFI 개발자 키트)에는 NT32 타겟이 포함되어 있어, EFI 펌웨어와 EFI 응용 프로그램을 Windows 응용 프로그램 내에서 실행할 수 있습니다. 그러나 EDK NT32에서는 직접적인 하드웨어 접근이 허용되지 않습니다. 이것은 EDK NT32 타겟에 의해 EFI 응용 프로그램과 드라이버의 하위 집합만 실행될 수 있음을 의미합니다.

2008년에, 더 많은 x86-64 시스템이 UEFI를 채택했습니다. 이들 시스템 중 다수는 여전히 호환성 지원 모듈 (CSM)을 통해 BIOS-기반 OS만 부팅할 수 있지만 (따라서 사용자에게는 UEFI-기반이 아닌 것처럼 보임), 다른 시스템은 UEFI-기반 OS 부팅을 허용하기 시작했습니다. 예를 들어, IBM x3450 서버, ClickBIOS가 있는 MSI 마더보드, HP EliteBook 노트북 PC가 있습니다.

2009년에, IBM은 UEFI 기능이 있는 System x 기계 (x3550 M2, x3650 M2, iDataPlex dx360 M2)와 BladeCenter HS22를 출하했습니다. Dell은 UEFI 기능을 갖는 PowerEdge T610, R610, R710, M610, 및 M710 서버를 출하했습니다. 더 많은 상용 시스템은 UEFI 백서에 언급되어 있습니다.

2011년에, 주요 공급업체 (ASRock, Asus, Gigabyte, MSI, 등)는 UEFI를 탑재한 Intel 6-시리즈 LGA 1155 칩셋과 AMD 9시리즈 AM3+ 칩셋을 사용하는 여러 소비자 지향 마더보드를 출시했습니다.

2012년 10월에 Windows 8의 출시와 함께, Microsoft의 인증 요구 사항에 따라 이제 컴퓨터에 UEFI 사양을 구현하는 펌웨어가 포함되어야 합니다. 게다가, 컴퓨터가 Windows 8의 "연결된 대기" 기능 (장치가 대기 모드에서 거의 즉시 복귀하여 스마트폰과 비슷한 전원 관리를 할 수 있음)을 지원하면, 펌웨어는 호환성 지원 모듈 (CSM)을 포함하는 것을 허용하지 않습니다. 따라서, 연결된 대기를 지원하는 시스템은 레거시 BIOS 운영 시스템을 부팅할 수 없습니다.

2017년 10월, 인텔은 2020년까지 모든 제품에서 레거시 PC BIOS 지원을 제거하고 UEFI Class 3으로 전환한다고 발표했습니다. 2019년까지, 인텔 플랫폼을 기반으로 하는 모든 컴퓨터는 더 이상 레거시 PC BIOS를 지원하지 않습니다.

Operating systems

(U)EFI에서 부팅할 수 있는 운영 시스템은 (U)EFI 사양에 의해 정의된 (U)EFI-인식 운영 시스템이라고 불립니다. 여기서 (U)EFI에서 부팅된다는 용어는 임의의 스토리지 장치에 저장된 (U)EFI 운영 시스템 로더를 사용하여 시스템을 직접 부팅한다는 것을 의미합니다. 운영 시스템 로더에 대한 기본 위치는 <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI이며, 여기서 기계 유형의 약어는 IA32, X64, IA64, ARM 또는 AA64일 수 있습니다. 일부 운영 시스템 공급업체는 자체 부트 로더를 가질 수 있습니다. 그것들은 역시 기본 부팅 위치를 변경할 수도 있습니다.

리눅스 커널은 2000년대 초반부터 elilo EFI 부트 로더나, 더 최근에는 GRUB의 EFI 버전을 사용하여 부팅 시 EFI를 사용할 수 있습니다. Grub+Linux는 UEFI 없이 GUID 파티션 테이블에서 부팅하는 것도 지원합니다. Ubuntu 배포판은 버전 12.10부터 UEFI 보안 부팅에 대한 지원을 추가했습니다. 게다가, 리눅스 커널은 EFI 부트 스텁 기능을 통해 단독으로 EFI 부트로더로 실행하는 옵션과 함께 컴파일될 수 있습니다.
HP-UX는 2002년부터 IA-64 시스템에서 부팅 메커니즘으로 (U)EFI를 사용해 왔습니다.
OpenVMS는 2003년 12월 최초 평가 출시 이후 IA-64에서 EFI를 사용해 왔고, 2005년 1월 이후 프로덕션 출시에서도 EFI를 사용해 왔습니다. x86-64에서 OpenVMS도 UEFI를 사용하여 운영 시스템을 부팅합니다.
Apple은 인텔-기반 Mac 제품군에 대해 EFI를 사용합니다. Mac OS X v10.4 Tiger 및 Mac OS X v10.5 Leopard는 최신 64-비트 CPU에서도 32-비트 모드로 EFI v1.10을 구현하지만, OS X v10.8 Mountain Lion에서 전체 지원이 도입되었습니다.
Windows 2000의 Itanium 버전 (Advanced Server Limited Edition 및 Datacenter Server Limited Edition, 사전 릴리스 Windows Server 2003 코드베이스 기반)은 2002년에 EFI 1.10을 구현했습니다. Intel Itanium 프로세서 제품군을 위한 Windows XP 64-비트 Edition, Windows 2000 Advanced Server Limited Edition (사전 릴리스 Windows Server 2003) 및 IA-64에 대한 Windows Server 2003은 모두 DIG64 사양을 통한 플랫폼 요구 사항인 EFI를 구현합니다.
Microsoft는 Windows Vista SP1 [126] 및 Windows Server 2008을 사용하여 x64 Windows 운영 시스템에 UEFI를 도입했지만 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-비트 버전을 실행하는 PC는 UEFI Class 2와 호환됩니다. 32-비트 UEFI는 원래 지원되지 않았는데, 왜냐하면 공급업체가 64-비트 컴퓨팅의 주류 상태 때문에 네이티브 32-비트 UEFI 펌웨어를 생산하는 데 관심이 없었기 때문입니다. Windows 8은 마침내 Graphics Output Protocol (GOP) 지원, 더 빠른 시작, 32-비트 UEFI 지원, 및 보안 부팅 지원을 포함하여 UEFI 시스템에 대한 추가 최적화를 도입했습니다. Windows 부터, ACPI 프로토콜을 갖는 UEFI 펌웨어는 ARM-기반 Microsoft Windows 운영 시스템에 필수 요구 사항입니다. Microsoft는 Windows 11에서 Windows를 실행하기 위해 UEFI를 요구하기 시작했으며, Windows 11의 IoT Enterprise 에디션은 버전 24H2부터 이 요구 사항에서 면제되었습니다.
2013년 3월 5일, FreeBSD Foundation은 FreeBSD 커널과 부트로더에 UEFI 지원을 추가하기 위해 추구하는 개발자에게 보조금을 수여했습니다. 변경 사항은 처음에는 FreeBSD 소스 코드의 개별 분기에 저장되었지만, 2014년 4월 4일 (개정판 264095)에 메인라인 소스에 병합되었습니다; 변경 사항에는 설치 프로그램에서의 지원도 포함됩니다. amd64에 대한 UEFI 부팅 지원은 FreeBSD 10.1에 처음 등장했고 arm64에 대한 지원은 FreeBSD 11.0에 처음 등장했습니다.
Oracle Solaris 11.1 이상은 UEFI 펌웨어 버전 2.1 이상을 갖춘 x86 시스템에 대한 UEFI 부팅을 지원합니다. GRUB 2는 x86에서 부트 로더로 사용됩니다.
OpenBSD 5.9는 자체 사용자 정의 로더를 사용하여 64-비트 x86 시스템에 대한 UEFI 부팅 지원을 도입했으며, OpenBSD 6.0은 ARMv7을 포함하도록 해당 지원을 확장했습니다.
illumos는 2017년 10월에 기본 UEFI 지원을 추가했습니다.
ArcaOS는 5.1 릴리스 이후 UEFI 부팅을 지원합니다. ArcaOS의 UEFI 지원은 운영 시스템이 의존하는 특정 BIOS 기능을 에뮬레이션합니다 (특히 INT 10H 및 INT 13H를 인터럽트합니다).

With virtualization

HP Integrity Virtual Machines는 HP Integrity Servers에서 UEFI 부팅을 제공합니다. 그것은 역시 게스트 UEFI 인식 OS에 대한 가상화된 UEFI 환경도 제공합니다.
Intel은 SourceForge에서 Open Virtual Machine Firmware 프로젝트를 호스팅합니다.
Mac OS X에 대한 VMware Fusion 3 소프트웨어는 UEFI를 사용하여 Mac OS X Server 가상 기계를 부팅할 수 있습니다.
버전 11 이전의 VMware Workstation은 비공식적으로 UEFI를 지원하지만, .vmx 파일을 편집함으로써 수동으로 활성화할 수 있습니다. VMware Workstation 버전 11 이상은 물리적 호스트 시스템이 UEFI-기반인지 여부와 관계없이 UEFI를 지원합니다. VMware Workstation 14 (및 그에 따라 Fusion 10)는 UEFI의 보안 부팅 기능에 대한 지원을 추가합니다.
VMware ESXi 5.0 하이퍼바이저는 공식적으로 UEFI를 지원합니다. 버전 6.5에서는 보안 부팅에 대한 지원이 추가되었습니다.
VirtualBox는 3.1 이후로 UEFI를 구현해 왔지만, Unix/Linux 운영 시스템과 Windows 8 이상에 한해 지원됩니다 (Windows Vista x64 및 Windows 7 x64에서는 작동하지 않습니다).
QEMU/KVM은 TianoCore에 의해 제공되는 Open Virtual Machine Firmware (OVMF)와 함께 사용될 수 있습니다.
Microsoft Hyper-V 가상 기계의 2세대는 가상화된 UEFI를 지원합니다.
Google Cloud Platform Shielded VM은 보안 부팅을 활성화하기 위해 가상화된 UEFI를 지원합니다.

Applications development

EDK2 응용 프로그램 개발 키트 (EADK)는 UEFI 응용 프로그램에서 표준 C 라이브러리 함수를 사용하는 것을 가능하도록 만듭니다. EADK는 인텔의 TianoCore UDK / EDK2 SourceForge 프로젝트에서 무료로 다운로드할 수 있습니다. 예를 들어, Python 인터프리터의 포트는 EADK를 사용함으로써 UEFI 응용 프로그램으로 제공됩니다. 개발은 UDK2015 이후 GitHub로 옮겨졌습니다.

EADK를 사용하여 작성된 최소한의 "hello, world" C 프로그램은 보통의 C 짝과 유사합니다:

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/ShellCEntryLib.h>

EFI_STATUS EFIAPI ShellAppMain(IN UINTN Argc, IN CHAR16 **Argv)
{
    Print(L"hello, world\n");
    return EFI_SUCCESS;
}

Criticism

수많은 디지털 권리 운동가들이 UEFI에 항의해 왔습니다. coreboot의 공동 저자인 Ronald G. Minnich와 디지털 권리 운동가인 Cory Doctorow는 UEFI를 컴퓨터를 진정으로 제어하기 위한 사용자의 능력을 제거하려는 시도라고 비판해 왔습니다. 그것은 대부분의 하드웨어에 대해 펌웨어에 대한 드라이버 하나와 운영 시스템에 대한 드라이버 하나라는 두 개의 서로 다른 드라이버를 필요로 하는 BIOS의 오랜 문제를 해결하지 못합니다.

오픈-소스 프로젝트 TianoCore도 UEFI를 제공합니다. TianoCore는 칩셋 기능을 초기화하는 특수 드라이버가 부족하며, 대신 TianoCore는 여러 페이로드 옵션 중 하나인 coreboot에 의해 제공됩니다. coreboot의 개발은 초기화 드라이버를 개발하는 데 필요한 사양을 제공하기 위해 칩셋 제조업체로부터 협력이 필요합니다.

Secure Boot

2011년, Microsoft는 Windows 8 운영 시스템을 실행하도록 인증된 컴퓨터는 Microsoft의 공개 키가 등록되고 보안 부팅이 활성화된 상태로 제공되어야 한다고 발표했으며, 이는 이들 장치에 UEFI를 사용해야 함을 의미합니다. 발표 후, 회사는 비평가와 자유 소프트웨어/오픈 소스 지지자 (자유 소프트웨어 재단 포함)로부터 UEFI의 보안 부팅 기능을 사용하여 리눅스와 같은 대안적인 운영 시스템의 설치를 방해하거나 완전히 방지하려 한다는 비난을 받았습니다. Microsoft는 보안 부팅 요구 사항이 일종의 잠금 장치 역할을 하려는 것이라는 것을 부인했고, Windows 8에 대해 인증된 x86-기반 시스템은 보안 부팅이 사용자 지정 모드로 들어가거나 비활성화되도록 허용해야 하지만, ARM 아키텍처를 사용하는 시스템에서는 그렇지 않다고 명시하여 요구 사항을 명확히 했습니다. Windows 10에서는 OEM이 x86 시스템 사용자가 보안 부팅을 관리할 수 있는지 여부를 결정할 수 있습니다.

다른 개발자들은 일반적으로 리눅스 시스템에서 Secure Boot에 대한 지원을 구현하는 데 따른 법적 문제와 실질적 문제에 대해 우려를 표명했습니다. 전 Red Hat 개발자 Matthew Garrett은 GNU General Public License 버전 3의 조건으로 인해 배포판 개발자가 개인 키를 공개하지 않고는 GNU GRand Unified Bootloader를 사용할 수 없을 수 있다고 언급했고 (어쨌든, 자유 소프트웨어 재단은 이후 입장을 명확히 했으며, 키를 제공할 책임은 하드웨어 제조업체에 있다고 확언했습니다), 역시 고급 사용자가 자체 서명하지 않고도 Secure Boot가 활성화된 상태에서 작동할 수 있는 사용자 지정 커널을 빌드하는 것도 어려울 것이라고 언급했습니다. 다른 개발자들은 다른 키가 있는 서명된 리눅스 빌드를 제공할 수 있다고 제안했지만 OEM이 Microsoft 키와 함께 필요한 키를 사용하여 컴퓨터를 배송하도록 설득하기 어려울 것이라고 언급했습니다.

여러 주요 리눅스 배포판은 Secure Boot에 대한 다양한 구현을 개발했습니다. Garrett은 shim이라고 알려진 최소 부트로더를 직접 개발했으며, 이는 사용자가 리눅스 배포판에서 제공하는 키를 개별적으로 신뢰할 수 있도록 하는 사전 컴파일되고 서명된 부트로더입니다. Ubuntu 12.10은 부트로더만 확인하고 서명되지 않은 커널을 로드할 수 있도록 하는 Canonical의 자체 키와 함께 사용하도록 사전 구성된 이전 버전의 shim을 사용합니다; 개발자들은 신뢰할 수 있는 커널은 사용자 공간만 보호하는 데 효과적이고, Secure Boot가 보호를 추가하도록 설계된 부팅 전 상태는 보호하지 않기 때문에 부트로더만 서명하는 방식이 더 실행 가능하다고 믿었습니다. 그것은 역시 사용자에게 시스템을 재구성할 필요 없이 자체 커널을 빌드하고 사용자 정의 커널 모듈도 사용하도록 허용합니다. Canonical은 역시 운영 시스템을 실행하는 인증 OEM 컴퓨터에 사전 로드된 우분투 설치에 서명하기 위한 자체 개인 키를 유지 관리하고 있고, 호환성 이유로 Canonical 키와 Microsoft 키 (둘 다)가 펌웨어에 포함되어야 하는 보안 부팅 요구 사항도 시행할 계획입니다. Fedora도 shim을 사용하지만, 커널과 해당 모듈도 모두 서명되어야 한다고 요구합니다.

운영 시스템 커널과 해당 모듈도 서명해야 하는지에 대해서는 논란이 있었습니다; UEFI 사양에서는 그것을 요구하지 않지만, Microsoft는 계약 요구 사항에서 서명을 요구하고, 시스템 보안을 손상시키는 데 사용될 수 있는 코드에 서명하는 데 사용된 모든 인증서를 취소할 권리가 있다고 주장했습니다. Windows에서, 보안 부팅이 활성화되면, 모든 커널 드라이버는 디지털 서명이 필요합니다; 비-WHQL 드라이버는 로드가 거부될 수 있습니다. 2013년 2월, 또 다른 Red Hat 개발자는 Microsoft가 서명한 PE 파일에 삽입된 마스터 X.509 키를 사용하여 Microsoft의 인증 코드 서명을 구문 분석할 수 있는 패치를 리눅스 커널에 제출하려고 시도했습니다. 어쨌든, 이 제안은 Linux 창시자 Linus Torvalds가 비판했으며, 그는 Red Hat이 보안 부팅 인프라에 대한 Microsoft의 제어를 지원한다고 공격했습니다.

2013년 3월 26일, 스페인의 자유 소프트웨어 개발 그룹 Hispalinux는 OEM 시스템에 대한 Microsoft의 보안 부팅 요구 사항이 "방해적"이고 반-경쟁적이라고 주장하며 유럽 위원회에 공식적인 불만을 제기했습니다.

2013년 8월 Black Hat 컨퍼런스에서 보안 연구원 그룹은 보안 부팅을 악용하는 데 사용할 수 있는 UEFI의 특정 공급업체 구현에서의 일련의 악용 사례를 발표했습니다.

2016년 8월, 두 명의 보안 연구원이 Microsoft가 운영 시스템 서명에 사용하는 "골든 키" 보안 키를 발견했다고 보고되었습니다. 기술적으로, 키는 노출되지 않았지만 키로 서명된 악용 가능한 바이너리는 노출되었습니다. 이를 통해 임의의 소프트웨어가 Microsoft에서 진짜로 서명한 것처럼 실행될 수 있고 루트킷 및 부트킷 공격의 가능성이 노출됩니다. 이것은 역시 임의의 패치가 (서명된) 악용 가능한 바이너리로 대체 (다운그레이드)될 수 있기 때문에 오류를 패치하는 것을 불가능하게 만듭니다. Microsoft는 성명을 통해 이 취약성은 ARM 아키텍처와 Windows RT 기기에만 존재하고, 두 개의 패치를 출시했다고 답했습니다; 어쨌든, 패치는 취약성을 제거하지 않으며 (제거할 수도 없음), 이를 수정하려면 최종 사용자 펌웨어에서 키를 교체해야 합니다.

2023년 3월 1일, ESET Cybersecurity Firm에서 연구원들은 그들의 공개 분석 결과에서 "취약성을 제거하지 못하는 (또는 제거할 수 없는) 패치를 악용하는 메커니즘의 이론을 설명하는 'BlackLotus'라는 "UEFI 보안 부팅을 우회하는 최초의 실제 UEFI 부트킷"을 보고했습니다.

2024년 8월 Windows 11 및 Windows 10 보안 업데이트는 장치의 UEFI NVRAM에 Secure Boot Advanced Targeting (SBAT) 설정을 적용했으며, 이로 인해 일부 리눅스 배포판이 로드되지 않을 수 있습니다. SBAT는 새로운 버전의 Windows Boot Manager 및 shim에서 지원되는 프로토콜로, 버그가 있거나 취약한 중간 부트로더 (보통 winload.efi 및 GRUB)가 부팅 프로세스에 로드되는 것을 거부합니다.

현재 RHEL (RHEL 7 이상), CentOS (CentOS 7 이상), Ubuntu, Fedora, Debian (Debian 10 이상), OpenSUSE, SUSE Linux, 등 많은 리눅스 배포판이 UEFI 보안 부팅을 지원합니다.

Firmware problems

장치에서 UEFI 펌웨어의 중요성이 커지면서 해당 구현에 기인한 여러 기술적 문제도 발생해 왔습니다.

2012년 후반에 Windows 8이 출시된 후, Secure Boot을 갖는 특정 Lenovo 컴퓨터 모델에 임의의 다른 설정과 관계없이 "Windows Boot Manager" 또는 "Red Hat Enterprise Linux"라는 실행 파일만 로드할 수 있도록 하드코딩된 펌웨어가 있다는 사실이 발견되었습니다. 적절한 작동에 필요한 특정 인증서가 없는 Secure Boot를 갖는 여러 Toshiba 노트북 모델에서 다른 문제가 발생했습니다.

2013년 1월, 일부 삼성 노트북에서 UEFI 구현을 둘러싼 버그가 공개되어, UEFI 모드에서 리눅스 배포판을 설치한 후 노트북이 벽돌이 되었습니다. 처음에는 삼성 노트북의 시스템 기능에 접근하도록 설계된 커널 모듈과의 잠재적 충돌이 원인으로 지목되었지만 (역시 커널 유지 관리자가 안전 조치로 UEFI 시스템에서 모듈을 비활성화하도록 촉구했습니다), Matthew Garrett은 이 버그가 실제로 메모리에 너무 많은 UEFI 변수를 저장함으로써 발생했고, 특정 조건에서 Windows에서도 버그가 발생할 수 있음을 발견했습니다. 결론적으로, 그는 문제가 있는 커널 모듈이 커널 메시지 덤프가 펌웨어에 기록되도록 하여 버그를 발생시켰다고 판단했습니다.

(번역) UEFI

History

Advantages

Compatibility

Processor compatibility

Disk device compatibility

Linux

Microsoft Windows

Features

Services

Applications

Protocols

Device drivers

Graphics features

EFI system partition

Booting

UEFI booting

CSM booting

Network booting

Secure Boot

UEFI shell

Commands

Extensions

UEFI Capsule

Hardware

Classes

Boot stages

SEC – Security Phase

PEI – Pre-EFI Initialization

DXE – Driver Execution Environment

BDS – Boot Device Select

TSL – Transient System Load

RT – Runtime

Usage

Implementations

Platforms

Operating systems

With virtualization

Applications development

Criticism

Secure Boot

Firmware problems

External links

관련글

티스토리툴바