A Characterization of State Spill in Modern OSes Kevin Boos Emilio - - PowerPoint PPT Presentation

▶
a characterization of state spill in modern oses
SMART_READER_LITE
LIVE PREVIEW

A Characterization of State Spill in Modern OSes Kevin Boos Emilio - - PowerPoint PPT Presentation

Apr 24, 2023 399 likes •676 views

A Characterization of State Spill in Modern OSes Kevin Boos Emilio Del Vecchio Lin Zhong ECE Department, Rice University EuroSys 2017 How do we deal with complexity? 2 Modularization complex 1 2 3 4 system 3 Modularization 1

slide-1
SLIDE 1

A Characterization of State Spill in Modern OSes

Kevin Boos Emilio Del Vecchio Lin Zhong ECE Department, Rice University EuroSys 2017

slide-2
SLIDE 2

2

How do we deal 
 with complexity?

slide-3
SLIDE 3

Modularization

3

1 2 3 4

complex
 system

slide-4
SLIDE 4

Modularization

4

1 2 3 4

slide-5
SLIDE 5

5

Reducing complexity should make things easier…

  • Process migration
  • Fault isolation & 


fault tolerance

  • Live update, hot-

swapping, software virtualization

  • Maintainability
  • Security and more

1 2 3 4

slide-6
SLIDE 6

Effects of interactions:

  • Propagation of data


and control

  • Changes to the state 

  • f each entity

6

Modularization is not enough!

interactions have 
 complex effects! state spill

1 2 3 4

slide-7
SLIDE 7

State spill in a nutshell

a new term to describe the phenomenon when:


 A software entity’s state undergoes lasting change as a result of an interaction with another entity.

7

slide-8
SLIDE 8

Outline of contributions

  • 1. Define and identify state spill as a root cause
  • f challenging problems in computing
  • 2. Classify state spill examples collected from

real OSes

  • 3. Automate state spill detection with STATESPY
  • 4. Results from Android system services

8

slide-9
SLIDE 9

Definition of State Spill

9

slide-10
SLIDE 10

State spill definition by example

10

public class SystemService { static int sCount; byte mConfig; List<Callback> mCallbacks; int unrelated; public void addCallback( int id, byte cfg, Callback cb) { int b = id; Log.print("id=" + b); mConfig = cfg; mCallbacks.add(cb); sCount++; } } public void main() { int id = ; byte cfg = ; fn cb = handleCb; service.addCallback( id, cfg, cb); log(“added cb!”); } void handleCb() { // do something }

Before

(empty)

During After

Source (application) Destination (system service)

temporary

slide-11
SLIDE 11

STATESPY: Automated State Spill Detection

11

slide-12
SLIDE 12

STATESPY: runtime + static analysis

12

Modification-reachable whitelist

Runtime analysis Static analysis

Resolution requests Running software entity Runtime type resolutions Source files State spill results

  • Goal: help developers understand how 


state spill occurs in their entities

slide-13
SLIDE 13

State Spill in Android Services

13

slide-14
SLIDE 14

Evaluating Android system services

14

Application Service

Proxy Stub

Binder IPC transactions

  • StateSpy monitors service stub boundary (onTransact)
  • monkey induces real apps to invoke various transactions

Found state spill in 94% of service stubs analyzed.

slide-15
SLIDE 15

Secondary state spill

15

Entity S Entity D1 Entity D2

User Applications

KeyguardService VibratorService AlarmManagerService UsbService AudioService UiModeManagerService InputManagerService ActivityManagerService StatusBarManagerService PowerManagerService PackageManagerService HdmiControlService NotificationManagerService UserManagerService WindowManagerService DisplayManagerService SensorService

Hinders fault tolerance, hot-swapping, maintainability

slide-16
SLIDE 16

Case study: Flux [EuroSys’15]

  • Android app migration via record & replay
  • Manually handles residual dependencies with

decorator methods for each service transaction

