Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

ARM uVisor Debug Refinement Project(debugging facility improvements)

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio

Eche un vistazo a continuación

1 de 17 Anuncio

ARM uVisor Debug Refinement Project(debugging facility improvements)

Descargar para leer sin conexión

台灣SITCON投影片,by張家榮(Jared)。
mbed OS是ARM為了物聯網所推出的作業系統,號稱IOT界的Android,IOT無所不在,記錄大量的個人資料,於是安全性便顯得十分關鍵。
uVisor位於mbed最底層,為一專門負責安全的hypervisor,管理整個系統的記憶體安全;掌握了記憶體,就掌握了所有的輸入、輸出,就能確保程式碼、記憶體不會被任意執行、修改、竊取。
目前uVisor的完成度也相當低,開發進度緩慢,主要的原因是uVisor基於安全的考量,不允許I/O的直接存取,也就無法顯示任何訊息。
此計畫期望藉由整合多項開放原始碼專案:CrashDebug、CrashCatcher、MRI到uVisor,改善將來在mbed OS上開發App的開發者,可以在不影響到作業系統或其他box的情況下,順利除錯。

台灣SITCON投影片,by張家榮(Jared)。
mbed OS是ARM為了物聯網所推出的作業系統,號稱IOT界的Android,IOT無所不在,記錄大量的個人資料,於是安全性便顯得十分關鍵。
uVisor位於mbed最底層,為一專門負責安全的hypervisor,管理整個系統的記憶體安全;掌握了記憶體,就掌握了所有的輸入、輸出,就能確保程式碼、記憶體不會被任意執行、修改、竊取。
目前uVisor的完成度也相當低,開發進度緩慢,主要的原因是uVisor基於安全的考量,不允許I/O的直接存取,也就無法顯示任何訊息。
此計畫期望藉由整合多項開放原始碼專案:CrashDebug、CrashCatcher、MRI到uVisor,改善將來在mbed OS上開發App的開發者,可以在不影響到作業系統或其他box的情況下,順利除錯。

Anuncio
Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a ARM uVisor Debug Refinement Project(debugging facility improvements) (20)

Anuncio

Más reciente (20)

ARM uVisor Debug Refinement Project(debugging facility improvements)

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Q&A
  17. 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/

×