The use and study of hypervisors for embedded systems is active now. However, at the present, there are few hypervisors which are easy to add one`s own modification and to test its validity for individual interests.
As compared to other fields, the start of study on embedded hypervisors is not long, and there exist many spaces for improvements. I believe new methods for using hypervisors have the possibility to solve various existing problems in computer systems. Based on such an idea, a project, the Semzhu-Project, was launched on embedded hypervisors.
The current outputs of Semzhu-Project include:
- 1) Development of Semzhu-Visor, a simplified embedded hypervisor for AArch64, which runs on a modified QEMU, an open source CPU emulator.
- 2) Development of attack detection methods for embedded systems, “AsROP"and"AsCOP," using an embedded hypervisor
Usually it is considered not easy to develop any "security function" for those who are not experts in the field. In this talk, I raise some practical problems found in previous research on attack detection methods for embedded systems, and show the detailed process of developing the methods, "AsROP"and"AsCOP", as solutions to those problems. Through this talk, you will see how one ignorant high-school student could develop those security functions in a single one year.
* Semzhu Project is the result of research and development in SecHack365, a Japanese security hackathon conducted by NICT in order to train young security innovators.
Communication Accommodation Theory Kaylyn Benton.pptx
[CB19] Semzhu-Project – A self-made new world of embedded hypervisors and attack detection methods by Yoshifumi Shu (Yiwen Zhu)
1. Semzhu-Project
A self-made new world
of embedded hypervisors and attack detection methods
at CODE BLUE 2019
Yoshifumi Shu (YIwen Zhu)
2. Who am I
Yoshifumi Shu (YIwen Zhu)
● A 12th grade student
○ at SETAGAYA GAKUEN High School (世田谷学園高等学校)
● Interests
Embedded system
● Security Camp National Convention 2017 graduate
● SecHack365 2018 Excellent graduate
● Twitter : @envzhu
2
3. SecHack365 -The starting point of Semzhu-Project
➢ A Japanese U-25 security hackathon for one year
○ Conducted by NICT in order to train young security innovators
○ Includes seven times training camp
○ For student member, NICT covers all costs associated with participation.
○ Activity period: 2018/5 ~ 2019/3
4. 4
What is the result when one high school student created an
embedded hypervisor and security functions ?
Today’s Topic
5. 5
① Development of an embedded hypervisor
○ Background:
○ There are few embedded hypervisors which are easy to add one`s own
modification and to test its validity for individual interests.
○ Output:
○ Development of Semzhu-Visor, a simple embedded hypervisor for AArch64, which
runs on a CPU emulator.
Abstract (1/2)
6. 6
② Research and development of security functions for embedded systems
○ Background: Few attack detection methods are applicable for embedded
systems.
■ Constraints on security functions for embedded systems:
● Support proprietary software
● Ensure real-time performance
○ Outputs: Development of two attack detection methods for embedded
systems, with a hypervisor.
■ AsROP
■ AsCOP
Abstract (2/2)
7. Agenda
➢ The core idea
➢ Development of Semzhu-Visor
➢ Raise a problem in previous research
➢ Propose “AsROP” and “AsCOP” as solutions
➢ Conclusion
7
9. What is an embedded system?
➢ A computer system which is dedicated to specific functions.
➢ e.g. camera, car, artificial satellite, MRI
➢ Often required …
➢ Small
➢ Power saving
➢ Real-time
9
10. What is a hypervisor?
➢ Technology and platform for virtualizing CPU and OS very fast.
10
Hypervisor
general purpose
OS
general purpose
OS
general purpose
OS
User Space User Space User Space
Physical CPU
11. What is an embedded hypervisor?
➢ A hypervisor specialized for embedded systems
11
Semzhu-Visor (Hypervisor)
general purpose
OS
Embedded OS① Embedded OS②
User Space User Space User Space
Physical CPU
12. Background
➢ The use and study of embedded hypervisors is active now.
○ e.g. ACRN, Xvisor, TOPPERS SafeG
12
13. Background
➢ The use and study of embedded hypervisors is active now.
○ e.g. ACRN, Xvisor, TOPPERS SafeG
➢ There are few hypervisors which are simple and small enough to add one`s own
modification and to test its validity easily.
13
14. Background
➢ The use and study of embedded hypervisors is active now.
○ e.g. ACRN, Xvisor, TOPPERS SafeG
➢ There are few hypervisors which are simple and small enough to add one`s own
modification and to test its validity easily.
➢ The start of study on embedded hypervisors is not long.
○ New ways of using hypervisors have the possibility to solve various problems in
computer systems.
○ Is it possible to develop new security functions with embedded hypervisors?
14
15. 15
The origin of the name “Semzhu-Project”
Senju kannon,千手観音
● The thousand-armed Buddhist Goddess of Mercy
● Supports us behind by his 1,000 arms
■ Support something without being noticed but strongly.
Semzhu = Senju
16. The final goal of Semzhu-Project
Develop an embedded hypervisor which is easy to add
modifications
Propose unique ways of using a hypervisor
+
16
17. The current outputs of Semzhu-Project
Develop a simple embedded hypervisor, Semzhu-Visor
Develop new security functions with a hypervisor,
AsROP and AsCOP
+
17
19. The Features of Semzhu-Visor (1/2)
➢ Development policy
○ Develop from scratch (i.e., also make a printf function)
○ Compiler independent
○ Shorter than 10,000 code of lines (Current: 7,000 lines)
○ Run on a CPU emulator
19
20. The Features of Semzhu-Visor (2/2)
● Specification
○ Type-1, bare-metal hypervisor
○ Linux and KOZOS(an embedded OS) can run as guest OS.
○ Ensure Real-Time Performance
○ Run on a modified QEMU
➢Target board:Raspberry Pi 3 (64bit/AArch64)
○ However, real machine operations are not conformed.
➢Development environment : Clang/LLVM
20
21. The Features of Semzhu-Visor (2/2)
● Specification
○ Type-1, bare-metal hypervisor
○ Linux and KOZOS(an embedded OS) can run as guest OS.
○ Ensure Real-Time Performance
○ Run on a modified QEMU
➢Target board:Raspberry Pi 3 (64bit/AArch64)
○ However, real machine operations are not conformed.
➢Development environment : Clang/LLVM
21
22. 22
Fixed bugs and added the following functions to QEMU(*) so that the hypervisor runs.
● Added a function for hypervisors to cause exceptions virtually on guest VMs.
● Added a function for hypervisors to tarp the abort exceptions that is taken on guest VMs.
● Fixed a bug which causes an interrupt regardless of interrupt enable state of the guest VMs, when
trapping the interrupt and exception function is enabled.
● Fixed a bug that a part of the page table format in the hypervisor MMU cannot be interpreted
correctly.
Modified Qemu
* QEMU ・・・ a widely-used open source CPU emulator
23. The current functions of Semzhu-Visor
Implement only the minimum necessary functions as an embedded hypervisor
➢Scheduler for Guest VMs
➢Virtualization of Guest VM
○ Exclusive management of peripheral devices such as serial devices
○ Virtualization of interrupts and exceptions
○ Virtualization of timers
23
Realize these functions with only 7,000 lines of code!
24. General view of Semzhu-Visor
Semzhu-Visor (Hypervisor)
General-
Purpose OS
Embedded
OS①
Embedded
OS②
User Space User Space User Space
Targeted CPU (AArch64)
24
Modified Qemu (CPU emulator)
Host PC
26. 26
Threat Model
Assume that target embedded systems have …
DEP or any equivalent functions
● No memory is both writable and executable.
○ → Almost all embedded systems have this condition
● → It is impossible to attack by injecting any code.
● → First of all, attackers will attempt to capture control by code-reuse attacks
such as ROP and COP.
27. 27
Threat Model
Assume that target embedded systems have …
DEP or any equivalent functions
● No memory is both writable and executable.
○ → Almost all embedded systems have this condition
● → It is impossible to attack by injecting codes.
● → First of all, attackers will attempt to capture control by code-reuse attacks such as
ROP and COP.
We need to detect ROP and COP.
28. 28
Detection Target : ROP
➢ ROP(Return-oriented programming)
○ Attack by overwriting return address with an arbitrary address and executing
sequences of instructions that ends with a ret instruction (called “ROP gadget”).
○ Chaining multiple gadgets together enables attackers to make complicated attacks.
function1:
...
ldr x0, [x29, 28]
ldp x29, x30, [sp], #32
ret
nop
example of AArch64
29. 29
Detection Target : COP
➢ COP(Call-oriented programming)
○ While ROP is based on “ret” instructions, COP is based on “indirect call”
instructions,
○ Not as frequent as ROP gadgets
○ COP gadgets have instructions with good operability such as argument operations.
function:
...
ldr x0, [sp, #8]
ldr x8, [sp, #16]
blr x8
…
example of AArch64
30. Widely used defense against ROP and COP
● ASLR(Address space layout randomization)
○ By randomize the location of stack and code, make difficult to make an attack.
○ However, attackers can bypass ASLR by Brute Force Attack or Information
Leakage.
■ ASLR doesn't become a solution to the root of the problem.
30
32. 32
Existing defenses against ROP and COP fall in two categories.
① CFI (Control-flow integrity)
② Behavior-based Heuristics
Previous research on attack detection methods
33. ① CFI(Control-Flow Integrity)
➢ Proposed in 2005. [1]
➢ The Core idea: Guard against flows of control not intended by the original
problems.
➢ Verify the correctness of the branch destination address of indirect jumps, indirect
calls, and returns from functions.
➢ Implementation :At compile time, insert verifying codes into target binaries.
33
[1] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti. Control-flow integrity. In Proceedings of the
12th ACM conference on Computer and communications security, pages 340–353. ACM, 2005.
https://users.soe.ucsc.edu/~abadi/Papers/cfi-tissec-revised.pdf
34. ① The Practical Problems of CFI(Control-Flow Integrity)
➢ Require the source code of the target program
➢ Cannot be applied to proprietary software.
➢ High overheads (25% ~ 50%)
→ To overcome these shortcomings, many researchers have tried to invent
practical variants of CFI since the inception of original CFI in 2005.
34
35. ② Behavior-based Heuristics
➢ Use detection theories based on empirical laws of program behaviors.
➢ e.g., Judge whether it is a ROP attack by the length of branch distance by return
execution.
➢ In most cases…
➢ Implemented in kernel space such as a kernel driver.
➢ Work at run-time
35
36. ② The Characteristics of Behavior-based Heuristics
➢ Can be applied to proprietary software.
➢ Less overhead
➢ In most cases, they are implemented with a kernel driver. So detection
processes are performed collectively at specific timings.
➢ Real-time performance is lost.
36
38. 38
● Support proprietary software
○ Because embedded developers often use software whose source code is not available.
● Ensure Real-Time performance
[Discussion] The constraints on security functions for
embedded systems
39. Compare previous research with the constraints
➢ CFI
➢ Implemented in compiler layer
➢ Work both at compile time and at run time.
○ → cannot be applied to proprietary software
➢ Behavior-based Heuristics
○ Implemented in kernel spaces such as a kernel driver
○ Work at run time
○ Real-time performance will be lost.
39
40. Compare previous research with the constraints
➢ CFI
➢ Implemented in compiler layer
➢ Work both at compile time and at run time.
○ → cannot be applied to proprietary software
➢ Behavior-based Heuristics
○ Implemented in kernel spaces such as a kernel driver
○ Work at run time
○ Real-time performance will be lost.
Either methods does not meet all the constraints.
40
41. Raise a problem
There is no previous research meets all the constraints on security
functions for embedded systems.
Little research addresses security functions for embedded systems.
41
42. 42
Is it possible to create security functions which is applicable
to embedded systems?
[Background] Motivation to develop security functions
44. Compare previous research with the constraints
➢ CFI
➢ Implemented in compiler layer
➢ Work both at compile time and at run time.
○ Cannot be applied to proprietary software
➢ Behavior-based Heuristics
○ Implemented in kernel spaces such as a kernel driver
○ Work at run time
○ Real-time performance is lost.
44
45. Compare previous research with the constraints
➢ CFI
➢ Implemented in compiler layer
➢ Work both at compile time and at run time.
○ Cannot be applied to proprietary software
➢ Behavior-based Heuristics
○ Implemented in kernel spaces such as a kernel driver
○ Work at run time
○ Real-time performance is lost.
45
The characteristic of detection method and implementation method have a strong
correlation.
We need to devise a new implementation method which enables security functions
to meet all the constraints.
47. [Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
47
48. [Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
48
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
Convert
Hypervisor
GuestVM
During development
49. [Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
49
Convert
Hypervisor
GuestVM
CPU layer
When an extended Instruction is executedfunction:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
An exception
occurs
50. [Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
50
Convert
Hypervisor
GuestVM
An exception
occurs
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
An exception
occurs
CPU layer
When an extended Instruction is executed
51. [Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
51
Convert
Hypervisor
GuestVM
An exception
occurs
Trap
Hypervisor layer
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
An exception
occurs
52. function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
[Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
52
Convert
An exception
occurs
Hypervisor
GuestVM
An exception
occurs
Trap
53. function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
[Mechanism] How to extend CPU instructions virtually
➢ No prevailed CPU architecture has any systems which enable to extend instructions.
➢ Realized by collaboration among multiple layers.
○ [During development] : Assign the target CPU instruction to an unused instruction.
○ [CPU]: If guest VMs execute an extended Instruction, CPU will cause an exception.
○ [Hypervisor] : Trap that exception and emulate the behavior of the instruction
○ * This time, I use hypervisor calls instead of unused instructions
53
Convert
An exception
occurs
Hypervisor
GuestVM
An exception
occurs
Trap
54. 54
● Applicable to proprietary software.
● Available on other CPU architectures which has a hypervisor layer.
● [Important] Collaboration among multiple layers is available, which is difficult
on the real CPU layer.
○ Collaboration with static analysis tools, etc. (used for overhead reduction
techniques in AsROP, which I describe later)
[Discussion] The advantages of virtually extended CPU
instructions
55. 55
[Discussion] The advantages of security functions with
hypervisors
In some implementations, …
● Applicable to kernel spaces
● Can ensure real-time performance
● Doesn’t require to modify guest OS
● Become easy for developers to utilize embedded OSs, by hypervisors taking
over security functions and reducing roles of guest embedded Oss.
56. 56
What kind of virtually extended instructions works
as security functions?
57. 57
Show security functions with virtually extended CPU instructions in the next slides.
● AsROP
● AsCOP
Security functions with virtually extended CPU instructions
59. 59
● The core theory
○ Based on ROPGuard(*).Normally, “ret” instructions returns back to an instruction following a
corresponding “bl“ instruction (called “call-preceded”).By checking this call-precedence, detect
ROP(in this talk, we call “call-precedence check”).
● Implementation
○ Add this call-precedence check process to the “ret” instruction
■ Called the “sec_ret” instruction
AsROP Mechanism
* Reference[2] ROPGuard I. Fratric. “ROPGuard: Runtime prevention of return-oriented programming
attacks.” 2012
function1:
...
3. bl function2
4. stur x0, [x29, #-16]
5. ...
6. ret
function2:
...
9. ret
CPU is expected to return
here from function 2
60. 60
In normal software, the “ret” instruction is executed frequently. The CPU
overhead is very high. Therefore, AsROP reduces overhead by the following
techniques:
① Code ROP detection process in AArch64 assembly.
② Reduce the number of the “ret” instruction which apply ROP detection process.
The overhead reduction techniques of attack detection
methods against ROP
61. 61
② Reduce the number of the “ret” instruction which apply ROP detection process.
● There some ret instructions which is impossible to abuse for attack.(“harmless ret
instruction”)
○ This time, AsROP defines ret instructions of functions that does not use any pointer and buffer
as “harmless ret instruction”.
● By working in cooperation with static analysis, execute “harmless ret instructions” as
they are without converting them to "sec_ret" instructions.
The overhead reduction techniques of attack detection
methods against ROP
62. 62
② Reduce the number of the “ret” instruction which apply ROP detection process.
● There some ret instructions which is impossible to abuse for attack.(“harmless ret
instruction”)
○ This time, AsROP defines ret instructions of functions that does not use any pointer and buffer
as “harmless ret instruction”.
● By working in cooperation with static analysis, execute “harmless ret instructions” as
they are without converting them to "sec_ret" instructions.
→ With implementations in a kernel driver and in a compiler layer, it is difficult to
realize this idea.
But, with my implementation by virtually extended instruction, it is very easy to realize!
The overhead reduction techniques of attack detection
methods against ROP
63. 63
「ROP is Still Dangerous: Breking Modern Defenses」[4]
● Mention the possibility for attack detection methods checking call-precedence check to be bypassed.
○ If an executable binary is 70KB or lager, there is usually a possibility to mount an attack only
with call-preceded ROP, i.e., the instruction before each gadget is a call instruction.
■ This is a peculiar story of x86, which is susceptible to ROP attack because of its variable length
instructions. So it is not applicable to other CPU architectures which are relatively difficult to attack with
ROP.
■ The attack method requires that ASLR is disabled
○ → It is very difficult to attack CPUs other than x86 with ASLR enabled and with call-preceded
ROP only.
○ → I think there is virtually no possibility to bypass AsROP with call-preceded ROP.
○ We need more research and verification in real applications !
[Supplementary Discussion]
The possibility that AsROP is bypassed
64. 64
Execute script to display “Hello world” with mruby on guest OS, Linux.
➢ Compile to intermediate language + execute intermediate language
The Performance Evaluation of AsROP
Semzhu-Visor(Hypervisor)
Linux(Kernel Space)
mruby VM(User Space)
CPU(AArch64)
65. 65
AsROP Performance Evaluation
Implementation CPU cycles in
total
CPU Overhead Number of
executions of
sec_ret
execution cycles
of sec_ret
(cycles per
execution)
Off AsROP
(Normal case)
45,026,014 0 0 0
Code in C language 80,580,786 35,554,772
(+79%)
113602 313
Code in assembly 59,887,536 14,861,522
(+33%)
113602 130
Code in assembly &
Apply the reducing
overhead techniques
56,433,742 11,407,728
(+25%)
83643 136
66. 66
● One execution of detection process is sure to finish within 200 cycles.
○ Succeed in ensuring Real-Time performance
● Work without any modifying OS.
● CPU overhead is 25%
○ Not practical.
○ → AsROP has to reduce more the number of the “ret” instruction which apply
ROP detection process. (Future Work)
[Discussion] The Characteristic of AsROP
68. 68
● The core theory
○ Normally, an indirect call (in AArch64, the blr instruction) branches to a prologue of a function.
However, in a COP gadget is execution, indirect call branches to a halfway point of a function.
○ Detect COP by checking whether the branch destination is a prologue of a function in the
execution of the blr instruction.
● How can we check whether an address points to a prologue of a function?
○ List the addresses of the function from the execution binary in advance with a static analysis
tool.
○ Add a behavior that checks whether the branch destination is a function by matching the
branch destination address with the function list to blr instruction. (called “sec_blr instruction”)
AsCOP Mechanism
69. 69
● Very high overhead.
● Real-time performance is lost.
● In some case, guest OS may need to be modified to apply functions to user
space.
○ When the memory space is isolated for each user application, the OS needs to
associate the function list with the corresponding user application.
The problems of function list matching
70. 70
The solutions to the problems of function list matching
In most cases, we can instantly judge if an address points prologue of the function.
① Return address saving process check
○ In executable binaries generated by a compiler …
■ Return address saving process are placed at a specific position in functions.
■ And the instruction used to save is not used in other situation..
○ If this process is detected in a function,
■ we can say the address points to the prologue of the function.
② ret instruction precedence check
○ With exception, ret are always placed just before prologues of functions.
• For ret instructions in the middle of the function ,
• AsCOP rewrite it as a branch to the ret instruction at the end of the function.
○ If an instruction is just after a ret, its address also points to the prologue.
List only exceptional functions, which are implemented in assembly and not just after ret instructions.
○ → Successful in reducing function list (1953 → 17) & matching times (10791 → 0)
…
1: add sp, sp, #32
2: ret
function:
3: sub sp, sp, #32
4: stp x29, x30, [sp, #16]
…
71. 71
Execute script to display “Hello world” with mruby on guest OS, Linux.
➢ Compile to intermediate language + execute intermediate language
The Performance Evaluation of AsCOP
Semzhu-Visor(Hypervisor)
Linux(Kernel Space)
mruby VM(User Space)
CPU(AArch64)
72. 72
The Performance Evaluation of AsCOP
CPU cycles in total CPU Overhead Number of
executions of
sec_blr
execution cycles of
sec_blr
46,698,998 total 1,672,984(+3.7%) 10791 total 155 cycles per
execution
73. 73
● CPU overhead was 3.7%; very practical !
● Ensuring Real-Time performance
● Don’t require to modify guest OS
[Evaluation] The Characteristic of AsCOP
76. 76
Log of Semzhu-VisorLog of Guest OS, Linux
AsROP detects a ROP.
And Semzhu-Visor causes an error exceptionon on
Guest VM virtually.
77. 77
AsROP detects a ROP.
And Semzhu-Visor causes an error exceptionon on
Guest VM virtually.
An error exception occurring,
Guest OS terminates abnormally the
user program
Log of Semzhu-VisorLog of Guest OS, Linux
79. 79
● Make Semzhu-Visor more sophisticated and convenient.
● Through the project, I got new ideas and saw massive potential in hypervisor.
○ e.g.
○ The risk of a “ret” instruction being abused for attack might depend on the
place of that instruction. Optimizing behaviors according to the places might
decrease CPU overhead.
○ Changing behaviors of extended instructions randomly might make it difficult
to attack.
○ Also in other fields, I would like to seek the possibility of new ways of using
hypervisors.
Future work
80. 80
● Developed Semzhu-Visor, a simple embedded hypervisor running on a CPU emulator.
● Proposed an implementation method with virtually extended CPU instruction.
● Devised overhead reduction techniques that take advantage of virtually extended CPU
instruction, and developed attack detection methods which is applicable to embedded
systems, AsROP and AsCOP.
■ Applicable to proprietary software.
■ Applicable to kernel spaces.
■ Don’t require to modify OS.
■ Ensure Real-Time performance.
○ For AsCOP, the performance experiment show that it is practical.
Summary
81. 81
Semzhu-Project is the result of research and development in SecHack365,
a Japanese security hackathon conducted by NICT in order to train young
security innovators.
Acknowledgements