A Multi-core Security Architecture Based on EFI - Springer Link

A Multi-core Security Architecture Based on EFI Xizhe Zhang1 , Yong Xie1 , Xuejia Lai1 , Shensheng Zhang1 , and Zijian Deng2 1

Department of Computer Science and Engineering, Shanghai Jiao Tong University, Shanghai, 200240, China 2 Lab of Information Security and National Computing Grid, Southwest Jiaotong University, Chengdu, 610031, China {zhangxizhe, vickyoung, sszhang}@sjtu.edu.cn, [email protected], [email protected]

Abstract. This paper presents a unique multi-core security architecture based on EFI. This architecture combines secure EFI environment with insecure OS so that it supports secure and reliable bootstrap, hardware partition, encryption service, as well as real-time security monitoring and inspection. With this architecture, secure EFI environment provides users with a management console to authenticate, monitor and audit insecure OS. Here, an insecure OS is a general purpose OS such as Linux or Windows in which a user can perform ordinary jobs without obvious limitation and performance degradation. This architecture also has a unique capability to protect authentication rules and secure information such as encrypted data even if the security ability of an OS is compromised. A prototype was designed and implemented. Experiment and test results show great performance merits for this new architecture.

1

Introduction

Extensible Firmware Interface (EFI) [1] defines a set of interfaces between the operating system (OS) and the platform firmware. These interfaces together provide a standard environment for booting an OS. EFI was designed to modernize firmware technology and overcome the limitations of a legacy BIOS. Management of platform firmware can be made effectively by using EFI directly. Multi-core architecture has a single processor package that contains two or more processor ”execution cores” or computational engines [2]. Accordingly, multi-core platform can provide more processing resources. In recent years, multi-core system has evolved from enterprise servers to desktop computers. PC users are greatly beneficial from this trend. With these advantages, more and more computers stay online 24 hours a day. As long as the world depends on internet, security is always a critical issue. Our desktop computers may store very important information such as emails, documents, pictures and videos. It may be installed with enormous uncertified programs. In such a typical multicore environment, all private information is only separated and protected from the dangerous outside world through a coarse OS fence. R. Meersman and Z. Tari et al. (Eds.): OTM 2007, Part II, LNCS 4804, pp. 1675–1687, 2007. c Springer-Verlag Berlin Heidelberg 2007 

1676

X. Zhang et al.

Passwords, encryption algorithms, anti-virus software and firewall all depend on a Trusted Computing Base (TCB) within an OS. When the OS is attacked by malicious software, security applications may fail and the system logs may become lost. Meanwhile, users may still be unconscious until serious destruction is happened. The damage can be catastrophic since all devices in the system are controlled by the OS. 1.1

Motivation

Motivated by the above concerns, a multi-core security architecture (MCSA) came into our vision. This architecture can provide a TCB for EFI running on Bootstrap Processor (BSP). It can monitor the activities of an OS running on Application Processor (AP) in real time manner. Computers can be physically partitioned according to various devices. Users will be notified immediately when the OS is being attacked. Users can also transparently monitor activities on a production OS without performance degradation. Meanwhile, EFI takes the responsibility to keep the system secure. Multi-core security architecture (MCSA) addresses many flaws in traditional security architecture and provides an extensible secure option for future computing environment. 1.2

Contribution

Main contributions of this paper are: • To propose a novel multi-core security architecture which is different from network security architecture, distributed system security architecture and virtual machine security architecture. Related works of these architectures will be discussed in section 6. • To present the design and implementation of a prototype system for proposed architecture. The system enables users to monitor OS activities and to dynamically inspect OS memory such as display memory, kernel code, or data memory. • To virtualize devices for insecure OS and fill the gap of physical partition and greatly reduce performance overhead of traditional virtual machine security monitor. • Multi-core security architecture is an on-the-shelf technique based on EFI. It is compatible with today’s PC motherboard without any additional hardware. 1.3

Organization

The remainder of the paper is structured as follows: Section 2 briefly introduces EFI architecture. Section 3 presents multi-core security architecture (MCSA), and discusses some mechanisms which the new system can achieve. section 4 addresses some design and implementation issues of the prototype system. While