  • Significant effort to overcome state spill

16

App

Sensor Location Alarm Notification Input Clipboard Sensor Location Alarm Notification Input Clipboard

App App

Alex Van’t Hof, et al., “Flux: multi-surface computing in Android”, EuroSys 2015.

slide-17
SLIDE 17

Case study: Flux [EuroSys’15]

  • Android app migration via record & replay
  • Manually handles residual dependencies with

decorator methods for each service transaction

  • Significant effort to overcome state spill

17

App

Sensor Location Alarm Notification Input Clipboard Sensor Location Alarm Notification Input Clipboard

App App

? ?

Alex Van’t Hof, et al., “Flux: multi-surface computing in Android”, EuroSys 2015.

slide-18
SLIDE 18

Case study: Flux [EuroSys’15]

  • Android app migration via record & replay
  • Manually handles residual dependencies with

decorator methods for each service transaction

  • Significant effort to overcome state spill

18

App

Sensor Location Alarm Notification Input Clipboard Sensor Location Alarm Notification Input Clipboard

App App

slide-19
SLIDE 19
  • Using Flux apps, we reproduced 113 unique

transactions for analysis with STATESPY

Comparison with Flux

19

Not 
 decorated

77%

Flux


23%

slide-20
SLIDE 20
  • State spill identifies problematic service

transactions

  • and which states need special handling

High correlation with state spill

20

Causes 
 State Spill

92%

Not 
 decorated

77%

Flux


23%

slide-21
SLIDE 21

STATESPY catches what’s missing

21

  • Found state spill in 18 (21%) undecorated

methods, each is potentially dangerous

  • Easy detection demonstrates STATESPY’s utility

Safely ignored

79%

missed 21% Not 
 decorated

77%

Flux


23%

slide-22
SLIDE 22

Parting Thoughts

22

slide-23
SLIDE 23

Designs to avoid state spill

  • Client-provided resources
  • Stateless communication
  • Separation of multiplexing from indirection
  • Hardening of entity state
  • Modularity without interdependence

23

RESTful principle

slide-24
SLIDE 24

Related work

  • Coupling[1]/modularity[2] as a necessary condition
  • Info-flow analysis[3,4]
  • Designs that partially reduce state spill
  • Compartmentalizing important states
  • Barrelfish/DC[5], Microreboot[6], CuriOS[7]
  • RESTful architectures (web)[11,12]

24

slide-25
SLIDE 25

Conclusion

  • State spill is an underlying problem that hinders

many computing goals

  • Prevalent and deeply ingrained in many OSes
  • Reducing state spill will lead to better designs
  • More so than minimizing coupling, etc.
  • Next steps: redesign OS to minimize state spill

STATESPY & more: http://download.recg.org

25

slide-26
SLIDE 26

References

(1) J. Offutt, et al., “A software metric system for module coupling.” Journal of Systems and Software, 1993. (2) B. Ford, et al., “The Flux OSKit: A substrate for kernel and language research.” SOSP, 1997. (3) S. Arzt, et al., “FlowDroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for Android apps.” PLDI, 2014. (4) W. Enck, et al., “TaintDroid: an information-flow tracking system for realtime privacy monitoring

  • n smartphones.” OSDI, 2010.

(5) G. Zellweger, et al., “Decoupling cores, kernels, and operating systems.” OSDI, 2014. (6) G. Candea, et al., “Microreboot - a technique for cheap recovery.” OSDI, 2004. (7) F. David, et al., “CuriOS: Improving reliability through operating system structure.” OSDI, 2008. (8) D. Engler, et al., “Exokernel: An operating system architecture for application-level resource management.” SOSP, 1995. (9) D. Porter, et al., “Rethinking the library os from the top down.” ASPLOS, 2011. (10) A. Madhavapeddy, et al., “Unikernels: Library operating systems for the cloud.” ASPLOS, 2013. (11) C. Pautasso and E. Wilde. “Why is the web loosely coupled?: a multi-faceted metric for service design.” WWW, 2009. (12) C. Pautasso, et al., “RESTful web services vs. ’big’ web services: making the right architectural decision.” WWW, 2008.

26