In this section, we will discuss some of the potential applications of the register to variable mapping information extracted by our proposed method REVAMP.
5.4.1 Register Allocation and Security Aspect
Register allocation is the mapping of a large number of variables to a limited number of physical registers. Let us assume thatVibe the set of variables withinumber of variables in a program andRj be the set of registers withj number of registers in the target architecture.
Register allocation is a function which maps the set of variables to the set of registers and/or memory locations, f : Vi Ñ RjYMk where usually j ď i and Mk is the reserved memory
REVAMP: Reverse Engineering Register to Variable Mapping in High-Level Synthesis
locations for arrays Vk where 0 ďk ďi. The following scenarios may arise due to register allocation.
´ A variable va is mapped to a register rx, i.e. fpvaq “rx.
´ More than one variable are mapped to a register. For example, fpvaq “fpvbq “fpvcq “ rx means the variables va,vb and vc are mapped to the register rx.
´ A variable is mapped to more than one register, i.e. fpvaq “ trx, ry, rzu which is called the live range splitting. In this case, some re-definitions of va is renamed first and then different instances of va is mapped to different registers. Usually, it reduces the register pressure. In case of limited registers, live range splitting is used if it minimizes the register usage.
´ If there are not enough registers, a array variable needs to be stored into memory, i.e.
fpvaq “ma wherema is the reserved memory location for the variable va.
Securing compiler transformation is an emerging research area and very few works have been done on trusted code generation. The correctness-security gap of compiler optimiza- tions attract some attention in recent times. D’Silva et al. [58] studied various compiler transformations to identify the leaky one. They conclude that the gap arises due to the techniques that do not model the state of the underlying machine. They only considered the transformations at the source level, nothing mentioned the information leaks in register allocation. Deng and Namjoshi presented a polynomial-time algorithm for secure dead store elimination in [56]. Recently, Besson et al. [27] proposed a formal definition of the Informa- tion Flow Preserving (IFP) program transformations in which they model the information leak of a program using the notion of attacker knowledge. The authors have shown how to validate register allocation and dead store elimination and if needed how to modify it in order to be IFP.
Register allocation is a mandatory transformation for any source program to generate the machine code. Thus, it should be properly investigated from the security point of view.
Moreover, none of the existing works provide a secure register allocation algorithm. In this work, we target the reverse engineering of the register to variable mapping in register allocation. Although, this work does not target the security analysis of register allocation, the recovered mapping can be useful in analyzing the same. Specifically, this mapping
Applications of REVAMP Framework
information can be used to identify the information leakage after register mapping and then iteratively modify the register allocation to stop the leak. This could be interesting future work.
5.4.2 Correlating C and RTL
The quality of designing a hardware device by the HLS tools depend on the way one has written the design specification in C/C++ code. From specification document, an RTL de- scription is created to examine the design in terms of functionality, performance, compliance with standards and other high-level issues by HLS tools. On the other hand, the high-level specification developers do not understand how the specification is represented in RTL. In order to help specification developers understand, debug and verify an RTL design that is generated from the HLS tool, it is important to bridge the knowledge gap between the two levels of abstraction. A C equivalent of the RTL model would be helpful for the specification developers to understand, debug and verify the output RTL design and hence use the HLS tool meaningfully. One of the important steps in obtaining a high-level C behaviour from the RTL is to recover the mapping between variables in input C and registers in the RTL generated by HLS. Our work is helpful in this context.
5.4.3 Fast Simulation and Debug
As discussed in Chapter3, the RTL co-simulation is the primary way to verify the correctness of the generated RTL of an HLS tool. Specifically, the test cases developed for the input C code are used by the commercial HLS tools [10] for RTL simulation. The C-simulation is faster than the RTL simulation. Therefore, generating an equivalent C code from the RTL would greatly reduce the verification time as well. In FastSim [15], an C code obtained from the RTL is shown to be much faster for RTL verification. However, the code obtained from the RTL cannot be used for correlating the bug with the source C code of the HLS tool and hence for souce level debug. With the variable to register mapping information obtained in our work, correlating the source C with RTL is possible in debugging a bug in the RTL.
REVAMP: Reverse Engineering Register to Variable Mapping in High-Level Synthesis