A Multi-core Security Architecture Based on EFI

1677

section 5 interprets and analyzes the performance tests. In section 6 a summary is given for some related work by other researchers. Finally, section 7 concludes the project and states future work.

2

EFI Architecture

EFI [1] was invented in 1999 and was traditionally used for booting Intel Itanium Processor-based Server. EFI is a specification that defines a new model for the interfaces between operating systems and platform firmware. It also defines boot and runtime service calls that are available to the operating system and its loader. A diagram of EFI architecture is given in Figure 1. Although it is primarily intended for the next generation of IA architecture-based computers, EFI is designed to be CPU architecture indepenFig. 1. EFI Architecture dent. It separates hardware platform from general purpose OS with abstract interfaces among the two. To make OS virtually capable to control the hardware platform and enable OS-neutral value adding, EFI defines and provides a series of programmatic service interfaces which are purely API specifications and implementation independent. Intel created a platform innovation framework named Tiano for EFI. Tiano [3] made EFI extended for Desktop computers. It has the following features which are not available in traditional BIOS. • Tiano created a secure boot chain while it is booting itself and OS. Tiano has a series of security architecture protocols and boot integrity services which can be used to perform integrity and authenticity tests before EFI accepts any discovered objects. At the meantime, they challenge the authenticity of a launched application or driver. • After OS gains control of the system, EFI can provide runtime service during OS execution. The runtime service consists of certain EFI drivers. • EFI has its own file system. Each file consists of a file header and an arbitrary amount of data. If firmware become corrupted, EFI provides many mechanisms (e.g. capsule update) to enable the firmware to be recovered. • Tiano is an open source program. Most part of its codes is written in C program language. Tiano adopts high level based design strategy on framework and modular components. It aims to involve system trapping into protected mode as early as possible. • EFI provides remote access service and has the ability to perform platform firmware management without OS support.

1678

3

X. Zhang et al.

Multi-core Security Architecture

With multi-core security architecture (MCSA) based on EFI, hardware devices can be virtually partitioned and activities of insecure OS can be monitored in real-time. Figure 2 illustrates this architecture. In this section, the focus will be first given to high-level description of security boundary. Then, the hardware partition with virtual device support will be described. At last, real-time monitor mechanism is discussed in more detail.

Fig. 2. Multi-core Security Architecture

3.1

Security Boundary

In MCSA, security boundary changes when the number of insecure OSs changes. A trusted computing base (TCB) consists of hardware and software which reside in the security boundary. The security boundary can be divided into two main interchangeable time periods: After Power On Self Test (POST): EFI environment is a TCB which includes all hardware resources in the system after POST. As described in pervious section, EFI is booted along a security assurance chain. This means the entire system is secured during this time period. Further, insecure OS images will be scanned to detect malicious codes and to check system integrity along with file system scan. Insecure OS Life Time: The TCB will shrink to just include BSP, a few devices and a part of memory, when insecure OS is booted. During this time period, insecure OS takes the control of AP, some devices and a part of memory. Some non-sharable or important devices are provided to insecure OS through device virtualization. These activities can be real-time monitored by EFI. When the OS encounters security problems, the TCB will not be affected as long as EFI is secure. EFI environment is the center core of the TCB in multi-core security boundary.

A Multi-core Security Architecture Based on EFI

1679

The security feature of the EFI environment has been practically proven. When equipped with Trusted Platform Module (TPM) hardware, its security level will be intensified. 3.2

Hardware Partition with Virtual Device Support

Hardware partition has been used in virtual machine monitor. However, it is the first time for hardware partition to be used in Basic Input/Output System (BIOS) environment. For MCSA shown in Figure 2, the system is composed of CPU cores, devices, and memories in conjunction with EFI. When an insecure OS begins running, EFI assigns necessary resources, which includes cores, devices and memories, to the OS. After that, the OS can freely control assigned devices without intervention from EFI. For performance perspective, hardware partition reduces overhead which is incurred by emulation. Some devices can be partitioned physically, such as core, memory, ports, etc. Security boundary will not be broken by physical partition because EFI is continuously running on BSP and BSP is not shared by insecure OS. For some devices which can not be physically partitioned, they can still be assigned to insecure OS by virtualization technique. General purpose OS such as Linux or Windows supports virtual devices by installing virtual driver. For MCSA, EFI device drivers are installed into insecure OS for device sharing. 3.3

