In this article we are going to analyze the Unified Extensible Firmware Interface, from both a technical and security perspective. We will also take a brief look at the new Windows 8 EFI Kernel, we’ll discover many new interesting feature Microsoft implemented in it.
In the beginning it was BIOS
Basic Input and Output system (BIOS) is a term used to indicate the technology introduced with the aim to successfully power on a Personal Computer in the early 1980s. Most CPUs at that time were implemented using 8 bit or 16 bit architecture. BIOS main task is to initialize all system peripherals as well as the CPU itself. Operating systems and software used to run in the so called “16 bit real mode” mode. Memory was limited to only 640 KB. After BIOS finished its initialization steps, it released control to the first sector of the bootable hard drive, called Master Boot Record.
BIOS technology still survives today, even though this technology is almost 30 years old. This kind of technology clearly showed its limits many times (especially with hard-drive sector addressing method). We don’t want to listen and analyze all the structural limits of the BIOS here, as it’s a well described topic online.
Before the EFI introduction, every x86 Operation System (and also x86-64 ones) used to start their loading stage still in 16 bit real mode. OS boot loader (intended here as MBR code + VBR code + boot loader) has to deal with old interrupts, used to proper initialize early stuff. Most part of the boot loader code has to be written indeed in assembly code. This makes the developing process of a boot loader an extremely hard and challenging job. The same applies to bootkit and boot viruses development.

