BATTLE OF SKM AND IUM
blackhat2015
blackhat2015
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
UEFI RUNTIME CALLS<br />
• The UEFI specification provides firmware with the ability to expose certain functions that remain<br />
resident in memory, and can be called from the live, running OS<br />
• A lot of complexity exists here around locking and memory map layouts, since there’s no facility provided to<br />
synchronize with the OS<br />
• NT uses certain key UEFI Runtime Calls, such as the ones that provide the ability to enumerate, get, and<br />
set EFI variables<br />
• System reset/shutdown also done through UEFI, as well as Capsules (firmware updates / crash dump data)<br />
• Specifically, the UEFI Variable API exposed to user-mode (Get/SetFirmwareEnvironmentVariable)<br />
performs a system call which is ultimately handled by the HAL, which then calls UEFI<br />
• So what happens if an <strong>IUM</strong> application wants to access UEFI Runtime Calls?<br />
• VSM can therefore be configured to virtualize UEFI Runtime Calls, and to run them in VTL 1<br />
• NTOS (or rather, HAL) therefore will perform a Secure Mode Service Call to access UEFI<br />
• This means that malicious firmware could access VTL 1 data during this time!
Change language