Real-Time Monitor and Inspect Mechanism

In MCSA, after booting up the insecure OS, EFI can monitor and inspect OS activities whenever a user needs. Security and performance can both be ensured by a dedicated BSP. MCSA supports three methods of monitoring and inspection: Insecure OS system call monitor: An OS often provides a lot of system calls to applications. So a monitor can be placed in OS kernel to log system call information such as caller Process ID (PID) and call parameters. The log will then be transferred the EFI. When insecure OS is compromised, malicious software may bypass this system monitor. However, it can not delete nor modify the logs stored in the EFI. Virtual device monitor: Device virtualization alternatively compensates for physical hardware partition. In addition, it can also log hardware and operation status and store them in EFI. In a traditional system, the logs of status information are normally embedded in physical devices, which is difficult to retrieve. In case of an insecure OS is compromised, EFI still keeps the logs of hardware status and operations. It securely protects the devices in the security boundary. Even when malicious software takes control of an insecure OS, it hardly has a chance to take control of all devices. Direct memory inspection: EFI assigns a part of the memories to an insecure OS. However, EFI can still access those memories. Using existing information from OS, EFI knows where kernel code or kernel data resides. Signatures can be

1680

X. Zhang et al.

calculated for important memory pages. If an intruder changes kernel code or data, EFI can easily find it and notify the user.

4

Prototype Design

This section presents the prototype built with multi-core security architecture (MCSA). The prototype design chooses Linux as insecure OS and a dual-core processor as reference hardware platform. Prototype diagram, technical details, as well as implementation issues are described and discussed. 4.1

System Call Monitor

Nowadays, most detection systems often rely on system call traces to build models and perform intrusion detection [22] [23] [24] [25]. So it is very important for the system call monitor to securely log all system activities. Figure 3 shows the mechanism of system call monitor prototype based on MCSA.

Fig. 3. System Call Monitor

In Figure 3, there are two main domains running in the prototype design. One is Linux kernel domain which acts as data capture sentinel. Another is the EFI environment domain which is used to log and record system activities and events. Two CPU cores manage each domain separately, but use the same physical memory. Meanwhile, two domains employ shared memory to communicate with each other. In Linux kernel domain, Write-Box is used to log system call information (e.g. Time, process-id, event-id, tty name and system call) into shared memory by

A Multi-core Security Architecture Based on EFI

1681

hooking system calls or functions such as receive buf(). Once there is information written into the shared memory region, EFI environment domain will find the change of semaphore and notify Read-Box. The semaphore is configured by the synchronization mechanism. After notification, Read-Box will fetch the data and record them in LOG component. Above system implementation imposes only minimal overhead. Its CPU occupancy rate is very low because of dual-core running independently. This monitor architecture also provides strong isolation between two domains. Therefore, even if the Linux kernel domain is compromised, it will be very difficult to corrupt and destroy the log file or database within Linux file system. 4.2

Virtual Disk Monitor

Hard disk drive is a non-sharable and very important device in the security boundary because OS relies on hard disk to store persistent data and other information. Malicious software also conceals data or modifies system data on the hard disk. Using virtual disk monitor, most attacks relying on file system can be detected and avoided. Virtual Disk Monitor is called Mobiledisk on EFI. It can load a pre-format FAT [20] disk image file from USB or any other EFI directories. Mobiledisk is a real-time FAT file system virtual disk monitor. It supports dynamic files access rules and separates OS kernel from security boundary.

Fig. 4. Virtual Disk Monitor

As shown in Figure 4, For EFI users, Virtual Disk Monitor acts as normal file system. In addition, it supports security rules: 1) File Read-Only, 2) File Read-Warning, 3) File Write-Prohibit, 4) Sector Read-Warning, 5) Sector Write-Prohibit, 6) Display all read/write operation. For Linux users, Virtual Disk Monitor acts as a block device. File system can read/write blocks. The design principle of Mobiledisk is based on FAT mechanism. When a user sets a security level index to a file, Mobiledisk will search the FAT table and find all sectors related to the file and mark them on a block-to-file mapping table. When a read or write request comes from insecure OS, Mobiledisk will first search sector table for security level and then proceed to finish the job.

