time to retire linux and c in iot
play

Time to retire Linux (and C) in IoT Lin Zhong http://www.recg.org - PowerPoint PPT Presentation

Time to retire Linux (and C) in IoT Lin Zhong http://www.recg.org By analyzing the problems of Linux, create a software systems research agenda for secure, efficient IoT devices. 2 Our mission better computers http://www.recg.org BIG World


  1. Time to retire Linux (and C) in IoT Lin Zhong http://www.recg.org

  2. By analyzing the problems of Linux, create a software systems research agenda for secure, efficient IoT devices. 2

  3. Our mission better computers http://www.recg.org

  4. BIG World first massive MIMO system prototype 4

  5. Small Mobile & embedded software systems & hardware 5

  6. Linux is taking over the world 6

  7. Linux IoT devices in our home 7

  8. Large Hadron Collider @CERN 8

  9. DeLaval automatic cow milking machine 9

  10. Cars 10

  11. April 2014

  12. Why IoT devices embrace Linux • Moore’s Law made silicon cheaper • 8-bit => 16-bit => 32-bit => 32-bit with MMU • Linux is free and ready available • well seasoned network stack 13

  13. The security crisis 14

  14. 15

  15. 16

  16. Mirai BillGates Kaiten XOR Spike 623 555 517 363 337 321 312 309 306 300 Oct. 16 Oct. 16 July 14 July 14 Dec. 15 Apr. 16 June 16 Sept. 16 Sept. 16 Oct. 16 Four botnets generated 10 DDoS attacks exceeding 300 Gbps between July 2014 and December 2016. Seven of these occurred in 2016 Security Spotlight: Internet of Things and the Rise of 300 Gbps DDoS Attacks Source: akamai

  17. 2.5M First major Kaiten botnet Mirai attack discovered 2M DYN DNS Source IP Count attack 1.5M 1M 500K Feb. July Mar. Apr. May June Aug. Sep. Oct. Nov. A rapid increase in scans of port 23 and 2323 began on May 13, 2016 as the Mirai botnet attempted to log into unsecure IoT devices. Security Spotlight: Internet of Things and the Rise of 300 Gbps DDoS Attacks Source: akamai

  18. The crisis is rooted in Linux/C 19

  19. C is not safe • No memory (type) • No language support safety for concurrency 20

  20. Most kernel vulnerabilities rooted in C Vulnerability Mem. corruption Policy violation DoS Info. disclosure Misc. Missing pointer check 6 0 1 2 0 Missing permission check 0 15 3 0 1 Buffer overflow 13 1 1 2 0 Integer overflow 12 0 5 3 0 Uninitialized data 0 0 1 28 0 Null dereference 0 0 20 0 0 Divide by zero 0 0 4 0 0 Infinite loop 0 0 3 0 0 Data race / deadlock 1 0 7 0 0 Memory mismanagement 0 0 10 0 0 Miscellaneous 0 0 5 2 1 Total 32 16 60 37 2 Chen et al APSys 2011

  21. Linux depends on human developers for correctness “Give enough eye balls, all bugs are shallow” — Linus’ Law 22

  22. Linux depends on human developers for correctness Keep incompetent programmers out by choosing C Linus Towalds, 2007

  23. No guarantee Introduced by Robin Seggelmann in 2011, code reviewed by Stephen Henson, into OpenSSL source code, 12/31/2011 Bug reported 04/01/2014

  24. It’s worse for IoT devices • Not many eye balls • Not many competent developers • Low profit margin • Short-time to market 25

  25. IoT system kernel is driver-rich System-on-a-chip for IoT devices teeming with non-CPU devices Drivers are the most buggy part of kernel

  26. There are a lot of IoT devices. There are a lot of IoT vendors.

  27. Sturgeon’s Law: 90% of everything is crap

  28. Sturgeon’s Law: 90% of IoT vendors are crap • Device shipped with debug access enabled • Hard-coded passwords • Unused features left in • Difficult to manage • Impossible to update Christopher Biggs, “The Internet of Scary Things - tips to deploy and manage IoT safely”, 2017

  29. Sturgeon’s Law: 90% of IoT devices are crap Top ten attack origins on monitored IoT honeypot in 2016, by count of unique attackers (Source: Symantec)

  30. “When identical devices are manufactured and sold in huge quantities, the possibility for mass takeover of those devices is real.” — Jonathan Corbet, Internet of Scary Things , LWN, 2017 31

  31. All top IoT malware identified by Symantec affect Linux systems • Linux.Dofloo (aka AES.DDoS, • Linux.Darlloz (aka Zollard) Mr. Black) • Linux.Aidra / Linux.Lightaidra • Linux.Pinscan / Linux.Pinscan.B (aka PNScan) • Linux.Xorddos (aka XOR.DDos) • Linux.Kaiten / Linux.Kaiten.B (aka Tsunami) • Linux.Gafgyt (aka GayFgt, • Linux.Routrem (aka Bashlite) Remainten, KTN-Remastered, • Linux.Ballpit (aka KTN-RM) LizardStresser) • Linux.Wifatch (aka Ifwatch) • Linux.Moose • Linux.LuaBot Source: Symantec 2016 https://www.symantec.com/connect/blogs/iot-devices-being-increasingly-used-ddos-attacks

  32. https://www.theregister.co.uk/2017/01/19/iot_will_get_worse_before_it_gets_better_dev_tells_linux_conference/

  33. IoT security is about securing the bottom 10% 34

  34. Linux/C invites hardware- based isolation • Privilege levels • User, kernel, hypervisor, monitor…. • MMU • Intel SGX, ARM TrustZone 35

  35. Microsoft Azure Sphere requires more complicated hardware Flash PMU GPIO, etc. CPU Flash Memory Controller Boot ROM GPU MMU GPU MMU Interconnect Fabric GPU MMU GPU MMU With MediaTek’s assistance we modified and extended the MT7687. We made three changes to the SHA, MD & AES WiFi SRAM Cryptographic Hardware RNG Subsystem Engines Microcontroller Die Figure 1. Architecture of the MT7687 Wi-Fi-enabled Microcontroller. With MediaTek’s assistance we modified and extended the MT7687. We made three changes to the The Seven Properties of Highly Secure Devices Galen Hunt, George Letey, and Edmund B. Nightingale Microsoft Research NExT Operating Systems Technologies Group Figure 2. Architecture of the Experimental Sopris Highly Secure WiFi-enabled Microcontroller. MediaTek’s MediaTek’s

  36. Shall we trust hardware for isolation? Unprivileged process Process accessing accessing privileged data address out of bound Failure of privilege levels Failure of MMU isolation 37

  37. Monsters in our home aka the toaster apocalypse 38

  38. Monsters in our home aka the toaster apocalypse 39

  39. IoT OS Wishlist • C => Safe language • No reliance on hardware isolation 40

  40. Linux has an efficiency problem 41

  41. Runtime enforcement of correctness is expensive Linux/C { Design Implmtn. Compile Install Load Run Post time time time time time time mortem Time of enforcement Inspired by Hunt & Larus (2004) 42

  42. Expensive system calls Syscall impact on user-mode IPC 1.5 Syscall impact on user-mode IPC (higher is faster) 1.3 1.5 User-mode IPC (higher is faster) 1.3 User-mode IPC 1.1 1.1 0.9 Lost performance (cycles) 0.9 Lost performance (cycles) 0.7 0.7 0.5 Syscall exception 0.5 0.3 Syscall exception 0 2000 4000 6000 8000 10000 12000 14000 16000 Time (in cycles) 0.3 0 2000 4000 6000 8000 10000 12000 14000 16000 Time (in cycles) Soares & Stumm, OSDI 2010 • Mode switch overhead: Stack access, exception handling • Locality reduction: cache, TLB pollution 43

  43. IoT services are I/O and network-oriented • A piece of sensor data has to cross the user-kernel boundary twice!!! 44

  44. IoT OS Wishlist • C => Safe language • No reliance on hardware isolation • Runtime enforcement => Static enforcement 45

  45. Linux has a maintainability problem 46

  46. Too big too complex for innovation 100 Linux Kernel Lines of code (Million) 10 1 0.1 1991 1994 1997 2000 2003 2006 2009 2012 2015 2018 47

  47. userspace Highly modularized but entangled processes nano-core Modules contain submodules Modules hold states for each other kern syscall PIC filesystem filesyst el dispatcher IRQ em cons s task fil ole c mgmt e h filesystem s e y sysc d VGA indirection module all st layer u indir e graphics mux l ecti m e s on s r event dispatcher c laye c RR h r h CFQ policy filesyst e e policy em d d u u PIC l l IRQ s input event e e c submodule mux r r h frame e stack allocator d PIT clock allocator ul IRQ FCFS er key policy boar entanglement d mouse heap indir indirection layer PIC via state spill allocator ecti PIC IRQ on IRQ laye r (b) Microkernel OS (a) Monolithic Kernel (c) Theseus Kernel Fate sharing Live update almost impossible 48

  48. State spill is ubiquitous and deep • When one software entity’s state undergoes a lasting change as a result of handling an interaction with another entity. • Migration, fault isolation, fault tolerance, live update, hot-swapping, maintainability….. 49 Kevin Boos, et al. A Characterization of State Spill in Modern Operating Systems. EuroSys, 2017.

  49. State spill explained Vice President Body man 50

  50. Solution in Data center Leverage redundancy Add layers of indirection 51

  51. Redundancy is a luxury out of Data Center 52

  52. Either bring the service down 53

  53. Reboot a powerplug? 54

  54. Or never updated 55

  55. Getting older and disappearing https://blog.bitergia.com/2013/02/01/demographics-of-linux-kernel-developers-how-old-are-they/

  56. Voyager 2: 40 years after launch, 20 Billion km away 58

  57. 59

  58. IoT OS Wishlist • C => Safe language • No reliance on hardware isolation • Runtime enforcement => Early enforcement • Modularization => Spill free modularization 60

  59. “Let’s retire Linux/C” 61

  60. “Why? Linux/C must be good since it has taken over the world” 62

Recommend


More recommend