The document discusses the ARM uVisor debug refinement project presented at the 2016 Information Technology Conference in Taiwan, focusing on security issues related to IoT devices and the design philosophy of uVisor. It outlines how memory protection and access control can mitigate vulnerabilities in embedded applications through hardware-enforced compartments and describes various debugging tools and methods for Cortex-M devices, including crash debugging and remote debugging capabilities. The presentation emphasizes the importance of secure and effective debugging practices in IoT development, showcasing the uVisor as a solution to enhance security and facilitate better debugging techniques.

1. ARM uVisor
Debug Refinement Project
STUDENTS’ INFORMATION TECHNOLOGY CONFERENCE
2016,TAIWAN
張家榮
Jared
jaredcjr.tw@gmail.com
National Cheng Kung University
Department of Engineering Science

2. • A university student wants to have a
representative work before graduating.
• I used to develop embedded
applications.
(Once won the championship in the
Realtek Semiconductor Ameba IOT
competition)
• Try to know more about system software.
• Then…I found jserv…
Who and Why?

3. Before knowing uVisor,
we need to know mbed OS
source:http://www.slideshare.net/FoolsDelight/resilient-iot-security-the-end-of-flat-security-models
The green block used for
controlling hardware for
security is where we will
discuss in this slide.

4. Security Issue
• mbed OS allows user to develop applications over web
• Developer may read or write memory over its address space
mindlessly.
• Some tricky bug is hard to find.
• IOT devices expose to Network/public
• Attack through I/O
• Cortex-M is Memory-mapped I/O
• All configurations , including read
and write through I/O are Memory issues.
• Ex. USART1_DR = 0x40011000 in STM32F429i
• All data go through USART1 need to
access this address.
photo source:http://www.slideshare.net/FoolsDelight/resilient-iot-security-the-end-of-flat-security-models

5. uVisor Design Philosophy
• Many IoT security problems can be solved with standarized building
blocks
• HARDWARE-ENFORCED COMPARTMENTS (SANDBOXES)
• For individual code blocks by limiting access to memories and
peripherals using the existing hardware security features of the Cortex-M
microcontrollers.
• ARM CORTEX-M MPU
• Sets up a hardware protected environment by using a Memory
Protection Unit
• ALLOWS INTERACTION FROM THE UNPRIVILEGED CODE BY EXPOSING SVCALL-
BASED APIS.
photo reference:http://www.idea-sandbox.com/assets/images/sandbox_graphic_baby_blue.png

6. SandBox v.s. MPU
• MPU IN ARM V7-CORTEX-M
• Set Memory regions
• Minimum size: 32 bytes
• Maximum size: 4GB
• Set as XN
• XN=Execute Never
• cause MemManage Fault
• Read/Write
• Privileged/Unprivileged
• Read Only
• Read/Write
• No access
• Denying access cause
MemManage Fault
• Accessing MPU relative registers in
unprivileged mode cause Bus Fault.
reference:https://github.com/ARMmbed/uvisor

7. HOW TO PROTECT?
reference: http://www.slideshare.net/vh21/introductiontombedosuvisor?related=1
uVisor
SPIUSARTFLASHRAM
BOX 2BOX 1
• ACCESS CONTROL LISTS(ACLS)
• Each color represents for one “user”
• Each of them can only access its “belonings”
• Otherwise,the MPU will cause it to get into “MemManage Fault”

8. SECURE GATEWAY
for communication between boxes
uVisor
BOX 1
secure_gateway(func,args)
BOX 2
func()
SVC SVC
return
unprivileged
privileged
reference: http://www.slideshare.net/vh21/introductiontombedosuvisor?related=1

9. Current debugging
• LED PATTERN
• Hard to know
what caused this issue.
• May difficult to reappear
the condition.
• SEMI-HOST
• Based on SVC
• Output/Input through GDB
• ON-CHIP DEBUGGER
• ST-LINK/J-Link
• wired
Error reason RED LED blinks
PERMISSION_DENIED 1
SANITY_CHECK_FAILED 2
NOT_IMPLEMENTED 3
NOT_ALLOWED 4
FAULT_MEMMANAGE 5
FAULT_BUS 6
FAULT_USAGE 7
FAULT_HARD 8
FAULT_DEBUG 9

10. (gdb) b main.cpp:44
Breakpoint 1 at 0x8000a5e: file main.cpp, line 44.
(gdb) where
#0 us_ticker_read () at ../../external/mbed/libraries/mbed/targets/hal/TARGET_STM/TARGET_STM32F4/us_ticker.c:50
#1 0x0800379e in wait_us (us=500000) at ../../external/mbed/libraries/mbed/common/wait_api.c:29
#2 0x08003766 in wait (s=0.5) at ../../external/mbed/libraries/mbed/common/wait_api.c:20
#3 0x08000a5e in main () at main.cpp:43
(gdb) c
Continuing.
Breakpoint 1, main () at main.cpp:44
44 myled = 0;
(gdb) p/x i
$1 = 0x1
GDB
• WITH GNU DEBUGGER,YOU CAN…
Look up
Memory
registers
…
Control execution
Singel Step
Single Instruction
Breakpoint
Watchpoint
…