1682

4.3

X. Zhang et al.

Encryption Service

Since encryption service is usually provided by OS, it can be potentially vulnerable when the OS is compromised. To address this issue, a lot of secure platforms have been equipped with TPM or other dedicated device to provide secure and reliable encryption service. However, they suffered from performance penalty and nonstandard programming interface. With proposed architecture, EFI provides high performance and reliable services and general programming interface. Performance detail is discussed in the next section. In EFI, SHA256 service can receive commands and data from Linux, and then send results back to the Linux. Figure 5 shows this service model. Since Message Digest is a data intensive algorithm, shared memory is used to reduce time spent for duplicating data. When EFI is doing computation, Linux can do other jobs until the EFI finishes its work.

Fig. 5. SHA256 Message Digest Service

In Figure 5, one can find that Message Digest algorithm is within EFI security boundary. In fact, it will not be compromised by malicious codes coming from insecure OS side. Linux applications can call this service like a hardware encryption device. Performance results will be shown in the next section.

5

Performance Test

Performance tests results are presented in this section. System platform details are listed as the following: software including Linux kernel 2.6.13, Modified Stress 0.18.1, busybox-20070523.tar.gz, and EFI V1.10; hardware including Intel Lakeport platform, Pentium D 3.2GHz, 1Gigabytes DDR2 RAM, Quantum Fireball 6.4GB PATA hard disk, and SanDisk Cruzer Micro 512MB USB memory stick.

A Multi-core Security Architecture Based on EFI

5.1

1683

EFI SHA256 VS Linux SHA256

In this test, computation complexity of SHA256 algorithm is increased for comparison purposes without loss of its precision. Programming is separately done for Linux and EFI. Stress is used for increasing average system load while SHA256 test programs are running on Linux (and EFI) simultaneously. The parameters of Stress are –cpu 100–timeout 30 –backoff 2500 for ’Stress Period 30s’ and –cpu 100 – timeout 45 –backoff 2500 for ’Stress Period 45s’. In Figure 6, [US0] means SHA256 test programs call usleep(0) immediately after call SHA256 service. SHA256 Test vectors (e.g.SHA256longmsg) [5] are used to informally verify the correctness of SHA256 algorithm implementation and to evaluate the performance.

Fig. 6. EFI SHA256 Service VS Linux SHA256 Service

Figure 6 illustrates executing time of SHA256 service in EFI with usleep(0) (EFI + Linux[US0]) and SHA256 service in Linux (Linux[US0]) with and without usleep(0) (Linux). It’s obvious that execution time of the tests on SHA256 service in EFI is not affected by Stress period. In contrast, execution time of the tests on SHA256 service in Linux is greatly affected by Stress period. Linux[US0] and Linux tests are dragged by Stress program. In fact, SHA256 tests can not be finished in their ordinary speed. 5.2

EFI Virtual Disk vs Physical Hard Disk

In the performance test, virtual disk is implemented using ram-disk method. The entire disk image is simulated in EFI memory. Ram-disk method can increase write performance. However, it is confined by memory size of EFI. In order to make sure all files are written to the storage media safely, unmount command is used to synchronize file system.

1684

X. Zhang et al.

Figure 7 illustrates the performance comparison of ram-disk and physical hard disk drive. All test results are averages calculated from tests repeated ten times. Linux command Time is used to do the test. There are three sets of data in the Figure 7: Real represents real time elapsed; User represents total number of CPU-seconds that the process spent in user mode; Sys represents total number of CPU-seconds that the process spent in kernel mode. Total is the sum of real time of tar command and real time of umount command. EFI virtual disk and hard disk is mounted to the same directory. FAT disk image of 32 Megabytes is used for testing.

Fig. 7. Virtual Disk Monitor Performance

Compressed busybox source code is used for testing. The test commands are - ”time tar -xzvf busybox-20070523.tar.gz” and ”time umount dirname”. EFI ram disk took 0.88 second to finish. In contrast, physical disk took 20.81 seconds which including 5.36 tar time and 15.45 umount time. The wide gap in time can be used for performing rules checking.

