VivienneVMM is a stealthy debugging framework implemented via an Intel VT-x hypervisor. The driver exposes a hardware breakpoint control interface which allows a user mode client to set and clear breakpoints. These breakpoints are invisible to the guest.
PG-compatible feature list:
Syscall hooks via MSR_LSTAR
Kernel inline hooks
Kernel page substitution
Kernel page EPT TLB splitting
Supported hardware: Intel processors with VT-x and EPT support
Supported platforms: Windows 7 – Windows 10, x64 only
Today Dimitri John Ledkov of Intel’s Linux team announced the availability of Clear Containers for Docker Engine for multiple OSes. This enables executing existing Docker applications in the secure and fast Clear Containers environment. The experimental source code is based on the Docker 1.8.1 upstream release. The primary host platform is Clear Linux Project for Intel Architecture, version 4000 or better, and binaries for multiple OSes, including: CentOS, Scientific Linux, Fedora, openSUSE, Debian, and Ubuntu.
The Clear Linux Project for Intel Architecture is a distribution built for various cloud use cases in order to showcase the best of Intel Architecture technology, from low-level kernel features to complex applications that span across the entire OS stack. We’re putting emphasis on power and performance optimizations throughout the operating system as a whole. Clear Containers leverage the isolation of virtual-machine technology along with the deployment benefits of containers. The security of containers is improved by using Intel Virtualization Technology (Intel VT). The optimization of key components results in slimmer, simpler, safer and substantially speedier virtualization.
For more information, see the full announcement on the archives of the dev list.
Wow, I wasn’t aware of Intel’s Kernel-Guard Technology (KGT) for Linux, until today. 😦
As found on the Twitter feed of Alex Bazhaniuk (@ABazhaniuk):
Intel Kernel-Guard Technology (Intel KGT) is a policy specification and enforcement framework for ensuring runtime integrity of kernel and platform assets. The Intel® KGT framework allows policy writers to specify:
* Which OS/platform resources to monitor
* Actions to take when the monitored resource is accessed
* A policy
A policy can be specified at build-time (embedded in the code), boot-time (such as through grub module), or at runtime (via configfs and script), and is enforced by an outside-OS component. The Intel KGT framework, along with an appropriate policy, can be used to achieve immutability and runtime integrity of critical resources such as kernel code pages, kernel pagetable mappings, kernel interrupt descriptor table (IDT), control registers (CRs), MSRs, and MMIO regions. The Intel KGT is based on xmon, which is a thin VT-x component. Xmon runs in vmx-root (ring -1), de-privileges the OS, and uses VTx controls to trap access to specified resources and enforce policy specified actions. Xmon is not limited to using VT-x and, in the future, is expected to incorporate other CPU and platform features in addition to VT-x to enforce policy.
Their Overview page gives a good introduction.
It looks like the last release was August 7th, with Intel TXT/tboot support:
Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine
Xiaoyu Ruan (Intel)
APress Open, 2014
ISBN: 978-1-4302-6571-9 and 978-1-4302-6572-6
The book reveals the technical details of Intel’s security and management engine, with the focus on the architecture and design of its firmware infrastructure. For the past several years, the engine has been serving as the base of many security technologies included in Intel platforms. This book talks about the various Intel boot security technologies, focusing on the Intel Management Engine (ME) and how ME interacts with the other Intel security technologies at the hardware, firmware, and OS-levels. Much of the book focuses on boot integrity, process isolation, and various Intel hardware-based protections. The book gives good background on how a chip vendor deals with hardware/firmware hybrid solutions, as well as how recent security researcher’s attacks against Intel have impacted their product designs.
It is from APress Open, not Intel Press. But it does read like an book-length whitepaper by Intel, explaining most of Intel’s hardware/firmware security offerings, with some crypto background on some of the designs. The author, Xiaoyu Ruan, is a security researcher with the Platform Engineering Group at Intel Corporation, and is responsible for designing cryptography infrastructure and security applications for Intel’s security and management engine.
The Management Engine (ME) is sometimes just called a management engine, later is starts to become called the security engine:
“Depending on the end product in which the embedded engine resides, the engine is denominated differently. For the embedded system shipped with computing devices featuring Intel Core family microprocessors, it is called the management engine. For the embedded system shipped with computing devices featuring the Intel Atom system-on-chip (SoC), it is called the security engine. Note that not all Atom platforms use the security engine introduced in this book.”
The list of Intel security technologies and acronyms discussed in this book is extensive:
* Intel Security Security Engine, aka Management Engine (ME)
* Intel Boot Guard
* Intel Trusted Execution Technology (TXT)
* Intel Software Guard Extensions (SGX)
* Intel Identity Protection Technology (IPT)
* Intel Active Management Technology (AMT)
* TCG’s TPM
* Intel Virtualization Technology
* Intel Anti-Theft Technology
* Intel management engine BIOS extension (MEBX)
* Host-Embedded Controller Interface (HECI)
* Intel EPID (Enhanced Privacy Identification)
* Intel PAVP (Protected Audio And Video Path)
* Intel Platform Trust Technology (PTT)
The discussion on Boot Guard goes into detail as to how it works with Verified Boot and Measured Boot, including use of TPM on Measured Boot. There is a comparison of these various Intel HW/FW security technologies to ARM’s TrustZone. There is discussion on how some of these security technologies are used for “Rights Protection” (DRM), including Intel Sandy Bridge hardware protection technology for UltraViolet-based video content. The author talks about WS-Management interfaces, as well as pre-WSMAN SOAP-based External Operations Interface (EOI) interfaces to engine. There is discussion of the OS-level drivers used to communicate with ME, including Baseboard Management Controllers (BMC) and Out-of-bound traffic to systems via ME on servers. There is some clarification of ME -vs- AMT -vs- vPro, as well as ME use of TPM (discrete or software-based).
The engine has many features. It includes a secure timer, a protected real-time clock in the engine. It can be used for secure storage:
“A partition of the SPI flash chip is reserved for storing the security and management engine’s nonvolatile data. As the flash size is very limited, the files cannot be too large. Generally speaking, the storage is intended for keys and credentials, such as device private keys, AMT passwords, and so on. It is not designed for storing bulk data such as video frames or network traffic.”
Regarding debugging, production parts have fewer silicon diagnostic abilities, but the ME “offers two ways—debug messaging and special production-signed firmware—to facilitate debugging on production parts.”
The book helps enlighten you as to some of the reasons your firmware is generating network traffic, eg:
“To get the current date/time information, the EPID manager requests a real-time OCSP (Online Certificate Status Protocol) response from a trusted OCSP server, which was endorsed by Intel.”
“As an embedded system, the security and management engine does not have convenient network access. Therefore, the SIGMA protocol is designed such that the platform does not communicate with the OCSP server directly but only connects with the verifier.”
The engine adds new crypto protocols, new PKIs, for cryptographers to enjoy. I’m not sure what code outside the engine uses this yet.
Intel EPID (Enhanced Privacy Identification) was added to the management engine:
“Intel’s chipset series 5 (released in 2008) and newer natively support the EPID platform functionality. A unique private key, in its encrypted form, is burned into security fuses for every chipset part during manufacturing. For this EPID ecosystem, Intel acts as the EPID authority. Using the private key, the security and management engine proves that it is a genuine Intel platform, and hence eligible for premium services that are only available for Intel platforms.
Yet it sounds like there is hardware and knowledge available for attackers to obtain to sidestep some of this technology, and rubberhoses can trump NDAs:
“The implementation of the security and management engine attempts to ensure that the EPID key cannot be revealed from a device without special and expensive equipment and advanced expertise in hacking.”
The engine includes a Dynamic Application Launcher (DAL). One thing that jumped out to me about the ME is that it runs Java code from the hard drive! After spending a lot of time explaining why ME is isolated and secure from third-party code, the author mentions two ME limitations: not enough space on Flash for more ME-based firmware apps, and inability of third parties to use the ME.
“To address these drawbacks to some extent, newer versions of the security and management engine firmware include a module called the Dynamic Application Loader, or DAL for short. As indicated by the name, the DAL allows the engine to dynamically load and execute Java applets at runtime. The applets are not stored on the flash, but on the host’s hard drive. With the DAL, the embedded engine is no longer a closed-door realm. The engine is now open to more flexibility and possibilities to be explored.”
“The DAL is essentially a Java virtual machine that enables the operation of Java applets in the security and management engine’s firmware environment. The Java applets in bytecode implement their designed functionalities that can be executed in the firmware.”
“Depending on product, the IPT may be implemented as an applet for the engine’s DAL feature, or a native firmware module on the engine. If the firmware supports DAL, for example, on most Intel Ultrabook models, then the IPT implementation will be distributed in a Java applet. On certain smartphones and other products where the DAL is not built into the engine’s firmware, the IPT will be a native firmware ingredient that is loaded from the system’s flash chip. The firmware design and functionalities of the IPT component are identical for both variants.”
Interestingly, it sounds like the management engine uses some open source code, but doesn’t mention what code is used, only that the TLS used in AMT is not ported from OpenSSL:
“In the security and management engine’s firmware, only a small fraction originates from open-source domain, and it is only used in modules that do not assume security responsibilities. For example, the TLS implementation in the AMT firmware application is not ported from OpenSSL and hence not affected by OpenSSL’s vulnerabilities such as the Heartbleed. The validation of the engine does not discriminate between open source and closed source. Thorough testing is performed against open-source software used by the engine.
(Tianocore’s UEFI implementation of Secure Boot requires the use of libOpenSSL to implement the crypto. OEMs/IBVs could replace that with another library, and may be doing so, but there’s no docs to clarify this.)
In some ways, I look at Intel platforms a bit differently now. In the beginning, it was simple (and insecure): BIOS loaded MS-DOS, then you had a shell, and you ran an app, with the occasional service (TSR). These days, OSes are much more complex, BIOS was replaced by UEFI, which itself a new OS added to stack. The mangement engine and SMM are two background layers to the stack as well. Before reading this, I really thought of the non-UEFI, non-SMM, non-TPM, non-IPMI background interactions were infrequent. But the management engine looks like a significant new addition to the stack, running it’s own drivers, virtual TPMs, ISV Java code off the hard disk, it sounds like yet-another OS (er, platform) added to the stack. It makes sense if you are Intel, I suppose. But I feel uneasy about how complex HW/FW is becoming… Some of these technologies are going to get in the way of General Purpose Computing, helping some companies make disposable systems where vendors dictate all FW/OS choices, and you cannot install your own OS. On the other hand, security issues need addressing, somehow. Boot system, start SMM, start background ME OS, then start background UEFI OS, then load user’s main OS, …that’s a lot of platforms in one stack.
In summary, I liked this book. Unlike my blog posts, the book was well-written. 🙂 The author knows a LOT about Intel security technologies. I learned a lot. If you care about firmware security on Intel platforms, you should get this book. You might be able to avoid the book if you spend a lot of time researching the various technologies off Intel’s web sites and online, but this book does a great job of integrating all of these technologies into one source. I hope to see a 2nd edition once Intel adds more features to the engine.
Today, AMI announced DuOS, aka AMIDuOS, a new OS that runs Windows (v7 or v8) along with Android v5, users are able to use both OSes without rebooting. AMIDuOS is now in Beta for download; it is a commercial product, not open source or freeware: it cost $10 for a lifetime license – with a 30–day free trial. A few excerpts from their press release are below.
“AMIDuOS is a revolutionary new concept that brings the functionality, depth and fun of the Android experience to Microsoft Windows devices. It runs on nearly any Windows 7 or 8 PC or tablet device for fast, easy switching between Windows and Android environments – without the need to dual boot! Usage of AMIDuOS is quite similar to Android device. You just have to download and install, You got your Android device on Windows PC.”
“AMIDuOS runs on any modern Windows Desktops, Laptops, Tablets and 2-in-1 Devices. System requirements: x86 Processor. 32/64-bit of Windows 7/8/8.1. OpenGL 3.0 and above. Hardware Virtualization Technology should be enabled in BIOS. Minimum 3GB of System RAM. Minimum 2GB of Hard disk free space.”
“Now, users have access to the full library of Android apps on their Windows device – running either full-screen or in a window, while retaining the ability to switch over to their traditional Windows apps at any time – with no need to reboot. AMIDuOS is truly the best of both worlds. AMI has utilized its decades of expertise to build hardware acceleration support into the app, and support direct hardware access whenever possible. Emulation is only used when needed – otherwise code runs natively. This, plus 3D acceleration support, means incredible performance so games and video-intensive apps run smoothly and quickly. Since AMIDuOS can access native PC hardware and drivers, apps can take advantage of the touchscreen, sensors, peripherals, GPS, camera and more to deliver a fully immersive Android experience. AMI has tested AMIDuOS with over 4,000 apps and is continually releasing updates to improve compatibility.
“In order to enjoy the full performance of DuOS, Virtualization Technology (VT-x) should be enabled in BIOS. Please ensure that your System supports Virtualization Technology.”