DOCSLIB.ORG

Phd-Manuscript.Pdf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Phd-Manuscript.Pdf Préparée à l'École Normale Supérieure Analyse de la sécurité de systèmes critiques embarqués à forte composante logicielle par interprétation abstraite Proving the security of software-intensive embedded systems by abstract interpretation Soutenue par Composition du jury : Marc Chevalier Patrick Cousot Le vendredi 27 novembre 2020 Professor, New York University, USA Président Jérôme Feret Chargé de recherche, INRIA, France Directeur de thèse École doctorale no386 Sciences Mathématiques Isabella Mastroeni Associate Professor, Università degli Rapporteuse de Paris Centre Studi di Verona, Italie Peter Müller Professor, ETH Zürich, Suisse Examinateur Spécialité David Pichardie Informatique Professeur, École Normale Supérieure Rapporteur de Rennes, France Marc Pouzet Professeur, École Normale Supérieure, Examinateur France Sukyoung Ryu Associate Professor, KAIST, Corée du Examinatrice Sud Mihaela Sighireanu Maîtresse de conférences HDR, IRIF, Examinatrice France Abstract his thesis is dedicated to the analysis of low-level software, like operating systems, T by abstract interpretation. Analyzing OSes is a crucial issue to guarantee the safety of software systems since they are the layer immediately above the hardware and that all applicative tasks rely on them. For critical applications, we want to prove that the OS does not crash, and that it ensures the isolation of programs, so that an untrusted program cannot disrupt a trusted one. The analysis of this kind of programs raises specific issues. This is because OSes must control hardware using instructions that are meaningless in ordinary programs. In addition, because hardware features are outside the scope of C, source code includes assembly blocks mixed with C code. These are the two main axes in this thesis: handling mixed C and assembly, and precise abstraction of instructions that are specific to low- level software. This work is motivated by the analysis of a case study emanating from an industrial partner, which required the implementation of proposed methods in the static analyzer Astrée. The first part is about the formalization of a language mixing simplified modelsofC and assembly, from syntax to semantics. This specification is crucial to define whatis legal and what is a bug, while taking into account the intricacy of interactions of C and assembly, in terms of data flow and control flow. The second part is a short introduction to abstract interpretation focusing on what is useful thereafter. The third part proposes an abstraction of the semantics of mixed C and assembly. This is actually a series of parametric abstractions handling each aspect of the semantics. The fourth part is interested in the question of the abstraction of instructions specific to low-level software. Interest properties can easily be proven using ghost variables, but because of technical reasons, it is difficult to design a reduced product of abstract domains that allows a satisfactory handling of ghost variables. This part builds such a general framework with domains that allow us to solve our problem and many others. The final part details properties to prove in order to guarantee isolation of programs that have not been treated since they raise many complicated questions. We also give some suggestions to improve the product of domains with ghost variables introduced in the previous part, in terms of features and performances. i ii ABSTRACT Résumé ette thèse est consacrée à l’analyse de logiciels de bas niveau, tels que les systèmes C d’exploitation, par interprétation abstraite. L’analyse des OS est une question im- portante pour garantir la sûreté des systèmes logiciels puisqu’ils forment le niveau immé- diatement au dessus du matériel et que toutes les tâches applicatives dépendent d’eux. Pour des applications critiques, on veut s’assurer que l’OS ne plante pas, mais aussi qu’il assure l’isolation des programmes, de sorte qu’un programme dont la fiabilité n’a pas été établie ne puisse perturber un programme de confiance. L’analyse de ce genre de programmes soulève des problèmes spécifiques. Cela provient du fait que les OS doivent contrôler le matériel avec des opérations qui n’ont pas de sens dans un programme ordinaire. De plus, comme les fonctionnalités matérielles sont en dehors du for du C, le code source contient des blocs de code assembleur mêlés au C. Ce sont les deux axes de cette thèse : gérer les mélanges de C et d’assembleur, et abstraire finement les opérations spécifiques aux logiciels de bas niveau. Ce travail est guidépar l’analyse d’un cas d’étude d’un partenaire industriel, ce qui a nécessité l’implémentation des méthodes proposées dans l’analyseur statique Astrée. La première partie s’intéresse à la formalisation d’un langage mélangeant des mo- dèles simplifiés du C et de l’assembleur, depuis la syntaxe jusqu’à la sémantique. Cette spécification est importante pour définir ce qui est légal et ce qui constitue uneerreur, tout en tenant compte de la complexité des interactions du C et de l’assembleur, tant en termes de données que de flot de contrôle. La seconde partie est une introduction sommaire à l’interprétation abstraite qui se limite à ce qui est utile par la suite. La troisième partie propose une abstraction de la sémantique des mélanges de C et d’assembleur. Il s’agit en fait d’une collection d’abstractions paramétriques qui gèrent chacun des aspects de cette sémantique. La quatrième partie s’intéresse à l’abstraction des opérations spécifiques aux logiciels de bas niveau. Les propriétés d’intérêt peuvent être facilement prouvées à l’aide de variables fantômes, mais pour des raisons techniques, il est difficile de concevoir un produit réduit de domaines abstraits qui supporte une gestion satisfaisante des variables fantômes. Cette partie construit un tel cadre très général ainsi que des domaines qui permettent de résoudre beaucoup de problèmes dont le nôtre. L’ultime partie présente quelques propriétés à prouver pour garantir l’isolation des programmes, qui n’ont pas été traitées car elles posent de nouvelles et complexes ques- iii iv RÉSUMÉ tions. On donne aussi quelques propositions d’amélioration du produit de domaines avec variables fantômes introduit dans la partie précédente, tant en termes de fonctionnalités que de performances. Contents Abstract i Résumé iii Contents v 1 Introduction 1 1.1 Context . 2 1.2 Motivation . 3 1.3 Overview . 4 2 The x86 Architecture and System Programming 7 2.1 An Overview of the x86 Architecture . 7 2.1.1 A Piece of History . 7 2.1.2 Characteristics of the 32-bit x86 Architecture . 8 2.1.3 Conventions . 9 2.2 Execution Environment . 10 2.2.1 Registers . 10 2.2.1.1 General-Purpose Registers . 10 2.2.1.2 EFLAGS Register . 11 2.2.1.3 Segment Registers . 12 2.2.1.4 Instruction Pointer . 12 2.2.1.5 Control Registers and Other System Registers . 13 2.2.2 Stack . 13 2.2.3 Privileges . 13 2.2.4 Modes of Operation . 14 2.2.5 Memory Protection Overview . 15 2.2.6 Assembly Language . 16 2.3 Memory Management . 17 2.3.1 Address and Operand Sizes . 17 2.3.2 Segmentation . 18 2.3.2.1 Real-Address Mode Segmentation . 18 2.3.2.2 Protected Mode Segmentation . 19 v vi CONTENTS 2.3.2.2.1 Segment Descriptor . 19 2.3.2.2.2 Segmenting the Linear Address Space . 21 2.3.2.2.3 Global Descriptor Table . 23 2.3.2.2.4 Segment Selectors . 23 2.3.2.2.5 System Descriptors . 24 2.3.3 Paging . 25 2.3.3.1 Translation Mechanism . 25 2.3.3.2 Memory Isolation . 27 2.3.3.3 Identity Paging . 27 2.3.3.4 Translation Lookaside Buffers . 28 2.4 Calls, Interrupts and Exceptions . 28 2.4.1 Near Calls . 29 2.4.2 Far Calls . 30 2.4.2.1 A Syntactic Digression . 30 2.4.2.2 Intra-Privilege Calls . 31 2.4.2.3 Inter-Privilege Calls . 31 2.4.3 Interrupts and Exceptions . 32 2.5 Tasks . 34 2.5.1 Task-State Segment . 34 2.5.2 Task Register . 35 2.5.3 Using Tasks . 35 2.6 System Calls . 36 2.6.1 Triggering a System Call . 36 2.6.2 Passing Arguments . 37 2.7 Boot . 37 I Semantics of Mixed C and x86 Assembly 39 3 Introduction 41 4 A Minimal C-like Language 43 4.1 Syntax . 43 4.2 Labels . 45 4.3 Semantics . 47 4.3.1 Memory Model . 48 4.3.2 Transition Systems . 49 4.3.3 Semantics of Lvalues and Expressions . 49 4.3.4 Semantics of Statements . 51 4.3.4.1 Transition Relation . 52 4.3.4.1.1 Blocks . 52 4.3.4.1.2 Conditional Branching . 53 4.3.4.1.3 Loop Statements . 53 4.3.4.1.4 Assignments . 54 CONTENTS vii 4.3.4.1.5 Declarations . 54 4.3.4.1.6 Return Statements . 55 4.3.4.1.7 Function Calls . 56 4.3.4.2 Initial States . 57 4.4 Comparison with Real C and Thoughts . 58 4.4.1 The Place of Undefined, Unspecified and Implementation-Defined Behaviors . 58 4.4.2 Desugaring C . 59 4.4.3 A Computability Digression . 60 4.4.4 Non-determinism and Memory Usage . 61 5 The Assembly Language 63 5.1 Structure of x86 Assembly Language . 64 5.2 Memory Model for Assembly . 65 5.3 The Reduced Instruction Set . 68 5.4 A Very Concrete Semantics . 69 5.5 A More Symbolic Semantics . 77 5.6 Comparison of Semantics . 80 6 Non-semantic Aspects of Mixed C and Assembly 81 6.1 Syntax of Assembly Blocks . 81 6.2 Sharing Operands . 82 6.2.1 Global Variables .
Load more