6

Related Works

This section reviews the previous work relevant to MCSA. 6.1

Distributed System Security Architecture

From previous research in management of digital document in distributed system environment of reference [6], the authors suggested a trusted time-stamping service. Authors in reference [7] extended this service to time-stamp the logs on

A Multi-core Security Architecture Based on EFI

1685

un-trusted machines so that it is difficult for attackers to hide their tracks. Victims can quickly learn that their machine has been attacked. In reference [8], authors presented a Saga Security Architecture for open distributed system. They proposed a distributed security monitor integrated with the agent. With this architecture, communication security is ensured but not the platform security. 6.2

Platform Enhancement

A modified BIOS is described in [10], authors divided BIOS into two sections, one for integrity verification and the other for normal boot. However, it is only a pre-boot static method. In reference [9], authors suggested a security processor model. It includes encryption hardware into processor and a security kernel of OS. Intel proposed LaGrande Technology in [13], which requires a number of hardware enhancements (Processor, chipset, keyboard and mouse, graphics, etc). Intel later proposed VPro [12] and TXT [11] techniques which provides hardware acceleration of virtual machine monitor (VMM). 6.3

Virtual Machine Security

Prior to the adoption of virtual machine technique, authors in [17] tried to make a secure environment for un-trusted application. They did it by restricting application access to the OS. In reference [14], authors use PIN [15] to implement the application. PIN uses virtual machine to do the inspection. Authors in [16] built a safe virtual machine to run un-trusted codes. In reference [18], authors widely discussed security on virtual machine architecture. They provided such architecture to communicate with VMM and translate hardware status. Xen [19] presented Domain-0 and Domain-U architecture. Nevertheless, this architecture needs kernel modification. 6.4

Multi-core Security Architecture

Most recently, authors of reference [21] presented virtualization architecture for security-oriented next generation mobile terminals. It includes a secure core and application cores. Host runs on the secure core can provide more secure operations for client OSs in order to protect the entire system. The rest cores can run client OS. The number of client OS can exceed the physical number of application cores.

7

Conclusion and Future Work

According to the statistical analysis in reference [4], hacking has moved from a hobbyist pursuit with a goal of notoriety to a criminal pursuit with a goal of money. The economic and social reasons for using the Internet are still far too compelling. So we need more solid architectural level improvements instead of some isolated methods to greatly enhance system security on personal computers.

1686

X. Zhang et al.

A novel multi-core security architecture (MCSA) is described in this paper. It balances system performance and security. With MCSA, EFI environment can keep security boundary even when an insecure OS is compromised. Judging from performance test results, one can find that, under high system load circumstance, EFI service can still finish encryption work and EFI virtual disk provides great speed enhancement in comparison with physical disk. A plan to develop more sophisticated integrated real-time monitor to inspect insecure OS and provide standard virtual device interface to the OS. With advancement of computer architecture, platform enhancement will be adopted into this architecture.

Acknowledgments We would like to thank anonymous reviewers for their valuable suggestions to improve this manuscript. This work is supported by Intel Corporation and Shanghai Jiao Tong University, under contracts No. 4507258277 and No. 4507255994. We appreciate such great opportunities to work on these projects. We also appreciate Mr. Wu Ming, Mr. Zhou Hua, Mr. Qian Yi and others from Intel EFI/Tiano team, who gave us great support on EFI architecture and multi-core programming as well as many useful suggestions. Last, thanks to Zhang Zhao Hua, Chen Zhi Feng in our team for their creative thinking and hard work.

