| |||||||||||||
Garrett: UEFI secure bootingGarrett: UEFI secure bootingPosted Sep 23, 2011 1:27 UTC (Fri) by hamish (subscriber, #6282)In reply to: Garrett: UEFI secure booting by etienne Parent article: Garrett: UEFI secure booting
This just means that the malware would run the boot-loader in an emulation and only show it what it expected to see.
(Log in to post comments)
Garrett: UEFI secure booting Posted Sep 23, 2011 10:20 UTC (Fri) by etienne (subscriber, #25256) [Link]
You can't "emulate" real mode with 4 Gbytes segments (which is needed to read that FLASH) with any x86 processor, even with SMM.
It is quite easy to detect that you are on real hardware, and I would say quite difficult to write the real-mode software so that it also runs inside a simulation.
Garrett: UEFI secure booting Posted Sep 30, 2011 9:00 UTC (Fri) by robbe (guest, #16131) [Link]
As I understand it EFI does away with real mode as well. So your bootloader would run in protected or long mode, both of which can be virtual.
Garrett: UEFI secure booting Posted Oct 3, 2011 11:14 UTC (Mon) by etienne (subscriber, #25256) [Link]
I was speaking of "standard Linux boot-loader", they will not work in protected or long mode, without extensive modifications.
For instance, even if Gujin can work in an emulation (i.e. DOS running EMM386 virtual memory management) it has to load the kernel at a physical memory address and uses HIMEM services for that, knowing that HIMEM has to use physical addresses because it was used by some old drivers to manage DMA buffers. It has also to detect it is not running in real mode and disable trying to access VESA2 video memory directly (disable 4 Gb segments). Also, LOADLIN could be used with EMM386 memory, but had to have a hook just after entering protected mode to relocate each kernel/initrd page. Basically, BIOS bootloader are mostly dealing with physical addresses and assume they own all memory over 1 Mbyte, loading the kernel just after that boundary and the initrd just before the end of memory. As such they could do a checksum/SHA of at least the first Mbyte of the FLASH if it were always located at 0xFFF00000, but newer PC probably have more FLASH than that. IHMO EFI mostly solves Windows problems, I fail to see which Linux problem is solved.
Garrett: UEFI secure booting Posted Oct 3, 2011 18:05 UTC (Mon) by raven667 (subscriber, #5198) [Link] IHMO EFI mostly solves Windows problems, I fail to see which Linux problem is solved. That's kind of amusing since AFAIK EFI has been mostly used for and presumably designed for booting UNIX systems, HPUX and then MacOSX, with Windows support being a distant afterthought.
|
|||||||||||||