5 ms·
> Even today's modern 64-bit CPUs begin execution in 16-bit mode. In UEFI, this is called the SEC phase. Is that true even for the T2 Macs and such?
by Razengan 7y ago
> Even today's modern 64-bit CPUs begin execution in 16-bit mode. In UEFI, this is called the SEC phase.
Is that true even for the T2 Macs and such?
- Avery3R 7y agoI'm not that familiar with Macs, but if they're using an Intel CPU it almost definitely starts in 16-bit mode. From what I understand the T2 chip is more akin to what's called an embedded controller in other laptops.
- fortran77 7y agoAccording to the CPU processor manuals, they all boot in "real mode" which is a 16-bit legacy/bootstrap mode.
- pwg 7y agoYes, all Intel X86 CPU's start up in 'real mode' which is 16-bit mode. They start this way because at initial reset none of the required data structures for protected mode operation (page tables, GDT, IDT, etc.) are present. So the CPU starts up as a very fast 8086 who's purpose is to setup just enough page tables, a GDT, an IDT, etc. to be able to switch into protected mode and continue system bootstrap.
- nixgeek 7y agoThere's coverage of that in Apple's Platform Security documentation. https://support.apple.com/guide/security/uefi-firmware-overview-seced055bcf6/web https://support.apple.com/guide/security/uefi-firmware-overv...
- saagarjha 7y agoThe T2's job is to bring the main processor out of reset. The actual booting is standard UEFI, apparently.
- onedognight 7y agoApple has been moving their defenses earlier and earlier in the boot process. According to this talk[0] they are even able to foil malicious option ROM[1] and other early boot attacks. I don’t recall if they mention boot passwords specifically, but they claim to lead the industry in this regard. [0] https://youtu.be/3byNNUReyvE https://youtu.be/3byNNUReyvE [1] https://www.blackhat.com/us-19/briefings/schedule/#behind-the-scenes-of-ios-and-mac-security-17220 https://www.blackhat.com/us-19/briefings/schedule/#behind-th...
- Avery3R 7y agoVerification of option roms as a part of secure boot is a part of the normal uefi spec, however some vendors forgot to implement it https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/uefi-validation-option-rom-validation-guidance https://docs.microsoft.com/en-us/windows-hardware/manufactur...
- oneplane 7y agoYes, because the CPU boots after the T2, and the T2 emulates the SPI ROM to the PCH. There is no actual BIOS Flash chip, only T2 Flash. Normally the CPU talks to the PCH and the PCH via SPI to a Flash ROM. The CPU has a BOOTROM which can cryptographically verify code blocks, the PCH has a CPU that can do the same, and the firmware has signed code blocks. It starts out with the CPU reading an authenticated code block which contains further code to verify other blocks. Problem is that you still read SPI Flash which can be modified out of band, so after the CPU ROM reads the ACB it continues reading code which can be altered and if the UEFI firmware is set to 'verify but don't stop running' mode, you can modify all you want and it will work. On the other hand, if it is configured that way but a bit flip happens you can't boot anymore and can repair either. Apple's solution was to get rid of that completely and just emulate that SPI Flash from the T2 chip. The T2 is a complete SoC running an OS and has a secure enclave. Because it doesn't have to support 1980's Intel architecture they had a lot more freedom in designing security from the start, something Intel can't do unless they can break with backwards compatibility.
- ben_bai 7y agoEvery X86, X86-64 CPU starts in 16bit mode. Because backwards compatibility is king!