We continue discussing the paper "Shielding applications from an untrusted cloud with Haven,” written by Andrew Baumann, Marcus Peinado, and Galen Hunt. We were discussing the limitations of SGX that Haven had to workaround and which were subsequently fixed in the revised version of SGX. We now read up on the performance evaluation. Haven was developed and tested using a functional emulator for SGX provided by Intel. This does not come with the SGX CPU and the emulator is not cycle-accurate, hence a performance model was formed. The approach was to measure Haven's sensitivity to SGX parameters. This model assumed that an SGX implementation will perform the same as a CPU. However it will have two drawbacks - first the additional costs of SGX instructions and asynchronous exits, and  second, an additional memory penalty (latency/bandwidth of cache misses )for memory encryption when accessing EPC. This ignores the cost at cold start and considers the performance after a warmup period. Many of the SGX instructions are executed only at enclave startup. EPC was considered large enough to hold the working set of the applications. The other overheads include the dynamic memory allocation and the transitions into and out of enclave mode and asynchronous exits. The dynamic allocation instructions only check and update the page protection metadata. The transitions necessitate a TLB flush and also perform a series of checks and updates.
As a control to study the comparision of Haven on SGX, a second version of Haven was implemented that does not use SGX.This simulates SGX performance for the above critical instructions by busy waiting the CPU for a configurable number of processor cycles. In addition, for each enclave transition a system call is used to flush the TLB. This adds a cost that is not on the SGX and hence this study gives a conservative estimate for the performance of Haven.  There are two disallowed instructions in SGX - IRET and CPUID but their overhead cannot be simulated. Fortunately, they happen only at startup or are very rare. To simulate memory penalties and a slower EPC,  the system's DRAM frequency was artificially reduced.
Two kinds of applications were run with this performance model. The first is a database server (SQL Server) and the second is a http server ( Apache ).  The experiments were run on a 4 core Intel processor running at 2.4 GHz with 8 GB of 1600 MHz DDR3 RAM, a 240GB SSD and a gigabit ethernet running Windows 8.1 This mobile optimized platform was used because it let the DRAM frequency and timings.
#typewritermonkey
Yesterday we were discussing a typewriter monkey problem. We said the solution depended on the max possible occurrence of the target word as well as the average expected number of target words
The max gives the number of bananas that should be brought and the average gives the number that should be handed out leaving the rest to keep. But let us take a few examples of how to get the average.
if the typewriter can only type A or B ( K = 2) and the target word is B (L=1) and the monkey types two letters (S=2) then we have four possible outputs with equal probability of AA ,AB, BA and BB giving 0,1,1 and 2 target occurrences and the average pay is 4/4= 1. Consequently we get to keep 1.
Let us assume there's a function that pattern matches. These are well known and all ready available as say regex.
Now we just have to compute the score for the monkey
max = 0
avg = 0
for each possible permutation of length S
     find substrings of length L by iterating i from 0 to S-L+1
         for each substring find number of occurrences with regex as count
             max = max(count, max);
             avg = avg + count

print output = max-(avg/ K^S)