11. How to improve it?
• CRASHDEBUG
• Tool to enable post-mortem debugging of Cortex-M crashes with GDB.
• CRASHCATCHER
• Catch Hard Faults on Cortex-M devices and save out a crash dump to
be used by CrashDebug.
• MRI(MONITOR FOR REMOTE INSPECTION)
• The gdb compatible debug monitor for Cortex-M devices.
• Running over any of the UART ports on the device.
• Get rid of On-Chip debugger.
• Wireless debug at any time and any where.
photo reference:http://shop.myavr.com/pic/articles/STM32F429-disco_g.png
Reference hardware:
STM32F429i-Discovery

12. CrashCatcher
• SAVE THE MEMORY CONTENT IN THE HARDFAULT_HANDLER
• Used by GDB+CrashDebug
• Send the content to remote host or save in the local flash memory.
• THE FORMAT MUST BE READABLE BY GDB WITH CRASHDEBUG
• Little-Edian
• registers content
• StartAddress-EndAddress
• Content
63430200
00000000
740200200000000000ED00E000000000
00000000000000000000000000000000
00000000000000000000000000000000
02000000
D0FF0220
950A0008A80B000800000021
03000020
0000002000C00120
00000320A15D0008ED5D0008FD0C0008
2B1F00082D1F00082F1F000800000000
000000000000000000000000ED5D0008
331F000800000000ED5D0008ED5D0008
ED5D0008ED5D0008ED5D0008ED5D0008
ED5D0008ED5D0008ED5D0008ED5D0008
ED5D0008ED5D0008ED5D0008ED5D0008
...
Original Project Developer : Adam Green(http://mbed.org/users/AdamGreen/) Reference hardware:
STM32F429i-Discovery

13. (gdb) c
Continuing.
Can't send signals to this remote system. SIGSEGV not sent.
**Hard Fault**
Status Register: 0x40000000
Forced
**Usage Fault**
Status Register: 0x08
Coprocessor Access
Program received signal SIGSEGV, Segmentation fault.
0x08000ba8 in dbg_vprintf (fmt=0x8000a3f <dbg_put_dec(uint32_t, int, char)+102> "", va=...)
at MyImplementationIO/usart:535
CrashDebug
• POST-MORTEM DEBUG
• With the crashed dump memory content,we can
• Let the GDB view it as an alive target.
• Use GDB commands.
• Seeing the critical variable value.
• View the location that causing the situation.
• backtrace
• HELP US TO KNOW WHAT HAPPENED.
Original Project Developer : Adam Green(http://mbed.org/users/AdamGreen/) Reference hardware:
STM32F429i-Discovery

14. Monitor for Remote Inspection
(MRI)
• ALLOWING TO USE GDB REMOTE DEBUGGING THROUGH ANY COMMUNICATION
METHOD(WIRELESS IS POSSIBLE)
• Replace On-Chip debugger
• Currently support USART in STM32F429i-Discovery Cortex-M4 devices.
• GDB REMOTE SERIAL PROTOCOL
• Communicating with host GDB.
• Get commands by modifying USART handler.
• According to the commands sent from host GDB
• MRI sets the debug monitor in Cortex-M devices.
• DEBUG MONITOR
• One of the two debugging methods in Cortex-M devices.
• Halt mode
• debug monitor
• Based on exception handler
photo reference:https://www.segger.com/cms/admin/uploads/imageBox/J-Link-PRO_left_shadow_350x.jpg
Original Project Developer : Adam Green(http://mbed.org/users/AdamGreen/) Reference hardware:
STM32F429i-Discovery

15. Ad-Hoc Debugging
future framework between debugger and debuggee
Reference hardware:
STM32F429i-Discovery
dashed line represents for any communication way,such as USART or Bluetooth.
Debug Box
CrashCatcher
MRI
System 1
remote GDB
System 2
Save
CrashCatcher
dump
GDB with
CrashDebug
uVisor
Application BOX(s)
with
access permission
in the ACLs of the
Debug Box

16. Q&A

17. THANKS FOR LISTENING！
Especially thanks for (The order does not represent for any significance)
jserv jserv.tw@gmail.com
George Kang georgekang03@gmail.com
Adam Green http://mbed.org/users/AdamGreen/
Milosch Meriac https://meriac.com/