U.S. patent application number 15/755073 was filed with the patent office on 2018-08-30 for system and method for monitoring and protecting an untrusted operating system by means of a trusted operating system.
This patent application is currently assigned to B. G. NEGEV TECHNOLOGIES AND APPLICATIONS LTD., AT BEN-GURION UNIVERSITY. The applicant listed for this patent is B. G. NEGEV TECHNOLOGIES AND APPLICATIONS LTD., AT BEN-GURION UNIVERSITY. Invention is credited to Yuval ELOVICI, Mordechai GURI.
Application Number | 20180248847 15/755073 |
Document ID | / |
Family ID | 58100002 |
Filed Date | 2018-08-30 |
United States Patent
Application |
20180248847 |
Kind Code |
A1 |
GURI; Mordechai ; et
al. |
August 30, 2018 |
SYSTEM AND METHOD FOR MONITORING AND PROTECTING AN UNTRUSTED
OPERATING SYSTEM BY MEANS OF A TRUSTED OPERATING SYSTEM
Abstract
The invention relates to a TEE (Trusted Environment Execution)
structure which comprises: (a) a main domain defining a domain of
operation for a main OS; (b) a privileged trusted domain defining a
domain of operation for a trusted domain OS; and (c) a low level
hypervisor which is separated from both of said main OS and said
trusted domain OS, said hypervisor is used for: (c. 1) receiving
packets from a network; (c.2) examining an address included in each
of said received packets; and (c.3) based on the determined address
in each of said packets, targeting respectively the packet to
either said main OS or to said trusted domain OS, while in the
latter case any interaction between the received packet and said
main OS is eliminated.
Inventors: |
GURI; Mordechai; (Modi'in,
IL) ; ELOVICI; Yuval; (D.N. Lachish, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
B. G. NEGEV TECHNOLOGIES AND APPLICATIONS LTD., AT BEN-GURION
UNIVERSITY |
Beer Sheva |
|
IL |
|
|
Assignee: |
B. G. NEGEV TECHNOLOGIES AND
APPLICATIONS LTD., AT BEN-GURION UNIVERSITY
Beer Sheva
IL
|
Family ID: |
58100002 |
Appl. No.: |
15/755073 |
Filed: |
August 16, 2017 |
PCT Filed: |
August 16, 2017 |
PCT NO: |
PCT/IL2016/050899 |
371 Date: |
February 24, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62209910 |
Aug 26, 2015 |
|
|
|
62209920 |
Aug 26, 2015 |
|
|
|
62241799 |
Oct 15, 2015 |
|
|
|
62300840 |
Feb 28, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 9/45558 20130101;
G06F 2009/45595 20130101; G06F 2009/45587 20130101; G06F 21/53
20130101; H04L 63/0236 20130101; G06F 21/52 20130101; G06F 21/57
20130101; G06F 21/74 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; G06F 9/455 20060101 G06F009/455 |
Claims
1. A TEE (Trusted Environment Execution) structure which comprises:
a. a main domain defining a domain of operation for a main OS; b. a
privileged trusted domain defining a domain of operation for a
trusted domain OS; and c. a low level hypervisor which is separate
from both of said main OS and said trusted domain OS, said
hypervisor is used for: (i) receiving packets from a network; (ii)
examining an address included in each of said received packets; and
(iii) based on the determined address in each of said packets,
targeting respectively the packet to either said main OS or to said
trusted domain OS, while in the latter case any interaction between
the received packet and said main OS is eliminated.
2. A TEE structure according to claim 1, wherein said received
packets that are targeted to the trusted domain OS convey
information to one or more services running by said trusted domain
OS at said trusted domain, and wherein results obtained by said
running services are conveyed in a packet form back to the
hypervisor, which respectively routes the packet to a target entity
at the network, without any interaction with said main OS.
3. A TEE structure according to claim 1, wherein said examination
by the hypervisor of the packet address is performed on a MAC
address as defined in a header within said packet.
4. A TEE structure according to claim 2, wherein said one or more
services of the trusted domain OS analyze data relating to the main
OS in a non-invasive manner, while said services of the trusted
domain OS are operated by an external entity at the network by
means of said packets, respectively, while entirely avoiding any
interaction between the packets that carry operation instructions
or service results respectively, and the main OS.
5. A TEE structure according to claim 2, wherein the trusted domain
OS comprises a check-alive service for periodically or upon receipt
of an external trigger, checks that the main OS is alive, namely
that it is not in a halt state.
6. A TEE structure according to claim 2, wherein the trusted domain
OS comprises an introspection process list service which extracts a
list of currently running services from the main OS, for further
inspection and analysis within the domain of the trusted OS.
7. A TEE structure according to claim 2, wherein the trusted domain
OS comprises an introspection process memory dump service which
halts the main OS, and extracts from the run-time memory that
stores the main OS, a section of its memory for further inspection
and analysis within the domain of the trusted OS.
8. A TEE structure according to claim 7, wherein said inspection
and analysis comprises scanning the memory for patterns or
signatures relating to malicious code.
9. A TEE structure according to claim 2, wherein said trusted
domain OS comprises a main domain reboot service that causes reboot
of the main OS from within the trusted domain, with no intervention
whatsoever of the main OS.
10. A TEE structure according to claim 2, wherein said trusted
domain OS comprises a main-domain software update service for
performing an update procedure of the main OS, wherein said update
procedure is performed by said service periodically halting the
processor which runs the main OS, replacing sections of contents of
the memory which contains the main OS, and rerunning the main
OS.
11. A TEE structure according to claim 1, wherein the hypervisor
comprises a timer for independently triggering processes within one
or more of the services of the trusted domain OS.
Description
FIELD OF INVENTION
[0001] The invention relates in general to the field of
cyber-security. More specifically, the invention relates to an
improved structure for protecting an untrusted operating system by
using an extensible operating system which operates within a
trusted zone, thereby to provide better security and novel
maintenance options compared to the prior art.
BACKGROUND OF THE INVENTION
[0002] Trusted Execution Environments (TEEs) are commonly used as a
"safe container" for executing processes or services in a trusted
manner. Examples of TEE implementations are the ARM TrustZone, and
Intel TEE. The common TEE architecture combines the main operating
system (OS) running on the main processor(s) and having its own
"main domain" (also referred herein as the "normal domain"), and a
single process or a set of processes that run within another, more
privileged and trusted section of the processor, which is commonly
referred to as a "trusted domain" or "secured domain". Typically, a
"Trusted Domain OS", which is separate, and most often also
different in structure, language and layer from the main OS,
operates within said privileged secured domain. The access to the
Trusted Domain OS can be performed (in a privileged manner) only
via the main OS, both for the purpose of its configuration, and for
the purpose of receiving service from it in run time.
[0003] In one example, the trusted zone is typically used to store
encryption and decryption keys. The main OS, in turn, submits data
to the trusted-domain OS, which in turn uses a respective process
running within the trusted domain to encrypt or decrypt said data,
respectively, and return the results to the main OS.
[0004] The TEE structure is not so commonly used in embedded
systems, and moreover, when used, it is commonly applied for
performing limited and specific functionalities.
[0005] As described, a user or a process may receive service from
the trusted domain only via the main OS. However, the main OS is
typically accessible to a wide range of users, devices, and
processes, particularly when the system includes a network.
Although the ability to access and receive services from the
trusted domain is limited and privileged, still the main OS itself
is susceptible to malicious code manipulations, in view of its
availability to such a wide range of users and processes.
Therefore, even though the trusted domain is relatively secured in
itself, the fact that the interaction with the trusted domain is
implemented via the relatively susceptible environment of the main
OS, significantly degrades the security of operation with the
trusted domain and its resources.
[0006] In another aspect, a hypervisor is commonly used in computer
systems as a privileged, low level layer below the operating
system. The hypervisor, also called a "virtual machine manager", or
a "virtual machine monitor", is a piece of low level software,
firmware or hardware. In one example, the hypervisor is commonly
used to create and run virtual machines, allowing multiple
operating systems to share a single hardware host. Each operating
system appears to have the host's processor, memory, and other
resources all to itself. In such a manner and structure, a
plurality of "virtual machines" is implemented on a single hardware
machine.
[0007] Even though the TEE and the hypervisor are sometimes
implemented on a same machine, their typical functions are totally
isolated, namely, one allows receiving services from a
trusted-privileged zone, and the other virtually provides the
possibility for a plurality of virtual machines to operate on a
single machine.
[0008] In still another aspect, many systems are required to be
turned off relatively frequently to allow performance of
maintenance or software updates. However, the turning off becomes
almost impossible in essential systems like embedded systems that
handle very sensitive processes. The fact that such systems can
only rarely be turned off (for example, for maintenance and
software upgrade purposes), leads to a situation where the security
and performance of the system are compromised.
[0009] Moreover, the inspection and analysis with respect to the
integrity of the main OS during runtime, even when they are
performed by services of the trusted domain OS, are also
compromised, as the interaction with said services of the trusted
domain OS must be performed via the relatively unsecured
environment (i.e., domain) of the main OS.
[0010] It is an object of the present invention to provide a
structure which significantly improves the security of interaction
with the trusted domain of a TEE structure, and with the resources
running therewith.
[0011] It is still another object of the present invention to
provide a structure that enables performance of a secured
maintenance and software updates during runtime, particularly in
embedded systems.
[0012] Other objects and advantages of the invention will become
apparent as the description proceeds.
SUMMARY OF THE INVENTION
[0013] The invention relates to a TEE (Trusted Environment
Execution) structure which comprises: (a) a main domain defining a
domain of operation for a main OS; (b) a privileged trusted domain
defining a domain of operation for a trusted domain OS; and (c) a
low level hypervisor which is separated from both of said main OS
and said trusted domain OS, said hypervisor is used for: (c.1)
receiving packets from a network; (c.2) examining an address
included in each of said received packets; and (c.3) based on the
determined address in each of said packets, targeting respectively
the packet to either said main OS or to said trusted domain OS,
while in the latter case any interaction between the received
packet and said main OS is eliminated.
[0014] In an embodiment of the invention, said received packets
that are targeted to the trusted domain OS convey information to
one or more services running by said trusted domain OS at said
trusted domain, and wherein results obtained by said running
services are conveyed in a packet form back to the hypervisor,
which respectively routes the packet to a target entity at the
network, without any interaction with said main OS.
[0015] In an embodiment of the invention, said examination by the
hypervisor of the packet address is performed on a MAC address
within said packet.
[0016] In an embodiment of the invention, said one or more services
of the trusted domain OS analyze data relating to the main OS in a
non-invasive manner, while said services of the trusted domain OS
are operated by an external entity at the network by means of said
packets, respectively, while entirely avoiding any interaction
between the packets that carry operation instructions or service
results respectively, and the main OS.
[0017] In an embodiment of the invention, the trusted domain OS
comprises a check-alive service for periodically or upon receipt of
an external trigger, checks that the main OS is alive, namely that
it is not in a halt state.
[0018] In an embodiment of the invention, the trusted domain OS
comprises an introspection process list service which extracts a
list of currently running services from the main OS, for further
inspection and analysis within the domain of the trusted OS.
[0019] In an embodiment of the invention, the trusted domain OS
comprises an introspection process memory dump service which halts
the main OS, and extracts from the run-time memory that stores the
main OS, a section of its memory for further inspection and
analysis within the domain of the trusted OS.
[0020] In an embodiment of the invention, said inspection and
analysis comprises scanning the memory for patterns or signatures
relating to malicious code.
[0021] In an embodiment of the invention, said trusted domain OS
comprises a main domain reboot service that causes reboot of the
main OS from within the trusted domain, with no intervention
whatsoever of the main OS.
[0022] In an embodiment of the invention, said trusted domain OS
comprises a main-domain software update service for performing an
update procedure of the main OS, wherein said update procedure is
performed by said service periodically halting the processor which
runs the main OS, replacing sections of contents of the memory
which contains the main OS, and rerunning the main OS.
[0023] In an embodiment of the invention, the hypervisor comprises
a timer for independently triggering processes within one or more
of the services of the trusted domain OS.
BRIEF DESCRIPTION OF THE DRAWINGS
[0024] In the drawings:
[0025] FIG. 1 shows in a general block diagram form a structure of
a prior art TEE system having a main domain and a trusted
domain;
[0026] FIG. 2 shows in a general block diagram form still another
structure of a conventional prior art TEE system having a main
domain and a trusted domain; and
[0027] FIG. 3 shows in a general block diagram form a novel
structure for performing secured operations within the trusted
domain 130 of the processor, according to the present invention;
and
[0028] FIG. 4 shows in a general block diagram form still another
example of a structure of a TEE system according to an embodiment
of the present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0029] FIG. 1 illustrates in a block diagram form the general
structure of a typical TEE, according to the prior art. As noted,
in the TEE structure (such as ARM TrustZone, or Intel TEE) two
separate domains of operation are defined: (1) a normal (main)
domain 20 of the Main OS 21; and (2) a trusted domain 30 of the
Trusted-Domain OS 31. The Trusted Domain OS 31, which comprises one
or more services S.sub.1, S.sub.2, . . . S.sub.n, is typically
different from the Main OS in structure and language, and is more
targets oriented. The interaction between said two operating
systems, 20 and 30, respectively, is typically performed via an
interface 40 which is susceptible to malicious code, as it resides
within the memory domain of the less privileged main OS.
[0030] While in offline, a user can define the trusted domain OS 31
only via the main OS 21. Likewise, during runtime, either a user
program or a network packet may interact with the trusted domain OS
31 only via the Main OS 21 (and interface 40).
[0031] FIG. 2 shows in a general block diagram form still another
structure of a conventional prior art TEE system having a main
domain 20 and a trusted domain 30. As noted, the main OS resides in
the main domain 20, while the trusted domain OS resides in the
trusted domain 30. As is conventional, each of said operating
systems is divided into a user space section (25 and 35
respectively) residing in a less privileged level PL0, and a kernel
space section (26 and 36 respectively) residing in a more
privileged level PL1. The trusted domain 30 provides highly secured
services to the main domain 20, for example, encryption/decryption
services, keys storing, integrity checks, etc. The main domain
typically communicates with the secured (trusted) domain via a
dedicated API (not shown). The main domain 20 conveys to the
trusted domain 30 requests for services. The requests 28 and 29 are
issued either from the user space 25, or from the kernel space 26
of the main domain 20. The processor transfers the control to the
trusted domain 30, which in turn processes the request and returns
the results and control to the main domain 20.
[0032] A request for a trusted domain service may result, for
example, from a network packet 50, or a user space program (not
shown) which causes issuance of a system call to the kernel space
26.
[0033] The prior art architecture of FIGS. 1 and 2, which requires
submission of requests to the secured domain via the main domain
has several drawbacks in term of security. First, the operating
system 20 at the main domain can be compromised, for example, by
the injection of malicious code. When the main operating system 21
(FIG. 1) which resides in the main domain 20 is compromised, an
adversary may exploite this compromise to manipulate all the
requests that pass through the main OS. For example, when a valid
request is conveyed to the main domain 20 (for example, from a
network packet) to initiate a call to the secured domain 30, a
malicious code at the main OS may intercept the request, abort the
call to the trusted domain 30, and return its own faked response.
In another example, a malicious code at the main domain 20 may
perform a denial of service (DoS) attack on the trusted domain to
entirely prevent receipt of request calls at the trusted
domain.
[0034] The present invention provides a structure that eliminates a
possible exploitation of the trusted domain 30 by maliciously
affecting the main OS at the main domain 20.
[0035] FIG. 3 shows in a general block diagram form a novel
structure for performing secured operations within the trusted
domain 130 of the processor, according to the present invention.
Components having indices similar to those of FIG. 2 perform
substantially a same function. According to the present invention,
the system further comprises a highly privileged low level
"hypervisor" 180 (at a privileged level PL3), which is used to
route packets that arrive from the network 150 either to the main
OS 121 or to the trusted domain OS 131. More specifically, those
packets arriving hypervisor 180 that are targeted to the trusted
domain OS 131 are conveyed directly to the trusted domain OS 131,
while avoiding any passage through or interaction with both the
main OS 121 and the high level API (not shown) at the main domain.
In one embodiment of the invention, said highly secured direct
channel to the trusted domain OS is defined as the only possible
channel to the trusted domain 130 (while eliminating entirely the
channels 141 and 142 from the main OS to the trusted domain OS).
Moreover, processing results from the trusted operating system
which operates at the trusted domain 131 are conveyed back to the
issuing entity in the network 150 via the hypervisor 180, while
entirely avoiding any interaction with the main operating
system.
[0036] In another embodiment of the invention, although less
preferable, said highly secured channel is provided in addition to
the conventional channels, 141 and 142 respectively, from the user
space 125 and from the kernel space 126 of the main OS 121 to the
kernel space 139 of the trusted domain OS 131. More specifically,
in said latter embodiment the user may still use said two
conventional channels 141 and 142 to the trusted domain, while
being aware that said conventional channels may be compromised.
[0037] In an embodiment of the invention, packets from network 150
that are targeted to the trusted domain OS 131 are differentiated
from packets that are targeted to the main OS 121 by their MAC
address. The hypervisor 180, in turn, inspects the header of each
arriving packet, and accordingly directs the packet either to the
main OS 121, or directly to the trusted domain OS 131 based on the
MAC address. This manner of differentiation between the packets is
very simple and efficient, therefore the routing of the packets
respectively can be performed by hypervisor 150 in a very fast
manner.
[0038] In an embodiment of the invention, the trusted operating
system 131 may comprise a variety of services, such as: maintenance
services, introspection services, debugging and memory-acquisition
services, integrity check services, and security and cyber-defense
services. As described above, all said services of the trusted
domain OS 131 operate in a way which is entirely independent from
the main OS 121, as the interaction between an external entity and
the trusted domain OS 131 is performed directly, by means of
packets passing via the hypervisor, and avoiding any interaction
whatsoever with the main OS 121 (i.e., without changing or
modifying the main OS memory or execution-flow). Therefore, this
structure and manner of operation is much safer compared to the
prior art.
EXAMPLES
[0039] As noted, the trusted OS runs alongside the main OS in the
TEE, and performs operations on the main OS in a non-invasive way.
For example, the trusted operating system services may perform the
following non-invasive operations on the main OS:
General Services:
[0040] 1. The services of the trusted domain OS may be triggered if
one the following events occurs: [0041] Timer triggered, periodic
(for example, every 1000 ms); [0042] Timer triggered--setup timer;
[0043] Hardware event triggered (for example, interrupts); [0044]
Network command triggered; [0045] 2. In another example, the
trusted domain OS 131 may perform an integrity analysis of the main
OS 121, by periodically halting the main OS 121, performing memory
acquisition, and scanning and inspecting the extracted memory
section for a possible existence of malicious code. As said, this
is done while avoiding any interaction or dependence on the main OS
121.
Maintenance Services:
[0045] [0046] 3. The services of the trusted domain OS 131 may
perform "heartbeat" checks on the main OS 121, for example,
checking the processor and its core activities to determine whether
the main OS 121 is fully functioning; [0047] 4. The services of the
trusted domain OS 131 a system-load monitoring of the main OS, and
sampling of the processor loads and processor counters; [0048] 5.
The services of the trusted domain OS 131 may check the memory
usage of the main OS 121, for example, by checking the free and
allocated memory tables; [0049] 6. The services of the trusted
domain OS 131 may check for exceptions and interrupts that may
occur in the main OS 121, for example, monitoring of hardware
interrupts and exceptions. [0050] 7. The services of the trusted
domain OS 131 may halt the main OS, for example, by halting the
processors or the cores by an appropriate request; [0051] 8. The
services of the trusted domain OS 131 may initiate a shutdown
process of the main OS 121, for example, by triggering a shutdown
interrupt of the main OS 121.
Introspection Services:
[0051] [0052] 9. The services of the trusted domain OS 131 may
extract a process/thread list of the main OS 121, namely, it may
perform introspective analysis of the main memory and extract the
process and thread list; [0053] 10. The services of the trusted
domain OS 131 may check for network activity reports, namely, it
may report the current open TCP/IP ports as reflected in the main
OS handles; [0054] 11. The services of the trusted domain OS 131
may reconstruct and parse various kernel objects of the main OS
121; [0055] 12. The services of the trusted domain OS 131 may open
file handle lists to reconstructing and parse various handle list
tables; [0056] 13. The services of the trusted domain OS 131 may
extract memory and object allocation tables or other kernel
elements for reconstruction of them.
Debugging and Memory Acquisition Services:
[0056] [0057] 14. The services of the trusted domain OS 131 may
extract system and kernel memory by range; [0058] 15. The services
of the trusted domain OS 131 may perform system debugging and trace
at various levels; [0059] 16. The services of the trusted domain OS
131 may perform kernel panic monitoring; [0060] 17. The services of
the trusted domain OS 131 may extract system logs; [0061] 18. The
services of the trusted domain OS 131 may issue critical alerts;
[0062] 19. The services of the trusted domain OS 131 may extract
memory content in a case of failure for offline analysis; [0063]
20. The services of the trusted domain OS 131 may analyze and
detect memory corruptions;
Integrity-Check Services:
[0063] [0064] 21. The services of the trusted domain OS 131 may
validate in-memory kernel integrity of the main OS 121, namely, a
validation of the kernel integrity on load and other invariant
parts after the load; [0065] 22. The services of the trusted domain
OS 131 may validate perform in-memory driver integrity check of the
main OS 121, namely validation of drivers integrity, and on-load
and after-load signatures; [0066] 23. The services of the trusted
domain OS 131 may validate in-memory application/process integrity;
[0067] 24. The services of the trusted domain OS 131 may file
system integrity check in a persistent storage.
Security and Cyber-Defense Integrity;
[0067] [0068] 25. The services of the trusted domain OS 131 may
perform implement a trusted firewall outside of the main OS 121;
[0069] 26. The services of the trusted domain OS 131 may also
perform trusted packet and I/O encryption and decryption for
entities external of the main OS; [0070] 27. The services of the
trusted domain OS 131 may also perform a trusted signing mechanism,
namely, it may sign packets outside of the main OS 121; [0071] 28.
The services of the trusted domain OS 131 may also perform a
trusted memory scanning, namely, it may scan the memory for
malicious signature, vulnerabilities and corruptions.
[0072] FIG. 4 shows still another example of a structure of a TEE
system according to an embodiment of the present invention. Monitor
181 within hypervisor 180 may receive an FIQ interrupt from either
an entity in the network 150 (in a form of a packet--as described
above) or from an internal timer 187. If the interrupt comes from
the network, the packet is conveyed to a routing unit 182. The
routing unit inspects the MAC address of the packet. If the MAC
address relates to the main OS 121, the packet is forwarded to the
main OS. Otherwise, when the MAC address relates to the TEE, the
packet is forwarded to the TEE service dispatcher 132 within the
secured domain 131. The TEE service dispatcher may then activate
one or more of the exemplary services 133, 134, 135, 136, or 137,
respectively.
[0073] The Check Alive service 133 checks various elements of the
main OS to ensure that it is not halted (i.e., that the OS is
indeed running).
[0074] The Introspection Process List service 134 extracts the list
of currently running services from the main OS 121, for further
inspection and analysis within the trusted OS 121 domain.
[0075] The Introspection Process Memory Dump service 135 halts the
main OS 121, and extracts from the main OS 121 a section of its
memory, for further inspection and analysis within the trusted OS
121 domain.
[0076] The Main Domain Reboot service 136 performs reboot of the
main OS 121 upon a specific event or trigger.
[0077] Finally, the Main Domain Software Update service 137
performs an updating procedure of the main OS 121. This procedure
is performed by periodical halting the processor which runs the
main OS, replacing sections of the memory, and rerunning the main
OS.
[0078] It should be noted that all said services are unique, as
they may be activated from an external entity (via the hypervisor),
they are operated from within trusted domain OS, and the results
may be conveyed back directly to the activating entity via the
hypervisor, without any intervention whatsoever of the main OS.
[0079] Alternatively, if the FIQ relates to a timer 187 issued
interrupt, the interrupt is conveyed from the monitor to the TEE
service dispatcher, which in turn activates one of the services,
132-137, respectively.
[0080] As a result of this structure, the secured services 133-137
may be triggered by one the following events: [0081] 1. Periodic
timer 187 trigger--A secured service begins execution every given
period of time. The wakeup is managed via timer 187 interrupts.
Example for a service which is activated is the check alive service
133 which checks every 10 seconds that the operating system is
alive (i.e., that it is not halted); [0082] 2. Timer triggered,
setup timer--A secured service begins execution of some procedure a
predetermined time after the occurrence of a predefined event;
[0083] 3. Hardware event trigger--The secured service begins
execution upon a hardware event as determined by the secured OS
131. This may occur, for example, when an I/O operation begins or
is completed, or upon arrival or sending of a network packet;
[0084] 4. Network command triggered--The secured service begins
execution when a command from the network 150 is received within a
packet from the routing unit 182.
[0085] The above types of events are managed in the internal queues
of the trusted OS 131, and are mapped to the appropriate
services.
[0086] While some embodiments of the invention have been described
by way of illustration, it will be apparent that the invention can
be carried into practice with many modifications, variations and
adaptations, and with the use of numerous equivalents or
alternative solutions that are within the scope of persons skilled
in the art, without departing from the spirit of the invention or
exceeding the scope of the claims.
* * * * *