References 1. Intel. Extensible Firmware Interface Specification Version 1.10 (December 2002), http://developer.intel.com/technology/efi/ 2. Intel. Multi-Core Overview, http://www.intel.com/multi-core/overview.htm 3. Intel. Tiano Architecture Specification Version 0.7 (June 2002), http://www.tianocore.org 4. Schneier, B.: Attack Trends 2004 and 2005. ACM Queue 3(5), 52–53 (2005) 5. Secure Hash Standard (SHS) (SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 algorithms), http://csrc.nist.gov/cryptval/shs.htm 6. Haber, S., Stornetta, W.S.: How To Time-Stamp a Digital Document. In: Menezes, A.J., Vanstone, S.A. (eds.) CRYPTO 1990. LNCS, vol. 537, pp. 437–455. Springer, Heidelberg (1991) 7. Schneier, B., Kelsey, J.: Cryptographic Support for Secure Logs on Untrusted Machines. In: Proceedings of the USENIX Security Symposium, pp. 53–62 (January 1998) 8. Soshi, M., Maekawa, M.: The Saga Security System a security architecture for opendistributed systems. In: Proc. 6th IEEE Computer society workshop on future trends of distributed computing systems, pp. 53–58 (1997) 9. Suh, E., Clarke, D., Gassend, B., van Dijk, M., Devadas, S.: AEGIS: Architecture for Tamper-Evident and Tamper-Resistant Processing. In: ICS. Proceedings of the 17 th International Conference on Supercomputing (2003)

A Multi-core Security Architecture Based on EFI

1687

10. Arbaugh, W., Farber, D.: A secure and reliable bootstrap architecture. In: IEEE Security and Privacy Conference, pp. 65–71. IEEE Press, New York (1997) 11. Intel Trusted Execution Technology Preliminary Architecture Specification (November 2006) 12. Intel Centrino Pro and Intel vPro Processor Technolog White Paper 13. Intel LaGrande Technology Architectural Overview (Sepember 2003) 14. Moffie, M., Kaeli, D.: ASM Application Security Monitor. In: WBIA 2005. Special issue on the 2005 workshop on binary instrumentation and application SPECIAL ISSUE, vol. 33(5), pp. 21–26 (December 2005) 15. Luk, C.-K., Cohn, R., Muth, R., Patil, H., Klauser, A., Lowney, G., Wallace, S., Reddi, V.J., Hazelwood, K.: Pin: building customized program analysis tools with dynamic instrumentation. In: Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation, Chicago, IL, USA (June 2005) 16. Scott, K., Davidson, J.: Safe Virtual Execution Using Software Dynamic Translation. In: Computer Security Applications Conference, 2002. Proceedings. 18th Annual, pp. 209–218 (2002) 17. Goldberg, I., Wagner, D., Thomas, R., Brewer, E.A.: A secure environment for untrusted helper applications. In: Proceedings of the 6th USENIX Security Symposium (July 1996) 18. Garfinkel, T., Rosenblum, M.: A Virtual Machine Introspection Based Architecture for Intrusion Detection. In: Proceedings of the Internet Society’s 2003 Symposium on Network and Distributed System Security (February 2003) 19. Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Pratt, I., Warfield, A., Barham, P., Neugebauer, R.: Xen and the art of virtualization. In: Proceedings of the ACM Symposium on Operating Systems Principles (October 2003) 20. Microsoft Extensible Firmware Initiative FAT32 File System Specification 1.03 21. Inoue, H., Ikeno, A., Kondo, M., Sakai, J., Edahiro, M.: A New Processor Virtualization Architecture for Security-Oriented Next-Generation Mobile Terminals. In: Proceedings of the 43rd annual conference on Design automation table of contents, Annual ACM IEEE Design Automation Conference, pp. 484–489 (2006) 22. King, S.T., Chen, P.M.: Backtracking intrusions. ACM Transactions on Computer Systems (TOCS) 23(1), 51–76 (2005) 23. Lam, L.C., Li, W., Chiueh, T.-c.: Accurate and Automated System Call PolicyBased Intrusion Prevention. In: Dependable Systems and Networks (DSN) International Conference on 2006, pp. 413–424 (October 2006) 24. Varghese, Mariam, S., Jacob, K.P.: Process Profiling Using Frequencies of System Calls. In: ARES 2007. Availability, Reliability and Security, 2007. The Second International Conference on 10-13, pp. 473–479 (April 2007) 25. Paek, S.-H., Oh, Y.-K., Yun, J.B., Lee, D.-H.: The Architecture of Host-based Intrusion Detection Model Generation System for the Frequency Per System Call. In: ICHIT 2006. Hybrid Information Technology, 2006. International Conference, vol. 2, pp. 277–283 (November 2006)