In-circuit Emulators Research Articles

Self-Spectre, Write-Execute and the Hidden State

Abstract The recent Meltdown and Spectre vulnerabilities have highlighted a very present and real threat in the on-chip memory cache units which can ultimately provide a hidden state, albeit only readable via memory timing instructions [Kocher, P.—Genkin, D.— Gruss, D.— Haas, W.—Hamburg, M.—Lipp, M.–Mangard, S.—Prescher, T.—Schwarz, M.—Yarom, Y.: Spectre attacks: Exploiting speculative execution, CoRR, abs/1801.01203, 2018]. Yet the exploits, although having some complexity and slowness, are demonstrably reliable on nearly all processors produced for the last two decades. Moving out from looking at this strictly as a means of reading protected memory, as the large microprocessor companies move to close this security vulnerability, an interesting question arises. Could the inherent design of the processor give the ability to hide arbitrary calculations in this speculative and parallel side channel? Without even using protected memory and exploiting the vulnerability, as has been the focus, there could very well be a whole class of techniques which exploit the side-channel. It could be done in a way which would be largely un-preventable behavior as the technology would start to become self-defeating or require a more complicated and expensive on-chip cache memory system to properly post-speculatively clean itself. And the ability to train the branch predictor to incorrectly speculatively behave is almost certain given hardware limitations, andthusprovidesexactly this pathway. A novel approach looks at just how much computation can be done speculatively with a result store via indirect reads and available through the memory cache. A multi-threaded approach can allow a multi-stage computation pipeline where each computation is passed to a read-out thread and then to the next computation thread [Swanson, S.—McDowell, L. K.—Swift, M. M.—Eggers, S. J.–Levy H. M.: An evaluation of speculative instruction execution on simultaneous multithreaded processors, ACM Trans. Comput. Syst. 21 (2003), 314–340]. Through channels like this, an application can surreptitiously make arbitrary calculations, or even leak data without any standard tracing tools being capable of monitoring the subtle changes. Like a variation of the famous physics Heisenberg uncertainty principle, even a tool capable of reading the cache states would not only be incredibly inefficient, but thereby tamper with and modify the state. Tools like in-circuit emulators, or specially designed cache emulators would be needed to unmask the speculative reads, and it is further difficult to visualize with a linear time-line. Specifically, the AES and RSA algorithms will be studied with respect to these ideas, looking at success rates for various calculation batches with speculative execution, while having a summary view to see the rather severe performance penalties for using such methods. Either approaches could provide for strong white-box cryptography when considering a binary, non-source code form. In terms of white-box methods, both could be significantly challenging to locate or deduce the inner workings of the code. Further, both methods can easily surreptitiously leak or hide data within shared memory in a seemingly innocuous manner.

Testing distributed embedded systems through logic analyzer

Testing distributed embedded systems is complex as the individual systems connected on to the network are heterogeneous in nature.The communication system that is used for establishing the networking also varies greatly leading to different testing requirements. Testing of embedded systems can be carried using different methods that include Scaffolding, assert macros, instruction set simulators. In-circuit emulators, logic analyzers each requiring establishment of different testing environment required for undertaking actual testing. Testing of any embedded systems involves testing hardware, testing hardware dependent code, and testing hardware independent code. Logic analyzers are generally used for testing proper working of the Hardware.In this paper, a framework is presented using which testing of hardware distributed across the distributed embedded system using logic analyzer is presented.

Hardware-Software Approaches to In-Circuit Emulation for Embedded Processors

In-circuit emulators have become part of the permanent structure of microprocessor cores to support on-chip test and debug activities in highly integrated environments such as SoCs. However, ICE design styles and operation principles are quite diverse. This article presents a taxonomy based on the notions of foreground and background operations and hardware-software implementation alternatives to organize existing in-circuit emulation approaches.

Engineering change protocols for behavioral and system synthesis