Traditional BIOS boot steps of a Windows System. Blue color highlights 16 bit code, Red color 32/64 bit code
UEFI technology has been introduced with the aim to bypass all these limits. UEFI’s job is to abstract all machine hardware-dependent code and provide a full framework capable of running EFI compatible boot applications. Thus, in a theoretical way, All EFI applications can run on any platform which is powered by UEFI technology.
UEFI Implementation – A Quick Glance
Entire UEFI code reside on the motherboard’s Firmware Volume (FV) that can be stored in a flash rom. UEFI Framework is composed by a list of handles’s database and a set of protocol interfaces.
The handle database is composed by objects called handles and protocols. Handles are a collection of one or more protocols, and protocols are data structures tagged by a GUID (global unique identifier). The data structure for a protocol may be empty, may contains data field, or may contain services (function pointer), or may contains both. During UEFI initialization, the system firmware, UEFI drivers (that run in DXE phase), and even UEFI applications create handles and attach one or more protocols to the handles. Information in the handle database is global and can be accessed by any executable UEFI images. The handle database is the central repository for the objects that are maintained by the UEFI-based firmware. It is a list of UEFI handles, and each UEFI handle is identified by a unique number. A UEFI handle may represent components such Executable Images like UEFI drivers and UEFI application (for example a boot loader), devices like network controllers and UEFI services.
UEFI Framework initialization process is composed by 4 phases:
- Security (SEC) Phase: Verifies some pieces of software present in Firmware volume, CPU, chipset, and Motherboard initialization code
- Pre EFI Initialization (PEI) Phase: Initialize CPU, temporary RAM and boot firmware volume (BFV), starts dispatching PEIMs (Pre EFI Initialization modules) found in BFV with the aim to basic initialize all found hardware in the system (only basic platform dependent initialization code). Finally it builds an Hand-Off Block List with all found resources interfaces (that serve as an abstraction to real peripherals platform dependent code) descriptors ready to be passed to the DXE phase.
- Driver Execution Environment (DXE) Phase: It consumes hand-off block list to initialize all system physical memory, I/O and MMIO resources, and to finally starts dispatching DXE Drivers found in all system Firmware Volumes (that are described still by HOBL). DXE Core is abstracted from the platform hardware through a set of DXE Architectural Protocols. The DXE Core consumes these protocols to produce the EFI Boot Services and EFI Runtime Services. DXE Drivers that are loaded from firmware volumes produce the DXE Architectural Protocols, and full initialize entire system. This design means that the DXE Core must have enough services to load and start DXE drivers before even a single DXE Driver is executed
- Boot Device Selection (BDS) Phase: Load all UEFI Drivers and one or more UEFI application found in a boot device. Is the phase responsible in presenting boot manager to the user and boot entire system. The boot sequence for UEFI consist of the following:
- Platform firmware reads the boot order list from globally defined NVRAM variable. The boot order list define a list of NVRAM variables that contain information about what is to be booted
- Each NVRAM boot variable contain a pointer to the hardware device and optionally to a file on that hardware device that contains the UEFI image to be loaded
Windows 8 EFI – Analysis of new features and architecture overview
At the next system restarts, when EFI Firmware ends execution, it releases control to the Windows EFI Boot Manager. One of the first thing Bootmgr does is to save EFI global data, like Boot and Runtime Services pointers. It then obtains Loaded Image protocol and Device Path protocol of its own loaded image handle, with the aim to gain Bootmgr image attributes (like base address, size, etc…). EfiInitpCreateApplicationEntry maps Bootmgr EFI Boot manager entry to Boot Configuration Data one. After EFI initialization has done, BmMain main startup function is called. Entire Bootmgr will use only EFI services to properly work.
The entire boot process is fully 64 bit (or 32 bit in case of 32 bits OSs) and that no Master Boot Record, Volume Boot Record or whatever 16 bit loader code exists.
Bootmgr uses EFI services to read BCD hive, initialize optional SecureBoot feature, locate Windows partition, and load and verify Windows EFI Loader file (winload.efi). Bootmgr uses ReadBlock service of EFI Block IO protocol to read and parse NTFS file system of partition that contains Windows Loader. At the end, Archpx64TransferTo64BitApplicationAsm Bootmgr function transfers control from Bootmgr to Windows loader.
Windows loader begins execution when it’s still in UEFI environment (with Boot Services still mapped and physical flat memory model). Loader does many things: it initializes the kernel debugger (with initial breakpoint), analyzes startup options, determines System root path, loads system hives, HAL module, all boot start drivers (especially FileSystem Driver where Nt Kernel resides), reads Nt Kernel & HAL files and their dependencies, setups hypervisor (if needed), start boot code integrity feature, protect secure boot variables and data structures (if needed), and much other. Finally Winload prepares the system for loading NT Kernel: OslFwKernelSetup loader procedure calls GetMemoryMap EFI boot service, and store returned structure pointer (current EFI virtual to physical memory map) in a global variable. This structure mainly describes the entire EFI Framework code (and obviously all of its loaded modules). Loader then prepares virtual address space to map NT kernel by calling OslBuildKernelMemoryMap procedure. Now if a kernel debugger is attached, Windows loader code patches Interrupt Descriptor Table (with the aim to render it compatible for Kernel debugging), reinitializes debugger module (for transition from Windows loader code to Kernel code), and load Windows Kernel image symbols.
Next, OslFwpKernelSetupPhase1 does an important thing: it calls ExitBootService EFI function. ExitBootService is used to signal that OS is able to use its own functions to control entire System. ExitBootService discard any EFI services needed to boot machine and destroy entire EFI handle database, releasing all employed memory. From now on, all boot services pointers become invalid. Immediately after ExitBootService has done its job, Winload calls SetMemoryMap EFI runtime function with the aim to remap EFI runtime services in the rights virtual addresses (Kernel only Virtual Addresses).
OslFwpKernelSetupPhase1 returns execution to OslpMain: Loader has now quite done its job: if needed it launches previously initialized Hypervisor (HvlpLaunchHypervisor procedure), it finds right Nt Kernel (previously loaded) loader data table entry and finally transfers execution to “ntoskrnl.exe” module (OslArchTransferToKernel procedure).
describe the physical memory on the system, a pointer to the in-memory copy of the HARDWARE and SYSTEM registry hives, as well as various other information related to the boot processing performed until this point. Nt Kernel begins first of its 2 phases initialization in KiSystemStartup function. The purpose of phase 0 is to build the rudimentary structures required to allow the services needed in phase 1. KiSystemStartup begins with interrupts disabled, starts initialization of Boot Structures (like IDT, System call dispatcher, Spin locks, HAL module, Multiprocessor support and so on), debugger module, and then calls KiInitializeKernel one time per each found processor. KiInitializeKernel, if running on the boot CPU, continues system and HAL initialization (HalInitSystem). After HAL is completely operative, InitBootProcessor deal with rest of system components: Multiprocessor dispatching, Language table, Executive (ExInitSystem), Memory Manager (MmInitSystem), Security (SeInitSystem), Processes and Threads Manager (PsInitSystem), Power Management (PpInitSystem) and Plug And Play Manager. When control returns to KiInitializeKernel, the last step is to allocate the DPC stack for the current processor, after which control proceeds to the Idle loop.
Indeed PsInitSystem, has previously initialized the Process and Thread object types, and created System process tied with the first System thread (Phase1Initialization start function). This System thread job is to start Phase 1 of Nt Kernel initialization. Process manager initialization procedure has also created the Idle process. Idle thread become the one that has executed KiSystemStartup routine.
Phase 1 of Windows 8 NT Kernel proceeds quite like old release of OS (Windows 7) until the creation of first user-mode process. The reader who would like to investigate this topic (that in the author opinion is very interesting) can refers to Windows Internals book.Near the end of its execution, Phase1InitializationDiscard procedure calls StartFirstUserProcess to create first Session Manager user mode process (smss.exe). Session Manager process doesn’t use any Win32 APIs because the Windows subsystem isn’t executing when Smss launches. In fact, one of Smss’s first tasks is to start the Windows subsystem. Session Manager in turn, after has done a lot of other things, end up in starting the default the Windows initialization process (Wininit, lauched from session 0) and interactive logon manager process (Winlogon, launched from another session). Here is the point where things change: Windows 8 EFI Boot manager has been moved indeed to a user mode process, called “BootIm”.
The Windows logon process (%SystemRoot%Winlogon.exe) is the system process responsible to handle interactive user logons and logoffs, manages the secure attention sequence (SAS) keystroke and implements user logons (with the aim of lsass.exe, local security authentication server). Winlogon manage furthermore the creation of interactive windows stations and desktops.
Winlogon builds System desktop and System windows station, then it determine if it has to display Boot manager or not. Windows Boot manager works in the following way: Windows Setup, as said before, maps every EFI NVRAM Boot entry to particular BCD objects (each represented by a GUID). Windows 8 EFI BCD store is located in /EFI/Microsoft/Boot/BCD file in EFI System partition. Boot manager reads the list of supported OSs from “BcdBootMgrObjectList_DisplayOrder“ Bootmgr BCD element (in the reader doesn’t know what are BCD objects and elements he has to just Google them) and draws relative buttons reading each right BCD object with the aim to obtain Description, path and all data needed (the BCD I/O is done with COM+).
But how Winlogon process knows whether or not to display Boot Manager? It checks 2 BCD elements in BCD store: the first Winload BCD element (the important thing to note here is that Winload elements are totally different from Bootmgr ones) “BcdOSLoaderInteger_BootMenuPolicy” (0x250000c2) globally enables or disables new Metro Boot Manager; the second and most important one is by the way “BcdBootMgrObjectList_BootSequence” Bootmgr element (0x24000002). Originally this element is not present in Bootmgr BCD store. When user clicks on a particular OS button, Boot manager add “Boot Sequence” element and immediately reboot system. At the next reboot, if Winlogon found this Bootmgr BCD element, and determines that GUID contained in it corresponds to current OS GUID, skips Boot Menù and proceeds with User Authentication. If instead GUID doesn’t correspond to a directly supported OS, Bootmgr at early stages proceeds to release control to other unsupported OS, with the aid of EFI Boot Services. In this last case Winlogon is not loaded.If Winlogon found that Boot manager has to be showed, WinLogonBootShell routine creates, launches “bootim.exe” process and attaches it to System desktop. It then wait indefinitely on new process handle. When bootim exits, Winlogon analyzes its exit code: if equals to 0, it switches to logon desktop and proceeds to normally load Windows User Interface; if it equals to 0xBC2 (or 0x281 whether a recovery tool has been chosen) it adjusts its token privileges (adding SeShutdownPrivilege) and reboot system with a call to NtShutdownSystem. No other actions are required because “bootim.exe” has already modified Bootmgr BCD object, adding the Boot Sequence element.
UEFI From a Security Point of View
We just took a quick glance at the kernel changes in Windows 8 UEFI. Now it’s time to discuss another important topic: Security. Starting from Windows Vista and 7, x64 NT Kernel is a real Secure System. Many new features have been introduced with the aim to render the life of an attacker very hard like ASLR, Patchguard, Driver Signing Enforcement (for further inspections the reader is can read the author’s X64 university thesis available here. Windows 8 keeps all this security features and introduces also some others (like Virtualization and Secure Boot)… We won’t analyze here these new characteristics, instead we would like to try to exploit its EFI boot mechanism.After successfully download EFI EDK2, it’s possible to start writing a new EFI Application with an environment like Visual Studio 2008. Every EFI Applications starts in the following entry point:
EFI_STATUS EfiMain (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE * SystemTable)
{ }
As already said in the Introduction, all the needed EFI interfaces are in the SystemTable parameter. What we would like to do in this example is to create an EFI Bootkit able to bypass Windows 8 Driver Signing Enforcement and Patchguard (just for example, we could easily do whatever modification we want). After having analyzed rights NT Kernel, Winload and Bootmgr parts of our interest, we conclude that our bootkit code must do the following:
- Obtain a Loaded Image and a Device Path Protocol from our ImageHandle
- Locate rights Device Path utility protocols needed to proper build up the device path of Bootmgfw.efi Windows boot loader
- Load Windows Boot loader EFI application image, and obtain its memory mapping address
- At this point we have two possible choices:
- Patch some procedures of interest in Windows Bootmgr EFI application (like Archpx64TransferTo64BitApplicationAsm). Used hook is very small, composed only of a “JMP” or a “CALL” opcode. In this way we can divert bootmgr execution in the same manner as seen in the classical BIOS Bootkit before it pass control to Winload.
- Hook only one or more EFI Runtime function, for example ExitBootServices is a perfect choice. We know in fact that these procedures are called only in late boot stages. We can indeed avoid to forge Bootmgr code and hit only Winload before it transfers control to Nt Kernel. New Hooked EFI runtime service has to patch Nt kernel.
- Start Windows Boot loader Image (with StartImage EFI BootService facility)
Conclusions
In the brief analysis we made we have seen that hitting an UEFI system is still a quite easy task. In our bootkit develop process, we have showed only a small subset of kernel patch modality. We can indeed hit Kernel in a lot of others way (hooking Block I/O protocol Read function for example). Furthermore, for an attacker, it would be easy with EFI to disable bootkit if a debugger is detected for example (task done by intercepting Load Options of Winload and Nt Kernel). Sky is the limit.We’ve also found that writing an EFI Bootkit is even a simpler task than writing a BIOS Bootkit. While a BIOS bootkit requires a very large knowledge of Assembly language and Intel x86 architecture, an EFI bootkit is much easier to be developed because with the UEFI framework everything is abstracted from machine.
How to protect Systems? Some words about the new Microsoft Secureboot technology are required. SecureBoot is a brand-new Microsoft Security feature that, in cooperation with Intel and OEM Firmware producers, digital signs even the main Boot EFI Loader. Firmware has a digitally signed catalog of recognized Boot loaders SHA hashes. If startup EFI Application is not digitally signed, or if it has been changed, EFI Firmware refuse to boot. This fact obviously will increase whole platform’s security, though the biggest drawback is that it will render entire architecture closer, decreasing user freedom’s of choice. Anyway, the discussion whether or not SecureBoot is the right technology is outside the scope of current analysis
Ad eccezione delle conclusioni cui arrivi, splendido lavoro!!
L’idea che paradossalmente questa nuova tecnologia presti il fianco ad un più facile abuso mi mette personalmente i brividi.
Fortuna, cmq, che la “ricetta” si completa con la tecnologia SecureBoot che dovrebbe mitigare il rischio discusso nel tuo articolo.
PS: l’abilitazione della tecnologia SecureBoot richiede, se non vado errato, una scheda madre espressamente certificata per Windows 8 (es., le ASUS serie P8Z77) dato che sulle vecchie schede con chipset P67/Z68 sembrerebbe non esservi alcuna possibilità di abilitarlo…
Ciao NV25!
Grazie mille per i complimenti.
Purtroppo devo dirti che personalmente ritengo la tecnologia SecureBoot una scelta sbagliata, in quanto, come detto nell’articolo, implica una grossa limitazione alla liberta dell’utente… Esistono infatti altri metodi di protezione. Ad ogni modo però questa è SOLO una mia opinione personale.
L’abilitazione di tale teconologia in linea teorica richiederebbe solo un aggiornamento del firmware (vedi specifiche UEDK rev. 2.3.1), quindi non è per forza necessaria una certificazione preventiva (parlo sempre in linea teorica) da parte di MS. Ho personalmente provato in questi giorni una Asus P8Z77-V LE con un Core i7. Appena montata la scheda NON sopportava Secureboot, ma con un aggiornamento del Firmware (BIOS) mi sono ritrovato l’opzione attivabile dalle impostazioni di sistema. Come vedi quindi ti consiglierei di andare a vedere sul sito del produttore della tua motherboard e verificare la disponibilità di aggiornamenti… Inoltre ho scoperto che molte Motherboard UEFI supportano a livello nativo anche NTFS (anche se non è una specifica di Intel), attraverso un DXE driver…
Saluti,
Andrea
complimenti per l’analisi ….meno male che i miei sistemi sono tutti con bios e 64 bit. Chissà se il secure boot resisterà al contrattacco dei programmatori linux e dei produttori hardware….vedremo
ps nella conclusione, per chi possiede piattaforme uefi, si consiglia di proteggersi con il secure boot ,facendo delle ricerche non sono riuscito a capire se e’ abilitato di default o bisogna abilitarlo?
grazie
Rispetto ovviamente la tua opinione ma non mi trovi d’accordo:
in definitiva, il costo di una chiave dovrebbe essere irrisorio alla luce poi di quelle che sarebbero le realtà chiamate a pagare questa somma (se non erro, oltretutto, si parla davvero di pochissimi $)…
A patto che, ovviamente, non vi siano altre motivazioni più “profonde” che a voi, da ricercatori, vi fanno storcere il naso…
Per il discorso della possibilità di utilizzare la tecnologia SecureBoot collegata al firmware, me l’auguro veramente indipendentemente dal fatto che decida di adottare 8 come mio OS.
Detto questo, complimenti perchè siete davvero bravissimi!
PS:
se riuscite, e anche se i contenuti dei vostri articoli sono molto tecnici vanificando quello che a breve passo a dire, potete presentare i prossimi articoli in 2 lingue?
@ arnyreny:
a regola è l’utente che deve abilitarlo a patto ovviamente che la scheda madre supporti la tecnologia UEFI e che, come chiarito anche da Andrea, il firmware preveda questa opzione tra le sue impostazioni.
In automatico, cmq, sarà difficile…
Il grosso quesito tra i ricercatori, invece, cade proprio sul fatto che gli eventuali produttori OEM potrebbero in teoria decidere di attivare di default il SecureBoot. La logica conseguenza, attivando il SecureBoot di default, è che l’utente finale povrà utilizzare il proprio PC esclusivamente con il sistema operativo (o i sistemi operativi) per i quali il produttore OEM ha deciso di inserire la firma digitale nei propri database, senza possibilità di scelta.
In altre parole sarà il produttore OEM a forzare l’utente, senza possibilità alcuna di espandere il database del SecureBoot se non tramite aggiornamento rilasciato dal produttore OEM stesso.
PS: Grazie mille per i vari commenti ricevuti, continuate a leggerci 🙂
ah, ecco:
messa cosi’ suona già diversamente ed è comprensibile la perplessità…
La scelta, infatti, è interamente nelle mani del produttore di hardware (non avevo colto quest’aspetto, scusate)…
Figurati 🙂 Il campo Secure Boot è ancora un campo giovanissimo e le informazioni non sono poi così chiare come dovrebbero essere. Non essendoci ancora direttive concrete, né campi di applicazione reali, non si capisce bene come il mondo OEM si muoverà, in quale direzione.
Ciao! 🙂
@nv 25
Si si sono daccordo con te. È ovvio che se tale tecnologia potrà essere controllabile (nelle impostazioni del Firmware/BIOS per intenderci) dall’utente anche per me sarebbe una buona idea. Il mio “essere contro” è dato dal fatto che, sempre da quanto ne so, MS vuole che gli OEM abilitino di default Secureboot, senza lasciare all’utilizzatore modo di disattivarla. Pena il non ottenimento della certificazione per Win8. È questo che non ritengo per niente giusto.
Comunque sono daccordo con Marco, dovremmo aspettare ancora del tempo per vedere come verranno implementate applicazioni reali di Secureboot.
@ arnyreny
Esistono comunque anche dei bootkit per BIOS, anzi, i progetti originali erano su BIOS. L’unico problema è che sono MOLTO più difficili da sviluppare (devi infatti gestire almeno 3 memory models diversi)
Anche da parte mia un “Grazie mille” per i complimenti e i commenti ricevuti. Continuate a leggerci, in questo modo noi continueremo a scrivere. XD 🙂
Complimenti, bell’articolo!
Mi accodo però alla richiesta di nv25, sarebbe il massimo poter avere gli articoli anche in italiano.
L’inglese lo leggo abbastanza bene….ma in italiano sarebbe meglio e oltretutto “passabile” anche ad alcuni amici 😉
Grazie per il suggerimento, valuteremo sicuramente la richiesta 🙂 Purtroppo dobbiamo vedere quanto questa eventuale richiesta possa essere portata avanti, poiché riscrivere articoli in due lingue richiede un notevole dispendio di tempo.
Grazie ancora! 🙂
comprensibile.
Semmai una cosa:
vista la natura estremamente tecnica degli articoli che ne relegano la precisa comprensione solo a chi ha alle spalle solide basi, potreste offrire, al posto della traduzione letterale, una sorta di sintesi in coda agli articoli per facilitare la trasmissione dei messaggi…
C’è infatti una grossa domanda di sapere anche da parte di chi non ha mai percorso strade tecniche.
Buon lavoro!
Sicuramente alterneremo articoli più tecnici ad articoli molto più discorsivi e meno specialistici 🙂 Quindi in altre parole alcuni concetti, che magari tecnicamente non sono facilmente comprensibli, verranno riassunti anche in maniera più fluida e con molti meno tecnicismi.
Ciao!
Marco
chiedo scusa se continuo ad inquinare i commenti al vostro articolo con riflessioni estremamente materiali:
a proposito del secureboot, volevo solo far vedere l’impostazione che è presente nelle schede madri ASUS della serie P77:
http://i48.tinypic.com/2mxzyd.jpg
🙂
Unlike what you say, it is possible to write a BIOS boot-loader in C, see:
http://sourceforge.net/projects/gujin/
I’m sorry to contradict you but, that application (gujin) is only a framework… It is so written in C, but main parts are written in assembly language (look at “boot.c” file). For early startup stages is IMPOSSIBLE to use an high level language like C because Machine is in a “too uninitialized” state (and for a lot of others causes).
Regards,
Andrea
You can also mount the windows 8 EFI partition with a DOS console prompt:
mountvol z: /s
dir z:
But you can’t access it from explorer, only in the console.
Does from windows 8 OS level is it possible to invoke efi runtime services like getvariable gettime or reset calls . please let me know on how to achive it from windows application level.
No, generally is not possible because of the following reasons:
– EFI runtime services are ring0 services and are implemented in Kernel mode
– Windows isolate EFI Runtime pointers in “ntoskrnl.exe” code.
The only thing you can do is use “SetFirmwareEnvironmentVariableEx” Windows 8 API to set/get EFI firmware variables
Regards, Andrea
Tried latest build, it works a short time. After that, just bootloop. Even I cannot see logo of loading screen. It’s something like “restarting loop”.
My PC:
Motherboard: GA-MA78LMT-S2
CPU: AMD Phenom II X4 955 Black Edition 3.2 GHz
Memory: KINGSTON KHX1600C9D3B1K2/4GX 1600 MHz (2x2GB RAM)
HDD: SAMSUNG HD103SJ
GPU: Sapphire Radeon HD5670 512MB DDR5
My developer is trying to persuade me to move to .net from PHP.
I have always disliked the idea because of the costs. But he’s tryiong none the less.
I’ve been using WordPress on several websites for about a year and am worried about
switching to another platform. I have heard excellent things
about blogengine.net. Is there a way I can transfer all
my wordpress content into it? Any kind of help would be greatly appreciated!
Heya i am for the first time here. I found this
board and I find It truly useful & it helped me out a lot.
I hope to give something back and aid others like you helped me.
Understand that that is this beat- In which it you will most likely do a good deal to that it!
This is literally because reports can turn into shared
found in the clouds network. As a way to browse by simply PowerPoint’s film art gallery, click with the gallery icon around the stroking toolbar.
Very informative article, i am regular reader of your blog.
I noticed that your website is outranked by many
other blogs in google’s search results. You deserve to be
in top ten. I know what can help you, search in google for:
Omond’s tips outsource the work
Il secure boot è utilissimo per prevenire attacchi pre-load tipo Kon Boot, però deve essere enabled and locked altrimenti se è not locked si può disabilitarlo, potete vedere qui http://www.intelsecurity.com/resources/pr-bios-secure-boot-attacks-uncovered.pdf
Quindi dipende tutto da come noi configuriamo il UEFI perchè le porte per entrare ce ne sono diverse. Chiaro, per un server la virtualizzazione garantisce una solida protezione, ma vi ricordo che i metodi per ‘scappare’ o ‘escape from virtual machine’ all’interno dei processi del sistema ospite esistono, tipo questa https://goo.gl/2sdAa5. non ho seguito gli aggiornamenti e se ci sono variazioni, probabilmente sono bug gelosamente custoditi per chi li ha scoperti, solo hacker legati ai governi credo riescono a superare certe soluzioni, bisogna sempre tornare a chi produce, ai costruttori di queste tecnologie, e non è sempre detto che rivelare subito questi bug sia economicamente vantaggioso per la Intel.
Hello admin, i must say you have high quality articles here.
Your page can go viral. You need initial traffic only.
How to get it? Search for: Mertiso’s tips go
viral
I feel this is one of the most important information for me.
And i am happy reading your article. But should remark on some common issues, The web site taste is
ideal, the articles is in reality nice : D. Excellent job,
cheers