## 5 Evaluation
### Functional Evaluation
For both methods, token matching actions in rules parsing share the same processes and variables. Additionally, XLabel applies the command-line tools getfattr and setfattr to retrieve and set xattr values for the files to be measured. Meanwhile, a text editor is used to edit the XList configuration file that sets the file list to be written to the XList pseudo-file. Additionally, to simplify the system administration package management, integration is introduced. The results of the functional evaluations suggest that both policy mechanisms work as expected and meet the requirement of IMA measurement. However, performance evaluations revealed advantages and shortcomings, which can be addressed in the development of a more effective and efficient solution. Latency evaluations measure the time used for processing tasks and reflect how much CPU power is consumed. The evaluations measure latency for file operations through IMA hooks, syscalls, and user-space programs. The results reveal that XLabel policy latency is slightly higher than the default policy rule set, but with minimal difference in the trimmed mean. This small difference indicates that the xattr retrieval function has minimal impact on computational power. However, latencies for the XList policy rule sets show a greater difference, and the variance depends on the length of the file list. When a file list with 50 items was applied, the latency showed minimal variance with the XLabel policy but that variation increased markedly when the list increased to 550 and 1050 items. The variances can be explained by the combined impact of the length of the items list and how long it took for the list traversal period to complete, where the cumulative effect of more list items triggers an increasing number of search operations, which then leads to more context switching in the runtime. However, this does not explain the variation between the XList policies in which the hook ima_file_mmap is much higher than either ima_bprm_check and ima_file_check. When compared to the above IMA hooks, measurement at the kernel syscall level showed a very different scenario. For both execve and mmap function calls, the latency values for all policies presented a stable trend. Even between the three XList policies, the differences in latency were insignificant. This result may be due to the number of function calls involved in the syscall interfaces, such that the overall measurement value is not sensitive to the latency values produced by the three IMA hooks, which account for a small number of function calls compared with other kernel functions. The user-space evaluation performed by the time command provided a similar pattern to the IMA hooks. Nonetheless, the three XList policy measurements reveal a greater variance than that above. It is possible that the target program, tar, includes a large number of file operations with combined latencies aggregating as the length of the file list increases. This is different from the syscall level measurement, where the accumulation happens during function execution and is unrelated to IMA hooks. The evaluation of memory consumption addressed overall kernel processing measurement rather than user-space programs because the IMA functions in the design are implemented at the kernel level. The evaluation results show that the memory consumption for the kernel as a whole was almost identical across all five policy mechanisms. Analysis of the XFilter code indicates two changes that may affect memory usage, with the first being the introduction of new variables. However, since only a few new variables are defined in this design, their impact is minimal. The other modification is the creation of the XList policy file list that is stored in the kernel memory space. With 1050 listed items in the evaluation, the amount of memory consumed is around 35 kB, which is a small proportion of the overall consumption rate of more than 34,000 kB.