Initial microbenchmark numbers suggest that the overhead of the Flask microkernel mechanisms can be made negligible through the use of the access vector cache and local hints when appropriate. They also highlight the need for an access vector cache so that communications with the security server and security computations within the security server are minimized. They also point to several areas for potential optimization, such as the AVC implementation, the communications infrastructure and the prototype security server computations. A complete analysis of the effectiveness of the AVC remains as future work. Issues such as the optimal cache size and the sensitivity of the AVC hit ratios to policy changes remain to be explored.
Results of the simple macrobenchmark test are inconclusive. Although the performance impact numbers are encouraging (5-11% slowdown), the bad absolute performance of the prototype system cannot be ignored. More completely exploring the performance overhead of the Flask security architecture remains as future work, and will likely be done in the context of a Linux or OSKit implementation of the architecture. This will permit more realistic workloads to be measured.