DOCSLIB.ORG

Intel Management Engine Deep Dive

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Intel Management Engine Deep Dive Intel Management Engine Deep Dive Peter Bosch About me Peter Bosch ● CS / Astronomy student at Leiden University ● Email : [email protected] ● Twitter: @peterbjornx ● GitHub: peterbjornx ● https://pbx.sh/ About me Previous work: ● CVE-2019-11098: Intel Boot Guard bypass through TOCTOU attack on the SPI bus (Co-discovered by @qrs) Outline 1. Introduction to the Management Engine Operating System 2. The Management Engine as part of the boot process 3. Possibilities for opening up development and security research on the ME Additional materials will be uploaded to https://pbx.sh/ in the days following the talk. About the ME About ME ● Full-featured embedded system within the PCH ○ 80486-derived core ○ 1.5MB SRAM ○ 128K mask ROM ○ Hardware cryptographic engine ○ Multiple sets of fuses. ○ Bus bridges to PCH global fabric ○ Access to host DRAM ○ Access to Ethernet, WLAN ● Responsible for ○ System bringup ○ Manageability ■ KVM ○ Security / DRM ■ Boot Guard ■ fTPM ■ Secure enclave About ME ● Only runs Intel signed firmware ● Sophisticated , custom OS ○ Stored mostly in SPI flash ○ Microkernel ○ Higher level code largely from MINIX ○ Custom filesystems ○ Custom binary format ● Configurable ○ Factory programmed fuses ○ Field programmable fuses ○ SPI Flash ● Extensible ○ Native modules ○ JVM (DAL) Scope of this talk Intel ME version 11 , specifically looking at version 11.0.0.1205 Platforms: ● Sunrise Point (Core 6th, 7th generation SoC, Intel 100, 200 series chipset) ● Lewisburg ( Intel C62x chipsets ) Disclaimer ● I am in no way affiliated with Intel Corporation. ● All information presented here was obtained from public documentation or by reverse engineering firmware extracted from hardware found “in the wild”. ● Because this presentation covers a very broad and scarcely documented subject I can not guarantee accuracy of the contents. ● The goal of this talk is to introduce people to the subject and introduce new tools, as such parts of the background information have been discovered/published by other researchers. Working with ME firmware images ● File format already extensively documented by Positive Technologies team (Mark Ermolov, Dmitry Sklyarov, Maxim Goryachy) ○ https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-File-System-Ex plained-wp.pdf ○ https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf ● Ready to use tools are available ○ Unpacks code, metadata: ■ ptresearch/unME11: Intel ME 11.x Firmware Images Unpacker ○ Unpacks code, metadata, config archives, config FS ■ platomav/MEAnalyzer: Intel Engine Firmware Analysis Tool ○ Unpacks/Repacks config archives ■ peterbjornx/meimagetool: Image manipulation tools for the Management Engine firmware ● Flash Image Tool contains XML descriptions of formats that can be retrieved using binwalk Understanding the ME: Firmware Partitions IDX NAME START SIZE TYPE ● FTPR/NFTP ○ Read only filesystem 1: [FTPR] 1000:A7000 Code ○ Contains firmware code 2: [FTUP] 110000:AC000 Code ○ Mounted on /bin 3: [DLMP] 0:0 Code ■ FTPR is recovery/normal boot partition. 4: [PSVN] E00:200 Data ■ NFTP binaries not used during recovery. 5: [IVBP] 10C000:4000 Data 6: [MFS ] A8000:64000 Data ● MFS 7: [NFTP] 110000:AC000 Code ○ Read/write filesystem 8: [ROMB] 0:0 Code ○ Contains configuration data, state 9: [FLOG] 1BC000:1000 Data ○ Initialized by Flash Image Tool 10: [UTOK] 1BD000:2000 Data ● FLOG -> Crash log 11: [ISHC] 0:0 Code ● UTOK -> Unlock Token ● ROMB -> ROM Bypass Understanding the ME: Code partitions ● Code Partitions contain modules ○ .mod files are loadable data/code (extension added by unME11) ○ .met files are metadata (Converted by unME11 to .txt) ● and the partition manifest ○ Filename : <partition>.man ○ Same general format as the metadata files, but has header prepended. Understanding the ME: Metadata ● Type-Length-Value store, entries are called extensions ● Converted to human readable form by unME11 ● Extensions: ○ Data module info Code module info ○ typedef struct { ○ Shared Library info ○ Process info uint32_t tag; ○ MMIO ranges uint32_t length; ○ Device file definitions } met_ext_t; ○ ...and more... See also: https://github.com/peterbjornx/meloader/blob/master/include/manifest.h Code verification chain ERRATUM (Added after talk): Intel Key hashes are in boot ROM, not fuses. Fuses only select which keys are actually trusted. Analysing a simple module ● The module file itself is a flat binary ● Metadata contains memory space info ○ Base load address is easy to find, and usually does not vary across modules within a single firmware version Missing code section? Missing code section? Missing data section? ME shared libraries ● No dynamic linker! ● Jump vector table with fixed address entry points ● Normal SysV i386 calling convention ME shared libraries ● syslib.mod ○ Entry point addresses vary per firmware version ○ Contains ■ hosted libc ■ libsrv ■ libheci ■ crypto library ■ … ● mask ROM ○ Entry point addresses fixed per chipset family (eg. SPT/LBG). ○ Base: 0x0000_1000 ○ Contains ■ freestanding libc ■ MMIO ■ miscellaneous utility routines Analysing a simple module ● The module file itself is a flat binary ● Metadata contains memory space info ○ Base load address is easy to find, and usually does not vary across modules within a single firmware version romlib_func_1000? syslib: clear_ctx Missing data section? C Runtime Startoff (crtso) Data sections ● Initialized data is appended to .rodata ● Before crtso even runs it is copied over to “.bss” ● Addresses can be inferred from code or metadata. Data sections ● Processes use flat 32-bit memory model ● Base address and various area sizes are stored in metadata. ● System library state resides in program-specified area. For a minimal working implementation of this, see: GitHub meloader repo: user/loader/map.c Familiar APIs ME provides many familiar POSIX APIs: ● libc: ○ read(), write(), close(), open(), fcntl(), ioctl(), select() ○ chdir(), stat(), ○ nearly everything in string.h ○ exit() ○ malloc(), free(), calloc() ● pthreads ○ pthread_create(), … ○ pthread_mutex_{lock,unlock} ○ ... Example driver main() function cookie = cookie_value; memset(&funcs, 0, 40); funcs.open = VdmDrvOpenCallback; ... libsrv callbacks funcs.select = VdmDrvSelectCallback; funcs.var_1C = sub_2D062; sven_init(7); ... event_fd = open("/dev/events", 2); POSIX file IO ... if ( srv_init(&g_srv_ctx, 24, &funcs, 0, 5) ) { libsrv init sven_catalog0i(2, 0x320033); goto LABEL_7; SVEN tracing } return srv_task(&g_srv_ctx); libsrv main loop Trace output: SVEN ● Intel Software Visible Event Nexus ● Trace print format strings are replaced by message IDs ○ These are reasonably stable for given platform/major version. ● Output goes to Trace Hub ○ Can be read back from host using memory trace ○ Can be read over debug interface EVEN WITHOUT UNLOCK ● Intel System Studio used to contain decoder and dictionary ○ GREEN dictionary is not very useful, only has a handful of messages ○ System Studio 2018 beta had a nearly complete one for LBG void sven_catalog<n>( int level, int id, ... ); void sven_printf( const char *fmt, ... ); void sven_printf_l( int level, const char *fmt, ... ); void sven_init( int mmio ); ME driver overview: device files ● Unix-style special files under /dev ○ One major number per module ○ Major, minor numbers and names specified in metadata ○ Drivers implement read(), write(), open(), close(), ioctl() for device files ○ Not just for device drivers, used for all high-level services. ● syslib contains convenient framework for implementing this ○ Implementation details hidden, just provide callbacks Ext#9 SpecialFileProducer[3]: major_number=0x0018 1: vdm_gde access_mode:0660, user_id:0x0074 group_id:0x0037 minor_number:00 2: vdm_pavp access_mode:0660, user_id:0x0074 group_id:0x018B minor_number:01 3: vdm_rosm access_mode:0660, user_id:0x0074 group_id:0x018C minor_number:02 ME driver overview: libsrv Framework for drivers, allows driver to only implement simple callbacks. ● open(),close() implementations return their status, ● read(),write(),ioctl() call a reply function with their result data and status. ● libsrv also allows handling hardware interrupts and power state changes. typedef int (*ioctl_cb)(int info, int fd, int gtid, int request, void *par); typedef int (*open_cb)( srvctx_t *ctx, int minor, int gtid, int *p_fd, void *ok); typedef int (*close_cb)( srvctx_t *ctx, int fd); int srv_task( srvctx_t *ctx ) int srv_init( srvctx_t *ctx, int major, srvfuncs_t *ops, srvcli_t *clients, int maxclients ) int srv_ioctl_reply( srvctx_t *ctx, int fd, int gtid, int ?, int status, void *p ) Accessing hardware What’s this? . Ext#8 MmioRanges[41]: ... CF base:F00A0000, size:00006000, flags:00000003 RAVDM D7 base:F5050000, size:00010000, flags:00000003 ICC_CONTROLLER DF base:F0090000, size:00006000, flags:00000003 FTPM Accessing hardware ● MMIOs are accessed through ROM library functions ● The MMIO ranges are defined in the manifest ● mmio = (mmio_list_index * 8) | 7 ○ Seem familiar to anyone? . Ext#8 MmioRanges[41]: ... CF base:F00A0000, size:00006000, flags:00000003 RAVDM D7 base:F5050000, size:00010000, flags:00000003 ICC_CONTROLLER DF base:F0090000, size:00006000, flags:00000003 FTPM Accessing hardware ● MMIOs are accessed through ROM library functions ● The MMIO ranges are defined in the manifest ● mmio = (mmio_list_index * 8) | 7 ○ Seem familiar to anyone? void write_seg_32(int mmio, int offset, int value); void write_seg_16(int mmio, int offset, short value); void write_seg_8 (int mmio, int offset, char value); int read_seg_32 (int mmio, int offset); int read_seg_16 (int mmio, int offset);
Load more