Rapid prototyping and development of in-circuit and FPGA-based emulators as key accelerators for fast time-to-market has resulted in a need for efficient error correction mechanisms. Fabricated or emulated prototypes upon error diagnosis require an effective engineering change (EC). We introduce a novel design methodology which consists of pre- and post-processing techniques that enable EC with minimal perturbation. Initially, in a synthesis preprocessing step, the original design specification is augmented with additional design constraints which ensure flexibility for future correction. Upon alteration of the initial design, a new post-processing technique achieves the desired functionality with near-minimal perturbation of the initially optimized design. The key contribution is a constraint manipulation technique which enables the reduction of an arbitrary EC problem into its corresponding classical synthesis problem. As a result, in both pre- and post-processing for EC, classical synthesis algorithms can be used to enable flexibility and perform the correction process. We demonstrate the developed EC methodology on a set of behavioral and system synthesis tasks.

In-Circuit Emulators in the Microprocessor Laboratory

Microprocessor workstations, which include in-circuit emulators, now form the basis of the microprocessor interfacing course at the University of Kentucky. The availability of in-circuit emulators at a moderate cost allowed us to build six workstations to serve our senior and graduate students. Each workstation has a computer, an emulator, and a target system on which interface experiments can be connected. With this new equipment, we have seen a significant increase in the productivity and the quality of the work of the students and an improvement in their attitude toward the laboratory.

Instrumentation: Powerful microprocessors and standard buses help advance modular card instrumentation; meanwhile bench test equipment gets new features

The trend toward digital processing in test instrumentation continues unabated. Advances in the performance of microprocessors and the linkage of personal computers and workstations to instrumentation in 1985 increased not only data acquisition capability, but also the processing and analysis power of the instruments themselves. Powerful 16-bit processors-for instance, Motorola's MC6800 family-have allowed complex data analysis software to be built into instruments, often with user interfaces that are similar to those of personal computers. Improvements made to oscilloscopes, logic analyzers, and in-circuit emulators are discussed.

A hierarchical microprocessor laboratory facility

The microprocessor course offered by the Electrical Engineering and Computer Science department at the University of Santa Clara is a hardware/applications oriented course. Hardware interfacing as well as software is emphasized with laboratory equipment designed to facilitate hands-on hardware experience in a real-time environment. The needs of a real-time laboratory render the use of simulators and other non-real-time debugging tools inappropriate. Students should have individual hardware access as provided by single-board computers, and real-time analyzers or in-circuit emulators. Unfortunately, although such facilities are excellent for hardware development, their utility for software development is very restrictive. A hierarchical organization that provides software (top level) and hardware (bottom level) facilities will be described.

Development of a microprogrammable microprocessor system by means of a PDP-8E minicomputer

This paper describes a realized solution for some practical problems of microprogrammable microprocessor system applications, i.e. generation and verification of microprograms. The solution is especially suitable for emulation applications, e.g. simulation of the central processing unit of computers. Automatic microprogram generating, optimizing and verifying high level program were not used for microprogram writing. As a matter of fact the procedure itself and the hardware structure form a round whole, therefore neither the known microassemblers (CROMIS [8], Signetics Micro Assembler [9] nor incircuit emulators (as Intel MDS ICE-30 or the one described in [10]) were not applied. The program package described syntactically checks the symbolic source microprograms, makes it possible to edit the source programs, assembles them, and produces binary object programs. The hardware-software system presented here is Intel-3000 microprocessor family oriented but is applicable to any other type of microprogrammable microprocessor. The method for the symbolic writing of microprograms is presented; the assembler and auxiliary programs for generating and correcting microprograms are then described; and finally, descriptions of the development system and the program verification are given.

A hierarchical microcomputer system for hardware and software development

This paper describes a facility for integrated hardware and software development in the microprocessor area by graduate students. The constraints of a low budget, the necessity of providing fast turn-around time for software development, and tightly scheduled laboratory sessions, all of which are necessary in a university environment, precluded the use of methods such as primitive handtranslation of code (too slow), separate floppy-based development systems (too expensive) and in-circuit emulators (too expensive). The result was a hierarchical network of microprocessors whose design and development is described in detail. Experience with its operation and the applicability of the system for more general use is also discussed.