Current Limitations

Current Limitations

This pages describes the current limitations of PoMMES. The limitations can be divided into two part. First, restrictions on the input of PoMMES, i.e., the provided C code. Second, limitations regarding the behavior of PoMMES.

Initial C Code

PoMMES can handle different syntactical structures. In our examples we are able to handle

• conditions
• loops
• function calls
• pointers
• local arrays

which should already cover a wide range of functionality found in masked software gadgets. However, PoMMES is far from handling the extensive programming options that are supported by the C language.

A list of currently unsupported C syntax includes, but is not limited to

• structs
• unions
• custom data types in general
• dynamic memory allocation
• floating point instructions
• globally defined arrays

There are two main reasons why this syntax is currently not supported.

• First, the parser written to extract the information from the GIMPLE file into the internal structure of PoMMES is not yet capable of doing so.
• Second, it needs to be investigated how good the generated GIMPLE file is able to retain information about for example structs and unions. If the GIMPLE file is not extensive enough to deduce enough information to generate assembly code for certain syntax structures, e.g. structs and unions, then it would require a different starting point for PoMMES.

Furthermore, to ease the analysis of PoMMES we allow only unique variable definitions in the function, i.e., variable names must only be defined once. This means the following code can currently not be handled by PoMMES, as the loop variable i for both loops has the same variable name.

for(int i = 0; i < 10; ++i){
  int x = i;
}
for(int i = 0; i < 5; ++i){
  int y = i;
}

In order for PoMMES to handle the code it should be rewritten, such that there is no redefinition of i, e.g.

for(int i = 0; i < 10; ++i){
  int x = i;
}
for(int j = 0; j < 5; ++j){
  int y = j;
}

PoMMES Internals

Currently, PoMMES focuses only on one compiler backend step namely the register allocation. Other backend steps, i.e., instruction scheduling, instruction selection, and optimizations are out of scope and were implemented trivially. This, in combination with our modifications to the register allocation algorithm introduces a significant overhead on the generate assembly code.