Pentium FDIV Bug

Total Page:16

File Type:pdf, Size:1020Kb

Pentium FDIV Bug Pentium FDIV bug The Pentium FDIV bug was a computer bug that affected the floating point unit (FPU) of the early Intel Pentium processors. Because of the bug, the processor might return incorrect binary floating point results when dividing a number. Discovered in 1994 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] The severity of the FDIV bug is debated. Intel, producer of the affected chip, claims that the common user would experience it once every 27,000 years while IBM, manufacturer of a chip competing with Intel's Pentium, claims that the common user would experience it once every 24 days. Though rarely encountered by most users (Byte magazine estimated that 1 in 9 billion floating point divides with random parameters would produce inaccurate results),[3] both the flaw and Intel's initial handling of the matter were heavily criticized by the tech community. In December 1994, Intel recalled the defective processors. In January 1995, Intel announced "a pre-tax charge of $475 million against earnings, ostensibly the total cost associated with replacement of the flawed processors."[1] 66 MHz Intel Pentium Contents (sSpec=SX837) with the FDIV bug Chronology Affected models Example symptoms See also References 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 University co-op student working for Intel in Hillsboro, Oregon, during testing of the FPU for its new P6 core, first used in the Pentium Pro. On October 30, 1994, Nicely sent an email describing the error he had discovered in the Pentium floating point unit to various contacts, requesting reports of testing for the flaw on 486-DX4s, Pentiums and Pentium clones.[1] This flaw in the Pentium FPU was quickly verified by other people around the Internet, and became known as the Pentium FDIV bug (FDIV is the x86 assembly language mnemonic for floating-point division). One example was found where the division result returned by the Pentium was off by about 61 parts per million.[1] The story first appeared in the press on November 7, 1994, in an article in Electronic Engineering Times, "Intel fixes a Pentium FPU glitch" by Alexander Wolfe.[4] The story was subsequently picked up by CNN in a segment aired on November 21, 1994.[1] This brought it into widespread public prominence. Publicly, Intel acknowledged the floating-point flaw, but claimed that it was not serious and would not affect most users. Intel offered to replace processors to users who could prove that they were affected. However, although most independent estimates found the bug to be of little importance and would have negligible effect on most users, it caused a great public outcry. Companies like IBM (whose IBM 5x86C microprocessor competed at that time with the Intel Pentium line) joined the condemnation. On December 20, 1994, Intel offered to replace all flawed Pentium processors on the basis of request, in response to mounting public pressure.[5] Although it turned out that only a small fraction of Pentium owners bothered to get their chips replaced, the financial impact on the company was significant. On January 17, 1995, Intel announced "a pre-tax charge of $475 million against earnings, ostensibly the total cost associated with replacement of the flawed processors."[1] Some of the defective chips were later turned into key rings by Intel.[6] A 1995 article in Science describes the value of number theory problems in discovering computer bugs and gives the mathematical background and history of Brun's constant, the problem Nicely was working on when he discovered the bug.[7] Affected models This problem occurs only on some models of the original Pentium processor.[8] The bug only existed in some Pentium family processors with a clock speed of less than 120 MHz.[8] On affected models, the Intel Processor Frequency ID Utility checks for the presence of this bug. The ten affected processors are listed below. The 39 S-specs of those processors are not listed in the Intel processor specification finder web page. Pentium P5 800 nm 5V Family Model Stepping Core stepping Clock rate FSB speed S-spec 5 1 3 B1 60 MHz 60 MHz Q0352, Q0412, SX753 5 1 3 B1 66 MHz 66 MHz Q0353, Q0413, SX754 5 1 5 C1 60 MHz 60 MHz Q0466, SX835, SZ949 5 1 5 C1 66 MHz 66 MHz Q0467, SX837, SZ950 Pentium P54C 600 nm 3.3V Family Model Stepping Core stepping Clock rate FSB speed S-spec 5 2 1 B1 75 MHz 50 MHz Q0601 5 2 1 B1 90 MHz 60 MHz Q0542, Q0613, Q0543, SX879, SX885, SX909, SX874 5 2 1 B1 100 MHz 66 MHz Q0563, Q0587, Q0614, SX886, SX910 5 2 2 B3 75 MHz 50 MHz Q0606, SX951 5 2 2 B3 90 MHz 60 MHz Q0628, Q0611, Q0612, SX923, SX922, SX921, SX942, SX943, SX944, SZ951 5 2 2 B3 100 MHz 66 MHz Q0677, SX960 Example symptoms The presence of the bug can be checked manually by performing the following calculation in any application that uses native floating point numbers, including the Windows Calculator or Microsoft Excel in Windows 95/98. The correct value is: When converted to the hexadecimal value used by the processor, 4,195,835 = 0x4005FB and 3,145,727 = 0x2FFFFF. The '5' in 0x4005 triggers the fault in the FPU control logic. As a result, the value returned by a flawed Pentium processor in certain situations is incorrect at or beyond four digits:[9][10] Another way of detecting the bug is using the pentnt utility included with Windows NT 3.51, NT 4.0, 2000, and XP.[11] See also Pentium F00F bug Meltdown (security vulnerability) and Spectre (security vulnerability) MOS Technology 6502 bugs and quirks Accuracy problems in floating point operations SRT division References 1. Professor Thomas Nicely. "Pentium FDIV flaw FAQ" (http://www.trnicely.net/pentbug/pentbug.html). 2. "Statistical Analysis of Floating Point Flaw: Intel White Paper" (http://download.intel.com/support/processors/pentium/sb/FDIV_Floating_Point_Flaw_Pentium_Processor.pdf) (PDF). Intel. 9 July 2004. p. 9. Solution ID CS-013007. Retrieved 5 April 2016. 3. Tom R. Halfhill (March 1995). "An error in a lookup table created the infamous bug in Intel's latest processor" (https://web.archive.org/web/20060209005434/http://www.byte.com/art/9503/sec13/art1.ht m). BYTE (March 1995). Archived from the original (http://www.byte.com/art/9503/sec13/art1.htm) (– Scholar search (https://scholar.google.co.uk/scholar?hl=en&lr=&q=intitle%3AAn+error+in+a+looku p+table+created+the+infamous+bug+in+Intel%27s+latest+processor&as_publication=%5B%5BBYTE%5D%5D&as_ylo=&as_yhi=&btnG=Search)) on February 9, 2006. Retrieved 2006-12-19. 4. Alexander Wolfe. "Intel fixes a Pentium FPU glitch" (http://davefaq.com/Opinions/Stupid/Pentium.html#glitch). 5. "Intel adopts upon-request replacement policy on Pentium processors with floating point flaw; Will take Q4 charge against earnings" (https://archive.is/20120710222033/http://findarticles.com/p/articles/ mi_m0EIN/is_1994_Dec_20/ai_15939945). Business Wire. 1994-12-20. Archived from the original (http://findarticles.com/p/articles/mi_m0EIN/is_1994_Dec_20/ai_15939945) on 2012-07-10. Retrieved 2006-12-24. 6. "How many engineers does it take to change a lightbulb?" (http://www.boiledbeans.net/2009/04/20/how-many-engineers-does-it-take-to-change-a-lightbulb/). Boiledbeans. 20 April 2009. Retrieved 10 November 2009. 7. Cipra, Barry A. (1995-01-13). "How number theory got the best of the Pentium chip". Science. 267 (5195): 175. doi:10.1126/science.267.5195.175 (https://doi.org/10.1126%2Fscience.267.5195.175). PMID 17791336 (https://www.ncbi.nlm.nih.gov/pubmed/17791336). 8. "FDIV Replacement Program: Frequently asked questions" (http://www.intel.com/support/processors/pentium/sb/CS-012748.htm). Intel. 2009-03-20. Solution ID CS-012748. Retrieved 2009-11-10. 9. "Pentium FDIV bug - a Picture" (http://www.ipsr.ku.edu/stafffil/hoyle/pentium_fdiv/). Kansas University Institute for Policy and Social Research. 1994-11-30. Retrieved 2010-11-03. 10. "Ivars Peterson's MathTrek: Pentium Bug Revisited" (https://web.archive.org/web/20081210133154/https://www.maa.org/mathland/mathland_5_12.html). Mathematical Association of America. Archived from the original (https://www.maa.org/mathland/mathland_5_12.html) on 10 December 2008. 11. "Pentnt" (https://technet.microsoft.com/en-us/library/bb490967.aspx). Microsoft TechNet. External links Personal website of Dr. Nicely, who discovered the bug (http://www.trnicely.net/#PENT) A page with precise information, also about the cause (http://www.cs.earlham.edu/~dusko/cs63/fdiv.html) A Tale of Two Numbers (http://www.mathworks.com/company/newsletters/news_notes/pdf/win95cleve.pdf), by Cleve Moler of MathWorks ZIP-file containing more details (http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=1666&objectType=file) (See ZIP file format for details on the file) Intel's official site (https://web.archive.org/web/20010429062848/http://support.intel.com/support/processors/pentium/fdiv/) Unopened Intel CPU box from the FDIV replacement program (http://www.cpucollection.se/details.php?image_id=784) Retrieved from "https://en.wikipedia.org/w/index.php?title=Pentium_FDIV_bug&oldid=822061952" This page was last edited on 24 January 2018, at 04:51.
Recommended publications
  • Wdv-Notes Stand: 29.DEZ.1994 (2.) 329 Intel Pentium – Business Must Learn from the Debacle
    wdv-notes Stand: 29.DEZ.1994 (2.) 329 Intel Pentium – Business Must Learn from the Debacle. Wiss.Datenverarbeitung © 1994–1995 Edited by Karl-Heinz Dittberner FREIE UNIVERSITÄT BERLIN Theo Die kanadische Monatszeitschrift The Im folgenden sowie in den wdv-notes verbreitet werden, wenn dabei die folgen- Computer Post, Winnipeg veröffentlicht Nr. 330 werden diese Artikel im Original den Spielregeln beachtet werden. in mehreren Artikeln in ihrer Januar-Aus- nachgedruckt. Der Dank dafür geht an Permission is hereby granted to copy gabe 1995 eine exzellente erste Zusam- Sylvia Douglas von The Computer Post, this article electronically or in any other menfassung des Debakels um den Defekt 301 – 68 Higgins Avenue, Winnipeg, Ma- form, provided it is reproduced without des Pentium-Mikroprozessors [1–2] des nitoba, Canada, Email: SDouglas@post. alteration, and you credit it to The Compu- Computergiganten Intel. mb.ca. Diese Artikel dürfen auch weiter- ter Post. Intel’s top of the line Pentium™ microproc- This particular error in the Pentium was in essor chip has turned out to have a slight flaw the floating-point divide unit. Intel manage- Editorial: The Computer Post – Jan.95 in its character: when dividing certain rare ment was concerned enough about it that pairs of floating point numbers, it gives the they pulled together a special team to assess The Way it Will Be wrong answer. For anyone who owns a Pen- the implications. tium-based computer, or was thinking about This month you’ll find we’re reporting a In the words of Andrew Grove, Intel’s CEO, buying one, or is just feeling curious, here lot of background information on Intel’s posting later to the Internet [3], “We were are..
    [Show full text]
  • 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]
  • Detecting and Removing Malicious Hardware Automatically
    Appears in Proceedings of the 31st IEEE Symposium on Security & Privacy (Oakland), May 2010 Overcoming an Untrusted Computing Base: Detecting and Removing Malicious Hardware Automatically Matthew Hicks, Murph Finnicum, Samuel T. King Milo M. K. Martin, Jonathan M. Smith University of Illinois at Urbana-Champaign University of Pennsylvania Abstract hardware-level vulnerabilities would likely require phys- ically replacing the compromised hardware components. The computer systems security arms race between at- A hardware recall similar to Intel’s Pentium FDIV bug tackers and defenders has largely taken place in the do- (which cost 500 million dollars to recall five million main of software systems, but as hardware complexity chips) has been estimated to cost many billions of dollars and design processes have evolved, novel and potent today [7]. Furthermore, the skill required to replace hard- hardware-based security threats are now possible. This ware and the rise of deeply embedded systems ensure paper presents a hybrid hardware/software approach to that vulnerable systems will remain in active use after the defending against malicious hardware. discovery of the vulnerability. Second, hardware is the We propose BlueChip, a defensive strategy that has lowest layer in the computer system, providing malicious both a design-time component and a runtime component. hardware with control over the software running above. During the design verification phase, BlueChip invokes This low-level control enables sophisticated and stealthy a new technique, unused circuit identification (UCI), attacks aimed at evading software-based defenses. to identify suspicious circuitry—those circuits not used Such an attack might use a special, or unlikely, event to or otherwise activated by any of the design verification trigger deeply buried malicious logic which was inserted tests.
    [Show full text]
  • Can the Computer Be Wrong?
    Can the computer be wrong? Wojciech Myszka Department of Mechanics, Materials and Biomedical Engineering January 2021 1 Data 2 Human (operator) 3 Hardware (inevitable) 4 Hardware 5 Manufacturer fault 6 Software 7 Bug free software 8 List of software bugs Data Absolute error I I was talking about this in one of the previous lectures. I One of the main sources of errors are data. I Knowing the range of each value allows us to predict values of the result. I This can be difficult and tricky. I However, in most cases we assume that the data values are correct and believe in computer calculations. Human (operator) Operator I In general, it is difficult to take into account human errors. I These include: I not understanding the problem solved by the program, I errors in preparing input data, I wrong answer to the computer prompt, I ... Hardware (inevitable) Number of bits This is a quite different source of error. 1. Most of todays computers have I 32 or 64 bits processors 2. What does this mean? Number of bits — rangeI 1. The biggest integer value I 32 bits: from −231 to 231 − 1 (−2; 147; 483; 648 to 2; 147; 483; 647) or two billion, one hundred forty-seven million, four hundred eighty-three thousand, six hundred forty-seven I 64 bits: from −263 to 263 − 1 (−9; 223; 372; 036; 854; 775; 808 to 9; 223; 372; 036; 854; 775; 807) nine quintillion two hundred twenty three quadrillion three hundred seventy two trillion thirty six billion eight hundred fifty four million seven hundred seventy five thousand eight hundred and seven 2.
    [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]
  • A Hybrid-Parallel Architecture for Applications in Bioinformatics
    A Hybrid-parallel Architecture for Applications in Bioinformatics M.Sc. Jan Christian Kässens Dissertation zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften (Dr.-Ing.) der Technischen Fakultät der Christian-Albrechts-Universität zu Kiel eingereicht im Jahr 2017 Kiel Computer Science Series (KCSS) 2017/4 dated 2017-11-08 URN:NBN urn:nbn:de:gbv:8:1-zs-00000335-a3 ISSN 2193-6781 (print version) ISSN 2194-6639 (electronic version) Electronic version, updates, errata available via https://www.informatik.uni-kiel.de/kcss The author can be contacted via [email protected] Published by the Department of Computer Science, Kiel University Computer Engineering Group Please cite as: Ź Jan Christian Kässens. A Hybrid-parallel Architecture for Applications in Bioinformatics Num- ber 2017/4 in Kiel Computer Science Series. Department of Computer Science, 2017. Dissertation, Faculty of Engineering, Kiel University. @book{Kaessens17, author = {Jan Christian K\"assens}, title = {A Hybrid-parallel Architecture for Applications in Bioinformatics}, publisher = {Department of Computer Science, CAU Kiel}, year = {2017}, number = {2017/4}, doi = {10.21941/kcss/2017/4}, series = {Kiel Computer Science Series}, note = {Dissertation, Faculty of Engineering, Kiel University.} } © 2017 by Jan Christian Kässens ii About this Series The Kiel Computer Science Series (KCSS) covers dissertations, habilitation theses, lecture notes, textbooks, surveys, collections, handbooks, etc. written at the Department of Computer Science at Kiel University. It was initiated in 2011 to support authors in the dissemination of their work in electronic and printed form, without restricting their rights to their work. The series provides a unified appearance and aims at high-quality typography. The KCSS is an open access series; all series titles are electronically available free of charge at the department’s website.
    [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]
  • P5 (Microarchitecture)
    P5 (microarchitecture) The Intel P5 Pentium family Produced From 1993 to 1999 Common manufacturer(s) • Intel Max. CPU clock rate 60 MHz to 300 MHz FSB speeds 50 MHz to 66 MHz Min. feature size 0.8pm to 0.25pm Instruction set x86 Socket(s) • Socket 4, Socket 5, Socket 7 Core name(s) P5. P54C, P54CS, P55C, Tillamook The original Pentium microprocessor was introduced on March 22, 1993.^^ Its microarchitecture, deemed P5, was Intel's fifth-generation and first superscalar x86 microarchitecture. As a direct extension of the 80486 architecture, it included dual integer pipelines, a faster FPU, wider data bus, separate code and data caches and features for further reduced address calculation latency. In 1996, the Pentium with MMX Technology (often simply referred to as Pentium MMX) was introduced with the same basic microarchitecture complemented with an MMX instruction set, larger caches, and some other enhancements. The P5 Pentium competitors included the Motorola 68060 and the PowerPC 601 as well as the SPARC, MIPS, and Alpha microprocessor families, most of which also used a superscalar in-order dual instruction pipeline configuration at some time. Intel's Larrabee multicore architecture project uses a processor core derived from a P5 core (P54C), augmented by multithreading, 64-bit instructions, and a 16-wide vector processing unit. T31 Intel's low-powered Bonnell [4i microarchitecture employed in Atom processor cores also uses an in-order dual pipeline similar to P5. Development The P5 microarchitecture was designed by the same Santa Clara team which designed the 386 and 486.^ Design work started in 1989;^ the team decided to use a superscalar architecture, with on-chip cache, floating-point, and branch prediction.
    [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]
  • APA Newsletters NEWSLETTER on PHILOSOPHY and COMPUTERS
    APA Newsletters NEWSLETTER ON PHILOSOPHY AND COMPUTERS Volume 11, Number 1 Fall 2011 FROM THE EDITOR, PETER BOLTUC FROM THE CHAIR, DAN KOLAK SPECIAL SESSION DAVID L. ANDERSON “Special Session on ‘Machine Consciousness’” FEATURED ARTICLE JAAKKO HINTIKKA “Logic as a Theory of Computability” ARTICLES DARREN ABRAMSON AND LEE PIKE “When Formal Systems Kill: Computer Ethics and Formal Methods” HECTOR ZENIL “An Algorithmic Approach to Information and Meaning: A Formal Framework for a Philosophical Discussion” PENTTI O A HAIKONEN “Too Much Unity: A Reply to Shanahan” PHILOSOPHY AND ONLINE EDUCATION RON BARNETTE “Reflecting Back Twenty Years” © 2011 by The American Philosophical Association ISSN 2155-9708 FRANK MCCLUSKEY “Reflections from Teaching Philosophy Online” TERRY WELDIN-FRISCH “A Comparison of Four Distance Education Models” KRISTEN ZBIKOWSKI “An Invitation for Reflection: Teaching Philosophy Online” THOMAS URBAN “Distance Learning and Philosophy: The Term-Length Challenge” FEDERICO GOBBO “The Heritage of Gaetano Aurelio Lanzarone” APA NEWSLETTER ON Philosophy and Computers Piotr Bołtuć, Editor Fall 2011 Volume 11, Number 1 Terry Weldin-Frish, in his informative paper, compares the ROM THE DITOR experiences he had with online learning in philosophy first as a F E graduate student, reaching a Ph.D. entirely online, and later as a faculty member, at four different educational institutons in the UK and the US. Kristen Zbikowski presents a spirited defense Peter Boltuc of teaching philosophy online based on her experiences as an University of Illinois at Springfield online student and then a faculty member also teaching online courses. Thomas Urban raises a specific problem of the length I used to share the general enthusiasm about web-only of viable online philosophy courses.
    [Show full text]
  • On Improving Cybersecurity Through Memory Isolation Using Systems Management Mode
    On Improving Cybersecurity Through Memory Isolation Using Systems Management Mode A thesis submitted for the degree of Doctor of Philosophy James Andrew Sutherland School of Design and Informatics University of Abertay Dundee August 2018 i Abstract This thesis describes research into security mechanisms for protecting sensitive areas of memory from tampering or intrusion using the facilities of Systems Man- agement Mode. The essence and challenge of modern computer security is to isolate or contain data and applications in a variety of ways, while still allowing sharing where desir- able. If Alice and Bob share a computer, Alice should not be able to access Bob’s passwords or other data; Alice’s web browser should not be able to be tricked into sending email, and viewing a social networking web page in that browser should not allow that page to interact with her online banking service. The aim of this work is to explore techniques for such isolation and how they can be used usefully on standard PCs. This work focuses on the creation of a small dedicated area to perform cryp- tographic operations, isolated from the rest of the system. This is a sufficiently useful facility that many modern devices such as smartphones incorporate dedic- ated hardware for this purpose, but other approaches have advantages which are discussed. As a case study, this research included the creation of a secure web server whose encryption key is protected using this approach such that even an intruder with full Administrator level access cannot extract the key. A proof of concept backdoor which captures and exfiltrates encryption keys using a modified processor wasalso demonstrated.
    [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]