## 3 Method  
The study applied the Design Science Research Methodology (DSRM) [32] to produce a practicable implementation as an artefact that may be a model, method, build, or instantiation. The framework provided by DSRM allows for the inclusion of relevant methods to define the problem, design a solution, and to construct an artefact. Thus, in this instance the artefact is a method that extends existing IMA functions to achieve a built-in fine-grained measurement policy. The DSRM process in this research is illustrated as Figure 1.  
To provide an interference-free running platform, the libvirt virtual environment [33] was deployed, which relies on the Qemu emulator and Kernel Virtualization Module (KVM) hypervisor as the backend. A guest VM was configured with two CPU cores, 1024 MB memory, and other specifications matching the host machine. In addition, TPM emulation was enabled to simulate a complete IMA measurement function in the guest system. The openSUSE Leap 15.2 [34] (July 2) Linux distribution, which includes core packages and security patches with SUSE Linux Enterprise (SLE15) [35], was selected as the operating system for development. The robustness [36] of regular-release distribution and the using of enterprise-targeting packages provides a stable environment for kernel development. Regarding kernel version, upstream Long-Term Support (LTS) release 5.4 [37] was used in this research because it reflects the standard functions for general IMA features and its ease of migration to other platforms. The code in this development was built with kernel-provided configurations, such as makefile and Kbuild [38], and the GNU Compiler Collection (GCC) (Version 7.5.0). The requirement of default settings in Kconfig means that the IMA subsystem is not built as a kernel module. Debugging was conducted using the kernel built-in ftrace function with trace-cmd as a front-end command-line tool. In addition, reliance was placed upon the ring buffer generated by the Linux kernel, which is called using the dmesg command. The evaluation has two phases--the function test and performance evaluation. The function test targets workability and functionality and verifies the basic working process of new XFilter-based IMA policies. The performance evaluation collects performance data that include execution latency and memory consumption in the kernel space for statistical analysis. Evaluation data collection and processing is handled with bash shell scripts, which call multiple external tools. Rather than commonly used benchmarking applications, low-level tracers, strace and ftrace, are applied in the performance evaluation. These have been applied for I/O latency evaluation of the function call interfaces in specific file operations [39]. Apache2 (Version 2.4.43) was chosen as the target application because it is widely deployed [40] and involves a large number of dynamic libraries or configuration files. The measurement target is introduced to simulate the workload in the evaluation. GNU tar (Version 1.30) is a suitable candidate as a target for the time command to capture observable latency values based on the compression operation, whereas the ls command (GNU coreutils version 8.29) is sufficient for strace for system call measurement from the userspace. Regarding the measurement of kernel function using ftrace, a minimal program developed specifically is involved as the target for controlling overall complicities. Since the IMA functions are implemented in the kernel space, kernel memory allocation needs to be examined. In this project, overall memory consumption in the kernel space, reflected by slabs allocation counts, was captured inside the running kernel via /proc/meminfo [41]. For the data analysis, applications of IMA policy scenarios for the built-in policy in XLabel and XList were compared. Multiple measurement runs were conducted to provide a sufficient sample size, to derive a representative value or central tendency, and to balance efficiency against sample space size.