Microarchitectural for monitoring application specific instructions Sai Chandra kosaraju

Introduction In present scenario  we have absorbed driving reliability and security are most major and critical concerns for embedded processors and computer hardware's . The vulnerabilities in the system to the software attacks has increased, This leads for  a new design goal for security in addition to the design constraints of performance and power consumption . The security attacks includes elements like  buffer overflow, fault injections, and data and software integrity attacks

Application-specific instruction-set processors (ASIPs) It is a component used in system-on-chip(SoC) design. The instruction set of ASIP is designed to get benefit of a specific application. This special design of the core provides a tradeoff between CPU and ASIC , that is general purpose of CPU and the performance of an AISC. ASIPs have a customizable or configuration instruction set . ASIPs  cores are divided into two parts  1)Static logic which defines a minimum Instruction-set-architecture 2)Configurable logic which is used to design a new instruction set. The Configurable logic can be either programmed during the chip synthesis or in the fields similar to the FPGAs (Field programming gate arrays)

Advantages of ASIPs We can ASIPs as alternative for hardware accelerators as baseband signal processing or video coding. With traditional hardware in the market our primary concern  is to  reuse the hardware datapath with handwritten FSM it is very difficult . The retargetable compilers of ASIPs come in handy to the designer to update the program and reuse the datapath without the change of hardware. The  ASIPs has a  ability to  allow  designers  to customize the instruction set architecture (ISA)for a specific application domain.

Overview of the topic By monitoring run-time of program execution  We will go through  the problem of program code integrity monitoring  Step 1:- A monitor design in such a way it should capture properties of the permissible behavior and compare it with the real time  execution. Step 2:-When there is a mismatch or deviation is detected  the monitor throws an exception  Even though there are many  hardware-assisted architectural mechanisms for security supports , the main disadvantage is their separate hardware modules are not directly coupled with microprocessors. In addition, they  require compiler supports and result in considerable performance and overheads . As remedy for this problem we use  ASIPs, as ASIPs connects both the ISA and underlying microarchitecture

Work for monitoring run time execution of program:- Our main problem of security attacks and soft errors can be solved by  Monitoring code integrity technique. To prevent our computers hardware's against  security attacks that execute malicious code, The checkpoints will be placed at  multiple layers in a system.  hardware approaches have been proposed to protect the code when it is stored in memory. Here we Discuss about two approaches XOM and AEGIS  XOM:- XOM encrypts code and it only allows instructions to be executed it doesn't allow the code to modify. AEGIS:- AEGIS encrypts both code and data that stored in off-chip memory and it uses hash functions to check the integrity of code and data in cache .

Proposals and disadvantages of other method The scientist named Zhang et al. proposed method called SWIFT a separate secure co- processor for monitoring critical kernel data structures .however this  secure co-processor, is too expensive to be used for  low-end computing devices. The disadvantage of this method is it cannot detect multiple-bit faults and it pre assumes that the processor has sufficient resources like registers and functional units to execute  codes without significant performance degradation. however this  secure co-processor, is too expensive to be used for  low-end computing devices. The scientist Arora et al. proposed a run-time monitoring method and  implemented with hardware . In addition to the integrity of instruction streams, this method also monitors interprocedural and intraprocedural control flow . Since its architecture is separated from the pipeline It slows down the performance and cycle time of processor. The scientist Ragel et al. proposed a method called IMPRES to monitor processor security, reliability and runtime, where he used a special register to store the expected checksum of a basic block and this value is checked with the checksum generated during the run-time.  This extra set instructions requires re-compilation of program  and binary instrumentation which result in significant code size increase and performance of the hardware will be  degradation. 

Code Monitoring The hash values are a good indicator to identify  program behaviors, here they monitor program code integrity by comparing two hash values of the instruction streams. First hash value is obtained  before the program starts in the processors it is considered   as the expected behavior of the program. The second other hash is generated after instructions set fetched in  the processor during  runtime  The expected hash values  should be computed statically before the execution and should be matched with the dynamic hash if the program is not compromised. A behavior violation of runtime should be detected promptly and the compromised code or code which takes abnormal runtime should be stopped before any damages are inflicted. The hardware and performance overhead involved in monitoring the run-time checking should be reasonable and flexible.

