![](https://csdnimg.cn/release/download_crawler_static/15984091/bg4.jpg)
However, it is unrealistic for processors to
provide the anticipant support in the near fu-
ture. Therefore, pure software solutions are
proposed in existing work including CFI [1],
StackGuard [20], control flow locking [25],
etc. However, in this paper, we resort to an
available hardware feature, which is called as
Performance Monitoring Counter(PMC), to
reach the end. PMC introduces a set of per-
formance-monitoring counters that are capable
of counting performance monitoring events.
With the support of PMC, in this paper, we
propose a novel approach to detecting each
dynamic control transfer by counting the
number of executed branch instructions. The
observation behind our approach is straight-
forward and effective. A dynamic control
transfer should be made by only one branch
instruction in normal execution. If malware
subverts a control transfer, it certainly intro-
duces extra executions for the malicious goal.
Consequently, the additional executions in-
crease the number of executed branch instruc-
tions. Therefore, we are able to detect com-
promised control transfers by the abnormal
increase.
Some scrupulous audiences may wonder
that malware will absolutely introduce addi-
tional executed branch instructions after sub-
verting a normal control flow. To validate our
viewpoint, we have conducted the following
experiments. We use objdump, a disassem-
bling tool, to recover assembly code for vari-
ous software including Linux 2.6.15 kernel,
Linux 2.6.16 kernel, adore-ng 0.56, wpns 0.26,
etc. We count the number of branch instruc-
tions (e.g., jmp, call, ret) and total instructions
in those software, and calculate the ratio of
branch instructions to total instructions. Figure
1 shows the result. In figure 1, the vertical axis
denotes the ratio, while the horizontal axis
denotes the software. It indicates that the
branch instructions occupy about one-fifth of
all instructions. Our experiments show that
branch instructions are indispensable in all
software. It means that any piece of malicious
code will inevitably contain branch instruc-
tions. Moreover, its execution must lead to the
execution of these branch instructions.
We present an overview of our solution be-
fore diving into its detail. Intruders definitely
launch additional execution after breaking
control flow, and the execution inevitably in-
troduces some executed branch instructions.
Therefore, with the support of branch counters,
we are able to detect stealthy execution by
counting the number of executed branch in-
structions, and further detect compromised
control transfers on the stealthy execution.
Fig.1 Ratio of branch instructions to total instruc-
tions
III. DESIGN
In this section, we present the design of
DCFI-Checker, a novel system that checks
integrity of kernel dynamic control flows. In
our opinion, an important step is to count the
executed branch instructions in the execution
of the monitored code snippet. We explain our
approach with the following example. For
example, we want to know the number of
executed branch instructions when a code
snippet A executes. We denote the time of the
execution at the beginning of A as time_b, and
the time at the end as time_e. To get the values,
we read the branch counter at time_b and
time_e, and the values are num_b and num_e
respectively. Thus, the number of executed
branch instructions is num_e minus num_b.
However, we face three challenges. The first is
to identify valuable objects worth being
monitored. The second is to obtain the values
from branch counters. The last is to verify
dynamic control flow integrity by these values.
In the following, we discuss our approach in
detail.
3.1 Monitored instructions
Which pieces of kernel code are necessary to