We continue discussing the paper "Shielding applications from an untrusted cloud with Haven,” written by Andrew Baumann, Marcus Peinado, and Galen Hunt. Today we review the SGX Limitations and workarounds. There were three main limitations encountered. These were in addition to the need for dynamic memory allocation that unmodified applications required. Together these limitations were hard enough to prevent the unmodified applications to run. Therefore SGX needed to be revised. The paper mentions workarounds for these limitations. They are :
Exception handling, Permitted instructions and Thread-local storage. SGX allows an enclave to handle its own exceptions by reporting the exception cause and register context securely. But the exceptions are not always reported to the enclave. Hardware interrupts were not reported because they divulged private information about the host. The list of reported exceptions included program faults such as division by zero, breakpoint instructions, and undefined instructions, and floating point/SIMD exceptions, but not page faults or general protection faults. This prevented the enclave from handling these faults without trusting the host. But faults such as page faults are handled in user mode code. SGX was therefore revised to report these faults to the enclave.
The permitted instructions prohibits in-enclave execution of instructions that may cause VM exit or change software privilege levels. But three of these instructions are commonly encountered in applications and LibOS. These are CPUID, RDTSC and IRET. The first one queries processor features to test for extended instructions. It is prevented because a VM may trap and emulate it. However emulation doesn't work because the enclave's registers are not visible to the hypervisor. Haven worksaround it by emulating CPUID in its exception handler with static knowledge of features available on SGX. The second instruction return the cycle counter and are used as timestamps. SGX prevents it, because like CPUID, they may cause a VM exit but unlike CPUID, they may cause a VM exit. SGX was revised to permit it if VM exit is disabled. IRET is an interrupt return and it is used at the end of an exception handler when restoring processor state. It is disallowed because it can change protection level. Haven worksaround it by emulating IRET. The third limitation stems from legacy architectures such as x86 using FS or GS segments from Thread control structures (TCS) but TCS is immutable once created. This prevented user mode scheduling in shield module. Haven worksaround it by mapping application threads 1:1 onto TCSs and host threads. Revised SGX has addressed this limitation.
#typewritermonkey problem
A typewriter consists of K keys from the upper case English alphabets with repetitions. A monkey can type one letter at a time to make a string of length S. A target word of length L can appear many times in the output. The monkey can get paid one banana for each word. If you bring as many bananas such that you will not run out, how much can you expect to keep.
The solution here is to find the max and the average of the number of success. The max is say S-L+1 bananas if all the letters of the target word are in the K keys. The average depends on the sum total of all possible successes and varies from case to case depending on what S and L are or can be taken as probability. Given the keys on the keyboard and the target word spelled out, we can choose each letter with the probability depending on the number of times it appears in K. Multiplying each letter with its probability for each of L elements gives the total probability.
Exception handling, Permitted instructions and Thread-local storage. SGX allows an enclave to handle its own exceptions by reporting the exception cause and register context securely. But the exceptions are not always reported to the enclave. Hardware interrupts were not reported because they divulged private information about the host. The list of reported exceptions included program faults such as division by zero, breakpoint instructions, and undefined instructions, and floating point/SIMD exceptions, but not page faults or general protection faults. This prevented the enclave from handling these faults without trusting the host. But faults such as page faults are handled in user mode code. SGX was therefore revised to report these faults to the enclave.
The permitted instructions prohibits in-enclave execution of instructions that may cause VM exit or change software privilege levels. But three of these instructions are commonly encountered in applications and LibOS. These are CPUID, RDTSC and IRET. The first one queries processor features to test for extended instructions. It is prevented because a VM may trap and emulate it. However emulation doesn't work because the enclave's registers are not visible to the hypervisor. Haven worksaround it by emulating CPUID in its exception handler with static knowledge of features available on SGX. The second instruction return the cycle counter and are used as timestamps. SGX prevents it, because like CPUID, they may cause a VM exit but unlike CPUID, they may cause a VM exit. SGX was revised to permit it if VM exit is disabled. IRET is an interrupt return and it is used at the end of an exception handler when restoring processor state. It is disallowed because it can change protection level. Haven worksaround it by emulating IRET. The third limitation stems from legacy architectures such as x86 using FS or GS segments from Thread control structures (TCS) but TCS is immutable once created. This prevented user mode scheduling in shield module. Haven worksaround it by mapping application threads 1:1 onto TCSs and host threads. Revised SGX has addressed this limitation.
#typewritermonkey problem
A typewriter consists of K keys from the upper case English alphabets with repetitions. A monkey can type one letter at a time to make a string of length S. A target word of length L can appear many times in the output. The monkey can get paid one banana for each word. If you bring as many bananas such that you will not run out, how much can you expect to keep.
The solution here is to find the max and the average of the number of success. The max is say S-L+1 bananas if all the letters of the target word are in the K keys. The average depends on the sum total of all possible successes and varies from case to case depending on what S and L are or can be taken as probability. Given the keys on the keyboard and the target word spelled out, we can choose each letter with the probability depending on the number of times it appears in K. Multiplying each letter with its probability for each of L elements gives the total probability.
No comments:
Post a Comment