Location of Code Monitoring We would like to place it close to the decode stage as possible, because  We need to capture more potential code changes during the fetching phase In this process to we incorporate the runtime monitoring mechanism into pipelines and perform the checking in the instruction fetch (IF) and decode (ID) stages.  Any alterations in the code made before instructions are fetched into processor pipeline will be detected. 

Managing Hash Values To compute and compare hash values, the microarchitecture needs to upgrade. An internal hash table (IHT) which is a special register is added to store expected hash values.  When the execution of the program  proceeds to the end of our basic block where IHT, the IHT(internal hash table) is searched. If the hash table entry for this basic block is found and the expected one matches the dynamic hash value, then it is a called a hash hit and the basic block is intact and the program will execute.  The second case ,If the basic block of the program is found in the internal hash table (IHT) but our the dynamic hash does not match the value at the basic block it is called as hash mismatch. Third case the basic block is not found in the hash table at all for the program it is called hash miss,

Loading the hash values into basic blocks Loading an hash value into IHT can be done by two ways:- If applications load the hash values into hash table, then compilers need to insert at proper locations of programs the instructions that load expected hash values. It increase the code size and complexity of the compiler. The OS can be manage IHT . The compiler will still generate the expected hashes for each block. Here all the hash values are attached to the application code itself and when the application starts data will be loaded into a section of memory which is managed by the OS application loader. In Hash miss case when the hash value is not found in (IHT) then the full hash table (FHT) in memory will be searched and if found some entries in the IHT will be replaced by the found values. If the dynamic value is not found either in the FHT , or program dynamic hash is different from the hash value in IHT, the OS will just terminate the program.

Design representation

Design representation Here datapath flow is divided into 5 stage pipelines IF,ID,EX,MEM,WR .IF indicates for instruction fetch ,ID indicates instruction decode ,EX indicates execute, MEM indicates memory register and WR indicates write and read operations .since we discussed early that the monitoring mechanism is placed close to execution so it compares the hash from instruction decode phase. The dataflow pipeline stages interact with the instruction cache, data cache, and control logic which are placed to the left of datapath. For code monitoring purpose the data path is extended with a Code Integrity Checker (CIC) which is placed below the processor's datapath, where our internal hash table (IHT ) is setup to capture dynamic hash values and expected program behavior of program, a hash functional unit (HASHF U ) to  compute the dynamic hash value of the program in execution and forwards the values to COMP(comparator), and a comparator (COMP ) compares the both hash values and detect deviation of program execution from the expected behavior at run-time. Exception signals will be passed to OS when a hash miss or a mismatch is detected in COMP(comparator).The control logic will notify the OS to take control and respond with actions to terminate a program. Since the components in the code integrity checker are distributed into different pipeline stages, CIC will not affect the number of execution cycles for any program running on the processor.

Internal Hash table architecture The internal hash table IHT is again divided into three parts Add st , Add en ,hash .Where Add st for starting address Add en stands ending address hash is for behavioral analysis. CONCLUSION:-    We this method we can detect soft errors and security attacks before execution stage and we can protect our hardware's for malicious threats

Above figure represents one of the Hash miss rates where x-axis represents type of instructions and y-axis represents % of hash miss rate for different number of instructions

References ASIP Meister. [http://www.eda-meister.org/asipmeister]. G. A. Reis, J. Chang, N. Vachharajani, R. Rangan, and D. I.August. SWIFT: Softwareimplemented fault tolerance. In Proc. Int. Symp. on Code Generation & Optimization,2005. Z. Shao, Q. Zhuge, Y. He, and E. H.-M. Sha. Defending embedded systems against buffer overflow via hardware/software. In Proc. Annual Computer Security Application Conf., pages 352–361, Dec. 2003. doi.ieee computer society.org/10.1109/DATE.2007.364391 https://www.semanticscholar.org/paper/Microarchitectural-Support-for- Program-Code-Integr-Fei- Shi/05b1ae9f50e4af7356a2c628da86efc0fb452e77

Thank you

de