Cryptography Reference
In-Depth Information
Table 16.3
Normalized
frequencies of different error
patterns per CPU clock
setting
CPU Clock [MHz]
Loaded Pattern
[%]
140
{3}
58.76
{21}
10.01
{3, 21}
31.22
224
{21}
100.0
266 (Full)
{10, 16}
38.72
{10}
53.23
{9, 10, 11, 12, 15, 16, 21}
2.95
{ 9, 10, 16}
3.34
possible, we ran the same memory exploration program changing the loaded value to
both a zero-filled 32-bit word and some random values. In all the cases only bit flip-
downs occurred, and there was never a single instance of a flip-up. When analyzing
the position of the bits that are flipped down during the faulty loads, we detected that
only a very small number of flip-down patterns were present (namely four) and one of
them accounted for more than 50 % of the fault occurrences. When repeating the tests
on different boards, the recurring patterns changed, but their number and frequency
did not, allowing us to deduce that some bits within a word are more susceptible to
flip-downs when the CPU performs a load operation while under-powered. This may
be ascribed to the capacitive load of the signal lines of the CPU, and is due to routing
issues which may force the I/O lines of a register to have different lengths.
To complete the analysis of the error patterns, we decided to run the same error
pattern detection experiment while varying the CPU frequency according to the
allowed working range. By piloting the clock generator on the board we were able
to scale the frequency of the CPU, mimicking a real-world scenario where the ARM
processor is often run at frequencies lower than the maximum allowed, in order to
save power. It is possible to choose from among a number of frequency settings
which alter globally the working frequency by writing in the Phase Locked Loop
(PLL) generator register interface. This causes both the board and the CPU to switch
their working frequency: the board is run at the frequency written in the register
while the CPU is run at twice the set value. The clock setting is retained until the
board is rebooted, but it is possible to customize the deployment model in order to
either lock it permanently or leave the frequency scaling to the operating system. We
wanted to investigate whether the faulty behavior had any changes while working in
different frequency environments; therefore we locked the running frequency in order
to collect homogeneous samples of the behaviors. In a real-world scenario this may
happen to be the actual working environment, since it is quite common to lock the
CPU frequency at a lower value than the maximum allowed in order to save power.
The possibility that the frequency choice is left to the operating system does not
impair our analysis since the CPU will be running at constant frequency in discrete
time slices, thus reporting the same faulty behavior per time slice. Table
16.3
reports
the result of the experiments performed and shows how, regardless of the frequency
