U.S. patent application number 13/543673 was filed with the patent office on 2013-01-10 for microprocessor protected against stack overflow.
This patent application is currently assigned to STMicroelectronics (Rousset) SAS. Invention is credited to Pierre Guillemin, William Orlando.
Application Number | 20130013965 13/543673 |
Document ID | / |
Family ID | 45047922 |
Filed Date | 2013-01-10 |
United States Patent
Application |
20130013965 |
Kind Code |
A1 |
Guillemin; Pierre ; et
al. |
January 10, 2013 |
MICROPROCESSOR PROTECTED AGAINST STACK OVERFLOW
Abstract
A microprocessor includes a central processing unit, at least
one call stack, a stack pointer, an address bus, and a data bus.
The microprocessor further includes a hardware monitor configured
to supply protection codes, insert the protection codes in the
stack or let the central processing unit insert them, and then
generate an error signal in response to an attempt to modify a
protection code present in the stack.
Inventors: |
Guillemin; Pierre;
(Marseille, FR) ; Orlando; William; (Peynier,
FR) |
Assignee: |
STMicroelectronics (Rousset)
SAS
Rousset
FR
|
Family ID: |
45047922 |
Appl. No.: |
13/543673 |
Filed: |
July 6, 2012 |
Current U.S.
Class: |
714/48 ;
714/E11.024 |
Current CPC
Class: |
G06F 21/52 20130101;
G06F 2221/2153 20130101; G06F 2221/2123 20130101 |
Class at
Publication: |
714/48 ;
714/E11.024 |
International
Class: |
G06F 11/07 20060101
G06F011/07 |
Foreign Application Data
Date |
Code |
Application Number |
Jul 8, 2011 |
FR |
11/56210 |
Claims
1. A microprocessor, comprising: a central processing unit; at
least one call stack structure; a stack pointer structure; an
address bus; a data bus; and a hardware monitor configured to:
generate protection codes; insert protection codes in the stack
structure or let the central processing unit insert protection
codes in the stack structure; store addresses of protection codes
inserted in the stack structure; and generate an error signal in
response to an attempt to modify a protection code present in the
stack structure.
2. A microprocessor according to claim 1 wherein the hardware
monitor is configured to generate the error signal in response to
an attempt to read a protection code in the stack structure.
3. A microprocessor according to claim 1 wherein the hardware
monitor is configured to generate random or pseudo-random
protection codes.
4. A microprocessor according to claim 1 wherein the hardware
monitor is configured to generate deterministic and reproducible
protection codes.
5. A microprocessor according to claim 1 wherein the hardware
monitor is configured to: monitor the address bus; and generate the
error signal if an address of a stored protection code appears on
the address bus.
6. A microprocessor according to claim 1 wherein the hardware
monitor comprises a register, the register being write-accessible
to the central processing unit, and the hardware monitor is
configured to generate a register protection code and apply the
value of the register protection code on the data bus in response
to the write of data in the register by the central processing
unit.
7. A microprocessor according to claim 6 wherein the hardware
monitor is configured to insert the register protection code in the
stack structure at an address present in the register.
8. A microprocessor according to claim 1 wherein in response to a
protection code erase request by the central processing unit or by
a program executed by the central processing unit, the hardware
monitor is configured to: read a first protection code in the stack
structure at an address specified by the erase request; compare the
first protection code with an expected protection code value; and
generate the error signal if the first protection code is different
from the expected value.
9. A microprocessor according to claim 8 wherein the hardware
monitor is configured to erase the first protection code in the
stack after having verified the protection code.
10. A microprocessor according to claim 8 wherein the hardware
monitor comprises a register, the register being write-accessible
to the central processing unit, and the hardware monitor is
configured to interpret a write of the register as a request to
erase the first protection code.
11. A microprocessor according to claim 10 wherein the hardware
monitor is configured to interpret a write of the register as an
erase request of the first protection code at an address present in
the register.
12. A method executed by a microprocessor, comprising: initializing
a stack pointer; generating a plurality of protection codes;
inserting protection codes in a stack based on an address stored in
the stack pointer; storing addresses of inserted protection codes
in a memory; monitoring, with a hardware monitor, addresses on an
address bus; and generating an error signal in response to an
attempt to modify a protection code present in the stack based on
detecting a monitored address on the address bus.
13. The method according to claim 12 wherein the inserting is
performed with the hardware monitor or with a central processing
unit.
14. The method according to claim 12, comprising: executing a
secure error processing function in response to the error
signal.
15. The method according to claim 12, comprising: erasing
protection codes when corresponding return functions are executed,
wherein the erasing includes removing stored addresses of the
inserted protection codes from the memory.
16. The method according to claim 12 wherein generating the
plurality of protection codes includes drawing random or
pseudo-random numbers from an associated random or pseudo-random
number generator.
17. A stack overflow monitoring circuit, comprising: a control
circuit configured to generate protection codes and further
configured to direct operations of the stack overflow monitoring
circuit; a bus interface configured to couple the stack overflow
monitoring circuit to a stack structure, the stack structure
operable to store protection codes; at least one internal memory; a
plurality of comparators coupled to the at least one internal
memory; and gating logic coupled to the plurality of comparators
and configured to output an error signal upon detection of an
address on an address bus read via the bus interface being equal to
an address stored in the at least one internal memory.
18. The stack overflow monitoring circuit according to claim 17,
comprising: an address memory configured within the at least one
internal memory; and a value memory configured within the at least
one internal memory, wherein the address memory is operable to
store addresses of protection codes stored in the stack structure
and the value memory is operable to store protection code values
equal to the protection codes stored in the stack, wherein the
gating logic is configured to output an error signal upon detection
of a protection code value on a data bus read via the bus interface
being equal to a value stored in the value memory.
19. The stack overflow monitoring circuit according to claim 17,
comprising: a first register coupleable to a central processing
unit, the first register operable to receive a function address,
wherein the function address is usable by the control circuit to
generate a protection code; and a second register coupleable to the
central processing unit, the second register operable to receive an
address of a protection code.
20. The stack overflow monitoring circuit according to claim 17,
comprising: a random or pseudo-random number generator, the random
or pseudo-random number generator operable during generation of the
protection codes.
Description
BACKGROUND
[0001] 1. Technical Field
[0002] The present disclosure relates to the protection of a
microprocessor against stack overflow. The call stack of a
microprocessor is a volatile memory zone directed to the storage of
data concerning functions executed by the microprocessor. In
particular, the stack allows the storage of an address to which the
microprocessor should return after having executed a function.
[0003] 2. Description of the Related Art
[0004] When a first function or "call function" calls a second
function or "called function", the call function places its return
address in the stack. When the called function has finished the
task for which it was designed, it fetches the return address from
the stack. When the functions call each other, return addresses
accumulate in the stack and are fetched one after the other after
the execution of a function. Besides return addresses, the stack
receives data associated with call or called functions, such as
local variables of the called function, parameters of the called
function, a frame pointer of the call function, etc.
[0005] When too much information is stored in the stack, a
phenomena called stack overflow occurs, which may be an external
overflow or an internal overflow. External overflow is an overflow
beyond the amount of memory space attributed to the stack, whereas
internal overflow is when writing of a data zone overflows into
another data zone, in particular into a zone containing a return
address. Such an internal overflow may be caused intentionally by
an attacker aiming to take control of the microprocessor, and the
return address pointing to the call function may be replaced by a
return address pointing to a malicious program. In the present
application, the term "stack overflow" designates an internal
overflow.
[0006] A known method of countering stack overflow attacks consists
of inserting a protection code, also known as a "canary", in the
stack. Such codes are generally small whole numbers of random value
placed at strategic locations in the stack, preferably before each
return address. To detect that the stack has not been subjected to
a fraudulent overflow, the value of the canary is checked to
determine that it has not been changed before the called function
uses the return address present in the stack.
[0007] This technique considerably increases the difficulty of
exploiting stack overflow, since it relates to the attacker taking
control of the instruction pointer by complex means.
[0008] Nevertheless, this technique is not infallible because it
entirely depends on the provision of canary insertion and
verification instructions in the program executed by the
microprocessor. An attack on the program itself may therefore allow
a subsequent attack on the stack by neutralizing the canary
verification instructions.
[0009] Similarly, an attacker may provoke a stack overflow that is
undetected by reading the canary and then re-writing the correct
value of the canary in the initial space while modifying the return
address.
[0010] It may therefore be desired to reinforce the security
offered by the insertion of canaries in the call stack of a
microprocessor.
BRIEF SUMMARY
[0011] Embodiments of the invention relate to a microprocessor
having a central processing unit, at least one call stack, a stack
pointer, an address bus, a data bus, and a hardware monitor
configured to: generate protection codes, insert protection codes
in the stack or let the central processing unit insert them, store
addresses of protection codes inserted in the stack, and generate
an error signal in response to an attempt to modify a protection
code present in the stack.
[0012] According to one embodiment, the monitor is also configured
to generate the error signal in the case of an attempt to read a
protection code in the stack.
[0013] According to one embodiment, the monitor is configured to
generate random or pseudo-random protection codes.
[0014] According to one embodiment, the monitor is configured to
generate deterministic and reproducible protection codes.
[0015] According to one embodiment, the monitor is configured to
monitor the address bus, and generate the error signal if an
address of a stored protection code appears on the address bus.
[0016] According to one embodiment, the monitor includes a first
register write-accessible to the central processing unit, and is
configured to generate a protection code and apply the value of the
protection code on the data bus in response to the write of a data
in the register by the central processing unit.
[0017] According to one embodiment, the monitor is also configured
to insert the protection code in the stack, at an address present
in the first register.
[0018] According to one embodiment, in response to a protection
code erase request by the central processing unit or by the program
executed by the central processing unit, the monitor is configured
to read the protection code in the stack at an address specified by
the erase request, compare the protection code with an expected
protection code value, and generate the error signal if the read
value is different from the expected value.
[0019] According to one embodiment, the monitor itself is
configured to erase the protection code in the stack after having
verified the protection code.
[0020] According to one embodiment, the monitor includes a second
register write-accessible to the central processing unit, and is
configured to interpret a write of the second register as a request
to erase a protection code.
[0021] According to one embodiment, the monitor is configured to
interpret a write of the second register as an erase request of a
protection code at an address present in the second register.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0022] Non-limiting and non-exhaustive embodiments are described
with reference to the following drawings, wherein like labels refer
to like parts throughout the various views unless otherwise
specified. The sizes and relative positions of elements in the
drawings are not necessarily drawn to scale. For example, the
shapes of various elements and angles are not drawn to scale, and
some of these elements are enlarged and positioned to improve
drawing legibility. Further, the particular shapes of the elements
as drawn are not intended to convey any information regarding the
actual shape of the particular elements and have been solely
selected for ease of recognition in the drawings. One or more
embodiments are described hereinafter with reference to the
accompanying drawings in which:
[0023] FIG. 1 shows a microprocessor comprising a stack monitor
according to one embodiment;
[0024] FIG. 2 shows an example of contents of the stack; and
[0025] FIG. 3 shows an implementation example of the stack
monitor.
DETAILED DESCRIPTION
[0026] FIG. 1 shows a microprocessor 100 according to one
embodiment. The microprocessor 100 includes a central processing
unit CPU, hereinafter "the CPU", a program memory PMEM, a call
stack STCK, and a registry bank RBK. These different elements are
linked by an address bus B1, a data bus B2, and an instruction bus
B3.
[0027] Registry bank RBK includes a stack pointer register SP and a
frame pointer register FP. The stack pointer contains the address
of the top of the stack STCK and the frame pointer contains the
start address of a frame of a function being executed. Program
memory PMEM contains a program executed by the CPU.
[0028] It will be noted that instruction bus B3 is an optional
microprocessor element, its provision particular to the
architecture used, here the Harvard architecture. A Von Neumann
architecture only includes bus B2 to convey both the data and the
instructions.
[0029] The microprocessor 100 also includes a stack monitor MT
according to one embodiment. Monitor MT is configured to place
protection codes or "canaries" in the stack STCK as it is being
filled by the CPU. The monitor is also configured to detect
attempts to write the stack at the canary addresses, e.g., attempts
to alter the canaries, and preferably to also detect attempts to
read the canaries.
[0030] In one embodiment, the monitor only monitors address bus B1
and launches an alert when the address of a canary appears on
address bus B1. In this case, the monitor does not try to determine
whether it is a read or write attempt, and does not monitor
instruction bus B3 (or bus B2 in a Von Neumann architecture). The
alert is unconditional and is for example emitted in the form of an
error signal ER.
[0031] Signal ER is applied to an interruption decoder that sets
the CPU in a secure error processing sub-program (for example a
secure interrupt of the platform termed "trust zone", the
processing of which is done in secure mode in protected memories).
Alternatively, signal ER is used to provoke a CPU reset.
[0032] During the return to a call function, monitor MT also
operates such that the canary surveillance is lifted before the
canary is erased. Before lifting the surveillance, the monitor
verifies that the canary value has not been altered. To this end,
the monitor reads the canary and compares it with an initial value
saved in its internal memory 102. In one embodiment, the monitor
itself performs the erasure of the canary in the stack. In another
embodiment, this erasure is assured by the CPU.
[0033] Thus, monitor MT is a hardware means to generate and to
monitor the canaries, and cannot be corrupted by a fraudulent
alteration of the program executed by the CPU. The monitor is a
sort of impartial arbitrator, independent of the program itself,
and confers a high level of security to the generation and the
surveillance of canaries.
[0034] FIG. 2 shows an example of inserting canaries in stack STCK
and an example of the stack contents. An arrow DIR1 indicates the
increasing address direction and an arrow DIR2 indicates the stack
filling direction. Here, the filling is done from the highest value
address to the lowest value address. The "top" of the stack,
corresponding to the current value of stack pointer SP, thus
corresponds here to the lowest value of the stack. It will be noted
that in other embodiments, the stack can have a reversed filling
direction, corresponding to the increasing address direction.
[0035] In the example shown, the stack includes frame FFA of a
function FA, frame FFB of a function FB, and frame FFC of a
function FC being executed. It is assumed that function FC was
called by function FB and that function FB was called by function
FA. Each frame contains contextual data of the considered function
and return data to the call function.
[0036] Thus, frame FFB of function FB includes a return address
RAFA to function FA, a frame pointer value FPFA of function FA, and
local variables LVFB of function FB. A canary C1 was inserted by
monitor MT in frame FFB, for example between return address RAFA
and frame pointer value FPFA.
[0037] Frame FFC of function FC includes a return address RAFB of
function FB, a frame pointer value FPFB of function FB, and local
variables LVFC of function FC. A canary C2 was inserted by monitor
MT in frame FFC, for example between return address RAFB and frame
pointer value FPFB.
[0038] The current value of stack pointer SP designates the top of
the stack (the lowest address), and the current value of the frame
pointer designates the position of the return address RAFB to
function FB.
[0039] Canaries C2 and C1 are monitored in real time by monitor MT.
Thus, any attempt to overflow the stack in order to smash return
address RAFB and/or return address RAFA implies a stack write
attempt at the locations of canaries C2 and C1. This attempt is
detected by monitor MT and leads it to emit error signal ER.
Similarly, any attempt to read the canaries is preferably detected
by the monitor, which also emits the error signal.
[0040] To use monitor MT, canary insertion and erasure instructions
are provided in the program executed by the CPU (program stored in
program memory PMEM).
[0041] The implementation of embodiments may be the object of
diverse variations which will be evoked in the following, before a
detailed example implementation of monitor MT is provided in
relation with FIG. 3.
Modification of the Program to Use the Monitor
[0042] The use of monitor MT supposes instructions in the program
executed by the CPU for the insertion and erasure of canaries.
[0043] By "canary erasure instruction" is meant an instruction that
leads monitor MT to lift the surveillance of the canary targeted by
the instruction, in preparation for its erasure by the CPU, or
which leads the monitor to lift the surveillance and to erase the
canary from the stack itself.
[0044] To this end, several options may be provided: [0045] an
explicit modification of the program by the programmer (calling
macros or dedicated functions), [0046] a modification of the
program by the compiler so that this operation is transparent to
the programmer, [0047] a post-compilation of the generated binary
code, also to render the operation transparent to the programmer,
[0048] the modification of the compiler so that the programmer can
indicate, by means of a "preprocessing" command (for example a
command of the "pragma" type as specified by the C language
standard), how the compiler should operate to compile a program
section or a function. This allows the compiler to add the canary
insertion and erasure instructions, while leaving to the programmer
the choice as to which program sections or functions should be
protected.
Generation of Canaries
[0049] The value of a canary may be: [0050] supplied by a random or
pseudo-random generator, or [0051] deterministic and reproducible:
the value of the canary is for example determined by the monitor as
a function of known variables such as the address at which the
canary is placed, and of a secret or random value known only to the
monitor, or even a call function identifier supplied by the
compiler.
[0052] The value of the canary preferably includes a byte at 0 to
offer protection against faults due to character chain
manipulations.
Insertion of Canaries in the Stack
[0053] The canaries are placed between the local variable zones and
the return addresses in the embodiment. Indeed, it is preferable
that they are situated between the zones sensitive to overflow and
the zones to protect from an overflow. In one embodiment,
additional canaries are placed at other locations in the stack to
obtain the equivalent of a "mine field" offering application
perspectives extending beyond the simple protection of return
addresses.
[0054] The insertion of a canary in the stack may be launched by
the monitor: [0055] automatically upon detection of a "call" type
instruction causing a change of context in the stack. In this case,
the monitor is linked to instruction bus B3, as shown in dotted
lines in FIG. 1, and includes means of decoding such an instruction
(in the Von Neumann architecture, this monitoring is done on bus
B2); [0056] upon an explicit request by the program. An explicit
request may consist of a specific canary insertion instruction that
the monitor decodes, or more simply a write instruction of a
monitor register, interpreted by the monitor as an insertion
instruction.
Management of Canary Addresses
[0057] In order to monitor the different canaries placed in the
stack, the monitor keeps track of where they are. To this end, the
canary addresses are stored in an internal memory 102 of the
monitor or an external memory 104 accessible by the intermediary of
the data and address buses. Alternatively, a low-capacity internal
memory 106 (memory zone within the CPU) may be provided to store
the addresses of the canaries most recently introduced into the
stack, and a complementary memory 104 may be provided to store the
addresses of other canaries. A distinction is therefore made
between "active" canaries, the addresses of which are under
surveillance because they are loaded in the internal memory 102 of
the monitor, and "inactive" canaries, the addresses of which are
not monitored. During a change of context, the addresses of
canaries present in the external memory 104 are transferred to the
internal memory 102 to be monitored by the monitor. The canaries
whose addresses were transferred thus become "active".
[0058] The addresses stored in an external memory 104 are
preferably protected in confidentiality and integrity, for example
by encryption and association with an error correction code.
[0059] Similarly, the values of the canaries, if they are not
deterministic and reproducible, may be stored in an internal memory
102 of the monitor or in the memory 106 of the CPU, in a form
protected by confidentiality and integrity.
Monitoring of Canary Addresses
[0060] The monitor should first detect and prevent an attempt to
write the stack at the canary addresses. The write attempt may be a
modification attempt by the CPU or by a host device that can access
the data bus and the address bus.
[0061] Preferably, the monitor also detects and prevents attempts
to read the stack at a canary address. Indeed, certain attacks take
advantage of a prior knowledge of the canary values.
[0062] To this end, the monitor compares the current address
present on the address bus to the addresses of "active"
canaries.
[0063] This monitoring may concern the addresses of all the
canaries inserted in the stack (exhaustive monitoring) or only the
addresses of the canaries associated with the current task, the
function being executed. In the second case, the monitor is
informed of a task change so that it can update the canary
addresses to monitor.
[0064] The surveillance of the current address is done for example
by comparators, each receiving the current address on one input and
an address of a canary to monitor on another input. The detection
time is preferably constant and short. The number of canaries
simultaneously monitored may be limited to the number of
comparators included in the monitor. A multiple-value comparator
may also be provided to successively compare the current address
with each canary address.
[0065] If the surveillance only concerns the canaries of the
current task, the monitor recharges its internal comparators during
a context change by applying the canary addresses associated with
the new task to the comparators.
[0066] The new addresses applied to the comparators are imported
from an external memory after integrity verification and error
correction, or are selected in an internal memory zone associated
with the considered task.
Erasure of a Canary
[0067] The erasure of a canary includes a prior step of verifying
the value of the canary by comparison with an expected value by the
monitor.
[0068] To this end, the monitor reads the canary in the stack and
compares it with an expected value. If the value of the canary is
not the same as the expected value, the monitor emits error signal
ER.
[0069] The erasure of a canary may be launched upon detection of a
"return" type instruction on instruction bus B3 (or on bus B2 in a
Von Neumann architecture), or by the intermediary of an explicit
request, indicating the address of the canary to erase, present in
the program, or even by the intermediary of an access to a monitor
register.
[0070] FIG. 3 shows an implementation example of monitor MT
according to the guidelines presented above.
[0071] Monitor MT includes a control circuit CCT linked to address
bus B1 and to data bus B2 of the CPU, a volatile memory CAM, a
volatile memory CVM, address comparators CA0, CA1, . . . CAi, and a
canary comparator CDT. Control circuit CCT is a hard-wired circuit
of the state machine type. It is equipped with a random or
pseudo-random generator CGEN, and two registers R1, R2
write-accessible to the CPU. Memory CAM is provided to store canary
addresses, whereas memory CVM is provided to store canary values.
The outputs of comparators CA0-CAi, CDTn are sent to an OR type
gate G1, the output of which supplies error signal ER.
[0072] Memory CAM has a look up table structure and includes N
parallel outputs supplying, in read mode, i+1 canary addresses
associated with an index applied at the input of the memory. Each
canary address supplied by memory CAM is applied on an input of a
comparator CA0-CAi, the other input of which is linked to address
bus B1.
[0073] Memory CVM also has a look up table structure and includes
an output supplying, in read mode, a canary value associated with
an address value supplied at the input of the memory. This value is
applied to an input of comparator CDT, the other input of which is
linked to data bus B2.
[0074] Register R1 receives an insertion address of a canary
supplied by the CPU, and optionally a call function identifier, a
called function identifier, or both.
[0075] Control circuit CCT is configured to detect a write of
register R1 and to interpret this write as a request to write a
canary in stack STCK, at the address present in the register.
[0076] Thus, to write a canary, the programmer or the compiler
simply inserts a write instruction of register R1 in the program.
This embodiment can be adapted to any type of microprocessor
without having to provide a specific canary insertion
instruction.
[0077] In response to the write of register R1, control circuit
CCT: [0078] generates a canary, here by means of generator CGEN,
[0079] takes control of address bus B1 and of data bus B2 and
writes the canary in stack STCK at the specified address, [0080]
stores the address of the canary in memory CAM in relation with an
associated index which can be the identifier of the call or called
function, [0081] stores the value of the canary in memory CVM in
relation with the address of the canary, [0082] sets memory CAM in
read mode and applies the index associated with the canary address
to the memory.
[0083] Thus, the addresses of all the canaries associated with this
index (for example all the canaries associated with the identifier
of the call or called function) are applied to comparators CA0-CAi
and are under surveillance. If the address of one of the canaries
under surveillance appears on address bus B1, the output of one of
comparators CA0-CAi goes to 1 and signal ER at the output of gate
G1 goes to 1, launching the protection process of the system
described herein (reset of the microprocessor or secure error
processing).
[0084] In one variant, the write address of the canary is applied
on the address bus by the CPU. Register R1 is used to communicate
the identifier of the current process or any other information
other than the address of the canary to control circuit CCT.
Control circuit CCT reads this address on the address bus in order
to store it in memory CVM, and supplies only the value of the
canary on the data bus. The CPU itself then applies a write command
to stack STCK.
[0085] In response to the write of an address in register R2,
control circuit CCT: [0086] applies the address present in register
R2 on the bus and reads the value of the canary in the stack. This
value is thus found on data bus B2 and on one input of comparator
CDT, [0087] sets memory CVM in read mode and applies the address
present in register R2 as a read index to the memory. The initial
value of the canary stored in relation with this address thus finds
itself on a second input of comparator CDT.
[0088] If the two values are different, the output of comparator
CDT goes to 1 and signal ER at the output of gate G1 goes to 1,
launching the system protection process.
[0089] In absence of the error signal, control circuit CCT itself
can perform the erasure of the canary in the stack by accessing it
in write mode, then erasing the address of the canary in its
internal memory. Alternatively, circuit CCT can let the CPU do this
erasure, after having erased the address of the canary from its
internal memory in order that it is no longer under
surveillance.
[0090] In the case where circuit CCT is not configured to perform
this erasure by itself, the programmer or the compiler should
provide a stack erase instruction to the attention of the CPU after
a write instruction of register R2.
[0091] In a variant evoked herein, control circuit CCT generates
deterministic canary values and regenerates them in response to a
write of register R2. In this case, memory CVM is not
necessary.
[0092] Many other embodiments may be provided by the skilled
person. In particular, in certain embodiments, the CPU is equipped
with a cache memory, which may be formed for example as all or part
of memory 106, arranged between the program memory and the CPU and
receives instructions to execute several clock cycles before they
are to be executed. In this case, the monitor is preferably
arranged between the CPU and the cache, and is configured to
observe the transactions performed by the CPU.
[0093] The various embodiments described above can be combined to
provide further embodiments. Aspects of the embodiments can be
modified, if necessary to employ concepts of the various patents,
applications and publications to provide yet further embodiments.
These and other changes can be made to the embodiments in light of
the above-detailed description. In general, in the following
claims, the terms used should not be construed to limit the claims
to the specific embodiments disclosed in the specification and the
claims, but should be construed to include all possible embodiments
along with the full scope of equivalents to which such claims are
entitled. Accordingly, the claims are not limited by the
disclosure.
* * * * *