Recommended publications
  • Beyond MOV ADD XOR – the Unusual and Unexpected
    Beyond MOV ADD XOR the unusual and unexpected in x86 Mateusz "j00ru" Jurczyk, Gynvael Coldwind CONFidence 2013, Kraków Who • Mateusz Jurczyk o Information Security Engineer @ Google o http://j00ru.vexillium.org/ o @j00ru • Gynvael Coldwind o Information Security Engineer @ Google o http://gynvael.coldwind.pl/ o @gynvael Agenda • Getting you up to speed with new x86 research. • Highlighting interesting facts and tricks. • Both x86 and x86-64 discussed. Security relevance • Local vulnerabilities in CPU ↔ OS integration. • Subtle CPU-specific information disclosure. • Exploit mitigations on CPU level. • Loosely related considerations and quirks. x86 - introduction not required • Intel first ships 8086 in 1978 o 16-bit extension of the 8-bit 8085. • Only 80386 and later are used today. o first shipped in 1985 o fully 32-bit architecture o designed with security in mind . code and i/o privilege levels . memory protection . segmentation x86 - produced by... Intel, AMD, VIA - yeah, we all know these. • Chips and Technologies - left market after failed 386 compatible chip failed to boot the Windows operating system. • NEC - sold early Intel architecture compatibles such as NEC V20 and NEC V30; product line transitioned to NEC internal architecture http://www.cpu-collection.de/ x86 - other manufacturers Eastern Bloc KM1810BM86 (USSR) http://www.cpu-collection.de/ x86 - other manufacturers Transmeta, Rise Technology, IDT, National Semiconductor, Cyrix, NexGen, Chips and Technologies, IBM, UMC, DM&P Electronics, ZF Micro, Zet IA-32, RDC Semiconductors, Nvidia, ALi, SiS, GlobalFoundries, TSMC, Fujitsu, SGS-Thomson, Texas Instruments, ... (via Wikipedia) At first, a simple architecture... At first, a simple architecture... x86 bursted with new functions • No eXecute bit (W^X, DEP) o completely redefined exploit development, together with ASLR • Supervisor Mode Execution Prevention • RDRAND instruction o cryptographically secure prng • Related: TPM, VT-d, IOMMU Overall..
    [Show full text]
  • View See for Instance [13])
    Towards Dynamic Execution Environment for System Security Protection against Hardware Flaws Kenneth Schmitzy Oliver Keszocze∗y Jurij Schmidt∗y Daniel Große∗y Rolf Drechsler∗y ∗Institute of Computer Science, University of Bremen, 28359 Bremen, Germany yCyber-Physical Systems, DFKI GmbH, 28359 Bremen, Germany {kenneth, keszocze, grosse, drechsler}@cs.uni-bremen.de Abstract—Attacks exploiting security flaws in software are complex, verification and test become more challenging and very common. They are typically addressed during the ongoing flaws can remain undiscovered prior to the fabrication. Powerful software development process or by providing software patches. instruction set extensions to the x86 Instruction Set Architecture Attacks making use of hardware related flaws via malicious soft- ware recently gained popularity. Prominent examples are errata- (ISA) have been recently reported to result in unpredictable based, aging-related or, for example, the infamous Rowhammer- behavior [5]. Undocumented features inside the ISA, which can attack. In this paper, we present an approach to detect software- cause unpredictable system behavior, have been revealed [6] based attacks which exploit hardware flaws. Since the flaws are as well. typically triggered by characteristic instruction sequences, our approach is implemented as a dynamic execution environment for The second category covers flaws which are inherited program monitoring at runtime. Several case studies underline from the feature sizes used to fabricate the components. The the effectiveness and the low overhead of our approach. Rowhammer-attack affects Random Access Memory (RAM) and Solid-State Drives (SSDs) [7]. The malicious aging in I. INTRODUCTION circuits/cores (MAGIC) [8] leads to very fast semiconductor Malicious software such as Trojans or viruses can be aging.
    [Show full text]
  • Developing and Verifying Methods to Search for Hidden Instructions On
    Bachelor Computer Science Developing and Verifying Methods to Search for Hidden Instructions on RISC Processors Michael G¨oebel Supervisors: Dr. E. van der Kouwe & Dr. K. F. D. Rietveld BACHELOR THESIS Leiden Institute of Advanced Computer Science (LIACS) www.liacs.leidenuniv.nl 06/07/2019 Abstract This thesis describes two methods to scan RISC chips for the presence of undocumented instructions. We developed a memory cage method and a ptrace method. These methods scan the entire instruction search space while maintaining control. The developed program writes an instruction to memory, executes it and performs analysis based on the result. Any undocumented instructions are logged, and after the scan has finished the results are analysed. Through a verification using QEMU, we show that the memory cage method is capable of finding hidden instructions. The memory cage method performs better than the ptrace method. No undocumented instructions were found on the Cavium ThunderX, Ampere eMAG 8180 and AL73400 AWS Graviton. However, we did find some hidden instructions on the QEMU emulator. 2 Contents 1 Introduction 1 1.1 Contributions.......................................2 1.2 Thesis overview......................................2 2 Background 3 2.1 Hidden Instructions....................................3 2.2 Signal handling......................................4 2.3 Disassembler........................................5 2.4 QEMU emulator.....................................5 2.5 RISC architectures....................................6 3 Related Work 7 4 Overview 8 5 Design 10 5.1 Program Survival..................................... 10 5.2 Memory Cage....................................... 11 5.2.1 Hang issue..................................... 13 5.3 Ptrace........................................... 13 5.4 Ground Truth....................................... 13 5.5 Result Analysis...................................... 13 6 Implementation 15 6.1 Architecture Dependent Settings............................. 15 6.2 Initialization.......................................
    [Show full text]
  • Cyber Threats and NATO 2030: Horizon Scanning and Analysis
    King’s Research Portal Document Version Publisher's PDF, also known as Version of record Link to publication record in King's Research Portal Citation for published version (APA): Stevens, T., Ertan, A., Floyd, K., & Pernik, P. (Eds.) (2021). Cyber Threats and NATO 2030: Horizon Scanning and Analysis . NATO Cooperative Cyber Defence Centre of Excellence. https://ccdcoe.org/uploads/2020/12/Cyber-Threats-and-NATO-2030_Horizon-Scanning-and-Analysis.pdf Citing this paper Please note that where the full-text provided on King's Research Portal is the Author Accepted Manuscript or Post-Print version this may differ from the final Published version. If citing, it is advised that you check and use the publisher's definitive version for pagination, volume/issue, and date of publication details. And where the final published version is provided on the Research Portal, if citing you are again advised to check the publisher's website for any subsequent corrections. General rights Copyright and moral rights for the publications made accessible in the Research Portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognize and abide by the legal requirements associated with these rights. •Users may download and print one copy of any publication from the Research Portal for the purpose of private study or research. •You may not further distribute the material or use it for any profit-making activity or commercial gain •You may freely distribute the URL identifying the publication in the Research Portal Take down policy If you believe that this document breaches copyright please contact [email protected] providing details, and we will remove access to the work immediately and investigate your claim.
    [Show full text]
  • The Challenge of Networked Complexity to NATO's Digital Security
    The Challenge of Networked Complexity to NATO’s Digital Security Laurin B. Weissinger Lecturer The Fletcher School Tufts University Abstract: In the aftermath of the 2016 Democratic National Convention (DNC) hack and with ongoing disinformation campaigns attacking dem- ocratic elections worldwide, cyber defence has never been more important for the North Atlantic Treaty Organisation (NATO) allies. However, current security strategies often fall short because they do not adequately address the problem of networked complexity. To protect cyberspace, national assets and key institutions, we must solve for the strategic, tactical and operational complexities of the technology stack, including its interconnections and in- terdependencies. States and organisations must address three levels of complexity: entity, layered and networked complexity. Entity complexity is the complexity of a single component or system, for example, a central processing unit (CPU). Layered complexity arises when we layer multiple levels of complex hard- ware and software. The third level of complexity involves emergent networks and interactions of multi-layered technical and socio-technical systems. This paper establishes the critical importance of understanding networked complexity in cyber security, a topic which is underrepresented in extant cy- ber security literature. It proposes practical solutions, including a focus on ‘defence in breadth’. All systems, including consumer-grade products, must be shipped more secure by default. Mitigating networked complexity in cyber defence will also require better threat and attack modelling. Security strat- egies should move from hierarchical models to a graph-driven, networked understanding of cyber security that incorporates socio-technical dimen- sions. Lastly, states should leverage the security community and public-pri- vate partnerships.
    [Show full text]
  • Cyber Threats and NATO 2030: Horizon Scanning and Analysis
    King’s Research Portal Document Version Publisher's PDF, also known as Version of record Link to publication record in King's Research Portal Citation for published version (APA): Stevens, T., Ertan, A., Floyd, K., & Pernik, P. (Eds.) (2021). Cyber Threats and NATO 2030: Horizon Scanning and Analysis . NATO Cooperative Cyber Defence Centre of Excellence. https://ccdcoe.org/uploads/2020/12/Cyber-Threats-and-NATO-2030_Horizon-Scanning-and-Analysis.pdf Citing this paper Please note that where the full-text provided on King's Research Portal is the Author Accepted Manuscript or Post-Print version this may differ from the final Published version. If citing, it is advised that you check and use the publisher's definitive version for pagination, volume/issue, and date of publication details. And where the final published version is provided on the Research Portal, if citing you are again advised to check the publisher's website for any subsequent corrections. General rights Copyright and moral rights for the publications made accessible in the Research Portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognize and abide by the legal requirements associated with these rights. •Users may download and print one copy of any publication from the Research Portal for the purpose of private study or research. •You may not further distribute the material or use it for any profit-making activity or commercial gain •You may freely distribute the URL identifying the publication in the Research Portal Take down policy If you believe that this document breaches copyright please contact [email protected] providing details, and we will remove access to the work immediately and investigate your claim.
    [Show full text]
  • Uncovering Hidden Instructions in Armv8-A Implementations
    Uncovering Hidden Instructions in Armv8-A Implementations Fredrik Strupe∗ Rakesh Kumar Silicon Labs, Norway NTNU, Norway [email protected] [email protected] ABSTRACT behaviours for devising offensive and defensive mechanisms. For Though system and application level security has received and example, Spectre [10] and its successors [3, 4, 11] alter a victim continue to receive significant attention, interest in hardware secu- program’s control flow to leak its memory contents by leveraging rity has spiked only in the last few years. The majority of recently a well documented optimization called speculative execution. Simi- disclosed hardware security attacks exploit well known and docu- larly, observing the cache/memory response time can also be used mented hardware behaviours such as speculation, cache and mem- to mount an attack. ory timings, etc. We observe that security exploits in undocumented We observe that undocumented or hidden behavior of the hard- hardware behaviour can have even more severe consequences as ware can create new security vulnerabilities. A great amount of such behaviour is rarely verified and protected against. trust is put into the hardware designers and manufacturers, in that This paper introduces armshaker, a tool to uncover one such the hardware functions exactly as documented with no hidden or undocumented behaviour in the Armv8 architecture, namely hidden undocumented behavior. However, even without any malicious instructions. These are the instructions that are not documented in intent, security vulnerabilities can still be present in hardware as a the ISA reference manual, but still execute successfully. We tested result of design bugs [5, 10, 12] or manufacturing faults [14].
    [Show full text]
  • Cyber Threats and NATO 2030: Horizon Scanning and Analysis
    Published by Cyber Threats and NATO 2030: Horizon Scanning and Analysis A. Ertan, K. Floyd, P. Pernik, T. Stevens (Eds.) Published by Cyber Threats and NATO 2030: Horizon Scanning and Analysis A. Ertan, K. Floyd, P. Pernik, T. Stevens (Eds.) Cyber Threats and NATO 2030: Horizon Scanning and Analysis Copyright © 2020 by NATO CCDCOE Publications. All rights re- served. ISBN (print): 978-9916-9565-0-2 ISBN (pdf): 978-9916-9565-1-9 COPYRIGHT AND REPRINT PERMISSIONS No part of this publication may be reprinted, reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of the NATO Cooperative Cyber Defence Centre of Excellence ([email protected]). This restriction does not apply to making digital or hard copies of this publication for internal use within NATO, or for personal or educational use when for non-profit or non-commercial purposes, providing that copies bear this notice and a full citation on the first page as follows: Cyber Threats and NATO 2030: Horizon Scanning and Analysis A. Ertan, K. Floyd, P. Pernik, T. Stevens (Eds.) 2020 © NATO CCDCOE Publications NATO CCDCOE Publications LEGAL NOTICE: This publication contains Filtri tee 12, 10132 Tallinn, Estonia the opinions of the respective authors only. They do not necessarily reflect the policy or Phone: +372 717 6800 the opinion of NATO CCDCOE, NATO, or any Fax: +372 717 6308 agency or any government. NATO CCDCOE E-mail: [email protected] may not be held responsible for any loss or Web: www.ccdcoe.org harm arising from the use of information contained in this book and is not responsi- ble for the content of the external sources, including external websites referenced in this publication.
    [Show full text]
  • A Performance Evaluation of Platform-Independent Methods to Search for Hidden Instructions on RISC Processors
    Opleiding Informatica A Performance Evaluation of Platform-Independent Methods to Search for Hidden Instructions on RISC Processors Rens Dofferhoff Supervisors: Dr. E. van der Kouwe & Dr. K.F.D. Rietveld BACHELOR THESIS Leiden Institute of Advanced Computer Science (LIACS) www.liacs.leidenuniv.nl 02/08/2019 Abstract Undocumented and faulty instructions can pose a security risk, as shown in the past with the infamous f00f-bug. A scanner that searches for undocumented instructions can be a useful tool to help verify the secure operation of processors. This research proposes two methods for finding undocumented instructions on RISC processors. These methods attempt the execution of a single instruction and analyze the resulting signal information to determine if the instruction is seen as valid by the processor. The results are compared to the behavior specified by the ISA the processor implements. The resulting scanner program is used to scan multiple ARMv8 and RISC-V systems. Various flaws were discovered in the used disassemblers and the QEMU emulator. An undocumented instruction was found on a RISC-V chip. Within this research the performance of the resulting scanner including multi-core scaling behavior is analyzed. Both methods allow the scanning of 32-bit instruction spaces in less than a day. Good multi-core scaling is seen on systems with less than 16 cores. Contents 1 Introduction 1 1.1 Contributions.......................................1 1.2 Thesis overview......................................1 2 Background 3 2.1 Instruction set architecture................................3 2.2 Hidden instructions....................................4 2.3 Exceptions & signal handling..............................4 3 Related work 5 4 Overview 7 5 Design 10 5.1 Program state protection................................
    [Show full text]
  • Radio Frequency Identification Based Smart
    ISSN (Online) 2394-2320 International Journal of Engineering Research in Computer Science and Engineering (IJERCSE) Vol 5, Issue 1, January 2018 BUGS in Silicon [1] [2] Dr. Latika Kharb, Permil Garg [1] [2] Associate Professor, Student Jagan Institute of Management Studies (JIMS), Delhi, India. Abstract: - In computing system, a processor refers to an electronic circuit which performs operations on some external data which is stored in usually memory or some other data stream like Hard-disk, Flash-drive, etc. The market leaders in manufacturing CPU’s are Intel, AMD and ARM. MMX, SSE, SSE2, SSE3, SSE 4, SSE 4.1, SSE 4a, SSE4.2, SSE5, x86-64, AMD-V, Intel-VTx, AVX, AVX2, AVX-512, AES, SHA, FMA3, FMA4, F16C, XOP, 3D-NOW are the major instruction set present in today’s CPU’s. In this paper, we will discuss literature study on available processors and emphasized on Bugs in processors that are top marketers today. is exploited to gain unauthorized access or privileges on a I. INTRODUCTION computer system are called a security bug. Any vulnerability in system which is exploited to bypass Authentication of In computing system, a processor refers to an electronic user or other entities, to get authorization of access rights circuit which performs operations on some external data and privileges and to breach the data confidentiality is which is stored in usually memory or some other data considered as security bug. The main causes of bugs are stream like Hard-disk, Flash-drive, etc. There are various poor designing of system. Bugs are classified into two types types of processors such as CPU - central processing unit, namely, Software Bug and Hardware Bug.
    [Show full text]
  • Breaking the X86 ISA W
    1 Breaking the x86 ISA Christopher Domas [email protected] July 27, 2017 maintaining backwards compatibility, the processor has kept Abstract— A processor is not a trusted black box for running even those instructions and modes that are no longer used code; on the contrary, modern x86 chips are packed full of secret today. The result of these continuous modifications and instructions and hardware bugs. In this paper, we demonstrate evolutions is a processor that is a complex labyrinth of new how page fault analysis and some creative processor fuzzing can and ancient technologies. Within this shifting maze, there are be used to exhaustively search the x86 instruction set and uncover the secrets buried in a chipset. The approach has instructions and features that have been largely forgotten and revealed critical x86 hardware glitches, previously unknown lost over time. machine instructions, ubiquitous software bugs, and flaws in enterprise hypervisors. I. OVERVIEW hile the x86 architecture has been around for over 40 W years, there exist no public tools for auditing and validating the processor’s instruction set. With a history of processor errata, security flaws, and secret instructions, such introspection tools are necessary for establishing trust in a computing system built on an x86 platform. Here, we introduce the first effective technique for auditing the x86 Figure 1. Evolution of x86 execution modes. instruction set, through guided fuzzing. The approach uses a x87, IA-32, x86-64, MMX, 3DNow!, depth-first instruction search algorithm in conjunction with SSE, SSE2, SSE3, SSSE3, SSE4, page fault analysis to exhaustively enumerate the distinct x86 SSE4.2, SSE5, AES-NI, CLMUL, instructions, while requiring no pre-existing knowledge of the RdRand, SHA, MPX, SGX, XOP, F16C, ADX, BMI, FMA, AVX, AVX2, AVX512, instruction format.
    [Show full text]
  • Pentium FDIV Bug from Wikipedia, the Free Encyclopedia
    Pentium FDIV bug From Wikipedia, the free encyclopedia The Pentium FDIV bug is a bug in the Intel P5 Pentium floating point unit (FPU). Because of the bug, the processor can return incorrect decimal results, an issue troublesome for the precise calculations needed in fields like math and science. Discovered by Professor Thomas R. Nicely at Lynchburg College,[1] Intel attributed the error to missing entries in the lookup table used by the floating-point division circuitry.[2] Though rarely encountered by average users 66 MHz Intel Pentium (Byte magazine estimated that 1 in 9 billion (sSpec=SX837) with the floating point divides with random parameters FDIV bug would produce inaccurate results),[3] both the flaw and Intel's initial handling of the matter were heavily criticized. Intel ultimately recalled the defective processors. Contents 1 Chronology 2 Affected models 3 Example symptoms 4 See also 5 References 6 External links Chronology Thomas Nicely, a professor of mathematics at Lynchburg College, had written code to enumerate primes, twin primes, prime triplets, and prime quadruplets. Nicely noticed some inconsistencies in the calculations on June 13, 1994, shortly after adding a Pentium system to his group of computers, but was unable to eliminate other factors (such as programming errors, motherboard chipsets, etc.) until October 19, 1994. On October 24, 1994, he reported the issue to Intel. According to Nicely, his contact person at Intel later admitted that Intel had been aware of the problem since May 1994, when the flaw was discovered by Tom Kraljevic, a Purdue co-op student working for Intel in Hillsboro, OR, during testing of the FPU for its new P6 core, first used in the Pentium Pro.
    [Show full text]