Broken UEFI implementations: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
No edit summary
Line 32: Line 32:
- Fixes some Linux secure boot issues.
- Fixes some Linux secure boot issues.
- Updates Microcode M12306A9 to V17. </pre>
- Updates Microcode M12306A9 to V17. </pre>

= Apple =

Revision as of 15:12, 27 July 2015

This page serves as a repository of information about any aspect of the system firmware which is broken on UEFI machines, but especially those directly related to UEFI itself.

El Torito boot

UEFI boot from CD is controlled using El Torito boot records in the CD

headers. Some machines get this wrong. In particular, one common set of known issues stem from early CSM packages which don't correctly interpret multiple El Torito boot catalog entries. The most common failure is the CSM's parser not recognizing the 0xEF platform ID, and instead of interpreting "I don't know this platform ID" correctly as "This is not for my platform" when there are multiple boot entries, some versions present you with a menu:

1.
2.
Select CD-ROM boot type:

Which represents the boot catalog entries (cleverly unlabeled). On some platforms (including some Apple laptops, among others) this happens without setting up any keyboard controller, and you are now stuck.

BGRT Table

  • BGRT is an ACPI table to tell us if and where UEFI firmware has drawn its logo on the screen. Technically the BGRT is an ACPI 5 table, but its use corresponds with UEFI 2.4 deployments, and it goes hand in hand with the EFI Graphics Output Protocol and ESRT + UEFI UpdateCapsule and [Microsoft's firmware update graphics capsule]. In theory, "uint16_t version" (offset 0x24) should always be 1, and "uint8_t status" (offset 0x26) with 0x1 set means "valid data" - that is, if the firmware displayed a splash graphic, it sets the values in the table and sets status to 1; if not, status should be 0.

Here are some sample entries. These are from real machines, but the problems are common across lots of hardware from lots of vendors:

Lenovo X1 Carbon (1st gen, 346035U)

00000000  42 47 52 54 38 00 00 00  00 00 4c 45 4e 4f 56 4f  |BGRT8.....LENOVO|
00000010  54 50 2d 47 36 20 20 20  00 27 00 00 50 54 4c 20  |TP-G6   .'..PTL |
00000020  02 00 00 00 00 00 01 00  18 b0 7e d3 00 00 00 00  |..........~.....|
00000030  0f 02 00 00 b4 00 00 00                           |........|

This helpfully has version=0x0000 and status=0x01 i.e. some version that doesn't exist but the table claims its information is valid.

Intel strawberry mountain (DQ67SW)

00000000  42 47 52 54 38 00 00 00  01 fe 49 4e 53 59 44 45  |BGRT8.....INSYDE|
00000010  4d 48 42 20 43 52 42 20  01 00 00 00 41 43 50 49  |MHB CRB ....ACPI|
00000020  00 00 04 00 01 00 00 00  00 d0 fd a7 00 00 00 00  |................|
00000030  fa 00 00 00 4f 00 00 00                           |....O...|

This particular firmware says it's version 1 but that the data is invalid; this implementation /always/ says the data is invalid, whether it displays the logo or not.

The Lenovo ThinkCentre M92p and maybe some related products

The Lenovo ThinkCentre M92p initially shipped with a firmware which would only let you select boot entries where the Boot#### variable label was "Microsoft Windows" or "Red Hat Enterprise Linux". This may have been fixed in firmware version 9SKT61A/9SJT61A , which says:

CHANGES for 9SKT61A/9SJT61A
- Fixes some Linux secure boot issues.
- Updates Microcode M12306A9 to V17.  

Apple