Recommended publications
  • How to Hack a Turned-Off Computer Or Running Unsigned
    HOW TO HACK A TURNED-OFF COMPUTER, OR RUNNING UNSIGNED CODE IN INTEL ME Contents Contents ................................................................................................................................ 2 1. Introduction ...................................................................................................................... 3 1.1. Intel Management Engine 11 overview ............................................................................. 4 1.2. Published vulnerabilities in Intel ME .................................................................................. 5 1.2.1. Ring-3 rootkits.......................................................................................................... 5 1.2.2. Zero-Touch Provisioning ........................................................................................... 5 1.2.3. Silent Bob is Silent .................................................................................................... 5 2. Potential attack vectors ...................................................................................................... 6 2.1. HECI ............................................................................................................................... 6 2.2. Network (vPro only)......................................................................................................... 6 2.3. Hardware attack on SPI interface ..................................................................................... 6 2.4. Internal file system .........................................................................................................
    [Show full text]
  • Issue #63, July 2000 Starting Our SIXTH Year in Publishing!
    Issue #63, July 2000 Starting our SIXTH year in publishing! 64a Page 1 Wed, Jul 2000 Cover by: Bill Perry [email protected] Published by My Mac Productions 110 Burr St., Battle Creek, MI 49015-2525 Production Staff Tim Robertson • [email protected] Publisher / Creator / Owner Editor-in-Chief Adam Karneboge • [email protected] Webmaster / Contributing Editor Roger Born • [email protected] Website Edior Barbara Bell • [email protected] Director, Public Relations •Jobs & Woz • Inspiration Artwork Created by: •Mike Gorman• [email protected] •Bill Perry• [email protected] •Tim Robertson• [email protected] •Adam Karneboge• [email protected] This Publication was created with: DOCMaker v4.8.4 http://www.hsv.tis.net/~greenmtn & Adobe Acrobat 4.0 http://www.adobe.com 64a Page 2 Wed, Jul 2000 Other Tools: Adobe Photoshop 5.5, 5.0.1 ColorIt! 4.0.1 BBEdit Lite ClarisWorks 5.0 Microsoft Word 98 GraphicConverter Snapz Pro 2.0 SimpleText Netscape Communicator 4.6.1 Internet Explorer 4.5 Eudora Pro 4.0.2 FileMaker Pro 4.0v3 QuickKeys 4.0 and the TitleTrack CD Player (To keep us sane!) Website hosted by Innovative Technologies Group Inc. http://www.inno-tech.com My Mac Magazine ® 1999-2000 My Mac Productions. All Rights Reserved. 64a Page 3 Wed, Jul 2000 http://www.inno-tech.com http://www.smalldog.com http://www.megamac.com 64a Page 4 Wed, Jul 2000 Advertising in My Mac = Good Business Sense! With over 500,000 website visits a month and thousands of email subscribers, You just can't go wrong! Send email to [email protected] for information.
    [Show full text]
  • Intel X86 Considered Harmful
    Intel x86 considered harmful Joanna Rutkowska October 2015 Intel x86 considered harmful Version: 1.0 1 Contents 1 Introduction5 Trusted, Trustworthy, Secure?......................6 2 The BIOS and boot security8 BIOS as the root of trust. For everything................8 Bad SMM vs. Tails...........................9 How can the BIOS become malicious?.................9 Write-Protecting the flash chip..................... 10 Measuring the firmware: TPM and Static Root of Trust........ 11 A forgotten element: an immutable CRTM............... 12 Intel Boot Guard............................. 13 Problems maintaining long chains of trust............... 14 UEFI Secure Boot?........................... 15 Intel TXT to the rescue!......................... 15 The broken promise of Intel TXT.................... 16 Rescuing TXT: SMM sandboxing with STM.............. 18 The broken promise of an STM?.................... 19 Intel SGX: a next generation TXT?................... 20 Summary of x86 boot (in)security.................... 21 2 Intel x86 considered harmful Contents 3 The peripherals 23 Networking devices & subsystem as attack vectors........... 23 Networking devices as leaking apparatus................ 24 Sandboxing the networking devices................... 24 Keeping networking devices outside of the TCB............ 25 Preventing networking from leaking out data.............. 25 The USB as an attack vector...................... 26 The graphics subsystem......................... 29 The disk controller and storage subsystem............... 30 The audio
    [Show full text]
  • Thinkcentre M58p with Intel AMT White Paper
    ThinkCentre M58p with Intel Active Management Technology First Edition (October 2008) Contents About this document . .v Intel ME configuration. .10 Intel AMT setup and configuration . .13 Driver description . .18 Chapter 1. Introduction to Intel vPro and Intel AMT technology . .1 Chapter 6. Web user interface . .19 Acronyms . .1 Access the Web user interface . .19 Provision the Intel AMT system . .19 Chapter 2. Lenovo ThinkCentre Logging onto the client system . .19 computer equipped with Intel AMT Function in Web user interface . .20 technology . .3 Appendix A. Two examples of Intel Chapter 3. ISV solution introduction . .5 AMT setup and configuration: SMB mode and enterprise mode . .23 Chapter 4. Main features of computers Intel AMT setup and configuration steps - SMB built with Intel AMT . .7 mode . .23 Intel AMT setup and configuration steps - Enterprise mode . .23 Chapter 5. Intel AMT setup and configuration based on Lenovo Appendix B. Default configuration ThinkCentre M58p . .9 values for Intel MEBx . .25 Associated Intel AMT setup and configuration in BIOS . .9 Intel MEBx setup and configuration . .10 Appendix C. Notices . .27 Entering MEBx configuration user interface. .10 Trademarks . .28 Changing Intel ME password . .10 iii iv ThinkCentre M58p with Intel AMT White Paper About this document ® This document provides information about the application of the Intel Active ® ® Management Technology (Intel AMT) for Lenovo ThinkCentre M58p desktop computers. It provides a step-by-step approach to successfully use the Intel AMT technology. This document is intended for trained IT professionals, or those responsible for deploying new computers throughout their organizations. The readers should have basic knowledge of network and computer technology, and be familiar with these terms: TCP/IP, DHCP, IDE, DNS, Subnet Mask, Default Gateway, and Domain Name.
    [Show full text]
  • AMT Implementation on a UTC RETAIL 3170 POS
    VICTOR , NY – CLEVELAND , OH – SCOTTSDALE , AZ AMT Implementation on a UTC RETAIL 3170 POS Controlling POS systems using Intel AMT Features UTC RETAIL 1 November 19, 2012 11823029A VICTOR , NY – CLEVELAND , OH – SCOTTSDALE , AZ Scope The document was written for use by UTC RETAIL 3170 POS customers to enable the AMT feature in the 3170 hardware. It includes step-by-step instructions to configure a 3170 system allowing AMT to be examined and exercised. Background AMT is a feature of the Intel® vPro™ Technology. From the Intel website: “Intel® vPro™ technology is a set of security and manageability capabilities built into the 3rd generation Intel Core vPro processor family, the Intel Xeon processor E3-1200 product family, Intel® chipsets, and network adapters.” Also, vPro: “Uses Intel® Active Management Technology (Intel® AMT) to facilitate remote management of platform applications, even when the platform is turned off, as long as the platform is connected to a power line and network.” A discussion of vPro is beyond the scope and purpose of this document. Full vPro implementation requires a CPU upgrade from the CPU included in a base 3170 and an IT staff that has the resources to dedicate itself to implementation and use. Every 3170 has the Standard AMT . The security features enabled by AMT require a certain level of Intel CPU, an Intel AMT enabled chipset and an Intel network interface IC. These components all exist in the 3170. To use the Standard AMT , the 3170 must have its power cord plugged into an active power plug, must be connected to an active network and its AMT system must be configured.
    [Show full text]
  • The Strangeness Magnetic Moment of the Proton in the Chiral Quark Model
    The Strangeness Magnetic Moment of the Proton in the Chiral Quark Model L. Hannelius, D.O. Riska Department of Physics, University of Helsinki, 00014 Finland and L. Ya. Glozman Institute for Theoretical Physics, University of Graz, A-8019 Graz, Austria Abstract The strangeness magnetic moment of the proton is shown to be small in the chiral quark model. The dominant loop contribution is due to kaons. The K∗ loop contributions are proportional to the difference between the strange and light constituent quark masses or −2 mK∗ and therefore small. The loop fluctuations that involve radiative transitions between K∗ mesons and kaons are small, when the cut-off scale in the loops is taken to be close to the chiral symmetry restoration scale. The net loop amplitude contribution to the strangeness magnetic moment of the proton is about −0.05, which falls within the uncertainty range of arXiv:hep-ph/9908393v2 24 Aug 1999 the experimental value. 0 1. Introduction The recent finding by the SAMPLE collaboration that the strangeness magnetic moment s 2 2 of the proton is small, and possibly even positive [1] (GM (Q = 0.1 GeV )=0.23 ± 0.37) was unexpected in view of the fact that the bulk of the many theoretical predictions for this quantity are negative, and outside of the experimental uncertainty range (summaries are given e.g. in refs. [2, 3, 4]). A recent lattice calculation gives −0.36 ± 0.20 for this quantity [5], thus reaffirming the typical theoretical expectation, while remaining outside of the uncertainty range of the empirical value.
    [Show full text]
  • An Introduction to Morphos
    An Introduction to MorphOS Updated to include features to version 1.4.5 May 14, 2005 MorphOS 1.4 This presentation gives an overview of MorphOS and the features that are present in the MorphOS 1.4 shipping product. For a fully comprehensive list please see the "Full Features list" which can be found at: www.PegasosPPC.com Why MorphOS? Modern Operating Systems are powerful, flexible and stable tools. For the most part, if you know how to look after them, they do their job reasonably well. But, they are just tools to do a job. They've lost their spark, they're boring. A long time ago computers were fun, it is this background that MorphOS came from and this is what MorphOS is for, making computers fun again. What is MorphOS? MorphOS is a fully featured desktop Operating System for PowerPC CPUs. It is small, highly responsive and has very low hardware requirements. The overall structure of MorphOS is based on a new modern kernel called Quark and a structure divided into a series of "boxes". This system allows different OS APIs to be used along side one another but isolates them so one cannot compromise the other. To make sure there is plenty of software to begin with the majority of development to date has been based on the A- BOX. In the future the more advanced Q-Box shall be added. Compatibility The A-Box is an entire PowerPC native OS layer which includes source and binary compatibility with software for the Commodore A500 / A1200 etc.
    [Show full text]
  • Basics of Qcd Perturbation Theory
    BASICS OF QCD PERTURBATION THEORY Davison E. Soper* Institute of Theoretical Science University of Oregon, Eugene, OR 97403 ABSTRACT (•• i This is an introduction to the use of QCD perturbation theory, em- I phasizing generic features of the theory that enable one to separate short-time and long-time effects. I also cover some important classes of applications: electron-positron annihilation to hadrons, deeply in- elastic scattering, and hard processes in hadron-hadron collisions. •Supported by DOE Contract DE-FG03-96ER40969. © 1996 by Davison E. Soper. -15- 1 Introduction 2 Electron-Positron Annihilation and Jets A prediction for experiment based on perturbative QCD combines a particular In this section, I explore the structure of the final state in QCD. I begin with the calculation of Feynman diagrams with the use of general features of the theory. kinematics of e+e~ —> 3 partons, then examine the behavior of the cross section The particular calculation is easy at leading order, not so easy at next-to-leading for e+e~ —i- 3 partons when two of the parton momenta become collinear or one order, and extremely difficult beyond the next-to-leading order. This calculation parton momentum becomes soft. In order to illustrate better what is going on, of Feynman diagrams would be a purely academic exercise if we did not use certain I introduce a theoretical tool, null-plane coordinates. Using this tool, I sketch general features of the theory that allow the Feynman diagrams to be related to a space-time picture of the singularities that we find in momentum space.
    [Show full text]
  • Introduction to Storage and Software Systems for Data Analysis
    INTRODUCTION TO STORAGE AND SOFTWARE SYSTEMS FOR DATA ANALYSIS Bob Jacobsen University of California, Berkeley, USA Abstract The Storage and Software Systems for Data Analysis track discusses how HEP physics data is taken, processed and analyzed, with emphasis on the problems that data size and CPU needs pose for people trying to do experimental physics. The role of software engineering is discussed in the context of building large, robust systems that must at the same time be accessible to physicists. We include some examples of existing systems for physics analysis, and raise some issues to consider when evaluating them. This lecture is the introduction to those topics. 1. INTRODUCTION Many modern high-energy physics (HEP) experiments are done by collaborations of hundreds of people. Together, these groups construct and operate complex detectors, recording billions of events and terabytes of data, all toward the goal of “doing physics”. In this note, we provide an introduction to how we currently do this, and raise a number of issues to be considered when thinking about the new systems that are now being built. 2. SCALE OF THE EXPERIMENTS BaBar, CDF and D0 are examples of the large experiments now taking or about to take data in a collider environment. The collaborations that have built these experiments contain 300 to 600 members with varying levels of activity. Almost everybody is considered “familiar” with using computing to do their work, but only a small fraction of the collaboration can be considered as computing professionals. Some of these can even be considered world-class experts in large scale computing.
    [Show full text]
  • Quarkxpress 8.0 Readme Ii
    QuarkXPress 8.0 ReadMe ii Contents QuarkXPress 8.0 ReadMe....................................................................................................3 System requirements.............................................................................................................4 Mac OS.....................................................................................................................................................4 Windows...................................................................................................................................................4 Installing: Mac OS................................................................................................................5 Performing a silent installation.................................................................................................................5 Preparing for silent installation....................................................................................................5 Installing.......................................................................................................................................5 Performing a drag installation..................................................................................................................5 Adding files after installation...................................................................................................................6 Installing: Windows..............................................................................................................7
    [Show full text]
  • Sok: Hardware Security Support for Trustworthy Execution
    SoK: Hardware Security Support for Trustworthy Execution Lianying Zhao1, He Shuang2, Shengjie Xu2, Wei Huang2, Rongzhen Cui2, Pushkar Bettadpur2, and David Lie2 1Carleton Universityz, Ottawa, ON, Canada 2University of Toronto, Toronto, ON, Canada Abstract—In recent years, there have emerged many new hard- contribute to lowering power consumption, which is critical ware mechanisms for improving the security of our computer for resource-constrained devices. systems. Hardware offers many advantages over pure software Furthermore, hardware is the Root of Trust (RoT) [48], as approaches: immutability of mechanisms to software attacks, better execution and power efficiency and a smaller interface it bridges the physical world (where human users reside) and allowing it to better maintain secrets. This has given birth to the digital world (where tasks run as software). To securely a plethora of hardware mechanisms providing trusted execution perform a task or store a secret, the user trusts at least part of environments (TEEs), support for integrity checking and memory the computer hardware. safety and widespread uses of hardware roots of trust. Dedicated hardware security support has seen its prolif- In this paper, we systematize these approaches through the lens eration since the early days of computers. It can take a of abstraction. Abstraction is key to computing systems, and the interface between hardware and software contains many abstrac- straightforward form as discrete components to assist the tions. We find that these abstractions, when poorly designed, can CPU, ranging from the industrial-grade tamper-responding both obscure information that is needed for security enforcement, IBM Cryptocards (e.g., 4758 [37]), Apple’s proprietary secure as well as reveal information that needs to be kept secret, leading enclave processor (SEP [84]) for consumer electronics, to the to vulnerabilities.
    [Show full text]
  • SECURITY INFORMATION SUMMARY the Latest Security Information on Dynabook PC Products
    SECURITY INFORMATION SUMMARY The latest security information on dynabook PC products. THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE. ”INTEL” IS A TRADEMARK OF INTEL CORPORATION IN THE U.S. AND OTHER COUNTRIES. OTHER NAMES AND BRANDS MAY BE CLAIMED AS THE PROPERTY OF OTHERS. Last modified: June 22, 2021 © 2021 Dynabook Europe GmbH Security Information Summary Contents [ 2020 / 2021 ] DATE* VENDOR ID VULNERABILTY DESCRIPTION DATE* VENDOR ID VULNERABILTY DESCRIPTION June 22, 2021 Intel-SA-00545 Intel® Rapid Storage Technology Advisory Sep 16, 2020 Intel-SA-00337 Intel® Wireless Bluetooth® Advisory Intel-SA-00520 Intel® Wireless Bluetooth® and Killer™ Bluetooth® Advisory Intel-SA-00355 Intel® PROSet/Wireless WiFi Software Advisory Intel-SA-00506 Intel Unite® Client for Windows Advisory Aug 05, 2020 Intel-SA-00366 Intel® Innovation Engine Advisory May 18, 2021 Intel-SA-00473 Intel® PROSet/Wireless WiFi , Intel vPro® CSME WiFi and Killer™ WiFi Advisory Jul 21, 2020 Intel-SA-00322 2020.1 IPU - BIOS Advisory2020.1 IPU - BIOS Advisory Intel-SA-00455 Intel® SGX Platform Advisory Intel-SA-00320 Special Register Buffer Data Sampling Advisory Mar 29, 2021 Intel-SA-00448 Intel® PROSet/Wireless WiFi and Killer™ Driver Advisory Intel-SA-00295 2020.1 IPU – Intel® CSME, SPS, TXE, AMT, ISM and DAL Advisory Intel-SA-00438 Intel® Graphics Drivers Advisory Apr 15, 2020 Intel-SA-00338 Intel® PROSet/Wireless WiFi Software Advisory Intel-SA-00404 Intel® AMT and Intel® ISM Advisory Mar 30, 2020 Intel-SA-00330 Intel® Snoop Assisted L1D Sampling
    [Show full text]