improving the performance, availability, and security...
TRANSCRIPT
IMPROVING THE PERFORMANCE, AVAILABILITY,AND SECURITY OF DATA ACCESS FOROPPORTUNISTIC MOBILE COMPUTING
BY STEPHEN D. SMALDONE
A dissertation submitted to the
Graduate School—New Brunswick
Rutgers, The State University of New Jersey
in partial fulfillment of the requirements
for the degree of
Doctor of Philosophy
Graduate Program in Computer Science
Written under the direction of
Liviu Iftode
and approved by
New Brunswick, New Jersey
May, 2011
c© 2011
Stephen D. Smaldone
ALL RIGHTS RESERVED
ABSTRACT OF THE DISSERTATION
Improving the Performance, Availability, and Security of
Data Access for Opportunistic Mobile Computing
by Stephen D. Smaldone
Dissertation Director: Liviu Iftode
An opportunistic model of mobile computing is presently emerging in which users can
fully benefit from their personal computing environment wherever they are without hav-
ing to carry “heavy-weight” mobile systems with them. The transition to this model
can be seen as part of the pervasive computing vision, being catalyzed by the near
ubiquity of powerful smart phones, the increasing availability of local PC hardware,
and recent trends in virtualization and cloud computing. The fate of the opportunistic
mobile computing model will be essentially decided by the performance, availability,
and security of data access relative to alternative solutions. Mobile users require safe
and efficient access to their data from whatever PC or device they are currently us-
ing, wherever they may be. These requirements expose several new challenges to the
performance, availability, and security of user data access under opportunistic mobile
computing conditions.
In this dissertation, we identify challenges to user data access within the opportunis-
tic mobile computing model, present novel approaches to address them, and demon-
strate the effectiveness of these approaches through extensive experimentation. To im-
prove the performance of data access for opportunistic mobile computing, we introduce
the concept of safe borrowing of local storage, which we prototyped as the TransPart
ii
system. To improve the availability of data access for opportunistic mobile computing,
we introduce the concept of a self-cleaning portable cache, which we prototyped as the
Horatio system. To improve the security of remote data access for opportunistic mo-
bile computing, we introduce the Working Set-Based Access Control (WSBAC) scheme,
which applies the concept of the working set to distributed file system access control.
The main conclusion of our research is that opportunistic mobile computing can be
realized in a safe and efficient manner for mobile users. Given the ad-hoc nature of
opportunistic mobile computing, it is likely that the challenges identified in this dis-
sertation will continue to exist into the foreseeable future. Fortunately, as our research
shows, they can be addressed using nascent technologies and applying our concepts
without violating the basic tenet of opportunistic mobile computing, namely to mini-
mize the burden of what hardware users must carry.
iii
Acknowledgements
This dissertation was only possible through the contribution, encouragement, advice,
support, and good will of a large number of people. I cannot hope to repay them in kind,
and I humbly thank them all for their efforts. I wish to thank my advisor, Professor
Liviu Iftode, and the members of my committee, Professor Mahadev Satyanarayanan
(Carnegie Mellon University), Professor Badri Nath, Professor Vinod Ganapathy, and
Dr. Ramon Caceres (AT&T Labs Research) for their generosity in taking the time to
review and offer insightful suggestions to greatly improve this dissertation. I would also
like to thank the other Rutgers Computer Science faculty members whose classes and
seminars I have had the privilege of attending. I have thoroughly enjoyed the many
hours of learning, discussion, and debate.
I first met my advisor, Professor Liviu Iftode, when I was an undergraduate at
Rutgers. Since then, his vision, passion, drive, and sense of humor have been a constant
source of motivation and confidence for me as I progressed (and sometimes stumbled)
along the trail to this point. Through the past decade that I have had the honor of
working with Liviu, he always believed in me and my work, even during the times when
I lost confidence in myself. He taught me to always strive for improvement and that
good enough can always be made better. He also taught me to listen to and value the
opinions of others as much as my own. It is impossible to enumerate all of the other
valuable lessons, which I have learned while working with Liviu. Simply put, I cannot
imagine having undertaken this effort without him. I thank him for this and everything
else I have undoubtedly failed to mention.
I have also had the good fortune of being able to work on the greater part of this
dissertation with Professor Mahadev Satyanarayanan (Carnegie Mellon University).
Satya’s clear vision, direction, constant optimism, and kind advice have provided a
iv
wealth of benefit to me as I struggled to complete this work. I am honored to have had
the opportunity to work so closely with Satya. His impact on my technical thinking
and writing skills cannot be overstated.
Through my time at Rutgers, I have had the pleasure of working with many excellent
people. My relationship with Aniruddha Bohra began when he was the TA for the
undergraduate operating systems class I attended. Later he became my good friend
and research partner. I can hardly think of a single topic, both technical and non-
technical, that we did not debate during the six years we spent together at Rutgers.
He was both a mentor and role model to me, always willing to offer both advice and
criticism whenever they were needed. For this I thank him. I was very lucky to be
introduced to real systems research by Florin Sultan. I can still remember speaking
with him late at night after crashing Minuet, once again. If not for him and Aniruddha,
I may never have ventured into research on my own. Pravin Shankar has been both a
good friend and colleague. Our numerous discussions and debates have served, at times,
to alter and validate my own opinions. Finally, Professor Vinod Ganapathy helped me
to frame a substantial portion of this dissertation. His energy and optimism helped
to guide me through the failures on the road to success. I have enjoyed working with
Vinod.
I want to acknowledge the many members of the DiscoLab with whom I have had the
privilege of sharing my time at Rutgers. I especially thank Murali Rangarajan, Nishkam
Ravi, Arati Baliga, Lu Han, Tzvika Chumash, Vancheswar Ananthanarayanan, Mohan
Dhawan, Shakeel Butt, Vivek Pathak, Gang Xu, and James Boyce. I also want to
include Professor Ahmed Elgammal and his graduate student Chetan Tonde, who are
members of the Rutgers Computer Science Department, but not affiliated with Dis-
coLab. Working with Ahmed, Chetan, and Vanchi on the CyberBike has been a very
rewarding endeavor. Through the years, all of these people have contributed their time,
ideas, and opinions to the many projects, discussions, meetings, practice talks, papers,
and posters that encompass the work and life of a graduate student. They have been
crucial to my time at Rutgers, and I have enjoyed interacting with each of them. I also
want to thank the numerous people outside of Rutgers who have collaborated with me
v
on to my work, especially, Benjamin Gilbert (Carnegie Mellon University), Jan Harkes
(Carnegie Mellon University), Professor Eyal de Lara (University of Toronto), and his
graduate student Nilton Bila (University of Toronto). Their insights, hard work, and
feedback helped me to build and evaluate the systems central to this dissertation.
I want to thank my parents, Donald and Lesyle, and my brother, Gregory, for the
unfailing confidence and encouragement they have given me in my life. I would not be
me, without them. Finally, I must thank my wife, Marcy. She gives meaning to my
life and work. Her love, dedication, and willingness to sacrifice have been unbounded
over the past ten years. I can never repay her for the freedom she has afforded me in
allowing me to pursue a dream. This dissertation would not exist, but for her love and
assistance.
Thank you all!
vi
Dedication
To my wife, Marcy.
vii
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Dedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Opportunistic Mobile Computing . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Taxonomy of Opportunistic Mobile Computing Approaches . . . . . . . 3
1.4. Data Access Challenges for Opportunistic Mobile Computing . . . . . . 21
1.5. Summary of Dissertation Contributions . . . . . . . . . . . . . . . . . . 28
1.6. Contributors to the Dissertation . . . . . . . . . . . . . . . . . . . . . . 30
1.7. Organization of the Dissertation . . . . . . . . . . . . . . . . . . . . . . 31
2. Improving the Performance of Mobile Data Access . . . . . . . . . . . 32
2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2. TransPart Design and Implementation . . . . . . . . . . . . . . . . . . . 33
2.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3. Improving the Availability of Mobile Data Access . . . . . . . . . . . 64
viii
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2. Motivating Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3. Horatio Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.4. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.5. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.7. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4. Improving the Security of Mobile Data Access . . . . . . . . . . . . . 101
4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.2. Applicability of WSBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.3. WSBAC Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.4. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.5. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.7. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.1. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
ix
List of Tables
1.1. Comparison of Opportunistic Mobile Computing Approaches . . . . . . 10
2.1. Portable Storage Device Characteristics . . . . . . . . . . . . . . . . . . 34
2.2. Postmark Configuration for TransPart Evaluation . . . . . . . . . . . . . 44
2.3. Modified Andrew Benchmark Results for TransPart . . . . . . . . . . . 47
3.1. Data and Control State . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2. Portable Devices Used In Horatio Evaluation . . . . . . . . . . . . . . . 80
3.3. Macrobenchmark Workloads for Horatio Evaluation . . . . . . . . . . . 83
3.4. Microbenchmark Suspend Results for Horatio . . . . . . . . . . . . . . . 85
3.5. Microbenchmark Resume Results for Horatio . . . . . . . . . . . . . . . 85
3.6. Self-Cleaning Time for Horatio (Microbenchmarks) . . . . . . . . . . . . 89
3.7. Self-Cleaning Time for Horatio (Macrobenchmarks) . . . . . . . . . . . . 89
3.8. Energy Consumption for Horatio (Microbenchmarks) . . . . . . . . . . . 92
3.9. Eager State Propagation Results for Horatio . . . . . . . . . . . . . . . . 94
4.1. Working Set Estimation Time and Storage Costs for WSBAC . . . . . . 121
4.2. Working Set Error and Over-Estimation Results for WSBAC . . . . . . 123
4.3. Working Set Sensitivity Results for WSBAC . . . . . . . . . . . . . . . . 124
x
List of Figures
1.1. Virtual Machine Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. VM Encapsulation for Mobility . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Thin Client Remote Access Overview . . . . . . . . . . . . . . . . . . . . 12
1.4. VM on USB Device Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5. VM on USB Device Architecture . . . . . . . . . . . . . . . . . . . . . . 14
1.6. VM on Network Share Overview . . . . . . . . . . . . . . . . . . . . . . 16
1.7. VM on Network Share Architecture . . . . . . . . . . . . . . . . . . . . . 17
1.8. VM over Internet Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.9. VM over Internet Architecture . . . . . . . . . . . . . . . . . . . . . . . 20
2.1. TransPart Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2. TransPart System Architecture . . . . . . . . . . . . . . . . . . . . . . . 37
2.3. TransPart Experimental Configuration . . . . . . . . . . . . . . . . . . . 43
2.4. Postmark Results for TransPart . . . . . . . . . . . . . . . . . . . . . . . 45
2.5. Application Launch Latency for TransPart . . . . . . . . . . . . . . . . . 46
2.6. Office Productivity Benchmark Results for TransPart . . . . . . . . . . . 49
2.7. Software Installation Benchmark Results for TransPart . . . . . . . . . . 50
2.8. Bonnie++ Results for TransPart . . . . . . . . . . . . . . . . . . . . . . 51
2.9. Start-up Time for TransPart . . . . . . . . . . . . . . . . . . . . . . . . 53
2.10. SanDrive Shutdown Time for TransPart . . . . . . . . . . . . . . . . . . 54
2.11. MSD Shutdown Time for TransPart . . . . . . . . . . . . . . . . . . . . 55
2.12. IPOD Shutdown Time for TransPart . . . . . . . . . . . . . . . . . . . . 56
3.1. Oases of Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.2. Data and Control Transfer in Horatio . . . . . . . . . . . . . . . . . . . 70
3.3. VM Ownership and Handoff in Horatio . . . . . . . . . . . . . . . . . . 71
xi
3.4. Rules for Ownership Transfer . . . . . . . . . . . . . . . . . . . . . . . . 74
3.5. Suspend and Resume Overheads for Horatio (Macrobenchmarks) . . . . 88
3.6. Workload Dirty State Generation for Horatio . . . . . . . . . . . . . . . 95
3.7. Update Locality for Horatio . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.1. Remote File Access Scenario . . . . . . . . . . . . . . . . . . . . . . . . 103
4.2. WSBAC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.3. WSBAC Implementation – Polex Components . . . . . . . . . . . . . . 113
4.4. Policy View Namespace (PVN) for WSBAC . . . . . . . . . . . . . . . . 115
4.5. WSBAC Implementation – Polen Components . . . . . . . . . . . . . . 116
4.6. OpenSSH Compilation Results for WSBAC (Polex) . . . . . . . . . . . . 122
4.7. Microbenchmark Results for WSBAC (Polen) . . . . . . . . . . . . . . . 126
4.8. OpenSSH Compilation Results for WSBAC (Polen) . . . . . . . . . . . . 127
xii
1
Chapter 1
Introduction
1.1 Thesis
Opportunistic mobile computing can be achieved if critical challenges in
the performance, availability, and security of user data access, introduced
by the weakening of the binding between the user’s data location and the
environment from where it is accessed, are solved.
In support of this thesis, the dissertation we present identifies challenges to current
models of user data access for opportunistic mobile computing along the key attributes
of performance, availability, and security, and presents novel solutions to them in the
form of three system architectures. We demonstrate improvements in mobile user data
access for: (i) performance by introducing the concept of safe borrowing of local storage;
(ii) availability by introducing the concept of a self-cleaning portable cache; and (iii) se-
curity by applying the working set concept to distributed file system access control. As
mobile computing becomes more influenced by pervasive computing concepts through
the inclusion of virtualization and cloud computing technologies, the tight binding be-
tween the storage location of a user’s data and the personal computing environment
from where it is accessed is weakened. Therefore, a critical goal of opportunistic mobile
computing is for users to have safe and efficient access to their data, and we believe
that mobile data access plays a key role in the effectiveness of opportunistic mobile
computing for users. Therefore, improvements to data access for mobile users that
address current challenges in performance, availability, and security, advances the over-
all effectiveness of opportunistic mobile computing for users to the betterment of the
overall user experience.
2
1.2 Opportunistic Mobile Computing
Mobile computing is growing beyond the original usage model where users carry their
laptops with them, wherever they go. Slowly, it is merging with the vision of pervasive
computing [91, 113], largely fostered by modern trends in virtualization and cloud
computing. In this newly emerging opportunistic mobile computing model, users are
no longer burdened by the need to carry “heavy-weight” hardware in order to interact
with their personal computing environments. Instead, users are free to take advantage
of whatever PC hardware resources are available to them within their locality. By
leveraging such local computing resources, users are able to carry out their computing
tasks on this “borrowed” hardware. The key effect of this is a reduction of the size,
weight, and energy demand of what must be carried to be effective on the go; a user’s
mobility footprint.
As a user’s mobility footprint is reduced, as close to zero as possible, other challenges
emerge. These challenges are due to the weakening of the tight binding between the
location of a user’s data and the computer environment from where it is being accessed.
The need for users to carry their computers in preparation for all possible computing
tasks they may require is being retired, but at the same time, this challenge is being
replaced by new challenges that affect the adoption of the opportunistic computing
model.
Central to personal computing is that users have safe and efficient access to their
data. This data can be generalized to include not only the files and directories of a user’s
file system structure, but also the applications, associated libraries, and preferences
that make up the complete personal computing user experience. Although computing
resources can be borrowed in an opportunistic fashion, mobile users cannot simply
borrow their data. It is unique to them and cannot simply be “foraged” from the local
environment around them.
The requirements of safe and efficient access to data expose challenges along three
critical dimensions under opportunistic mobile computing scenarios: (i) performance,
(ii) availability, and (iii) security. In the remainder of this chapter, we explore the
3
breadth of opportunistic mobile computing approaches, examining each with respect to
their advantages and disadvantages, and introduce three critical challenges to oppor-
tunism in mobile computing, which motivates the respective approaches presented in
the chapters to follow. As we describe, each of the two most opportunistic approaches
faces a different challenge; performance of data access on one hand and availability of
data access on the other. At the same time, they both share the security of data access
as a common challenge.
1.3 Taxonomy of Opportunistic Mobile Computing Approaches
Since the advent of laptop precursors and other “small” form factor devices to provide
portable computational resources for users, the concept of mobile computing has evolved
to a point where today there exist a vast number of different forms of mobile devices.
As new generations of devices are unveiled, they speciate to support an ever more
specified set of computing tasks. Although there have been periods of convergence, it is
still common for people to carry one, two, or sometimes even more computing devices.
Essentially, there seems to be a certain, perhaps psychologically motivated, requirement
for preparedness that mobile individuals feel necessary in order to account for whatever
tasks they may need to accomplish while in transit.
While pervasive computing [113] concepts are steadily being realized and accepted in
people’s daily lives, the world of mobile computing has attempted to adopt the seamless
feel of pervasiveness. The concept of cyber foraging [91], for example, trades user
preparedness in favor of adaptability. Under this model of mobile computing, a mobile
individual is willing to shed some (perhaps most) of her technological devices, lightening
her load in terms of what must be carried to satisfactorily meet her requirements. A
mobile individual doing so assumes that there will be ample computing resources to
satisfy her needs, wherever and whenever those needs arise.
Adaptability under Cyber Foraging come in two forms. First, the mobile individ-
ual must be willing to adapt to use whatever computational resources are available
at her present location. Second, the technology in the environment must be capable
4
of adapting to the task requirements of the individual. While traditional models of
mobile computing have presented a pessimistic approach, assuming that all resources
must be carried, cyber foraging, and other related concepts such as Mobile Ad-Hoc
Networks (MANETs) [54], Vehicular Ad-Hoc Networks (VANETs) [85], desktop and
server virtualization [14, 21, 22, 24], Cloud Computing [11, 16, 19], and Online Social
Networks (OSNs) [10, 15, 18], present more optimistic models that favor and support
opportunism [51, 52].
In this dissertation, we primarily restrict our consideration of mobile computing ap-
proaches to a subset of the universe of approaches. When referring to mobile computing,
we strictly limit our scope to the traditional sense of mobile personal computing, that
of a mobile user interacting with her personal computing environment. At times, this
style of computing has been referred to as a mobile form of the desktop paradigm of
computing. By extension, when we refer to opportunistic mobile computing, we mean
any approach to mobile personal computing that allows a mobile individual to oppor-
tunistically take advantage of local computer resources to lighten the burden of what
must be carried to complete her desired tasks.
To better understand the breadth and scope of opportunistic mobile computing, we
present a taxonomy of approaches. We classify them according to a set of criteria and
qualitatively assign values based upon the properties of each criterion and its impact on
the mobile user experience. In the taxonomy presented in this section, we first define the
classification criteria, briefly review the Virtual Machine technology and terminology
underlying some of the approaches, then describe each of the existing mobile computing
approaches according to our classification criteria.
1.3.1 Classification Criteria
To classify the variety of opportunistic mobile computing approaches, we propose a set
of qualitative classification criteria that characterize the relevant properties that may
impact the user experience under each approach. The criteria we propose are: (i) Mo-
bility Footprint, (ii) Accuracy of Re-Creation, (iii) Network Resiliency, (iv) Network
5
Demand, (v) Physical Vulnerability, and (vi) Efficiency of Opportunism. For every ap-
proach, each criterion is evaluated as one of {zero, very low, low, high, very high, perfect}.
Mobility Footprint
We define mobility footprint as the size, weight, and energy demand of what must
be carried by a mobile individual in order to perform her computer-related activities.
Broadly speaking, we make a subjective judgment across the three dimensions based
upon the amount of effort required by the user in order to make efficient use of her
computer resources within the scope of typical personal use. Of course, the bounds of
this scope can vary dramatically. For example, the requirements of a person updating
her online social networking status are likely to be substantially less than that of a
business traveler relying on her devices to act as a mobile proxy for her office. For
the purposes of this taxonomy, we generalize the requirements of the mobile individual
and just assume a reasonable usage model. A zero rating in this criterion is the best
possible, while very high is the worst. We do not assign a meaning to perfect for this
criterion.
Accuracy of Re-Creation
We define accuracy of re-creation to be the level to which the user experience is simi-
lar to the user-anticipated experience. There are two ways in which we must consider
similarity. First, how accurately does an approach reproduce the same computing ex-
perience as the original or base case, for example a laptop the user carries. Second,
how accurately does an approach reproduce the same computing experience between
hardware environments. In other words, how dependent is the approach on the under-
lying similarity of the hardware configuration at each location. The former is concerned
primarily with the translation of user experience from a typical user environment into
a form that is approach-ready, perhaps on the same hardware environment. The lat-
ter is concerned with the translation between varying configurations of the available
hardware environments. For this criterion, a perfect rating is the best possible, while
the worst is very low. Since all approaches recreate the experience to some extent, we
6
assign no meaning to the zero rating.
Network Resiliency
We define network resiliency to be the impact of network performance on the user
experience provided by a specific approach. The two common network performance
parameters are latency and bandwidth. This criterion is concerned with the level to
which an opportunistic mobile computing approach relies on either predictable perfor-
mance or a specific threshold of performance to be met. Some approaches are impacted
more by latency issues, such as jitter, while others depend heavily on bandwidth. From
a user’s perspective, latency issues tend to impact interactive performance [108], while
poor bandwidth tends to cause delays in bulk data transfers. Either of these usually
has a negative impact on the user experience. Additionally, this criterion is concerned
with the tolerance of an approach to network disconnection. For this criterion, the best
possible rating is perfect, while the worst is zero.
Network Demand
We define network demand to be the level to which an approach depends on the network
for correct functioning. While network resiliency attempts to assess the impact of
network performance on the user experience, network demand assesses how heavily
an approach may utilize the network, whenever it chooses to do so. For example,
an approach may function correctly under conditions of network disconnection, but
may fully utilize the network whenever it is available. A good exemplar of such a
system is the Coda [72] network file system, which functions under conditions of network
disconnection by caching a user’s files and updates locally at the client until a network
connection is once again available, at which point it will synchronize the local cache
with the server. Coda would be classified as having very high network resilience and
very high network demand. For this criterion, a zero rating is the best possible, while
very high is the worst. We do not assign a meaning to perfect for this criterion.
7
Figure 1.1: Virtual Machine Architecture
Physical Vulnerability
We define physical vulnerability to be the level of potential risk due to physical damage
or theft, and the impact of those occurrences on user experience. Primarily, we are
concerned with the tolerance to such events a user’s data possesses. At one extreme,
a user may always access her data over a network on a server where it is kept syn-
chronously replicated. At the other extreme, a user may carry her data on a portable
device and never bother to back it up. The former would be classified as zero physical
vulnerability, while the latter as very high. For this criterion, perfect has no meaning.
Efficiency of Opportunism
We define efficiency of opportunism to be the level of opportunism required by each
approach. Opportunism is broadly defined to include hardware, software, and network
requirements. Basically, anything that might be required to be supplied to a mobile
individual at any specific location is included in the assessment of this criterion. The
best possible rating for this criterion is perfect, while the worst is zero. Of course, in
the context of this dissertation, we assume opportunism to be a desirable property.
8
Figure 1.2: VM Encapsulation for Mobility
1.3.2 Virtual Machine Overview and Terminology
Before we present the comparison of different opportunistic mobile computing ap-
proaches, we need to provide some virtual machine related background and terminology.
Virtual Machines (VMs) [61] have been proposed as a method to migrate a mobile
individual’s computing environment from location to location [47]. They do so by
encapsulating all of a user’s data, applications, and preferences into a single “virtual
PC” image, and transferring that image over networks between systems. Figure 1.1
illustrates the architecture of a typical Virtual Machine installation and Figure 1.2
illustrates how VM encapsulation can be utilized to support user mobility through
“virtual PC” migration.
In Figure 1.1, the high-level architecture of a Virtual Machine is presented. A
hypervisor or Virtual Machine Monitor (VMM) is the software layer that provides
hardware virtualization and monitoring functions to a number of Virtual Machines
(VMs) or guests. We refer to the underlying hardware as local or host hardware. Finally,
an independent instance of an operating system executes within each guest VM, and
each guest OS may execute one or more processes. We use this terminology consistently
9
throughout this dissertation.
In Figure 1.2, as a user moves between locations, the user’s VM State, i.e. files,
applications, preferences, etc. are migrated between clients. This state migration can
occur over the network or through the use of a USB flash device carried by the user.
As we will discuss in the following sections, the method of VM State migration has a
direct impact on the performance and availability characteristics of the user’s computing
experience.
1.3.3 Approaches Toward Opportunistic Mobile Computing
The opportunistic mobile computing approaches can be classified into four categories:
(i) Thin Client Remote Access, (ii) VM on USB Device, (iii) VM on Network Share, and
(iv) VM Delivered over the Internet. In our taxonomy, we also define a fifth category
to include the baseline non-opportunistic approach, referred to as Carry PC Hardware.
Table 1.1 presents a comparison of the the opportunistic mobile computing ap-
proaches. For each approach, the table lists our six classification criteria and the as-
sociated assigned ratings. In the remainder of this section, we present a description of
each approach and review the classification criteria ratings for each.
Carry PC Hardware
The baseline Carry PC Hardware approach is not opportunistic at all. Obviously, car-
rying your PC hardware in any form, e.g., laptop, handheld, tablet, etc., is an approach
in which users favor preparedness over opportunism. This approach is characterized by
a relatively large mobility footprint. The first benefit is a lack of network dependency.
This approach is perfectly resilient with respect to network performance, and places
no demand on the network, as it pertains to recreating a user’s personal computing
environment. The applications a user may choose to execute may have their own net-
work performance requirements, but we do not consider that for the purposes of this
classification. The second benefit is that the accuracy of re-creation for this approach
is perfect, regardless of location. The PC hardware never varies, ensuring a consistent
computing experience for the user.
10
App
roac
hes
Car
ryP
CT
hin
Clie
ntV
Mon
VM
onV
MD
eliv
ered
Har
dwar
eR
emot
eA
cces
sU
SBD
evic
eN
etw
ork
Shar
eov
erIn
tern
etla
ptop
,T
HIN
C,
VN
C,
Soul
Pad
,v.
Clo
ne,
vDes
kIS
RE
xam
ples
netb
ook,
GoT
oMyP
C,
Moj
oPac
,U
3,ha
ndhe
ldV
DI
Cee
do,
Thi
nApp
Mob
ility
Foot
prin
tla
rge
zero
very
smal
lze
roze
roA
ccur
acy
ofR
e-C
reat
ion
perf
ect
perf
ect
high
high
high
Cri
teri
aN
etw
ork
Res
ilien
cype
rfec
tve
rylo
wpe
rfec
tm
oder
ate
very
high
Net
wor
kD
eman
dze
rolo
wze
rove
ryhi
ghve
ryhi
ghP
hysi
cal
Vul
nera
bilit
yhi
ghze
rohi
ghve
rylo
wve
rylo
wE
ffici
ency
ofO
ppor
tuni
smze
rove
rylo
whi
ghhi
ghpe
rfec
t
Tab
le1.
1:C
ompa
riso
nof
Opp
ortu
nist
icM
obile
Com
puti
ngA
ppro
ache
s
11
Aside from the size of the user’s mobility footprint, the potential cost associated
with this approach is due to the high level of physical vulnerability. Portable devices
and the associated data stored on them may be lost, damaged, or stolen. Frequent
backups can offer a measure of data protection, but they do not guarantee zero data
loss or ensure continuity of availability. In the event of such a catastrophic occurrence,
there will most likely be a period of unavailability while the user acquires replacement
hardware and restores her applications, files, and preferences.
Thin Client Remote Access
The Thin Client Remote Access approach is one where a user accesses her PC environ-
ment from a client application that executes on local PC hardware and communicates
over a network connection to a remote display server. Figure 1.3 presents a graphical
representation of this approach. In the figure, a thin client station communicates with
a remote display server. The client application captures all keyboard and mouse input,
and transmits it to the server. All of a user’s applications, files, and preferences are
stored and accessed at the server, which sends display images, sometimes called screen
scrapes, back to the client. A number of freely available and commercial versions of
thin clients are available today.
VNC [32], or Virtual Network Computing, is one of the more popular freely available
examples of the thin client approach, but there are a number of others [26, 31, 12].
Recently, a model that utilizes virtual machines as a method of isolation between user
processes on the remote display server has emerged. This approach has been termed
the Virtual Desktop Infrastructure (VDI) approach, but is similar in spirit and usage
model to traditional thin clients. Finally, the THINC [37] project employed various
low-level graphical optimization in order to improve the performance of thin clients for
graphically intensive execution scenarios.
In terms of opportunism, we classify this approach as very low. Whether the client
PC hardware is borrowed or not, only the display, keyboard, and mouse are fully
utilized. All other system resources, i.e., CPU, memory, and disk, are minimally used
just to store and execute the thin client software. No user applications or data are
12
Figure 1.3: Thin Client Remote Access Overview
ever stored, executed, or accessed at the thin client. The benefits of this approach
are four-fold. First, there is zero mobility footprint as users can access their remote
desktops from virtually any PC that can establish a network connection to their remote
display server. Second, the accuracy of re-creation is perfect. Users will always be able
to access their unique desktop environment from the remote display server. Third, the
demand placed on the network is low, due to the fact that only the low level inputs and
display images are transferred between the client and server. Due to compression and
other optimizations, the amount of data exchanged can be kept relatively low. Finally,
there is zero physical vulnerability, under this approach due to the fact that all of a
user’s data is maintained at the remote display server.
Aside from the very low opportunism of the thin client approach, there are other
drawbacks. This approach requires network connectivity. It is not resilient to network
disconnection and it is highly sensitive to network jitter. Although the approach min-
imizes network bandwidth requirements, it is subject to fairly strict network latency
requirements for the entire duration of a user session, as demonstrated by Tolia et
al. [108]. Finally, since multiple user sessions are executed concurrently on each remote
display server, there are potential reliability issues, and a single server failure may im-
pact a large number of users. Recent trends, including the VDI approach, are making
strides in improving this situation, by providing better isolation between users and live
session fail-over between servers, but this still requires a careful architecting of both
the server and network infrastructure to support such fault tolerance.
13
Figure 1.4: VM on USB Device Overview
VM on USB Device
The VM on USB Device approach takes advantage of a VM’s ability to completely
encapsulate a user’s personal computing environment, including her files, applications,
and preferences, and store it on a small form factor USB storage device. Essentially, a
user can carry her data and execution state, and otherwise opportunistically “live off
the land”, making use of whatever PC hardware is locally available.
Figure 1.4 presents an overview of the general model for this approach. In the
figure, a user at Location #1 suspends her computing session at Client Station #1
and initiates a shutdown of the client station. During this shutdown, all VM state
is updated directly on the portable USB device, which is utilized as a disk device by
the client station. Once shutdown is complete, the user disconnects her USB device
and leaves the site. In transit, she carries all of her execution state, files, applications,
preferences, etc. (VM state) with her. Upon arrival at Location #2, she connects the
portable USB device to Client Station #2 and boots the client station directly from
the USB disk to resume her computing session.
Figure 1.5 presents an example of the typical architecture utilized in this approach.
Both the VM state and VMM software are stored on the USB storage device. The
client station boots directly from the USB disk, first loading and executing the VMM
software, then resuming the execution of the guest VM, reading the VM state directly
14
Figure 1.5: VM on USB Device Architecture
from the USB device. Other than a compatible hardware architecture and the ability
to boot from a USB storage device, there are no particular requirements on the client
station. Ubiquity is thus enhanced by eliminating the need to pre-install any software
on client stations. Only the USB storage device needs to be configured with the correct
boot image. Finally, under this model the client disk is unused and no state or state
updates are stored persistently on the local disk.
The SoulPad [42] project was the first to propose and evaluate this approach. Vari-
ous products [5, 6, 8, 13, 23] have since been launched to virtualize a user’s computing
experience across a broad spectrum from full environment encapsulation, similar to
SoulPad, to more application-specific virtualization, in which one or a small subset of
a user’s application set (and associated data) is encapsulated and stored on a USB key.
We classify this approach as highly opportunistic. Essentially, a user needs only
to carry a light-weight device in order to re-create her computing environment. The
benefits of this approach are a very small mobility footprint and, in general, a high
accuracy of re-creation. The accuracy of re-creation may vary for some of the appli-
cation virtualization techniques, depending on how application-specific they are, but
techniques such as SoulPad do not suffer from this. From a network perspective, this
approach is perfectly resilient to network performance issues including disconnection,
15
and it places absolutely no demand on the network. Not including potential user or
application requirements, the approach itself does not rely on the network. Similar to
the Carry PC Hardware model, the VM on USB Device approach assumes the user
carries all of the data required to re-create her computing environment.
Unfortunately, physical vulnerability is a concern with this approach. Loss or de-
struction of the USB device leads to, potentially permanent, data loss. Although a
careful regimen of backups can help, this requires users to be sufficiently disciplined
for it to be a satisfactory solution. It also requires a backup system to be run period-
ically to scan for data modifications, even when none may exist. Minimizing a user’s
window of vulnerability to potential data loss essentially means increasing the backup
frequency, potentially altering a user’s mobility patterns or behavior.
VM on Network Share
The VM on Network Share approach also takes advantage of VM encapsulation of a
user’s personal computing environment. In this case, though, rather than carrying a
portable USB storage device, a user utilizes a client PC, connects to a network share
exported from a file server within a distributed file system [28, 64, 89], and initiates her
computing session by resuming her guest VM from the client.
Figure 1.6 provides an overview of this approach. In the figure, wherever a user may
be, either Location #1 or #2, she directly accesses her data from a client station over
a client-server distributed file system connection. In this model, the primary replica
of her VM state remains on file server storage, and all read and write requests and
responses are passed between the distributed file system client and server. Although
the user’s data may be temporarily copied to the local OS buffer cache on the client,
it is not copied to any local persistent storage device. An extension of this model is
to perform a network boot from the network file system export using a network boot
technique such as the Preboot eXecution Environment (PXE) [27] specified by Intel.
With this extension, a user could directly boot a VMM image from a network export,
and subsequently resume her guest VM. This method allows for a completely diskless
local client. In either case, network booting or not, the user simply suspends her guest
16
Figure 1.6: VM on Network Share Overview
VM when she is done and disconnects the client from the file server.
Figure 1.7 presents the architecture of the typical VM on Network Server approach.
The figure presents the non-network boot case, where the VMM software is directly
installed on the local client. As a guest VM executes, the reads and writes to VM
state are issued over the network to the file server. These are handled similar to other
distributed file system accesses. While prefetching and caching do occur at the client,
nothing is stored persistently on any local client storage devices. On termination of
the guest VM session, updates that may reside in the client buffer cache are flushed
to the file server, to maintain consistency. Once the distributed file system export is
unmounted at the client, any state remaining in the client buffer cache will be purged
and is no longer available at the client.
vDesk [20] is a commercial system that utilizes network attached storage to imple-
ment the VM on Network Server approach. Since all major OSes support the execution
of file server software, and most allow for PXE configuration as well, it is straight-
forward for an administrator to deploy an instance of this approach with free or off-
the-shelf software. In fact, a recent study [60] has even been conducted using both the
NFS [43] and AFS [64] network file systems to serve VM state to clients.
17
Figure 1.7: VM on Network Share Architecture
The benefits of this approach are that it is highly optimistic, has a high accuracy
of re-creation, and has as small a mobility footprint as possible; one in which a mobile
individual has nothing to carry with her. Additionally, it has very low physical vulner-
ability, but it is not zero. This is due to the fact that when the distributed file system
export is mounted at the local client, direct file system-level access is possible from the
client to all of the data stored on the distributed file system export. This exposes the
guest VM state to potential corruption, inadvertent modification or deletion, or even
issues due to malicious client software such as a rootkit or virus.
Unfortunately, the VM on Network Server approach depends heavily on network
performance. In fact, it is directly dependent on the performance of the underlying
distributed file system. The network demand of this approach is very high, since it
must transfer VM state over the network prior to operating on it locally. Also, it is
only moderately tolerant of network degradation. Latency and jitter tend to have a sub-
stantially negative effect on distributed file system performance, due to the synchronous
message-passing nature of underlying distributed file system protocols. Distributed file
systems tend to perform very well under conditions of high bandwidth and low latency,
18
but very poorly under degraded performance, and disconnection can cause data avail-
ability problems for clients. In practice, distributed file systems are more likely to be
utilized for LAN deployments, and are typically not deployed under WAN conditions
such as would be found under Internet-scale deployments. Finally, although some file
system, such as the Coda [72] file system, are designed to gracefully handle conditions
of degraded network performance, the assumptions made regarding average file size and
the optimizations used to tolerate poor network performance do not generally apply to
VM state. For example, Coda performs whole file caching at the time a file is first
opened. Since guest VM state can range well over tens of gigabytes, whole file caching
would cause serious, likely intolerable, delays during the initial resume of a guest VM.
VM Delivered over the Internet
The VM Delivered over the Internet approach is another approach that leverages VM
encapsulation of a user’s personal computing environment. Unlike the previous ap-
proach, it does not leverage a generic distributed file system as the delivery mechanism
for VM state. Instead, recognizing the detrimental effects of poor network performance
on distributed file systems, this approach utilizes a specialized software layer to replicate
VM state between a client station and a specialized VM state server. A user initiates
a session by first creating a local replica copy at a client, and then can resume a guest
VM once a consistent replica has been established.
Figure 1.8 provides an overview of the approach. In the figure, once a user has
completed her computing session, she suspends her guest VM and initiates a VM state
checkin process. This process transfers VM state updates to the server. Once the server
has validated and committed the updates to its copy of the VM state, replica ownership
is transferred to the server from the client, Client Station #1 in this case. To verify
ownership, a token is passed by the client to the server. Only a client with a valid
token can commit VM state updates to the server. Once the state updates have been
committed and ownership transferred, the user is free to travel to her next location.
When she arrives at Location #2, she borrows Client Station #2, initiates the VM state
checkout process, which creates a new replica at the client, and transfers ownership to
19
Figure 1.8: VM over Internet Overview
the client. To ensure consistency, a new ownership token is generated during each
checkout, and it is only known to both the client and server. As an optimization, in the
event that some or all of a VM state replica still resides on this client, only the updates
need to be transferred. This may happen if a user has previously initiated a replica at
this client, during a prior site visit. Once ownership has been transferred, the guest
VM can be resumed and the user can continue to utilize her computing environment
from where she last suspended.
Figure 1.9 presents the architecture of the VM Delivered over the Internet approach.
The base model of this approach requires only the VMM software to be installed at a
client. Once a VM state replica has been established through the checkout process, it
may persist indefinitely at a client, such that the next time a user initiates a checkout
at the same client, some or all of the VM state may already be in residence. Since the
approach attempts to be efficient in the amount of VM state transferred between client
and server, only updates are ever sent in either direction. Additional optimizations
include lazy VM state copying and lookaside caching [106]. The former allows the
client to wait until a portion of VM state is about to be accessed before downloading
20
Figure 1.9: VM over Internet Architecture
it from the server. The latter allows a user to carry a small USB storage device pre-
populated with a version of her VM state replica, which can serve as a low latency, high
bandwidth source of VM state.
The Internet Suspend/ResumeR© (ISR) system [73, 92] was the first to propose the
VM Delivered over the Internet approach towards opportunistic mobile computing.
While ISR builds upon previous work in the Andrew [64] and Coda [72] distributed
file systems, it introduced numerous improvements specific to the area of opportunistic
mobile computing. These improvements span both optimizations for performance and
new security mechanism in order to cover multiple aspects of the approach.
In terms of opportunism, the VM Delivered over the Internet approach is perfect.
In the absence of lookaside caching, a user is not required to carry anything with her
from site to site. This also leads to a zero mobility footprint. Similar to the other VM-
based approaches, the accuracy of re-creation is high, while this approach also benefits
from a very low physical vulnerability due to the validation of VM state that occurs
during the checkin process. Additionally, since there are fixed checkpoints introduced
by the checkin/checkout process, the approach allows a user to initiate a VM state
21
rollback, to a prior version of her VM. Finally, this approach exhibits very high network
resiliency. By replicating VM state locally, at a client, it is much less susceptible to
variations and degradations in network performance. In fact, this approach can even
operate completely disconnected from the network, provided a fully populated replica
is available either on the local client or from a lookaside cache.
The VM Delivered over the Internet approach achieves very high network resiliency
by relying more heavily on network bandwidth to reduce the effects of varying network
latency. Synchronous network access is needed only to service cache misses. Once a
part of VM state is cached, further execution only involves local accesses to it. The zero
mobility footprint of this approach comes at the price of large VM state transfers. Even
if this state is fetched lazily from a server, it is likely to involve many tens or hundreds
of MB at startup, with further transfers during execution. This results in significant
startup delay and slower interactive execution. When a user terminates a session, VM
state updates have to be transferred back to the server. In trusted environments such
as home or office, the user can depart without waiting for this transfer to complete. At
other locations, the user must suffer this delay.
1.4 Data Access Challenges for Opportunistic Mobile Computing
In surveying the approaches to opportunistic mobile computing, we observe a common
distinction that separates them into those that are highly opportunistic from those
that are not. Opportunism weakens the binding between the data storage location of a
mobile individual’s data and the data access location through the inclusion of borrowing.
The act of borrowing PC hardware all but ensures that a mobile individual will have
to go outside of the borrowed PC environment to bring in her data. This can even be
shown for the simple case of web browsing. Although a user can borrow someones PC
to browse web pages, it is not nearly as convenient as if she were to have access to all
of her bookmarks and browser preferences.
Although mobile individuals may be willing to accept the separation of data storage
location from data access location in favor of the benefits in seamless mobility, they are
22
not willing to accept degradation to their overall computing experience. Furthermore,
the act of borrowing reduces the level of trust mobile individuals can place in the
personal computing environment they utilize. Taken together, this means that we
cannot sacrifice data access efficiency or safety for the sake of mobility. Therefore,
to maximize the acceptance of opportunistic mobile computing, we must meet these
requirements as best as possible.
In this section, we first elaborate the requirements of data access efficiency and
safety, then describe the three challenges that we identify and solve to improve the per-
formance, availability, and security of data access for opportunistic mobile computing.
We present each challenge in terms of the opportunistic approach to which it applies
and in the context of the data access efficiency and safety requirements.
1.4.1 Requirements of Data Access Efficiency and Safety
To better understand the requirements of data access and efficiency, we examine the
lifecycle of a user session. We break it into three phases. In the first phase, a user
initiates her computing session to restore her environment to its execution-ready state
from its quiesced state. For a laptop, this means to boot or resume from hibernation.
For a VM, it means to resume from suspend. We call this phase Session Initiation.
The second phase is the execution-ready phase where a user interacts with her data
(applications, files, preferences, etc.). We call this phase Interactive Execution. In
the final phase, a user terminates her session. For a laptop this means to initiate
shutdown of hibernation, and for a VM this means to suspend. We call this phase
Session Termination. We list the requirements of data access efficiency and safety
throughout the user session lifecycle as follows.
Session Initiation
In the Session Initiation phase, the data access efficiency and safety requirements can
be broken down into two properties that must be maintained. First, ensure the avail-
ability of data access such that the required data is accessible to bring the system from
23
a quiesced state to an execution-ready state. Second, ensure that the latency of Ses-
sion Initiation is minimized. The first property is safety-oriented, while the second is
efficiency-oriented.
Interactive Execution
During the Interactive Execution phase, there are two properties to satisfy: the data
access efficiency and safety requirements. First, data access availability must be main-
tained to ensure correct session execution. Second, data access performance must be
good enough to ensure tolerable interactive response latency. As with the Session Initi-
ation tasks, the first property is safety-oriented, while the second is efficiency-oriented.
Session Termination
In the Session Termination phase, the data access efficiency and safety requirements
can be broken down into two properties that must be maintained. First, ensure the
availability of data access such that any updates to that data can be performed correctly.
Second, ensure that the latency of Session Termination is minimized. As with the tasks
in the prior phases, the first property is safety-oriented, while the second is efficiency-
oriented.
Preservation of Confidentiality and Integrity Throughout
Finally, throughout all three phases two additional properties must be maintained in
order to satisfy the data access efficiency and safety requirements: confidentiality and
integrity of the mobile individual’s data. Both of these properties are safety-oriented.
1.4.2 The Performance Challenge
In the VM on USB Device approach described earlier, a user carries her data on a
portable USB storage device. As she travels from location to location, she is free to
“live off the land” and borrow whatever PC hardware happens to be available for her
to use. At this point, she connects her USB device to the PC, boots off of the device,
and initiates her computing session by resuming her guest VM.
24
Unfortunately, since her data is stored on a small, portable, inexpensive USB stor-
age device, the performance of data access is significantly worse than what she would
normally expect to experience from a normal internal PC hard drive. Essentially, she
borrows the entire PC, except for the local internal disk. This affects performance
across the entire lifecycle of her session. During Session Initiation and Termination,
the slower performing drive causes additional latencies. During Interactive Execution,
response latencies are increased and, as we will show, can be intolerable at times. Fi-
nally, the performance of most common I/O-intensive tasks, e.g., software installs and
updates, source compilation, small and large file operations, and office processing, are
impacted by the relatively slower performing storage device. In fact, just about every
aspect of her computing experience if negatively impacted.
To overcome this challenge in performance, we introduce the concept of safe bor-
rowing of local storage. The key idea is to leverage the free disk blocks of the borrowed
computer’s internal disk to construct a virtual storage device to provide faster storage
for a guest VM. An additional goal of this concept is to ensure reciprocal protection
between the VM and borrowed PC by isolating their disk accesses. As long as the
integrity of the the USB device is preserved (i.e., it is not modified), the integrity of its
virtual storage device is also preserved. Hence, the privacy and integrity of data in the
non-free parts of the internal disk are also preserved. Software running within a VM
(malicious or not) cannot view or modify non-free parts of the internal disk. At the
same time, all data stored on the virtual storage device can be encrypted to preserve
the confidentiality of the VM state. By using the free space of the higher-performing
local storage of borrowed hardware, the speed at which performance-critical operations
can be completed is increased, improving the user experience during all session lifecycle
phases.
In Chapter 2 of this dissertation, we demonstrate the feasibility of safe borrowing,
as a solution for the performance challenge under opportunistic mobile computing sce-
narios. In the context of the VM on USB Device approach, we present the design,
implementation, and prototype evaluation of the TransPart system.
25
1.4.3 The Availability Challenge
In the VM Delivered over the Internet approach described earlier, a mobile individual
relies completely on leveraging local computer resources opportunistically. When a user
resumes her session, a replica of the associated VM state must instantiated at the local
client station. Once the necessary portions of VM state have been copied to the local
client, a user can resume her guest VM.
Unfortunately, the availability of a user’s data can vary greatly under opportunistic
mobile computing conditions, influenced by factors such as network connectivity and
performance. As discussed earlier, VM state transfer can place a very high demand on
the network due to the potentially large size of the VM state, even after factoring in
existing optimizations, such as lazy state transfer. This affects data access availability
throughout the session lifecycle. During Session Initiation, poor network performance
including disconnection can lengthen the resume latency or even completely prevent
a guest VM from being resumed. During Interactive Execution, since portions of VM
state are requested lazily from the VM state server, the impacts of network performance
can be perceived as additional interactive response latency, or as in the case of network
disconnection, premature session termination due to unavailable data. Moreover, pre-
mature termination can have catastrophic effects on the consistency of the local VM
state replica, potentially forcing a user to roll back to a previous consistent checkpoint.
During Session Termination, suspend latency is dependent on network performance.
Under conditions of severe network performance degradation, the time to terminate a
session may be so large that it forces a user to choose between saving her updates to
the VM state server or foregoing it and rolling back her guest VM to a recent point of
consistency, losing her most recent updates. Of course, in trusted environments such
as home or office, the user can depart without waiting for VM state update transfer to
complete. In public environments such as an Internet cafe, the prudent user suffers the
suspend latency in order to ensure safe completion of state update transfer.
To overcome this challenge in availability, we introduce the concept of a self-cleaning
portable cache. Our solution is to treat smart phones as trusted personal assistants that
26
serve as local self-cleaning, read-through, write-back caches of user data. We leverage
smart phone technology since it is portable, “light-weight”, has internal storage, and
offers multiple connectivity options. Under this model, a user can suspend her session
and check in her VM state to the smart phone rather than directly to the VM state
server; similarly, she can resume from the smart phone. Even when Internet connectivity
is poor, the physical proximity of a user’s smart phone to a borrowed client station
ensures good connectivity between them. To reduce device vulnerability, the portable
cache opportunistically uses cellular, WiFi, or other networking technology to self-clean;
that is, to asynchronously propagate modified VM state to VM state servers while users
are in transit. This self-cleaning aspect of Horatio distinguishes it from VM on USB
Device approaches, which rely solely on passive USB storage, and are hence vulnerable
to device loss or damage. A self-cleaning portable cache does not increase the size or
weight aspects of a user’s mobility footprint since most users already carry cell phones
for voice calls and texting. Only the energy aspect increases slightly.
In Chapter 3 of this dissertation, we demonstrate the feasibility of a self-cleaning
portable cache as a solution for the availability challenge under opportunistic mobile
computing scenarios. In the context of the VM Delivered over the Internet approach,
we present the design, implementation, and prototype evaluation of the Horatio system.
1.4.4 The Security Challenge
In both of the highly opportunistic mobile computing approaches described earlier, VM
on USB Device and VM Delivered over the Internet, mobile individuals initiate and
execute computing sessions from borrowed PC hardware. Until now, we have primarily
focused on ensuring usability under opportunistic mobile computing conditions. We
must also consider security aspects. As it pertains to user data access, there are two
aspects that are critical to ensure: (i) data integrity and (ii) data confidentiality. Cen-
tral to the issue is the reduced level of trust a user may place in borrowed hardware
relative to how strongly she trusts what she owns.
In the context of opportunistic mobile computing, there have been advances to-
wards the establishment of trust in borrowed PC hardware. Surie et al. [105] utilize
27
a USB device-based approach to establish a root of trust from the USB device up
through guest VM state. Unfortunately, this approach cannot protect against BIOS or
VM-based attacks. They also assume untampered, non-malicious hardware. Ravi et
al. [84] propose a similar model, but extended to support verification of the local PC
BIOS and protection against VM-based attacks. Finally, Garriss et al. [59] focus on
detecting software attacks for borrowing situations that involve public kiosks. Similar
to the other approaches, the authors acknowledge that hardware-based attacks remain
a concern. This leaves open the possibility of attacks that modify or replace hardware
peripherals and internal components with malicious versions, e.g., covertly introducing
a USB sniffer.
It is this lack of a mechanism to completely determine the trustworthiness of a bor-
rowed PC that prevents there being a good solution to the dual data access challenges
of maintaining confidentiality and integrity. In fact, we take the position that there is
unlikely to be a good solution to this; one that is both verifiably correct and will con-
vince the average non-technical user of such. Instead, we take the complimentary goal
of minimizing the potential damages that may result from such an attack due to the
lack of full trust establishment. We claim that our approach is complimentary to even
one that provides full trust establishment, since attacks can still occur within trusted
computing environments.
In both of the highly opportunistic approaches, VM on USB Device and VM De-
livered over the Internet, on disk data confidentiality is maintained through the use
of data encryption. The VM Delivered over the Internet also utilizes cryptographic
hashing to validate the integrity of the data, while both rely on a regimen of frequent
backups to provide further data integrity. Since access to VM state is a requirement
of both approaches, we extend our focus to include remote data access to file servers,
from untrusted borrowed computers. Remote file access is typically secured using stan-
dard distributed file systems authentication mechanisms, such as VPNs and firewalls.
Since a borrowed computer is essentially untrusted, it may contain malware, for ex-
ample viruses, worms, hardware sniffers, etc., that compromise the confidentiality and
integrity of a user’s remotely stored files when they are accessed via these devices. The
28
security challenge exists throughout the lifecycle of a user session.
To overcome this security challenge, we apply the concept of working sets to access
control, specifically in the context of remote data access for users over distributed file
systems. Our solution is to observe and extract working sets for users when they access
files from trusted (non-borrowed) devices and use the working sets to restrict user
file accesses when performed from untrusted (borrowed) devices. Intuitively, most file
accesses are governed by the working set; indeed prior work has shown temporal patterns
in user file accesses [100]. Since a user will tend to access a file that she has recently
accessed, using the working set does not overly restrict file accesses, while malware
accesses to the file system typically exhibit no such temporal patterns. This novel
access control scheme improves the security of user data access under opportunistic
mobile computing conditions by minimizing the risks to the confidentiality and integrity
of remote data and restricting user data access to those items a mobile individual is
likely to access in the near future. Damage caused by malware is thus restricted to a
user’s working set.
In Chapter 4 of this dissertation, we demonstrate the feasibility of the Working Set-
Based Access Control (WSBAC) scheme as a solution for the security challenge under
opportunistic mobile computing scenarios. In the context of the VM on USB Device
and VM Delivered over the Internet approaches, we present the design, implementation,
and prototype evaluation of the WSBAC system.
1.5 Summary of Dissertation Contributions
This dissertation has three main contributions in the area of data access for opportunis-
tic mobile computing, which were published in the Proceedings of the 7th International
Conference on Mobile Systems, Applications, and Services (MobiSys), 2009 [97], Pro-
ceedings of the 14th ACM Symposium on Access Control Models and Technologies (SAC-
MAT), 2009 [96], Proceedings of the First International Workshop on Mobile Comput-
ing and Clouds (MCC), 2010 [93], and Carnegie Mellon University School of Computer
Science Technical Report CMU-CS-10-110, 2010 [98].
29
We present the design, implementation, and evaluation of three different systems –
TransPart [93, 98], Horatio [97], and Working Set-based Access Control (WSBAC) [96],
which improve the performance (TransPart), availability (Horatio), and security (WSBAC)
of data access for opportunistic mobile computing users, respectively.
TransPart is a system to improve the performance of data access for opportunistic
mobile computing systems by using the higher-performing local storage of borrowed
hardware to speed up performance-critical operations. We introduce the concept of
safe borrowing of unused portions of local disk storage. Safe borrowing allows a user
to fully realize the benefits of the higher-performing local storage while preserving the
integrity and privacy of the existing data on the non-free parts of that local storage. To
facilitate this, our solution constructs a virtual storage device on demand by borrowing
free disk blocks from the host’s storage. In support of user mobility and opportunistic
use of available local hardware, TransPart requires no modifications to the software
or hardware of a borrowed computer. We also suggest potential uses of the ideas
underlying TransPart in other VM-based contexts. We present experimental results
confirming that TransPart offers low overheads and startup cost, while improving the
performance of data access for opportunistic mobile computing users.
Horatio is a system to improve the availability of data access for opportunistic
mobile computing systems by utilizing nascent smart phone technology. We introduce
the concept of a self-cleaning portable cache for VM state and leverage the nearly-
ubiquitous presence of smart phones to transform them into trusted personal assistants
for mobile users. Since most users already carry cell phones for voice calls and texting,
Horatio does not increase the size or weight of what must be carried — there is only
a small increase in the energy requirements. We present the benefits of Horatio, which
are threefold: it (i) reduces the suspend and resume latencies of VM guests by acting as
a local read-through and write-back cache for VM state, (ii) performs self-cleaning by
transferring VM state updates back to the persistent store while the user is in transit
between sites, and (iii) minimizes the energy demands it places on the smart phone
by opportunistically offloading associated state management computation to the local
resources. We present a system design for Horatio that separates VM state into two
30
distinct components: data state and control state. This separation simplifies the use of
VM state replication and VM state transfer parallelism, while enabling the speculative
transmission of VM state updates through eager state propagation (see Section 3.3.6).
We report experimental results confirming that Horatio improves the availability of
data access for opportunistic mobile computing users, even with current smart phone
limitations. We also suggest improvements to the smart phones’ protocol stacks to
further improve Horatio’s performance by an order of magnitude.
Working Set-Based Access Control (WSBAC) is a novel scheme to restrict dis-
tributed file system accesses from untrusted (e.g., borrowed) devices, in support of
remote user file access. For example, such remote file access occurs frequently for em-
ployee’s accessing files on corporate intranets. Under opportunistic mobile computing,
users not only access the local state of their personal computing environment from bor-
rowed PC hardware, but also any remote resources such as files stored on distributed
file systems. This potentially exposes such remote resources to data confidentiality and
integrity risks, due to viruses, rootkits, malicious hardware, and other malware. The
key idea of WSBAC is to continuously observe and extract working sets for users when
they access files from trusted devices and use the working sets to restrict user file ac-
cesses from untrusted devices. For the purposes of this dissertation, we will assume
that devices administered by the corporation are trusted, and that other devices (e.g.,
borrowed or personal devices) are untrusted. However, WSBAC is independent of this
assumption and will work with any technique that can be used to differentiate between
trusted and untrusted devices, e.g., devices equipped with TPM hardware and integrity
measurement tools [87] could be considered trusted. We present the design, implemen-
tation, and evaluation of tools to automatically extract working sets, and transparently
enforce WSBAC without requiring changes to the distributed file system.
1.6 Contributors to the Dissertation
The following is a list of people who co-authored papers from which material was used in
this dissertation. Chapters 2 and 3 of this dissertation are the result of a collaboration
between by my advisor, Professor Liviu Iftode, and Professor Mahadev Satyanarayanan
31
(Carnegie Mellon University). During this time, Professor Satyanarayanan acted as a
co-advisor and contributed in many ways to all aspects of this work. Professor Vinod
Ganapathy contributed to the motivation for WSBAC, and to the design of the Polen
speculative update mechanism. Aniruddha Bohra implemented parts of the FileWall
system upon which the WSBAC system was built and evaluated. He was a graduate
student at Rutgers at that time he worked on the project, also advised by Professor
Iftode. Benjamin Gilbert (Carnegie Mellon University) contributed to the design of
the state transference mechanism utilized by the Horatio client. He also contributed to
the design and implementation of the free block discovery and virtual device creation
mechanisms for the TransPart prototype. Jan Harkes (Carnegie Mellon University)
contributed to the initial design of the TransPart virtual device creation mechanism.
Professor Eyal de Lara (University of Toronto) contributed to Horatio prototype eval-
uation. Nilton Bila (University of Toronto) implemented and executed a custom real
work macrobenchmark as part of the Horatio prototype evaluation.
1.7 Organization of the Dissertation
This dissertation is organized as follows. Chapter 2 describes TransPart, a system that
improves the performance of data access for opportunistic mobile computing users.
Chapter 3 describes Horatio, a system that improves the availability of data access
for opportunistic mobile computing user. Chapter 4 describes the Working Set-Based
Access Control Scheme (WSBAC), an access control system that improves the security
of data access for opportunistic mobile computing users. Finally, Chapter 5 concludes
the dissertation.
32
Chapter 2
Improving the Performance of Mobile Data Access
2.1 Problem Statement
In Section 1.3.3, we described a class of systems that exploit virtual machine (VM)
technology to encapsulate and dynamically deliver user-specific state to a computer
from a bootable USB key, thus enabling user mobility across hardware. While the
specific systems that have been proposed [42, 45, 73, 90, 92] differ considerably in
their technical details, they share the top-level goal of decoupling a user’s personal
computing environment from a specific machine. Moreover, their usage model is quite
different from the email, Web access, and social networking capabilities provided by
BlackBerries, iPhones, and other mobile devices. The strength of these systems lies
in their ability to precisely, safely, and rapidly re-create a user’s Windows or Linux
desktop environment as a thick client on borrowed hardware at any time and place.
Unfortunately, portable storage devices sacrifice I/O performance in order to obtain
the highest capacity and robustness at the lowest cost, size, and weight. In addition,
USB connectivity limits storage bandwidth well below that of internal storage connec-
tivity such as SATA. As Table 2.1 shows, the I/O read and write performance of typical
USB-attached storage devices is substantially slower than that of an internal disk. This
severely impacts operating system performance, including basic functionality such as
swapping and application launch.
In this chapter, we propose a zero-install approach, called TransPart, that leverages
the free disk blocks of the host computer’s internal disk. TransPart constructs a virtual
storage device from these free disk blocks and uses it to provide faster storage for VM-
based mobility. TransPart ensures reciprocal protection between the VM and host by
isolating their disk accesses. As long as the integrity of TransPart is preserved (i.e., the
33
USB device is not modified), the integrity of its virtual storage device is also preserved.
Hence, the privacy and integrity of data in the non-free parts of the host disk are also
preserved. Software running within a VM (malicious or not) cannot view or modify
non-free parts of the host disk. At the same time, TransPart can encrypt all data
stored on the virtual storage device, and thus, preserves the privacy of the VM state.
In this chapter, we present the design, implementation, and evaluation of a TransPart
prototype. Experimental measurements from this prototype confirm that it offers low
overhead and start-up cost, while improving user experience.
2.2 TransPart Design and Implementation
In this section, we present the design and implementation of TransPart. Throughout
this chapter, we use a number of specific terms as we describe the model, design, and
implementation. For clarity, we define these terms first.
2.2.1 Notational Terminology
When referring to the borrowing of PC hardware from one user by another, we refer
to both users unambiguously as the owner and the borrower. We refer to the hardware
and software components of the owner’s PC as the local components. We also refer to
the owner’s PC as the borrowed PC.
As described before, the host is the execution environment within which a guest
virtual machine or VM may execute. We use the terms host, host virtual machine
monitor, or VMM interchangeably. Collectively, the host VMM and guest VMs define
the borrower’s software that executes on the owner’s PC hardware. The guest VM
executes a user’s transient personal computing environment and encapsulates the user’s
PC state.
Finally, a free disk block is a disk block that satisfies one of two conditions: (i) it
has not been allocated to a local file system or (ii) it has been allocated to a local file
system, but is not currently in-use by that file system.
34
Size
Spee
dT
rans
fer
Rat
e(M
B/s
ec)
Stor
age
Dev
ice
Lab
elT
ype
(GB
)(R
PM
)R
ead
Wri
teP
NY
Att
ache
USB
Fla
shD
rive
SanD
rive
USB
16F
lash
317
SanD
isk
Mic
roSD
Car
dM
SDU
SB8
Fla
sh16
12A
pple
iPod
IPO
DU
SB20
4200
1312
Inte
rnal
SAT
AD
rive
Tra
nsP
art
SAT
A25
072
0042
32G
uest
VM
onSA
TA
Dri
veH
ost
SAT
A25
072
0040
28
Tra
nsf
erra
tere
sult
sar
eth
em
ean
offi
vem
easu
rem
ents
.A
llst
and
ard
dev
iati
ons
are
less
than
6%.
Tab
le2.
1:P
orta
ble
Stor
age
Dev
ice
Cha
ract
eris
tics
35
2.2.2 Correctness Criteria
The design of TransPart is directed by a set of design goals. We list these below.
• Borrow the free disk blocks of a local hard disk to create a virtual storage device
for a guest execution environment.
• Protect the in-use local disk blocks from guest VM read and write operations.
• Achieve the first two goals without any modifications to local hardware, OS, or
application software.
Finally, our design assumes that the local OS does not execute concurrently with
the borrower’s software. This enforces a strict isolation between the local OS and the
borrower’s software accesses to the local storage device while the borrower’s VMM is
executed. Furthermore, the VMM is restricted from even mounting any host file systems
and using them directly. When a host OS is hibernated, its hibernated image contains
cached file system state. If the VMM were to mount and use a host file system directly,
it would likely cause a consistency problem between the on-disk file system state and
the hibernated host image.
2.2.3 Usage Model
A user who wishes to borrow a PC to temporarily execute her transient personal com-
puting environment must first connect her portable USB device to the PC and power
it on. This causes the PC to boot the VMM software stored on the user’s USB key.
In order to execute the user’s guest VM using the free blocks of the local disk as a
transient storage location, the VMM must export the available free blocks on the local
disk as a virtual device, and provide a device interface. While the VMM boots up,
TransPart discovers all available free blocks on the local disk partitions and allocates a
TransPart virtual disk device for the guest VM by aggregating them. The TransPart
device provides the user access to the free blocks of the local disk, while protecting the
privacy and integrity of any existing local data.
36
TransPart allows a user to utilize the free blocks of a local disk. This is illustrated as thewhite boxes in the local disk. The black boxes are in not free. Then it copies the guestVM from the portable USB storage device to the local disk. This is illustrated as the greenfilled boxes in the local disk. From this point on, the guest VM executes from the localdisk. The VMM is always accessed from the portable USB storage device.
Figure 2.1: TransPart Overview
Once the VMM has finished booting and TransPart has allocated a virtual device
for the user’s guest VM, the state of the guest VM can either be copied all at once
to the virtual device or it can be left on the USB device, and portions of it will be
copied on-demand, during guest VM execution. In either case, the user can resume her
guest VM, at this point. She is now free to start working within her personal computing
environment, unhindered by the performance restrictions of her portable storage device.
Figure 2.1 illustrates the usage model for TransPart.
2.2.4 Design Overview
In this section, we describe our design for the TransPart system. Recall that our design
goal is to borrow the free blocks from a local disk, while protecting both the integrity
and privacy of the existing local data. To accomplish this goal, TransPart must perform
several tasks. It must first discover free blocks on local disks and allocate a TransPart
device that aggregates these blocks into a virtual disk. It then transfers guest VM state
37
(1) TransPart performs free block discovery. (2) TransPart performs device allocation. (3)& (4) TransPart copies guest VM state from the USB flash disk to the newly allocatedTransPart device. Note: the host and guest I/O buffer caches are not shown in this figure.
Figure 2.2: TransPart System Architecture
to the TransPart device, either on-demand or prior to guest VM execution. Finally,
after the user finishes work and suspends the guest VM, TransPart must transfer all
guest VM state modifications back to the portable USB device. These operations are
depicted in Figure 2.2.
Figure 2.2 also illustrates the path I/O accesses take as they flow through the system.
A file system access from an application, for example, is issued to the guest VM’s virtual
file system. This access is intercepted by the VMM and passed to the TransPart device,
ultimately being serviced by one or more local disks. I/O performance is improved by
conventional buffer caches in both the host and guest OSes; these are omitted from the
figure for clarity.
Since TransPart devices only include free local disk blocks, it is impossible for a
guest VM to either read or write to a block that is in use by a local file system.
38
2.2.5 Free Block Discovery
During the host’s boot process, and prior to execution of a guest VM, TransPart scans
the host’s local storage devices to discover available free blocks. This process occurs in
two phases. In the first phase, TransPart enumerates local devices searching for storage
devices; then, it discovers the individual storage volumes on these devices. Such volumes
include physical disk partitions as well as aggregate volumes such as software RAID
and Logical Volume Manager volumes. Each storage volume usually contains a single
file system or swap partition.
In the second phase, TransPart searches through each storage volume to discover the
available free blocks. Most, if not all, modern file systems maintain a set of block allo-
cation tables as meta-data on disk, for each formatted disk partition. For instance, the
Linux ext2 [44] file system stores a block allocation bitmap in each block group, which
maintains the allocation status for each block in the associated block group. TransPart
utilizes file system on-disk semantics to properly parse the file system metadata and
discover free disk blocks. To preserve host file system consistency, TransPart will only
use host file systems that were unmounted cleanly when the host was powered off.
Normally, swap partitions are not available for use by TransPart, since host PC state
resides there when hibernated. However, if the host PC has been shut down rather than
hibernated, TransPart can also use disk blocks from any swap partitions it finds, since
in this case there is no risk of overwriting important data. Of course, since the PC has
been shut down, it must undergo a full reboot (rather than resuming from hibernation)
once the TransPart session has finished.
TransPart tracks free blocks not as individual units, but as free block extents, or
runs of consecutive blocks. This minimizes the amount of data that must be tracked
and allows for more intelligent block allocation policies. We defer discussion of block
allocation policies and the related topic of fragmentation until Section 2.4 of this chap-
ter.
39
2.2.6 Device Allocation
Once TransPart has discovered free disk blocks, it allocates a TransPart device for
the guest VM. The minimum size for the given TransPart device is determined by
the size of the guest VM state. In most cases, the device size can be substantially
smaller than the full guest VM state size, since only portions of the state are fetched on
demand as needed for guest VM execution. This on demand model incurs additional
I/O performance overhead but allows the guest VM to be executed without copying
the entire guest VM state to the host.
2.2.7 Implementation Details
Our TransPart prototype is implemented in about 550 lines of C and a small amount of
Python 2.6 and shell script code. Together, the TransPart components are installed on
the portable storage device and are executed from the portable storage device during
various stages of boot-up of the host VMM. No modifications are made to existing
software in either the host or the guest.
Our prototype supports free disk block discovery from ext2/3/4 and NTFS file
systems as well as Linux swap devices. For low-level semantic access to ext2/3/4 file
systems, TransPart uses the Linux e2fsprogs [112] library. For semantic access to NTFS
file systems, it uses the ntfsprogs [2] library. To create in-kernel TransPart devices,
we use the existing Linux Device-mapper [1]. By doing so, we take advantage of all
the performance benefits of the mature Linux kernel code supporting logical volume
management.
Finding Free Disk Space
The task of collecting available disk space into a TransPart volume is performed by the
gather free space tool, which performs the following actions:
First, the e2fsprogs blkid library is used to gather a list of disk volumes and their
file system types. Since gather free space executes after VMM initialization, Linux
software RAID and Logical Volume Manager (LVM) [3] volumes have already been
40
assembled, and are included in the volume list returned by blkid.
Next, each volume is examined using the appropriate file system-specific libraries,
unless it contains a Linux swap partition. In that case, it is examined directly by
gather free space. Volumes containing file systems not recognized by gather free-
space are skipped. For each recognized file system, gather free space performs a
consistency check on the file system. If the check indicates that a file system was not
unmounted cleanly or is known to have errors, or if an NTFS or Linux swap partition
contains hibernated memory state, the file system is skipped. Also, if any errors are
encountered while reading the file system, it is skipped. These tests attempt to ensure
that gather free space will not damage any local file system.
For each file system that is deemed safe to use, gather free space obtains the
file system block allocation bitmap. These bitmaps are scanned to generate a stream
of extents, or runs of free blocks. The lengths and locations of the largest 100,000
extents yet encountered are recorded in a binary heap. To improve the performance of
TransPart volumes, extents smaller than 4 MB are ignored. Building TransPart devices
from larger extents helps to decrease the average number of disk seeks required during
I/O operations, thus, improving overall throughput.
Finally, the Linux device-mapper infrastructure is directed via the libdevmapper
library to create a block device from the extents recorded in the binary heap. Device-
mapper [1] provides a mechanism for creating virtual disks that redirect accesses to other
disks in a configurable, table-driven fashion. Before the list of extents is presented to
libdevmapper, it is sorted by originating volume and sector offset within that volume.
This reduces seeks during streaming accesses to the TransPart volume, since its sectors
are more likely to be ordered with respect to sectors on the physical disks.
The device-mapper implements a logical volume as a table of extents. If the host’s
file systems were highly fragmented and gather free space were to include every
free extent, the table could grow quite large. The Linux kernel places the table in
the vmalloc allocation area, which is limited to 128 MB on x86 systems and cannot
be swapped to disk. Limiting the table to the largest 100,000 extents ensures that
gather free space creates the largest TransPart device possible without consuming
41
more than a few megabytes of kernel memory.
Allocating Free Disk Space
The gather free space tool can create a virtual disk, but cannot make it usable to
a guest VM. This task is performed by the early scratch setup initialization script,
which executes during VMM boot.
First, early scratch setup executes gather free space to create a TransPart
device. By default, early scratch setup imposes a minimum size for that device. If
gather free space is unable to create a volume of at least this size, early scratch-
setup produces an error and terminates. It then creates an LVM volume group on top
of the TransPart device. Next, it creates a swap partition (2 GB default size) within
the volume group, then formats and enables it for use. Finally, a storage volume is
created from the remainder of the space in the volume group. This volume is formatted
to create a file system (ext4 by default), which is then mounted within the VMM1.
2.3 Evaluation
Our experimental evaluation of the TransPart prototype addresses two questions:
• How much does TransPart improve the transient personal computing environment
performance?
• How much time does TransPart add to VM session start-up and shutdown?
Together, these questions allow us to explore both the benefits and costs of the TransPart
system. Our goal is to evaluate the benefits of the TransPart system towards improving
the user experience within the framework of VM-encapsulated mobile computing.
In this section, we describe our experimental methodology (Section 2.3.1), then
present two sets of experimental results. First, we report results pertaining to TransPart
1To improve performance under the default ext4 case, mkfs.ext4 is run with the lazy itable initoption, causing mkfs.ext4 to defer initialization of file system block groups to a background task whichruns when the volume is first mounted.
42
benefits (Section 2.3.2) and then we present results pertaining to TransPart costs (Sec-
tion 2.3.3).
2.3.1 Experimental Methodology
For all experiments, we use a Dell Optiplex 755 PC with a 2.33 GHz Core 2 Duo CPU,
3 GB of RAM, a 250 GB Serial ATA disk at 7200 RPM, and support for Hi-Speed USB.
This PC acts as the host PC, which boots the portable USB-based VMM and executes
OpenISR and the TransPart software. We use OpenISR version 0.9.9 as the transient
personal computing system and run a VMware guest VM (ISR parcel) configured to
use 512 MB of memory and a 4 GB virtual disk. We chose the size of our guest VM
to represent a small real-world parcel that a user might actually possess on a USB
key. The guest VM state is fully stored on the portable storage device (similar to the
SoulPad model described earlier). Inside the guest VM, we run the Fedora Linux 10
OS (Linux kernel version 2.6.27). For all VM storage devices, we use the Linux ext4
file system.
Figure 2.3 shows a diagram of the individual components of our experimental con-
figuration. For the transient personal computing case (Figure 2.3a), all guest VM state
is accessed directly from the attached portable USB device during guest VM execution.
For the TransPart case (Figure 2.3b), guest VM state is first transferred to the host
PC’s local SATA disk and accessed from there during guest VM execution.
We select a range of portable storage devices to hold the guest virtual machine
state. Table 2.1 lists the devices and their relevant performance characteristics. We
also include a row for the internal hard disk used in this study (Internal SATA Drive).
Transfer rates listed are the sequential read and write performance for each device.
The Label column specifies the short-hand notation used to refer to a specific device
throughout this evaluation.
To understand the performance improvements provided by TransPart, we execute six
different benchmarks that are representative of the range of tasks for a typical PC user.
Each benchmark is executed inside the guest VM and represents a different workload
focus. The Postmark [70] benchmark measures the performance of a small I/O and
43
(a) Portable USB Device Configuration (b) TransPart Configuration
Transient personal computing configuration is shown on the left (a) and TransPart config-uration is shown on right (b). Benchmarks are executed within guest VM on host PC. ForTransPart, a portion of guest VM state is first transferred to host PC disk, while the restis transferred on demand. Guest VM state is accessed directly from USB for the transientpersonal computing cases.
Figure 2.3: TransPart Experimental Configuration
metadata intensive workload across a set of files (Section 2.3.2). We execute a custom
benchmark to measure the launch latency of a variety of common desktop applications
(Section 2.3.2). The next benchmark we run is a modified Andrew benchmark [64],
which emulates a software development workload (Section 2.3.2). To determine user
perceived desktop application performance, we execute a custom office productivity
benchmark consisting of common operations within the OpenOffice.org [104] Writer
(word processor) application (Section 2.3.2). We then execute a software installation
benchmark that emulates the task of installing a set of software packages within the
guest VM (Section 2.3.2). Finally, the Bonnie++ [50] benchmark tests the performance
of a set of simple file system accesses to a single large file (Section 2.3.2).
The costs of TransPart can be broken down into two categories: start-up costs and
shutdown costs. At start-up, a new TransPart device must be allocated from the free
blocks available on the host disk. Additionally, VM state must be fetched from the USB
device and copied to the TransPart device prior to VM Resume. These two components
comprise the additional overhead that does not occur when resuming the VM without
44
Postmark ParameterNumber of Files 5000Number of Subdirectories 50File Sizes 512 bytes - 10 KBNumber of Transactions 20000Operation Ratios equalRead Size 4 KBWrite Size 4 KBBuffered I/O no
Table 2.2: Postmark Configuration for TransPart Evaluation
TransPart. At shutdown, TransPart must copy the modified portions of the suspended
VM’s state (memory and disk) back to the USB device. This comprises the additional
TransPart costs during shutdown. To better understand the real impact of these costs,
we perform experiments to measure the individual start-up and shutdown times for
each of the different portable USB devices with and without TransPart (Section 2.3.3).
All benchmarks in the evaluation are run a minimum of 5 times, and we report the
average results. Before each new run of a benchmark, we suspend the VM and rollback
its state to a saved checkpoint.
2.3.2 TransPart Performance Benefits
Postmark
In this experiment, we execute the Postmark [70] benchmark (version 1.51). Postmark
was created in 1997 and its workload is characterized by many operations on short-
lived, small files, and consists of many data and meta-data operations. Since it does
not attempt to approximate application processing, it performs very little CPU activity,
and is I/O-intensive by design. Table 2.2 lists the Postmark configuration that was used
in this experiment, based on the Traeger et al. [111] and Soules et al. [101] studies.
Figure 2.4 presents the results of this experiment. Each bar in the figure represents
one of the four devices included in the evaluation and reports the completion time
for the Postmark benchmark. Additionally, the bar labeled Host presents the results
for a guest VM that has been installed on and executes directly from the host PC.
We expect the Host case to represent the “optimum” VM performance, under normal
45
0
5
10
15
20
SanDrive MSD IPOD TransPart Host
Tim
e (s
ec)
Storage Device
Completion time of the Postmark v1.51 benchmark, in seconds. Results are the mean offive runs.
Figure 2.4: Postmark Results for TransPart
circumstances.
Since Postmark includes a mixture of operations (read, write, create, and remove),
it executes a diverse set of both data and meta-data operations. As such, it attempts
to generate a realistic workload under test. The IPOD and TransPart cases outper-
form both flash drive cases (SanDrive and MSD) by up to a factor of three, while
the TransPart IPOD, and Host cases are all similar to each other for this workload.
TransPart and Host are very close (less than two seconds separating them), demon-
strating that TransPart achieves near optimal performance for this benchmark. For
the TransPart case, only the guest VM is performing I/O operations to the host SATA
disk, while the VMM executes from the USB key. So, there is a slight benefit due to
this under meta-data intensive workloads, as demonstrated by the faster completion
time for TransPart over Host.
46
0
20
40
60
80
100
120
spreadsheet firefox gimp f-spot evince totem
Tim
e (s
ec)
Application
SanDriveMSDIPOD
TransPartHost
Application launch latency time for six common desktop applications, in seconds. Resultsare the mean of five runs.
Figure 2.5: Application Launch Latency for TransPart
Application Launch Latency
An important indicator of user experience is application launch latency [76]. In this
experiment, we are specifically interested in quantifying the time it takes for a typical
desktop application to be available for use by a user, once the user has chosen to launch
it. This is quite important, as poor performance in this area tends to evoke a visceral
reaction by a user, tainting her perception of overall desktop performance from that
point onward. To evaluate this, we launch a set of six commonly used applications,
measuring the application launch latency within a guest VM for the three portable
USB drives, TransPart, and a guest VM that executes within VMM software installed
on the host. We use a custom script to launch and measure the launch latency for
(i) the OpenOffice.org spreadsheet, (ii) the Firefox web browser, (iii) the Gimp image
manipulation tool, (iv) the F-Spot photo editing tool, (v) the Evince document viewer,
47
Benchmark Storage DevicePhase SanDrive MSD IPOD TransPart HostOverall 5904 4970 3142 2820 2275MakeDir 34 39 22 14 21Copy 782 616 178 164 136ScanDir 43 14 16 9 7ReadAll 57 137 80 50 42Make 4987 4506 2846 2583 2070
Completion times of a Modified Andrew benchmark for overall benchmark and for indi-vidual phases: (MakeDir) subdirectory creation, (Copy) source tree copy, (ScanDir) filestatus check, (ReadAll) file data access, and (Make) compilation and linking. Results arethe mean of five runs and all standard deviations are less than 6%.
Table 2.3: Modified Andrew Benchmark Results for TransPart
and (vi) the Totem multimedia (audio/video) player.
Figure 2.5 presents the results of this experiment. From the figure, we make three
observations. First and most important, TransPart improves performance for all appli-
cations tested. These improvements are most evident when focusing on the spreadsheet
and Firefox cases, but TransPart also exhibits the best performance for all transient
personal computing cases. When compared to the SanDrive, MSD, and IPOD cases,
TransPart exhibits up to a factor of 10, 7, and 4 performance improvements, respec-
tively. Second, application launch latencies for the SanDrive and MSD cases are both
high and variable, likely beyond the range of tolerance for a typical user. The latencies
for the IPOD case are still noticeably large to a user, but in a more tolerable range. The
latencies also vary less for IPOD than the SanDrive and MSD cases. Finally, TransPart
exhibits performance close to the Host case for all applications, but some of the re-
sults show that there is still room for improvement. The Gimp application performs a
number of small data and meta-data operations on launch, and so TransPart slightly
outperforms the Host case for this application.
Andrew Benchmark
We execute a modified Andrew benchmark [64] against the Linux kernel sources (version
2.6.31.6) such that it will exceed the memory capacity of the VM under test in order
to force I/O accesses to the disk. The benchmark consists of five phases: (MakeDir)
48
recursively create subdirectories, (Copy) copy the source tree, (ScanDir) query the
status of each source file in the tree without accessing data, (ReadAll) read the data of
each source file, and (Make) compile and link the sources.
The results are presented in Table 2.3. For each phase, we report the completion
time (in seconds) for each of the four portable USB devices included in the evaluation.
From the table, we observe that TransPart substantially improves the performance
in all transient personal computing cases. The result is a 109% improvement over
the SanDrive case, 76% over MSD, and 11% over IPOD. When examining the results
for the individual benchmark phases, we observe that in all but one phase (ReadAll)
both rotational disk devices (IPOD and TransPart) substantially outperform the flash
devices (SanDrive and MSD). Finally, when comparing TransPart to Host, we observe
that TransPart takes 23% longer than Host.
Office Productivity
The goal of this experiment is to measure the user experience for a user that is perform-
ing a mixture of typical operations in a suite of office productivity tools. To accomplish
this, we created a custom benchmark that performs word processing tasks using the
OpenOffice.org Writer application. The benchmark consists of a set of Python scripts
that interact with the open API provided by the OpenOffice.org suite [104].
Since the rate of document content generation will ultimately influence the disk I/O
rate during the benchmark due to periodic file saving, we introduce enough think time to
impose a maximum content generation rate of 30 words per minute. We choose 30 words
per minute based upon the study by Karat et al. [69], which shows the average content
creation rate for an average typist. In the ideal case (i.e., zero-latency I/O operations),
the minimum running time of the benchmark is 15 minutes due to synthetic think time.
This represents the best possible performance for the benchmark.
From the results shown in Figure 2.6, we observe a modest overall performance im-
provement between 22 and 73 seconds (from 2% to 8%) when comparing the portable
USB device cases to TransPart. These improvements are due to a reduction of applica-
tion start-up time and reduced delays in application interactive responsiveness during
49
0
200
400
600
800
1000
SanDrive MSD IPOD TransPart Host
Tim
e (s
ec)
Storage Device
Completion times of custom office productivity benchmark, in seconds. Results are themean of five runs.
Figure 2.6: Office Productivity Benchmark Results for TransPart
the benchmark. We verified the impact of TransPart on application responsiveness
qualitatively, and found the interactive performance of the word processing application
with TransPart to closely resemble that of the local PC. For the portable USB device
cases, we experienced additional and varied delays in application responsiveness. Fi-
nally, when we compare the TransPart and Host cases, we observe that they are similar
and TransPart is again near optimal.
Software Installation
While software installation may not seem typical of a mobile user, one can envision a
mobile user on an extended trip needing to apply software updates to remove recently
discovered security vulnerabilities [7]. We evaluate the effectiveness of TransPart for
software installs by simulating a user performing software installation tasks using the
50
0
50
100
150
200
250
300
350
SanDrive MSD IPOD TransPart Host
Tim
e (s
ec)
Storage Device
Completion times of custom software installation benchmark, in seconds. Results are themean of five runs.
Figure 2.7: Software Installation Benchmark Results for TransPart
well-known YUM [25] open-source package-management utility. To do so, we execute
the install of a set of software packages consisting of a commonly used, open-source,
office productivity suite (OpenOffice.org) and various related dependency packages.
In total, 45 packages are installed with a combined size of 151 MB, resulting in an
additional 350 MB of disk space utilization once installed. To eliminate the effects of
network I/O performance on this benchmark, we download the required packages to the
guest VM ahead of time. Therefore, the benchmark results only measure the time to
perform all local software installation operations. Most modern system update processes
first download all of the update packages and then install them during a second phase,
to ensure that updates are applied together and that success is not subject to network
performance. So, for the purposes of this experiment, we can safely ignore the network
download phase.
51
0
5
10
15
20
25
30
35
40
45
Sequential Write Sequential Read Random Seek
Tra
nsfe
r R
ate
(MB
/sec
)
Benchmark Phase
SanDriveMSDIPOD
TransPartHost
SanDrive-2G
Each bar represents the average transfer rate in MB/sec for a particular specific phase ofthe Bonnie++ v1.03 benchmark. Results are mean of five runs.
Figure 2.8: Bonnie++ Results for TransPart
Figure 2.7 presents the results of this experiment. From the figure, we observe
that TransPart substantially outperforms all portable USB device cases. Compared to
both SanDrive and MSD, TransPart exhibits improvement by over 75%, and results
in a 43% improvement over IPOD. Finally, the performance of TransPart and Host
are statistically equivalent and TransPart achieves near optimal performance for this
benchmark.
Bonnie++
Bonnie++ [50] was developed in 2000 as an improvement over its predecessor Bon-
nie [41]. The benchmark’s workload is composed of low-level I/O performance tests,
and is not necessarily typical of most mobile user tasks, but we include it in the interest
of completeness. In this experiment, we report the results of the following tests over all
52
device cases: (i) sequential read tests, (ii) sequential write tests, and (iii) random seek
tests, using Bonnie++ version 1.0.3.
Figure 2.8 presents the results, consisting of the data transfer rates (in MB/sec) for
each of the four devices included in the evaluation. From the figure, we observe that the
TransPart case substantially outperforms all other transient personal computing cases
for sequential write performance. For the random seek case, the SanDrive, IPOD, and
TransPart results are similar, while MSD exhibits lower performance. For sequential
reads, we observe that TransPart outperforms the MSD and IPOD cases. Also, we
observe an anomaly for SanDrive read performance. Investigating more deeply, we find
that this is due to a combination of the asymmetric read and write performance of the
SanDrive device (see Table 2.1), two layers of disk buffering occurring in the system
(guest VM and VMM buffer caches), and the Bonnie++ benchmark’s choice of test
file size (1 GB). We ran Bonnie++ using a larger test file (2 GB) and present the
results in Figure 2.8 as the SanDrive-2GB case. From these results, we observe that
the anomaly disappears. We also ran the MSD, IPOD, and TransPart cases with the
2 GB test file, and did not observe any difference from the original results. For clarity,
we choose not to report them. Finally, the TransPart and Host cases are quite similar,
with Host performing slightly better for sequential reads, while TransPart performing
slightly better for sequential writes. We interpret these results to mean that TransPart
performs close to optimal for this benchmark.
2.3.3 TransPart Costs
Start-up Time
This experiment measures the total start-up time taken to boot the borrowed PC from
the different portable USB drives and resume the guest VM parcel. We measure the
individual components of start-up time for each portable USB drive with and without
TransPart. For these experiments, TransPart discovers enough free blocks to allocate
a 100 GB TransPart device. The results are presented in Figure 2.9, and we group
the bars by portable USB device. For example, the SanDrive and TransPart-SanDrive
53
0
50
100
150
200
250
SanDrive
TransPart-SanDrive
MSD
TransPart-MSD
IPODTransPart-IPOD
Tim
e (s
ec)
Storage Device
VMM BootTP Allocate
VM State CopyVM Resume
Total start-up time, in seconds. Stacked bars are composed of the VMM Boot and VMResume components for all cases, and TP Allocate and VM State Copy components forthe TransPart cases. Results are mean of five runs. All standard deviations are less than6%.
Figure 2.9: Start-up Time for TransPart
cases are both booted from the SanDrive USB device. In the former, the guest VM
is resumed directly from the SanDrive, while in the latter, the guest VM state is first
copied to a TransPart device. Therefore, the cost of using TransPart is the difference
between the two bars in each group.
From Figure 2.9, we observe the net increase in total start-up time for TransPart
to be in the range of 2-15 seconds. Considering the benefits of TransPart as exhibited
earlier by the performance results presented in Section 2.3.2, the modest additional
start-up costs due to TransPart are completely acceptable. In fact, the improvements
in application launch latency alone more than make up for this additional start-up time.
Each stacked bar in Figure 2.9 is composed of the time to boot the VMM from the
portable USB drive (VMM Boot) and the time to resume the guest VM (VM Resume).
54
0
20
40
60
80
100
120
140
160
180
SanDrive
TransPart-0
TransPart-5
TransPart-50
TransPart-500
Tim
e (s
ec)
Storage Device
VMM ShutdownVM State Save
VM Suspend
Total shutdown time, in seconds. Stacked bars are composed of the VM Suspend andVMM Shutdown components for the SanDrive case, and VM State Save component forthe TransPart cases. The number (0, 5, 50, 500) is the amount of modified state (in MB)that must be saved back to the USB device. Results are mean of five runs. All standarddeviations are less than 6%.
Figure 2.10: SanDrive Shutdown Time for TransPart
For the TransPart cases, the free block discovery and allocation time (TP Allocate),
and the time to copy the guest VM state to the TP device (VM State Copy) are
also presented. By comparing the TransPart cases with their respective non-TransPart
cases, we observe a trade-off between the reduction in VM Resume time and the costs
of TP Allocation and VM State Copy. Although VM Resume Time is reduced by 20-53
seconds when compared to respective non-TP cases, this reduction is offset by 22-68
seconds of additional start-up costs (TP Allocate and VM State Copy), accounting for
the net increase in start-up time.
55
0
20
40
60
80
100
120
140
160
180
MSD
TransPart-0
TransPart-5
TransPart-50
TransPart-500
Tim
e (s
ec)
Storage Device
VMM ShutdownVM State Save
VM Suspend
Total shutdown time, in seconds. Stacked bars are composed of the VM Suspend andVMM Shutdown components for the MSD case, and VM State Save component for theTransPart cases. The number (0, 5, 50, 500) is the amount of modified state (in MB)that must be saved back to the USB device. Results are mean of five runs. All standarddeviations are less than 6%.
Figure 2.11: MSD Shutdown Time for TransPart
Shutdown Time
This experiment measures the total time taken to suspend the guest VM parcel to the
different portable USB drives and power off the borrowed PC. We measure the indi-
vidual components of shutdown time for each portable USB device and the TransPart
case, and present the results in Figures 2.10 - 2.12. We present the results in three
figures based upon portable USB device. For example, the SanDrive and TransPart-5
(Figure 2.10) cases are both booted from the SanDrive drive. In the former, the guest
VM is suspended directly to the SanDrive drive, while in the latter, the guest VM is first
suspended to the local SATA disk and then the modified portions of VM state (memory
and disk) are saved to the USB device. To account for a broad range of use cases, we
56
0
20
40
60
80
100
120
140
160
180
IPODTransPart-0
TransPart-5
TransPart-50
TransPart-500
Tim
e (s
ec)
Storage Device
VMM ShutdownVM State Save
VM Suspend
Total shutdown time, in seconds. Stacked bars are composed of the VM Suspend andVMM Shutdown components for the IPOD case, and VM State Save component for theTransPart cases. The number (0, 5, 50, 500) is the amount of modified state (in MB)that must be saved back to the USB device. Results are mean of five runs. All standarddeviations are less than 6%.
Figure 2.12: IPOD Shutdown Time for TransPart
vary the amount of modified state at suspend time between 0 MB and 500 MB. The
5 MB case represents light disk I/O workload such as web browsing or online shopping,
while the 500 MB case represents a heavy disk I/O workload such as downloading large
files or streaming video. Finally, in both the base portable USB device and TransPart-
0 MB cases, the VM is resumed, allowed to idle for a fixed period of time and then shut
down without any other VM state modifications due to user activity.
From Figures 2.10 - 2.12, we observe a net decrease in shutdown time for all
TransPart cases but TransPart-50 IPOD (Figure 2.12). This benefit is in the range
of 2-23 seconds. Conversely, for the workloads with the heaviest data modification
(TransPart-500), we see a net increase in total shutdown time for TransPart to be in
the range of 11-78 seconds. Considering the benefits of TransPart as exhibited earlier by
57
the performance results presented in Section 2.3.2, the additional shutdown costs due
to TransPart are completely acceptable. As with the start-up case, the improvements
in application launch latency alone more than make up for this additional shutdown
time.
Each stacked bar in Figures 2.10 - 2.12 is composed of the time to suspend the guest
VM (VM Suspend) and the time to power down the host PC from the VMM (VMM
Shutdown). For the TransPart cases, the time to copy back the varying amounts of
modified VM state is also reported (VM State Save). By comparing the TransPart cases
with their respective non-TransPart cases, we observe a trade-off between the reduction
in VM Suspend time and the additional costs of copying the VM modifications back to
the USB device after the VM has been suspended. We estimate the break-even point
to occur when there is approximately 150 MB of modified guest VM state to save.
2.3.4 Summary of Results
To summarize, we draw four conclusions from the results of our evaluation. First, un-
der data-intensive workloads, TransPart performs as well as or better than most non-
TransPart configurations. In only one specific case (Bonnie++ sequential reads) does
one of the non-TransPart configurations (SanDrive) perform better than TransPart.
Second, for mixed I/O workloads composed of both data and meta-data intensive op-
erations, TransPart clearly outperforms all non-TransPart configurations. Third, even
under conditions of light I/O workload, typical user interactive applications benefit
from TransPart through reduced application launch latency and improved responsive-
ness. Finally, TransPart improves software update and installation performance to a
more tolerable level, enabling more frequent software updates for mobile users.
58
2.4 Discussion
2.4.1 Reasonable Safety Assumptions
We have made two assumptions while designing TransPart. First, we assume that no
one physically tampers with any hardware involved, including the portable storage de-
vice and the borrowed local PC hardware. We believe this to be a realistic assumption
given the usage models envisaged. Most reasonable people would not loan out hard-
ware storing precious data if they expected physical tampering to occur. Additionally,
we believe it is reasonable to assume that in other scenarios where a user may borrow
a PC, such as in an Internet Cafe, while kiosk computing, or when using a compute
cluster, a level of surveillance (either human or video) would exist to deter such phys-
ical tampering from occurring. Second, we assume that the local OS does not execute
concurrently with the borrower’s software. This enforces a strict isolation between the
local and the borrower’s software access to the local storage device.
Under these two assumptions, we can extend the TransPart model to include a re-
mote software attestation process [94, 88]. One way to do so is for a host owner to
connect to a “well-known” trusted 3rd party verification site using his Internet con-
nection. Then, a local software component can calculate a secure hash of the host
borrower’s VMM software stored on the connected USB and send it to the verification
site. The verification site would then respond with the results of verification by compar-
ing the transmitted hash against “known-good” hashes. Since all user personalization
occurs in a guest, the VMM software is easy to sanitize as we expect there to be a small
number of such “known-good” hashes.
Validation of the VMM software by the 3rd party would establish a root of trust
starting with the verification site down to the VMM software stored on the user’s USB
disk (we refer the reader to [94, 75, 34, 88, 59, 105, 84] for the relevant details of these
techniques.) The guest VM need not be verified, since only the VMM needs to be
trusted to ensure that a borrower’s guest VM may safely use the free blocks on the
owner’s local disk. The owner’s and borrower’s blocks are isolated from each other, by
the trusted VMM, protecting both the integrity and privacy of each user’s data.
59
Nevertheless, the primary goal of this work is to enable one user to borrow another
user’s PC and execute their personal computing environment utilizing the full available
performance, without compromising the owner’s privacy or the integrity of her data.
Although it might be possible to provide a stronger security model by relaxing some
of our design constraints (i.e., allowing OS modifications), we believe that our model
provides a reasonable balance of safety for the owner and usability for both parties.
Although we have primarily focused on protecting the owner’s data, the proposed so-
lution should also guarantee the guest VM’s privacy with respect to the host. TransPart
achieves this goal at two levels: (i) the host OS is always suspended during guest VM
execution and (ii) all guest VM data can be encrypted while it resides on the local
disk. Although we chose to perform all experiments without TransPart encryption, we
have conducted a sampling of tests and find performance to be similar with encryption
as without. This is largely due to the existence of high performance in-kernel block
encryption modules, such as the Linux dm-crypt [9] module.
2.4.2 Recovery Semantics
Persistence is one of the key properties of file systems. Modern file systems must
be tolerant of system reboots, sudden losses of power, and even system crashes due
to software bugs. These file systems are designed to not only minimize data loss,
under such circumstances, but to allow consistency to be restored to the file system.
TransPart, given its transient nature, introduces a temporal factor to traditional file
system recovery semantics.
A normal file system expects to “own” all of its disk blocks, including the free ones.
Therefore, whenever it performs a consistency check, the file system can assume that
no changes have been introduced by an outsider. A TransPart file system cannot make
such an assumption. In the event of a crash requiring the recovery of a TransPart file
system, any changes made in host file system block allocation can potentially impact
TransPart recovery. Such changes might occur, for example, if after a TransPart session
crash, the host OS is booted and previously free blocks are allocated and overwritten.
In this event, once the user boots back into the TransPart-enabled VMM, file system
60
recovery may not complete correctly, resulting in potential loss of data.
To minimize the impacts of crashes, TransPart needs to keep a copy of the logical-
to-physical disk block mapping used to create any TransPart devices on the external
USB device. Additionally, TransPart needs to verify that all required disk blocks are
still free to borrow from the host file system prior to rebuilding the TransPart volume
and executing file system consistency checks. If certain blocks are no longer available
to TransPart, it might still be able to recover some portion of the corrupted file system.
It depends mainly on what is stored on the blocks that are no longer available. This
exposes an additional avenue for further investigation. The question is how to improve
recovery chances by placing critical file system metadata based upon an understanding
of the host file system allocation policy. Using this knowledge it may be possible to
choose a TransPart layout that allows for graceful degradation during periods of host
file system growth. In general, the longer the host OS executes between a TransPart
crash and recovery, the greater the probability of TransPart data loss.
2.4.3 Unsupported Volume Types
The current TransPart prototype does not support borrowing the free blocks from
encrypted or hidden [17] volumes. Nor does it support other existing volume types, such
as Microsoft’s venerable FAT file system or DBMS raw volume formats. The TransPart
design does not preclude these volume types from being utilized by TransPart. At
present, there is just a lack of support for such access within Linux, but if suitable
volume access libraries were to be developed, then such support could be integrated
into TransPart similar to what is already included.
2.4.4 Potential Improvements
Free Block Allocation Policies
Our design allows for a number of possible approaches for allocation of free blocks to
TransPart devices. In fact, since there are already multiple layers of indirection starting
with the guest OS down to the PC hardware, there may be some benefit to considering
61
the entire software stack in determining the correct block allocation approach for any
particular guest VM. With TransPart, since each guest VM is allocated a set of blocks
dynamically, it is possible to customize block allocation to match the needs of each
guest.
Effects of Disk Fragmentation
Fragmentation of the host’s disks can dramatically reduce the effective throughput of
the TransPart device. The small free space extents that are produced by file system
fragmentation incur the same access latency as larger extents, but many such extents
must be combined to produce even a few megabytes of storage capacity. To limit
performance degradation, our prototype therefore ignores extents smaller than 4 MB.
For sufficiently large or fragmented file systems, a more sophisticated policy might
further improve performance; for example, on disks with plenty of free space available,
TransPart could afford to be even more selective in its choice of free extents.
2.5 Related Work
The opportunistic use of free blocks on a storage device was investigated by Cipar
et al. [48] in the Transparent File System (TFS). Beyond this high-level similarity,
however, there is considerable divergence of goals and mechanisms between TFS and
TransPart.
TFS focuses on a class of Internet-scale peer-to-peer applications such as SETI@Home
and Freenet, where individual users contribute their personal desktops to a free pool
when the desktop is not being used. These applications have to be tolerant of weak
persistence guarantees: TFS can unilaterally release space allocated to any file that
is not currently open. In contrast, until the next reboot, TransPart offers the classic
persistence guarantee of a file system: once created, a file remains in existence until
it is explicitly deleted. This strict compatibility with the guarantees provided by ex-
isting file systems allows unmodified transient personal computing systems (and, by
extension, guest OSes and guest applications within a locally-executing VM) to use
62
TransPart. TFS and TransPart also differ in their interfaces, with TFS providing a file
system interface, while TransPart offers a block device interface that can support any
desired file system or can be utilized for non-file system purposes, such as swap space.
Files allocated via TFS need to be explicitly deleted. In contrast, no explicit cleanup
is needed after use of TransPart: the virtual device simply disappears, and its storage
reappears as free blocks of a mounted file system on the host OS.
Since TFS is intended to be used while the host OS is active, it is implemented
through in-kernel modifications to the ext2 file system. In contrast, TransPart is used
only when the host OS is inactive, hence its implementation completely avoids changes
to the host file system. Instead, it is implemented in userspace, using the same libraries
as fsck to navigate ext2/3/4 and NTFS file system data structures.
More broadly, opportunistic use of free storage has been extensively investigated by
earlier work. As early as 2002, Beck et al. introduced the term logistical storage to
describe opportunistic use of free storage at Internet sites to reduce network transmis-
sions [38]. Other work of this genre include IBM’s Storage Tank [80] and Kang et al.’s
work [67] on virtual storage provisioning. These efforts address storage opportunism
at network scale, while TransPart targets individual storage devices. Also relevant
is Lumb et al.’s work on using free blocks to improve disk scheduling by overlapping
high-priority and low-priority disk workloads [77].
2.6 Summary
This chapter introduced the performance challenge to user data access for opportunistic
mobile computing, and presented our approach to addressing this challenge by exploit-
ing the unused parts of the disk on the borrowed hardware. Our approach synthesizes
a virtual disk from these free disk blocks, and uses it for the I/O-intensive aspects of
VM on USB Device opportunistic mobile computing. Our experiments confirm that
this approach can result in significant user-visible performance improvement.
From a broader perspective, our work addresses a long-standing anomaly in the
transient use of hardware. Consider a situation where you borrow someones hardware,
63
use it, and then return it. Assuming that you have not tampered with the hardware,
the owner is confident after the next power cycle that almost every component of his
hardware (processor, memory, display, graphics accelerator, network interface, wireless
interface, DVD drive, etc.) is back in its pristine state. The sole exception is, of course,
the disk. Even if you had no malicious intent, it is possible that you inadvertently
ran software that viewed disk contents that the owner considered private or, worse,
modified or deleted important files. Encryption of disk blocks by the owner can ensure
privacy in this context, but it cannot prevent mutilation or deletion of disk contents.
In this context, TransPart can be viewed as a mechanism for transient borrowing
of free disk blocks. We posit that the unstated owner intent when loaning hardware is
(a) to allow unrestricted use of free disk blocks so long as they remain free at the end of
the loan period, but (b) to deny read and write access to allocated disk blocks during the
loan period. This is the intuitive meaning of “pristine” for a disk-like device. In other
words, it is to provide the borrower with the illusion of a virtual disk that is composed
solely of the free blocks of the real disk. Today, this owner intent is sustained purely
through the good will and best efforts of the borrower. TransPart can be viewed as a
lightweight mechanism that enforces this implicit owner intent.
64
Chapter 3
Improving the Availability of Mobile Data Access
3.1 Problem Statement
The zero mobility footprint benefit of the VM Delivered over the Internet comes at the
price of large VM state transfers. Even if this state is fetched lazily from a server, it is
likely to involve many tens or hundreds of MB at startup, with further transfers during
execution. This results in significant startup delay (“resume latency”), and slower
execution (“slowdown”). When a user finishes work, modified VM state has to be
transferred back to the server. In trusted environments such as home or office, the user
can depart without waiting for this transfer to complete. But in public environments
such as an Internet cafe, the prudent user suffers a final delay (“suspend latency”).
Moreover, poor network connectivity or even network disconnection presents a challenge
to the availability of a user’s personal computing environment under this approach to
opportunistic mobile computing.
In this chapter, we show how the storage and Internet connectivity of smart phones
can be used to alleviate the availability challenge to opportunistic mobile computing.
Our design treats smart phones as trusted personal assistants that serve as self-cleaning
portable caches for VM state. We call such an assistant Horatio, alluding to Hamlet’s
trusted ally in Shakespeare’s play. A user can suspend his VM state to Horatio rather
than directly to the server; similarly, he can resume from Horatio. Even when Internet
connectivity is poor, the physical proximity of Horatio to the client ensures good con-
nectivity between them: for example, a USB 2.0 cable or one of the emerging wireless
technologies such as Ultra-Wideband (UWB). To reduce device vulnerability, Horatio
opportunistically uses cellular, WiFi, or other networking technology to asynchronously
65
Figure 3.1: Oases of Connectivity
propagate modified VM state to VM state servers while users are in transit. This self-
cleaning aspect of Horatio distinguishes it from approaches such as SoulPad [42] that
rely solely on passive USB storage, and are hence vulnerable to device loss or damage.
Horatio does not increase the size or weight aspects of a user’s mobility footprint be-
cause most users already carry smart phones for voice calls, email, web browsing, and
texting. Only the energy aspect increases slightly.
3.2 Motivating Examples
To illustrate how Horatio can improve user experience, we provide two hypothetical
scenarios that capture the essence of real-world usage.
3.2.1 A Day in a Busy Professional’s Life
Jill is a young professional. On a typical morning, she does homework on a desktop for
her part-time MBA course and then checks her e-mail before leaving for work. During
her commute, her VM is suspended to a VM state server. At work, she resumes her
66
desktop session and has a productive morning. Over lunch, she finishes her homework
and then downloads and watches an episode of her favorite TV sitcom. After work, Jill
meets friends at a coffee shop to view and edit vacation pictures on a laptop loaned by
the coffee shop. Before heading to the gym, she updates her iPod for the workout with
a podcast delivered earlier to her VM.
In this scenario, the VM Delivered over the Internet approach readily supports Jill’s
well-connected desktop sessions at home and office. However, resume and suspend times
at the coffee shop are unacceptable because of poor Internet connectivity. Since the
loaner laptop has to be returned to the coffee shop, Jill is forced to wait for the full
duration of the suspend latency.
Horatio could greatly improve Jill’s user experience at the coffee shop. When leaving
work, Jill suspends her desktop session to her smart phone. At the coffee shop, she
quickly resumes from the phone. Before leaving the coffee shop, she quickly suspends
to her phone, returns the loaner laptop and heads off for the gym. During her walk,
Horatio uses the phone’s 3G connectivity to send VM state changes to the VM state
server; Horatio completes this task during her workout by using WiFi connectivity in
the gym.
3.2.2 A Week in a Global Traveler’s Life
Jack is a marketing consultant with projects that span the U.S. and Europe. An
upcoming business trip requires him to make multiple stops within the U.S. and then
multiple stops within Romania1. As Figure 3.1 illustrates, Jack will experience two
oases of connectivity (entirely within the U.S., and entirely within Romania) within
which Internet connectivity is excellent. However, connectivity is poor between the
U.S. and Romania. When Jack travels between client sites A and B within the U.S., he
can resume his personal computing session directly from the VM state server; when he
is ready to leave a site, he can suspend his session back to the server. However, when
Jack travels between sites in Romania (C and D in Figure 3.1), his user experience
1Advisor’s home country
67
is unacceptable2. Because of poor connectivity to his VM state server in the U.S., he
experiences long resume latency, substantial slowdown and long suspend latency. Thus,
his personal computing environment becomes virtually unusable.
Horatio offers a powerful solution to this problem. Before leaving the U.S., Jack
can suspend his session to Horatio. In Romania, he can resume directly from Horatio.
As Jack moves from Site C to Site D, for example, he can quickly suspend and resume
to and from Horatio, with performance similar to what he experiences while in the
U.S. Additionally, as he travels within Romania, Horatio can opportunistically take
advantage of transient good connectivity to the U.S. to incrementally propagate modi-
fied state to his VM state server. Finally, when Jack returns to the U.S., Horatio can
complete any remaining state transfer and synchronization steps.
3.3 Horatio Design
The enabling technology for Horatio is the smart phone, whose primary function in-
cludes basic mobile phone capabilities such as voice calls and texting. In addition, these
smart phones may be viewed as “always-on” computing and storage devices with mul-
tiple network modalities (such as 3G, WiFi, and Bluetooth) for Internet connectivity.
Since these devices are still in the early stages of evolution, their capabilities are likely
to improve significantly over time. Our goal in this research is to both validate the
Horatio concept on currently-available smart phones, and to identify specific directions
of improvement for future smart phones to serve as Horatio devices.
Horatio’s goal is to serve as a performance accelerator for VM Delivered over the
Internet approaches, and to thus improve user experience in situations where Internet
connectivity is poor or non-existent. In other words, Horatio should reduce resume
latency, slowdown, and suspend latency in scenarios such as those in Section 3.2. It
should also enable use of a machine with no Internet connectivity as a client station.
It should achieve these benefits without significantly increasing the mobility footprint
(i.e., energy usage) of a smart phone.
2Please note that this is meant as a hypothetical scenario, rather than a realistic portrayal of trueuser experience in Romania.
68
To meet these requirements, our design and implementation are based on a few key
principles. We list these below, and discuss them in Sections 3.3.2 to 3.3.6:
• Expose opportunities for parallelism, asynchrony, and speculation in data trans-
fers by separating data from control (Sections 3.3.2, 3.3.6, and 3.3.6).
• Recognize that trust flows upstream, while performance flows downstream (Sec-
tion 3.3.3).
• Use client and server resources rather than Horatio resources whenever possible
(Section 3.3.4).
• Keep Horatio clean (Section 3.3.5).
3.3.1 Design Assumptions
We have made the following four assumptions in designing Horatio. First, Horatio oper-
ates within the environment provided by the VM Delivered over the Internet approach.
Consistent with this model, a Horatio user requires temporary use of clients wherever
needed, and establishes or implicitly assumes trust in those clients prior to use [84, 105].
Second, we assume a Horatio user carries a smart phone that supports wireless
networking (3G and WiFi), and has a USB-mountable disk large enough to store a
user’s VM data. This assumption is realistic since modern smart phones already support
multiple wireless networking options, and many come with 8 GB or more of disk (some
are even upgradeable to over 16 GB with microSD storage). For both 3G and WiFi, we
assume a fixed-fee cost model rather than a volume-sensitive model for wireless data
transfers.
Our third assumption is that users place extended trust in their smart phones, but
only transient trust in clients that are opportunistically borrowed. Between resume and
suspend, the user trusts the client that is executing her VM. Once she walks away after
suspend, she no longer counts on that client to remain uncompromised or to propagate
dirty state to the server. In contrast, she has complete confidence that Horatio will
propagate dirty state to the server even if it takes many hours or days. Although
69
State Name Type Typical Size DescriptionMemory Image data 200 MB Encrypted and compressed memory
image and registers.Disk Image data 3.5 GB Individually encrypted and compressed
chunks of virtual disk.Keyring control 5.5 MB Encryption keys and cryptographic
hashes of virtual disk chunks. En-crypted with a key stored in the con-figuration file.
Configuration File control 500 bytes Operational parameters of a VM andencryption key used to encrypt thekeyring and memory image.
Ownership Nonce control 10 bytes A unique identifier generated when aVM is checked out from a VM stateserver.
Table 3.1: Data and Control State
attacks on smart phones are growing, this problem needs to be solved even if the smart
phone is not used as a Horatio device.
Fourth, we assume strong connectivity between the opportunistically borrowed
client and Horatio, which is reasonable given the close proximity of Horatio to the
client. For the client-server and Horatio-server links, we allow for the broadest range
of connectivity, including total disconnection.
3.3.2 Data and Control Separation
Achieving Horatio’s twin goals of improving the opportunistic mobile computing experi-
ence and efficient self-cleaning is complicated by several factors. These include the large
size of VM state, the wide range of network connectivity that has to be tolerated (rang-
ing from gigabit LANs down to kilobit wireless links and even total disconnection), and
the unpredictability in the availability and durability of network connections. When
WiFi coverage is available, it is preferable to 3G for self-cleaning both from the view-
point of performance and energy usage. When WiFi is unavailable, 3G may be the only
choice. In addition, a recently-used client may sometimes assist in propagating dirty
state after suspend, even though our trust model does not require it to provide this
assistance.
70
Figure 3.2: Data and Control Transfer in Horatio
A good Horatio design has to work robustly and efficiently even in the face of
considerable uncertainty in connectivity and client participation. We address these
requirements by enabling uncoordinated, asynchronous data transfers to take place
in parallel to the server from one or more recently-used clients as well as Horatio.
Our design follows the principle of meta-data separation advocated by Tolia et al. in
their work on DOT [107]. As their work shows, the key to achieving efficiency while
preserving correctness with minimal coordination across multiple data transfer channels
is to cleanly separate bulk data from its meta-data.
As Table 3.1 illustrates, Horatio views a VM as consisting of two very distinct
components: data state and control state. The data state consists of an encrypted VM
memory image and individually-encrypted 128 KB chunks of the virtual disk. The
control state, which is the knowledge necessary to decrypt, validate and use the data
state, consists of an encrypted keyring, a configuration file, and an ownership nonce.
Clean separation of control and data simplifies the use of replication and parallelism,
while enabling the speculative transmission of modified data to be performed through
the use of eager state propagation. Horatio can be quite cavalier in its use of these
techniques for data state, provided it handles control state very carefully. Figure 3.2
71
Data
Control
Server
(3b)(2)
(3b)(4)
Horatio
Horatio
Horatio
Client #1 Client #2
(3 )(1) (3a)
(1) Client 1 transfers data state updates, then control to Horatio. (2) As users transitsbetween sites, Horatio “cleans” data state by transmitting updates to the server. Horatiomay transfer VM ownership once all of the updates have reached the server. Optionally,as the user transits between sites prior clients can transmit data state updates as anoptimization to preserve Horatio’s battery life. Finally, (3a) VM ownership is transferredto Client 2 from Horatio. The client can fetch data state from Horatio (3a) or from theserver (3b) depending on network connectivity between the client and the server.
Figure 3.3: VM Ownership and Handoff in Horatio
illustrates client-Horatio-server interactions, which are explained in more detail in the
following sections.
VM Ownership and Handoff
The absence of state sharing across VMs means that a single exclusive lock per VM
is acceptable. In Horatio, the ownership nonce represents this lock. When a VM is
checked out, the VM state server generates a new ownership nonce. This nonce has
to be provided when the VM is checked in. Possession of the nonce is proof that the
entity performing the checkin is acting on behalf of the user. This is a reasonable
assumption since all network connections (client-server, client-Horatio, and Horatio-
server) are encrypted and authenticated. Exactly one site (client, server, or Horatio)
can own a particular VM at any point in time. Only the VM owner can decrypt and
72
validate the data state, but any site can cache parts of the data state or transmit parts
of it in any way it chooses. As a result, most of a VM’s data state can be transferred
by the site most able to do so. Regardless of how it reached its destination, such data
can be safely used after validation.
Ownership handoff occurs in three steps. First, the source site confirms that all
required data state updates have been sent to the destination site. Second, the keyring
and configuration file are transferred. These are utilized by the destination to validate
the data state that has been transferred from the source. The destination does so by
performing a SHA-1 cryptographic hash on the data state and comparing it to hashes
stored in the keyring. Finally, the ownership nonce is transferred using a two-phase
commit protocol. If the source site is a client or Horatio, it deletes its copy of the
control state, rendering it unable to decode any data state that is still cached.
Figure 3.3 illustrates the state transfers that occur along with the benefits of data
and control separation. In the figure, a user at Client 1 suspends his VM and initiates
the checking process to Horatio. Client 1 first transfers a full copy of the data state
updates to Horatio and then transfers VM ownership (1). As the user transits between
sites, Horatio transfers the data state updates to the server (2). Optionally, data state
updates can also be transferred by Client 1 to the server (4). Once a full copy of the
data state updates have arrived at the server, Horatio can complete the checkin process
and transfer VM ownership to the server (2). During this process, the server would
validate the data state using the cryptographic hashes stored in the keyring. It is also
possible for Horatio to retain ownership, based on the desire of the user. Finally, once
the user arrives at his destination, he can checkout from the current VM owner (either
Horatio (3a) or the server (3b)). The current owner (in the case of Figure 3.3 it is
Horatio) transfers VM ownership to Client 2 (3a). From this point on, Client 2 fetches
data state from either the server or Horatio depending on the network connectivity
between the client and the server.
73
Reducing Suspend Latency
When client-server bandwidth is poor, the user can save time by performing a checkin
of his VM to his Horatio device rather than directly to the server. This can occur over
any available connectivity such as USB, Ethernet, WiFi, or Bluetooth. Because the
bandwidth between the client and Horatio is likely to be greater than the bandwidth
between the client and server, checking in to Horatio can significantly decrease suspend
latency.
The client first transmits modified data state to Horatio, then transfers VM owner-
ship. After this point, the client may still have modified data state in its cache and may
continue transmitting this dirty state directly to the server after the user departs. Since
the data state is fully validated through cryptographic hashing during the checkin pro-
cess, correctness is preserved regardless of the source of data state transfers. Allowing
such transfers from prior clients is an optimization that can reduce Horatio’s mobility
footprint by reducing the volume of wireless data it needs to transmit.
Reducing Resume Latency
Horatio can reduce resume latency by serving as a lookaside cache [106] for data state.
If the VM is currently owned by the server, the control state is fetched from there.
Otherwise, it is fetched from Horatio. Using the control state, the cryptographic hashes
of the memory image and virtual disk chunks can be obtained. These are used to
demand-fetch parts of data state from Horatio, if possible. Sometimes, Horatio may
not possess parts of the data state (typically those parts that are unmodified relative
to the VM state version stored on the server). In that case, the lookaside reference fails
and the client fetches that data directly from the server.
Horatio can be used to resume a VM on a client that is disconnected from the Inter-
net. For this to be successful, the user must have performed two steps in anticipation
of this possibility. First, he should have transferred ownership of the VM to Horatio.
Second, he should have hoarded [72] all data state on Horatio.
74
Figure 3.4: Rules for Ownership Transfer
3.3.3 Trust versus Performance Flow
The separation of data from control, together with the extensive use of parallelism,
asynchrony and speculation in data transfers, results in a large and complex distributed
VM state space that spans a VM state server, multiple clients, and a Horatio device.
Reasoning about correctness in this state space (for example, “Can site A transfer
ownership of VM X to site B right now?”) requires a simple set of rules that is consistent
with user intuition. Our rules are based on a trust-performance hierarchy that arises
from the introduction of a trusted portable device into the client-server model.
At the apex of trust is a VM state server. By definition, a server is the ultimate
authority for all the VMs that it owns. It contains the definitive, complete and most re-
cent states of those VMs, except for some periods of time when a VM has been checked
out on a client or suspended to Horatio. Although the server may be temporarily inac-
cessible due to poor Internet connectivity, it is assumed to be completely trustworthy
and reliable.
In the eyes of its owner, a Horatio device is completely trustworthy. It is thus ideally
placed to offer VM-related services to its owner even when the server is inaccessible or
75
poorly-connected. For example, Horatio can buffer updates for asynchronous propaga-
tion to a server. This resembles the role envisioned for waystations by Kim et al. in
their work on Fluid Replication [71].
Lowest in the trust hierarchy is a borrowed client at which a user has checked out a
VM. The decision to trust the client is made by the user based on familiarity (such as
a machine at work or home), reputation (such as use of a machine at an Internet cafe
that is known to provide malware-free machines), or an explicit trust establishment
procedure [59, 105].
Counter to this trust hierarchy, which flows upstream (from client, through Horatio,
to server) is a performance hierarchy that flows downstream. State that is already
cached at the client has the lowest access cost and hence highest performance. State
on Horatio is slower to access, but often much faster than accessing state on a distant
server. Finally, state on the server is most complete, but slowest to access.
These considerations of trust and performance lead to a set of simple rules per-
taining to ownership transfer. We distinguish between “upstream” and “downstream”
ownership transfers as shown in Figure 3.4. In the case of downstream transfers, while
the downstream device must have access to all VM state in order to resume the VM,
the state can be fetched on demand. Therefore, the downstream site must either have
ongoing access to an upstream site holding all of the data state, or must hoard all of
that data state in advance. Dirty state can be held by an upstream site under the same
rules. When transferring ownership upstream, on the other hand, all dirty state must
be propagated before ownership transfer can complete, and the ownership transfer pro-
cess must cryptographically validate that the destination site does indeed hold a correct
copy of the state. This is necessary because the downstream site can discard VM state
after control transfer.
As just described, while Horatio is the VM owner, it must maintain copies of all
dirty data that has not yet been committed on the server. In addition, Horatio may
optionally retain copies of unmodified VM data. This allows Horatio to serve as a
lookaside cache, supplementing the client’s own cache. Cache misses can be serviced
from the well-connected Horatio rather than a poorly-connected server.
76
3.3.4 Resource Conservation on Horatio
In focusing on Horatio, it is important not to lose sight of the fact that the primary
function of a smart phone remains voice communication and texting. If its Horatio
functionality drains its battery to the point where the primary function is impacted
at a critical moment, the net effect for the user can be quite negative. Striving to
reduce Horatio’s mobility footprint is therefore an important aspect of our design and
implementation. We offload as much resource-intensive work as possible to clients and
servers. This is reflected both in the structure of Horatio-client and Horatio-server
communication protocols, and in low-level implementation aspects. In this context, a
major advantage of a wired client-Horatio communication link such as USB is that it
also has the potential to supply energy to the Horatio device.
Offloading work to clients and servers also has a positive impact on performance.
Smart phone designs must balance platform capabilities against battery lifetime, and
therefore have limited CPU, memory, and storage capacity. Even when the borrowed
client is a laptop, it is typically much more computationally capable than a smart
phone. Further, in scenarios such as the first scenario in Section 3.2.1, laptop battery
life tends to be less critical than Horatio battery life. Of course, these considerations
have to be balanced against the goal of improving opportunistic mobile computing user
experience. When necessary, Horatio should be prepared to supply its own resources
in order to ensure that the user’s needs are met. For example, if Horatio has good
connectivity to a server via a cellular data network, it should be prepared to upload
modified VM state rather than requiring the client to do so over a much poorer Internet
connection. This might be the case, for example, in the second scenario in Section 3.2.2.
3.3.5 Self-cleaning on Horatio
Despite the high level of trust placed in smart phones, they are also fragile. Since
they are small and carried everywhere, they can easily be damaged or lost; they can
also run out of energy. In these situations, the effect on the user must be minimized.
Therefore, when Horatio holds the most current copy of VM data, it uses any available
77
connectivity (such as WiFi or 3G) to save that data on the less-fragile server while the
user is in transit.
Once a VM has been checked in to a Horatio device, Horatio immediately begins
self-cleaning: checking in the VM to the VM state server using any available wireless
connectivity, such as WiFi, WiMax, UWB, or a cellular data network. Because Horatio
is a trusted device and the user need not wait for the transfer to complete, it is ac-
ceptable for this process to take some time. However, the VM data remains vulnerable
to the loss or destruction of the Horatio device until self-cleaning completes. Option-
ally, Horatio can retain VM ownership even after self-cleaning completes; this approach
provides maximum resiliency to loss of the Horatio device, while still allowing the next
resume site to check out from Horatio rather than from the server. If Horatio possesses
both VM ownership and cached copies of all of the VM data, the VM can be checked
out from Horatio and resumed on a fresh client that has no Internet connectivity.
If the Horatio device is lost or damaged while Horatio owns the VM, dirty VM state
stored on the device will be lost. The recovery procedure in this event is the same as
that for a lost or damaged VM: the user can instruct the VM state server to forcibly
make itself the current VM owner, invalidating modified state held by the previous
owner and allowing another client to check out the VM. This operation will roll back
the VM state to its most recent commit on the server. Should Horatio or a client later
attempt to check in the invalidated state, the ownership nonce will no longer match
that at the server, and the checkin will be rejected.
3.3.6 Additional Optimizations
Our prototype contains several additional optimizations for improving suspend latency
and energy efficiency. These are described in the following sections.
Concurrent Upload from Multiple Sites
As discussed in Section 3.3.2, the separation of control and data state allows for the
concurrent propagation of data state to a server from multiple sources. To reduce the
energy demands on Horatio, we take advantage of the fact that any client can continue
78
to transfer data state to a server even after ownership has been transferred to Horatio.
After checking in to Horatio and thus relinquishing VM ownership, a borrowed client
will attempt to upload modified VM data directly to the server. Because Horatio
maintains a complete copy of the modified data, the user need not trust that the client
will complete the upload successfully, but any data uploaded by the client is data that
Horatio does not have to expend energy to transmit. Horatio, through its interaction
with the server, will validate the SHA-1 cryptographic hashes of data uploaded by
clients and ignore invalid or incomplete data, so correctness is preserved even if the client
is compromised after the user departs. This optimization strictly improves Horatio’s
battery utilization: if the client fails to upload dirty data, or maliciously uploads invalid
data, Horatio expends no more energy in self-cleaning than if the client did not upload
at all.
Memory Image Differencing
OpenISR 0.9.4, upon which the Horatio prototype is based, treats a VM’s memory
image as a single, large object. Thus, if a VM is resumed even for a moment, the entirety
of the memory image must be transferred to the server at checkin. However, the VM
state server will always have, and Horatio will often have, a copy of the memory image as
of the most recent checkin (the “basis image”). The Horatio prototype implementation
check to see if the destination of a checkin possess such a copy. If so, only a delta
between the basis and current memory images is computed and transmitted to improve
energy efficiency, suspend latency, and self-cleaning time.
If the client is performing a checkin to the server, the server is responsible for
applying the delta to the basis image to produce the new memory image. If the checkin
is to Horatio, however, applying the delta is too expensive an operation to be performed
on the Horatio device. The delta is therefore saved separately on Horatio, forwarded
to the server during self-cleaning, and applied at the server when the VM state is
committed. If another client checks out the VM from Horatio, the basis image plus the
delta is sent.
79
Eager State Propagation
In the design described in Section 3.3.2, transfer of modified data state to Horatio
only begins at checkin, after the end of a user’s session. At this point, a user must
wait for potentially several hundred MB of data to be transferred. While this may be
faster than transferring the data to the server over a slow connection, it may still be
unacceptably slow. The client therefore opportunistically collects modified disk chunks
and memory image state from the VM while it is running, and speculatively transmits
this data to Horatio in the background. Due to this speculation, the state that is
collected in this way may not be internally consistent, but it serves to prepopulate the
Horatio device with data that is likely to be needed. At checkin, only the final set of
differences between the previously-transmitted and the final state are sent to Horatio,
minimizing the amount of time that the user must wait. Additionally, the final set of
differences fixes any inconsistencies incurred due to the speculation. Also, because of
potential update locality in the workload, some of the data transmitted to Horatio may
be overwritten before suspend. Eager data transfer thus increases the total amount of
data that needs to be transferred, and therefore, the amount of energy expended by
Horatio. The user can address this concern by connecting the Horatio device to a power
source while using the client.
The Horatio design also allows for concurrent eager state propagation, similar to
concurrent upload that occurs at suspend time. In this case, if ample bandwidth be-
tween the client and server exists, the client may choose to eagerly propagate state
modifications to the server, rather than to Horatio. In fact, given the broad possible
range of link performance combinations between the client-Horatio and client-server
links, the client can optimize eager state propagation by selectively choosing to which
target (Horatio, VM state server, or both) to eagerly propagate the state modifications.
Our current system allows the user to decide.
80
Ope
nmok
oN
eoFr
eeR
unne
rN
okia
N95
-8G
BSa
ndis
kM
obile
Ult
raA
bbre
viat
ion
OM
N95
SDT
ype
Smar
tph
one
Smar
tph
one
mic
roSD
card
Ope
rati
ngSy
stem
Lin
ux2.
6Sy
mbi
anO
S9.
2,S6
0r3
.1-
Pro
cess
orA
RM
920T
400
MH
zA
RM
1133
2M
Hz
-M
emor
y12
8M
B12
8M
B-
Inte
rnal
Fla
sh25
6M
B12
8M
B2
GB
Add
itio
nal
Fla
sh2
GB
mic
roSD
8G
BIn
tern
al-
Con
nect
ivit
yFu
ll-Sp
eed
USB
(12
Mbp
s)Fu
ll-Sp
eed
USB
(12
Mbp
s)H
i-Sp
eed
USB
(480
Mbp
s)B
luet
ooth
2.0
Blu
etoo
th2.
080
2.11
g,G
PR
S80
2.11
g,3G
Tab
le3.
2:P
orta
ble
Dev
ices
Use
dIn
Hor
atio
Eva
luat
ion
81
3.4 Implementation
The Horatio prototype implementation consists of three separate components: the
Client daemon, the Horatio Phone daemon, and the Server daemon, running respec-
tively on the client, Horatio device, and server. The Client and Horatio Phone daemons
are responsible for performing state and ownership transfers between their respective
devices. The Horatio Phone daemon performs self-cleaning, while the Client daemon
performs concurrent upload, by communicating with the Server daemon. The Server
daemon, in turn, acts as a proxy for the VM state server to assist the other daemons
with these tasks.
The Horatio prototype currently runs on two smart phone platforms, the Open-
moko Neo FreeRunner and the Nokia N95. Specifications for these devices are given
in Table 3.2. The FreeRunner is Linux-based, and supports GPRS and WiFi wireless
connectivity; the N95 is Symbian S60-based, and supports 3G and WiFi.
Most components of Horatio are written in Python version 2 for portability. Perform-
ance critical sections of the state transfer code are implemented in C and compiled
natively for each platform. Use of the Symbian S60 Open C libraries on the N95 al-
lowed the same C source code to be used for both smart phones. We use OpenISR
0.9.4 as our VM Delivered over the Internet system. As part of our Horatio prototype
implementation, we introduced changes to OpenISR [92] client and server code. The
client was modified to initiate the Client daemon. The server was modified to support
applying memory image deltas, as described in Section 3.3.6, and to support ownership
transfer between the client and Horatio. Throughout the evaluation, references to the
ISR client or ISR server map to the borrowed client and VM state server under the
generic VM Delivered over the Internet model.
3.5 Evaluation
Our experimental evaluation of the Horatio prototype addresses four questions:
1. How much does Horatio improve user experience (Section 3.5.2)?
82
2. How effective is self-cleaning in reducing the vulnerability of a Horatio device
(Section 3.5.3)?
3. What is the impact of Horatio on a user’s mobility footprint (Section 3.5.4)?
4. How effective is eager state propagation in reducing suspend latency (Section 3.5.5)?
3.5.1 Experimental Methodology and Setup
We use two types of experiments in evaluating Horatio. The “microbenchmark” exper-
iments use synthetically generated VM updates. The “macrobenchmark” experiments
use VM state generated by a set of scripted workloads.
Microbenchmarks
Each microbenchmark is based on an initial VM configured with 512 MB of RAM
and a 4 GB disk. For each set of measurements, we vary the amount of dirty data
state that must be transferred by synthetically generating a predetermined amount of
incompressible state and updating the VM disk and memory images. We distribute
the dirty state equally between memory and disk, e.g., 100 MB of dirty state would be
divided between 50 MB of dirty memory state and 50 MB of dirty disk state.
During suspend and resume, there is a fixed amount of base state that must be
transferred along with the dirty state. For suspend, the amount is 8 MB and consists of
the control state items (keyring, configuration file, and nonce) that must be transferred
to Horatio along with the data state. For resume, the amount is 175 MB consisting of
the control state items and the initial VM memory image. This image must be copied to
the client as the base memory image to which the dirty state memory diffs are applied.
In some situations, a client may already possess a cached copy of the base memory
image. In our experiments, we assume the worst case for Horatio and clear the client
cache after each run.
83
Wor
kloa
dE
xecu
tion
Dir
tySt
ate
(MB
)W
orkl
oad
Des
crip
tion
Nam
eT
ime
(s)
Mem
ory
Dis
kE
mai
l32
816
4U
seE
volu
tion
emai
lcl
ient
todo
wnl
oad,
read
,an
dre
ply.
Wor
d60
541
3U
seO
penO
ffice
Wri
ter
toco
mpo
sean
dsa
vea
lett
er.
Ph
oto
804
254
Use
GIM
Pim
age
edit
orto
edit
phot
osin
anal
bum
:re
mov
ere
d-ey
ear
tifa
cts
from
pers
ons
inth
eph
otos
,clo
nea
pers
onm
ulti
ple
tim
es,a
ndm
ake
colo
ran
dlig
htin
gad
just
men
tsto
phot
os.
Sh
op69
131
14Sh
opon
line
for
aT
V:b
row
sew
ebsi
tes
ofon
line
reta
ilers
usin
gM
ozill
aF
iref
ox,
and
note
pric
esan
dte
chni
cal
deta
ilsw
ithgedit
text
edit
or.
Po
dca
st41
912
010
9D
ownl
oad
a10
8M
BM
P3
audi
opo
dcas
tus
ing
the
Rhy
thm
box
med
iapl
ayer
,an
dtr
ansf
erth
ene
wpo
dcas
tto
port
able
mus
icde
vice
.V
ideo
2382
264
368
Dow
nloa
dan
dw
atch
a30
-min
ute,
378
MB
MP
EG
-4fil
e.R
esu
lts
are
exec
uti
onti
mes
inse
con
ds
and
stat
esi
zes
inM
B.
Eac
hre
sult
isth
em
ean
oftw
om
easu
rem
ents
and
all
stan
dar
dd
evia
tion
sar
ele
ssth
an3%
.
Tab
le3.
3:M
acro
benc
hmar
kW
orkl
oads
for
Hor
atio
Eva
luat
ion
84
Macrobenchmarks
Our macrobenchmarks consist of six workloads, lasting between three and forty minutes,
that exemplify activities commonly performed by desktop users. Table 3.3 summarizes
these workloads. Each workload uses the same VM, in the same state: a Debian Linux
5.0 guest with 512 MB of RAM and an 8 GB disk, containing all of the applications
needed to run the workloads.
Hardware Setup
Our evaluation uses three different Horatio devices: (i) an Openmoko Neo FreeRunner,
(ii) a Nokia N95, and (iii) a USB-connected flash storage card. Specifications for these
devices are given in Table 3.2. Device (iii) does not meet all of the requirements for
Horatio, since it cannot perform self-cleaning. We include it because it represents a
case that neither the N95 nor FreeRunner support: USB 2.0 in Hi-Speed (480 Mbps)
mode. Since new models of smart phones are starting to support both microSD and
Hi-Speed USB, it allows us to observe the expected suspend and resume latency for
Horatio on emerging devices.
Our client PC hardware is a Dell Optiplex 755 with a 2.33 GHz Core 2 Duo CPU,
3 GB of RAM, a 250 GB Serial ATA disk at 7200 RPM, and support for Hi-Speed
USB. The server hardware is a Dell SMP server with dual 2.8 GHz Pentium 4 Xeon
processors, 1 GB of RAM, a 32 GB Fast-Wide SCSI disk at 10,000 RPM, and a 1 Gbps
Ethernet connection. We consider two different client-Horatio interconnects: 802.11g
WiFi and USB. We evaluate WiFi for the FreeRunner and N95 smart phones, and
USB for the N95 phone and the USB-connected microSD card. We evaluate Horatio’s
self-cleaning performance over the Internet via both WiFi and the AT&T Wireless 3G
network. The 3G network has advertised upload speeds between 500 Kbps and 1.2
Mbps, and download speeds between 700 Kbps and 1.7 Mbps. For the WiFi experi-
ments, Horatio connects to the Internet via the Linksys 802.11g access point through
a 1 Mbps residential broadband Internet connection. The client and server are also
connected over the same residential link.
85
Dirty State SizeHoratio Device 1 MB 10 MB 100 MB 500 MBISR-1 (No Horatio) 1434 (7) 1488 (1) 2118 (3) 4936 (15)N95-WiFi 39 (3) 69 (2) 301 (5) 1239 (28)OM-WiFi 33 (2) 48 (1) 260 (5) 1040 (9)N95-USB 29 (4) 44 (3) 142 (1) 625 (4)SD-USB 23 (1) 25 (1) 40 (1) 136 (2)
Results are suspend times in seconds and are the mean of six measurements. Standarddeviations are reported in parentheses. ISR-1 represents the base ISR case over a 1MbpsWAN link.
Table 3.4: Microbenchmark Suspend Results for Horatio
Dirty State SizeHoratio Device 0 MB 1 MB 10 MB 100 MB 500 MBISR-1 (No Horatio) 282 (2) - - - -N95-WiFi - 398 (3) 409 (2) 506 (6) 951 (20)OM-WiFi - 292 (2) 315 (12) 372 (2) 692 (2)N95-USB - 226 (3) 237 (7) 284 (1) 521 (3)SD-USB - 35 (1) 34 (1) 36 (1) 51 (1)
Results are resume times in seconds and are the mean of six measurements. Standarddeviations are reported in parentheses. ISR-1 represents the base ISR case over a 1MbpsWAN link.
Table 3.5: Microbenchmark Resume Results for Horatio
Throughout Section 3.5, we refer to a particular combination of Horatio device
and connectivity via a two-part abbreviated name. The first part of the name is the
device type, using the abbreviations given in Table 3.2. The second part is the relevant
connectivity. For example, if a suspend-time measurement refers to “N95-WiFi,” it
refers to Nokia N95 using WiFi to communicate with the client. For a self-cleaning
experiment, the same name would refer to an N95 using WiFi to the server.
3.5.2 Improvement in User Experience
Microbenchmarks
We first evaluate Horatio’s suspend and resume times over WiFi and USB, using syn-
thetically generated dirty state as described in Section 3.5.1. Table 3.4 presents the
resulting suspend latencies with 1 to 500 MB of dirty state, and Table 3.5 presents
86
the resume times. With smaller amounts of dirty state, suspend and resume latencies
are dominated by the overhead of transferring the fixed VM state. As the dirty state
size increases, this effect is reduced. We also compare against standard ISR (without
Horatio) over a 1 Mbps residential Internet connection.
In the suspend case, Horatio shows a substantial performance improvement over
standard ISR. For resume, standard ISR performs better than both Horatio WiFi cases.
The primary reason for this is that these experiments include a fixed amount of dirty
state at Horatio, which must be propagated back to the client during resume from
Horatio. A resume from the ISR server implies clean state, since all state updates must
have been sent back to the server during the last suspend. Therefore, when resuming
from the ISR server, only the memory image and control state is propagated to the
client. By comparing the base ISR 0 MB case to the Horatio with 1 MB of dirty state
cases (column 2 in Table 3.5), we observe that both USB cases exhibit reduced resume
latencies. Since these cases are dominated by the memory image and control state
transfers, we can see that a clean Horatio resumes faster than the base ISR case.
On the FreeRunner and N95, suspend and resume latencies are limited by the USB
speeds of the Horatio device. At the higher transfer rates seen with the microSD card,
however, the bottleneck becomes the generation and application of memory images on
the client PC. In addition, for both suspend and resume times, observed performance
with the FreeRunner is consistently better than that obtained with the N95. Further
experiments show that the FreeRunner exhibits better WiFi throughput and better
write performance to internal storage: the FreeRunner achieves 870 KB/s and 2.03
MB/s, respectively, while the N95 achieves only 690 KB/s and 688 KB/s.
Finally, we note that as the state size passes 100 MB, the observed suspend and
resume latencies over WiFi start to approach the limits of what a user might be willing
to withstand. Observed latencies over USB are substantially better. The N95 exhibits
adequate performance even with only Full-Speed USB, while the microSD card with Hi-
Speed USB exhibits latencies under a minute for all but the 500 MB suspend operation.
87
Macrobenchmarks
In this section, we evaluate suspend and resume times experienced with Horatio using
the workloads described in Table 3.3. The testbed for these experiments consists of a
client and server, plus the Horatio device. The client is a desktop system with a 2.66
GHz Intel Core 2 Duo and 2 GB of RAM. Its software consists of Debian Linux 5.0 with
kernel 2.6.26, and the VMware Player 2.5.0 virtual machine monitor. The server is a 3
GHz Intel Pentium 4 host with 2 GB of RAM, running Ubuntu Linux with kernel 2.6.27.
The two hosts communicate through a netem-emulated WAN link with bandwidths of
1 Mbps and 10 Mbps, and a round trip time (RTT) of 20 ms. In today’s Internet,
10 Mbps represents a highly favorable connection. We evaluate Horatio suspend and
resume performance over WiFi using the Nokia N95, and over USB using the microSD
card.
The results of these experiments are presented in Figure 3.5. The figure includes
workload execution times because they represent productive work from a user’s view-
point — in the ideal case, workload execution time would dominate suspend and resume
times and thus result in an all-black bar. As the figure shows, Horatio improves both
suspend and resume times compared to standard ISR, particularly when Horatio is
connected to the client over USB. The improvement is the most dramatic on the 1
Mbps link. If Jill were to watch a thirty-minute video at the coffee shop with a 1 Mbps
connection to the ISR server, her suspend time would be more than one and a half
hours with standard ISR, but just over five minutes with Horatio over USB.
88
0
500
1000
1500
2000
2500
3000
ISR-1 ISR-10 N95-WiFi SD-USB
Tim
e (s
)
resumeexecutionsuspend
(a) Email
0
500
1000
1500
2000
2500
3000
3500
ISR-1 ISR-10 N95-WiFi SD-USB
Tim
e (s
)
resumeexecutionsuspend
(b) Word
0
500
1000
1500
2000
2500
3000
3500
ISR-1 ISR-10 N95-WiFi SD-USB
Tim
e (s
)
resumeexecutionsuspend
(c) Photo
0
500
1000
1500
2000
2500
3000
3500
ISR-1 ISR-10 N95-WiFi SD-USB
Tim
e (s
)
resumeexecutionsuspend
(d) Shop
0
500
1000
1500
2000
2500
3000
3500
4000
4500
ISR-1 ISR-10 N95-WiFi SD-USB
Tim
e (s
)
resumeexecutionsuspend
(e) Podcast
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
ISR-1 ISR-10 N95-WiFi SD-USB
Tim
e (s
)
resumeexecutionsuspend
(f) Video
The figure shows that Horatio reduces suspend and resume times experienced by the usersignificantly over normal ISR. The ideal case is an all black bar. The ISR-1 and ISR-10 barsrepresent normal ISR with an emulated WAN link of 1 Mbps and 10 Mbps, respectively.Results are the mean of three measurements and standard deviations are below 19% in allcases. The scales of the graphs differ to improve the presentation.
Figure 3.5: Suspend and Resume Overheads for Horatio (Macrobenchmarks)
89
Dirty State SizeHoratio Device 1 MB 10 MB 100 MBN95-WiFi 36 (1) 97 (0) 869 (15)OM-WiFi 13 (0) 82 (1) 775 (1)N95-3G 153 (1) 478 (14) 3848 (103)
Self-cleaning times (in seconds) are given as the mean and standard deviations of threemeasurements (in parentheses).
Table 3.6: Self-Cleaning Time for Horatio (Microbenchmarks)
Workload N95-WiFi N95-3GEmail 213 (14) 739 (5)Word 953 (9) 4354 (91)Photo 839 (19) 3381 (129)Shop 1103 (50) 4830 (313)Podcast 2200 (176) 6398Video 8034 23665
The self-cleaning times (in seconds) are given as the mean of three measurements. Stan-dard deviations are reported in parentheses. Results reported in italics are estimates basedupon measured self-cleaning rates.
Table 3.7: Self-Cleaning Time for Horatio (Macrobenchmarks)
3.5.3 Effectiveness of Self-Cleaning
We evaluate the effectiveness of Horatio’s self-cleaning functionality by determining the
window of time during which VM data stored on Horatio would be vulnerable to data
loss — that is, the amount of time required for self-cleaning. Intuitively, a user would
wish to minimize this time, but a vulnerability time of minutes or hours, rather than
days, is likely to be acceptable.
Microbenchmarks
To perform the self-cleaning microbenchmarks, we use the experimental setup described
in Section 3.5.1. The Horatio device self-cleans 4.5 MB of fixed state and between
1 MB and 100 MB of dirty state, uploading to the ISR server over WiFi or 3G wireless
connectivity. We evaluate self-cleaning over WiFi using both the Nokia N95 and Neo
FreeRunner. 3G connectivity is evaluated using only the N95, since the FreeRunner
does not support 3G.
90
As Table 3.6 shows, self-cleaning times are reasonable in all cases. The longest times
are observed for the N95-3G experiments. With 100 MB of dirty state, the N95 was able
to self-clean over 3G in approximately one hour. Use of 802.11g substantially improves
self-cleaning performance, reducing this worst-case time to just under 15 minutes.
Macrobenchmarks
In this section, we evaluate self-cleaning using the workloads described in Table 3.3,
over both WiFi and 3G wireless connectivity. The Horatio device transfers 4.5 MB of
fixed state, plus the amount of dirty state generated by the workload, to the ISR server.
The N95 smart phone is used as the Horatio device.
As Table 3.7 shows, the results are comparable to those in Table 3.6. Most cases
complete the self-cleaning process in under an hour, and all but two complete in under
two hours. The worst case self-cleaning time takes an estimated 6.5 hours to complete;
this is for the most data-intensive workload, which generates over 700 MB of dirty
state. Although the self-cleaning times are longer for the two download workloads, we
observe that users are likely to place substantially more value in personally-generated
data, such as their word processing documents and spreadsheets, than they would in
downloaded data such as multimedia files. This is because when lost, most downloaded
content can be fetched again. Therefore, Horatio performs very well under the most
important workloads.
Finally, in all cases there is a substantial performance benefit to using WiFi rather
than 3G. Based upon the observations from both the micro– and macrobenchmark
experiments, we conclude that self-cleaning can successfully reduce the window of data
vulnerability to an acceptable duration.
3.5.4 Impact on Mobility Footprint
In this section, we present an evaluation of the energy costs associated with the suspend
and resume operations. We also evaluate the energy cost of self-cleaning. In actual use,
the user should not have to pay the suspend and resume costs, since the Horatio device
should be able to charge its battery while connected to a PC client. However, it is
91
possible that an external power source may not be available for Horatio while the VM
is running.
We use the microbenchmark described in Section 3.5.1 to determine the energy
demands for three operations: (i) suspend, (ii) resume, and (iii) self-cleaning. We
report the amount of energy consumed by the N95 smart phone during each operation,
along with the percentage of battery utilization this represents. For the suspend and
resume operations, we conduct the experiments over both 802.11g WiFi and USB. For
self-cleaning, we perform the measurements for WiFi and 3G. Energy consumption is
measured using the Nokia Energy Profiler utility [4].
Table 3.8 shows the energy consumed during each measurement, and the percentage
of battery power utilized. We calculate the percentage from our energy measurements
and the battery capacity as reported in the device’s specifications. Although we assume
a linear relationship between energy consumption and battery lifetime, it has been
shown that batteries typically exhibit non-ideal properties [79], and the relationship
between energy consumption and battery lifetime is typically non-linear. To ensure
consistent measurements, we fully charged the battery prior to each experimental run.
Still, it is likely that our battery percentage calculations are affected by this non-ideality,
and are only included to provide an alternative representation of the energy costs of
Horatio. As in the previous microbenchmark experiments, we vary the synthetic dirty
state from 1 MB to 500 MB for suspend and resume, and from 1 MB to 100 MB for
self-cleaning.
As the results show, connecting Horatio via USB is more than twice as efficient than
via WiFi during suspend, and more than five times as efficient during resume. Two
factors contribute to this result. First, WiFi communication inherently requires more
energy than USB. Second, when connecting Horatio over USB we are able to treat
it as a mass-storage device rather than a networked host, allowing us to shift all of
the suspend and resume computation to the client PC. The USB connection therefore
allows us to minimize the work that must be done by the Horatio device during suspend
and resume.
92
Dir
tySt
ate
Size
Ope
rati
onH
orat
ioD
evic
e1
MB
10M
B10
0M
B50
0M
BSu
spen
dN
95-W
iFi
28(1
)[0
.2%
]71
(4)
[0.4
%]
400
(1)
[2.5
%]
1789
(9)
[11.
0%]
Susp
end
N95
-USB
12(3
)[0
.1%
]31
(1)
[0.2
%]
147
(4)
[0.9
%]
609
(14)
[3.7
%]
Res
ume
N95
-WiF
i50
7(4
1)[3
.1%
]61
3(1
)[3
.8%
]75
6(1
6)[4
.6%
]14
56(3
3)[8
.9%
]R
esum
eN
95-U
SB96
(2)
[0.6
%]
97(2
)[0
.6%
]12
0(1
)[0
.7%
]22
7(1
)[1
.4%
]Se
lf-C
lean
N95
-WiF
i36
(1)
[0.2
%]
103
(1)
[0.6
%]
916
(3)
[5.6
%]
-Se
lf-C
lean
N95
-3G
181
(4)
[1.1
%]
565
(13)
[3.5
%]
4553
(108
)[2
7.9%
]-
Res
ult
sab
ove
are
the
mea
nof
thre
em
easu
rem
ents
.R
esu
lts
expr
esse
din
Jou
les.
Sta
nd
ard
dev
iati
ons
are
rep
orte
din
par
enth
eses
.R
esu
lts
inbr
acke
tsex
pres
sed
asp
erce
nta
geof
bat
tery
life.
Tab
le3.
8:E
nerg
yC
onsu
mpt
ion
for
Hor
atio
(Mic
robe
nchm
arks
)
93
For self-cleaning, WiFi is more efficient than 3G by at least a factor of five. This is
due to the higher throughput of WiFi: self-cleaning times over WiFi are also shorter
than over 3G by a factor of five on average, enabling the Horatio device to power its
transmitter for much less total time. These results clearly motivate the opportunistic
use of WiFi. It would be especially helpful in the case of large self-cleaning transfers,
since self-cleaning 100 MB over 3G consumes nearly 28% of the device’s battery ca-
pacity. In contrast, a similar operation over WiFi consumes less than 6%. Overall, it
is clear that Horatio does increase the user’s mobility footprint with respect to energy
consumption. However, with opportunistic use of WiFi this increase can be kept small,
and is offset by the fact that the user is not required to carry any other devices to gain
this benefit.
3.5.5 Eager State Propagation
To further reduce the suspend latency after a user completes her personal computing
session, our implementation includes a mechanism for eager state propagation as de-
scribed in Section 3.3.6. The goal of this section is to quantify the benefit and cost
of this optimization in terms of the amount of dirty state transferred from a client
to Horatio. To accomplish this, we use a set of state generation profiles, which are
traces that characterize the updates performed to a VM’s state during a user session.
We gathered the state generation profiles on four of the six workloads described in
Section 3.5.1.
To capture a state generation profile for a specific workload, we execute the workload
in a VM while a background task takes periodic snapshots of the VM’s memory and disk
state. We pause the session during each snapshot to ensure consistency. The resulting
set of snapshots and accompanying traces allow us to deterministically replay the state
updates produced by the session.
To evaluate eager state propagation, we replay our state generation profiles on a
real VM while the eager propagation mechanism transfers dirty memory and disk state
to Horatio in the background. We use the client PC described in Section 3.5.1 and the
microSD card as the Horatio device.
94
Suspend Eager Lazy CleaningWorkload State State State CyclesEmail 3.1 129.6 19.5 3.0Word 1.7 220.8 44.1 3.3Photo 1.6 199.1 28.4 6.7Shop 29.3 485.7 44.4 11.0
Results presented are state sizes in MB and are the mean of three measurements. Allstandard deviations are less than 6%.
Table 3.9: Eager State Propagation Results for Horatio
Table 3.9 presents the results. The second and third columns give the amount
of state (in MB) transferred at and before suspend, respectively, and correspond to
the benefit and cost associated with eager propagation. The fourth column gives the
amount of state that would be transferred at suspend if eager state propagation were
not used. Finally, the last column gives the number of eager transfer cycles performed
by the client over the course of the session.
The table shows that the benefit of eager state propagation is very high for the four
workloads tested. For the first three, the amount of dirty state transferred at suspend
is less than 5 MB. The fourth workload contains a large number of state updates late
in the session, which do not have time to propagate to Horatio before suspend, but
are still less than the amount transferred without eager propagation. Finally, the ratio
of the fourth column to the second column is a good indication of the user-perceived
improvement in performance. In all four workload cases, a client would perceive a
performance benefit with Horatio.
As to cost, the total data transferred due to eager state propagation is roughly 5−7
times that occurring without eager transfer, except for the Email workload, where the
difference is a factor of 11. From these results, we conclude that eager state transfer
is worth the cost: the amount of state that must be transferred during suspend is
dramatically reduced, in exchange for a reasonable increase in the amount of data to
transfer. We do not evaluate the energy costs of eager state propagation since we assume
that local power (e.g., through USB, or wall socket) is available to Horatio when state
is being transferred to/from a borrowed client station.
Figure 3.6 presents the distribution of state updates (in MB) for each of the four
95
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 10 11 S
Dirt
y S
tate
(M
B)
Cleaning Cycle
EmailWordPhotoShop
The distribution of state updates (in MB) for each workload during each periodic cleaningcycle. A cleaning cycle starts approximately one minute after the end of the precedingcycle. Suspend time is marked by an “S” on the horizontal axis.
Figure 3.6: Workload Dirty State Generation for Horatio
workloads for each periodic cleaning cycle. In the figure, one run from each workload
is shown, so that the results align directly with cleaning cycles, as compared to the
average results presented in Table 3.9. The right-most set of bars represents the state
transferred at suspend time, which is marked by an “S” on the horizontal axis. These
results illustrate the fact that the rate of data generation by typical user workloads
underutilizes the available write capacity (approx. 360MB/min for microSD). Out of
the four shown, the Shop workload generates the largest amount of updates, yet still
only approaches 17% link utilization. Shop also performs a large number of updates at
suspend time, relative to the other three workloads, and this accounts for the differences
shown in Table 3.9.
Figure 3.7 presents a CDF that illustrates the effects of update locality during each
of the four user workloads. We measure this by periodically summing, at one minute
intervals, the number of updates to each memory location during workload execution.
For each workload, the graph plots the CDF of the number of updates to a 4KB memory
page, for all memory updates. The Word workload exhibits the least amount of update
96
0
20
40
60
80
100
0 2 4 6 8 10 12 14
% o
f Mem
ory
Loca
tion
Upd
ates
Number of Updates
EmailWordPhotoShop
CDF of the number of updates to each 4 KB memory page, for all memory updates withineach workload.
Figure 3.7: Update Locality for Horatio
locality with approximately 77% of updated memory pages only being updated one
time and 94% updated three or less times. The Email workload is similar to the Word
workload with 53% updated one time and 95% updated five or less times. The Online
workload exhibits the largest amount of update locality with only 25% of updated
memory pages being updated one time and 95% being updated eleven or less times.
Finally, the Photo workload is similar to the Online workload with 48% updated one
time and 95% updated twelve or less times. From these results, we conclude that by
adaptively adjusting the eager propagation algorithm to account for observed update
locality during a session, the costs of eager state propagation may be further reduced.
3.6 Discussion
3.6.1 Smart Phones as Horatio Platforms
While our experimental results clearly indicate that the current smart phone technology
is already adequate to support Horatio, there are several ways in which this technology
97
could better serve it if improved. Connectivity and storage performance are the two
most critical factors on which Horatio’s performance ultimately depends. Incorporat-
ing high-speed flash storage should become standard in order to allow smart phones to
benefit from most recent flash memory technology. Supporting high-performance im-
plementations of the latest interconnects such as USB 2.0, WiMAX and others allows
phones to choose the most effective way to perform self-cleaning at any given location.
The phone’s network stack also needs to be improved to fully exploit existing tech-
nologies, such as WiFi and USB. For example, while the Openmoko and the N95 both
provide 802.11g, which is rated at 54 Mbps, the bandwidth in our experiments maxed
out just under 6.8 Mbps. Fortunately, Horatio’s needs align well with current trends
towards transforming the smart phone into a personal mobile multimedia entertainment
platform.
3.6.2 VM State Size
In Section 3.3 of this chapter, we describe the storage capability requirements for smart
phones. Since current smart phones support 16 GB or more of storage via microSD,
it is realistic to assume that they provide ample capacity for VM state modifications
and caching. However, Horatio also supports operation when fully disconnected from
the server. In this mode, the entire VM state must be copied to Horatio in advance
of disconnection; this may require more than 16 GB. We expect current disk growth
trends to continue, and newer smart phones to support even larger storage capacity.
3.6.3 Impact of Network Connectivity
As discussed in Section 3.3, we assume good connectivity between a borrowed client
station and Horatio, while we allow for the broadest range of connectivity options be-
tween Horatio and the VM state server, and between the client and server. In practice,
Horatio must also be able to handle and recover from poor connectivity conditions, in-
cluding disconnection, when they occur. Poor connectivity between a client and server
may cause the user’s session to experience a performance reduction, or in the case of
98
disconnection, may block the user session while the client waits for reconnection in or-
der to fetch missing state from the VM state server. Poor connectivity between Horatio
and a server will impact self-cleaning performance, possibly even pausing it in the event
of a disconnect until the link has been reestablished. Once reestablished, self-cleaning
can be resumed from where it left off.
Figure 3.5 shows that as the bandwidth between a client and server increases from
1 Mbps to 10 Mbps, resume and suspend delays are reduced. This mitigates the need
for Horatio. Although Internet bandwidths will grow over time, so will average VM
sizes. It is difficult to predict the net effect of these factors.
3.6.4 Leveraging Mobility History and Prediction
Resume latency can be further reduced if the identity of the next resume site is known
or can be correctly predicted. VM state can be proactively transferred to that site,
effectively warming the cache on the next borrowed client with VM state. Potential
sources of knowledge for accurate prediction include a smart phone’s localization device
such as GPS, and personal calendar information.
3.6.5 Horatio User Interface
We believe that a user’s experience with Horatio can be further improved by providing
a richer GUI. Such an interface may provide users feedback and control over various
Horatio operations. An obvious candidate is the timing of the suspend operation,
where Horatio might be able to allow users to indicate an upper bound for the suspend
latency. This can potentially be enforced if Horatio’s client daemon is allowed to take
some action for the user (warning, slow down, or stop) when the amount of dirty
state to be transferred exceeds a threshold calculated based on the user’s suspend time
requirements and estimated transfer bandwidth.
99
3.7 Related Work
Horatio is related to approaches that transport PC state on a USB storage device
(i.e., the VM on USB Device model), for example SoulPad [42], MojoPac [5], and
others [6, 8, 13, 23]. The goal of Horatio is to improve the availability of the VM
Delivered of the Internet approach. It does so along the dimensions of network resiliency
and network demand, and achieves this at a slight increase in the mobility footprint.
Although Horatio shares the physical vulnerability of the VM on USB Device model
because dirty VM state may reside on a Horatio device while awaiting transfer to a
server, the self-cleaning aspect of Horatio bounds the duration of physical vulnerability.
If dirty state on Horatio is lost before self-cleaning completes, only the work done
since the most recent resume is lost. Compared to Horatio, the VM on USB Device
approaches have greater physical vulnerability, since entire computing state resides on
a local USB storage device. If the device is lost or damaged, the only recourse is to
restore from backup, assuming one exists.
3.8 Summary
This chapter introduced the availability challenge to user data access for opportunistic
mobile computing, and presented our approach to addressing this challenge. Our ap-
proach leverages the storage and Internet connectivity of smart phones to improve the
experience of VM Delivered over the Internet opportunistic mobile computing users in
environments with poor wide-area network bandwidth. We instantiated this approach
in a prototype system, which we call Horatio. Horatio treats smart phones as trusted
personal assistants that serve as self-cleaning portable caches for VM state. Horatio
reduces suspend latency by saving VM state to the phone rather than directly to the
server; similarly, users can resume their session from Horatio. To reduce vulnerability
to loss or damage, Horatio opportunistically uses the phone’s network connectivity to
asynchronously propagate modified VM state to VM state servers (self-cleaning).
Our experiments with the Horatio prototype running on the Nokia N95 and the
100
Openmoko Neo FreeRunner smart phones show that Horatio reduces resume and sus-
pend latencies by up to 98% and 97%, respectively. For example, Horatio reduces the
suspend latency from 38.3 minutes (for a demanding workload) or 3.3 minutes (for a
light workload) down to 1.2 minutes. While the performance of Horatio on existing
phones is adequate, our experiments also show that improvements in the phones’ pro-
tocol stacks and software environments could further improve Horatio’s performance
by an order of magnitude.
101
Chapter 4
Improving the Security of Mobile Data Access
4.1 Problem Statement
This chapter concerns the problem of securing access to files on corporate intranets
under opportunistic mobile computing conditions. This includes both the VM on USB
Device and VM Delivered over the Internet approaches. Remote file access is typically
secured using standard network file systems authentication mechanisms, such as VPNs
and firewalls. However, a user may choose to access files from an untrusted, borrowed
client station. Such a device may contain malware, for example viruses and worms, or
even malicious hardware modifications that can potentially compromise the confiden-
tiality and integrity of a user’s remotely stored files when they are accessed via these
devices.
Prior work on securing access to remote resources has focused on verifying the soft-
ware stack on users’ devices. Sailer et al. [87] present an attestation-based approach
that uses Trusted Platform Module (TPM) hardware to acquire integrity measurements
of the software running on a user’s device. User connections are allowed only from de-
vices that run software configurations approved by a remote validation server. While
this approach limits user connection origination from valid trusted devices, it assumes
the existence of TPM hardware on those devices. Unfortunately, given nature of op-
portunistic mobile computing, a user cannot guarantee that they will have access to
a client station with such hardware installed. This necessitates an all-or-nothing ap-
proach to allow access from such devices—either prevent them from accessing to the
remotely shared files, or allow the accesses at the risk of exposing the file system to
malicious actions from these devices.
In this chapter, we propose a novel approach, called Working Set-Based Access
102
Control (WSBAC), which restricts file access from untrusted devices without requiring
special hardware and in a manner that is fully compatible with legacy file systems. Our
approach augments access control mechanisms implemented on network file systems
with the notion of working sets. The key idea is to prevent accesses to files outside
a user’s working set when this access happens from an untrusted device.1 When a
user accesses files from a trusted device, she is allowed free access to all her files,
and is limited only by the native access control policy enforced by the network file
system. Simultaneously, a network agent observes her file access patterns and extracts
her working set. This working set is used to construct an access control policy that is
enforced upon access from an untrusted device.
Using the user’s working set to regulate file accesses ensures that access control
is neither overly restrictive, nor overly permissive. Intuitively, most file accesses are
governed by the working set; indeed, prior work has shown temporal patterns in user
file accesses [100]. Because a user will tend to access a file that she has recently accessed,
using the working set does not overly restrict file accesses. In contrast, malware accesses
to the file system, such as those by viruses and worms, typically exhibit no such patterns.
Using the working set to guard accesses from untrusted devices ensures that files outside
of the user’s working set are protected from such accesses by malware. Damage caused
by malware is thus restricted to the user’s working set. Because the working set only
contains files that have most recently been modified by the user (e.g., during the course
of a day), WSBAC can be coupled with version-control systems to recover quickly from
the damage caused by malware.
Implementing WSBAC requires the design and implementation of two key agents,
one that extracts the working set and formulates a file access policy (Polex), and
one that enforces this policy (Polen). We have implemented both Polex and Polen
for the network file system (NFS) protocol. Polex automatically extracts a user’s
1In the context of our research, we assume that devices administered by the corporation aretrusted, and that other devices (e.g., borrowed devices) are untrusted. However, WSBAC isindependent of this assumption and will work with any technique that can be used to differ-entiate between trusted and untrusted devices, e.g., devices equipped with TPM hardware andintegrity measurement tools [87] could be considered trusted.
103
Example scenario showing access to remote files from a borrowed client station.
Figure 4.1: Remote File Access Scenario
network file system working set by observing that user’s network file system accesses.
Through this extraction, Polex generates per-user working set summaries, which are
subsequently utilized by Polen. Polen is the WSBAC enforcement agent that inter-
poses on the network file system client-server path and intercepts all messages passed
between them. To perform WSBAC policy enforcement, Polen extracts, inspects, and
modifies network file system message attributes. Finally, Polen provides speculation
mechanisms to allow file creations and writes from untrusted devices to occur in the
case of imprecise working set estimation. Speculations are reconciled and committed to
the file server by the user (or user’s delegate) from a trusted device. To be compatible
with legacy file systems, we have implemented both Polex and Polen as network mid-
dleboxes utilizing our existing FileWall framework [95, 40]. However, WSBAC can also
be implemented without a network middlebox by suitably modifying the file system.
104
4.1.1 Example Scenario
To motivate WSBAC, consider the file accesses made by a typical user, Alice (Fig-
ure 4.1). At work, Alice may access several files during the course of a day using her
desktop PC, which she trusts. For instance, she may develop source code using an
IDE, look up or modify documentation using an editor, or use a spreadsheet applica-
tion. Each of these applications involves several accesses, both reads and writes, to
files stored on the network file server. She may also wish to access these files from a
borrowed computer that she does not fully trust, e.g., while at a friend’s house. Such
accesses typically happen via a VPN connection to the network file server.
To ensure safe yet easy access to files in such scenarios, two conflicting requirements
must be met. First, Alice must be allowed access to read/modify her files, being con-
strained only by the access control policy of the network file system. This requirement
is necessary to ensure seamless access to her files. Second, “insecure” accesses to Al-
ice’s files must be denied. This requirement is necessary to prevent accesses that may
potentially be performed by malicious software on an untrusted client station poten-
tially using her credentials. These requirements conflict because of the limited power
of existing network file system administration tools.
Network file system administration tools offer an all-or-nothing choice to enforce se-
cure accesses to remote files. First, existing tools do not offer any fine-grained method
to determine the file accesses performed by Alice, either from the remote file server,
or from client stations. Consequently, these tools can neither observe Alice’s file sys-
tem access patterns nor enforce policies that disallow anomalous file accesses. Second,
network file systems do not store the network context of a user’s accesses with the file
system context. This makes it difficult to differentiate Alice’s file system accesses from
different devices, such as from her work PC or from a borrowed client station.
WSBAC addresses the above shortcomings by extracting the working set of Alice’s
file accesses from trusted devices and enforcing access control based upon her working
set when she accesses files from untrusted devices. WSBAC’s Polex agent continuously
approximates Alice’s working set by observing her file access patterns when she is
105
connected from trusted device. This working set is used as the basis for enforcing
access control when Alice connects from an untrusted client station. WSBAC’s Polen
agent enforces policy, in this case as a network middlebox, thereby ensuring transparent
enforcement, even with legacy network file systems.
The ability of WSBAC to continuously and automatically adapt to changes in Alice’s
working set is its central, novel, feature. This feature ensures that untrusted file accesses
are not governed by a static access control policy that is restrictive, hard to formulate,
and hard to maintain. Working sets offer a flexible yet secure abstraction to restrict file
accesses from untrusted client stations. However, enforcing access control by denying
all accesses outside the working set may be too restrictive in certain scenarios. For
example, the IDE or spreadsheet application that Alice uses to access her files may
create temporary files, such as locks, that may not be in her working set. Alice may be
unable to usefully access her files from the untrusted station if the creation of such files
is disallowed. WSBAC handles such cases by allowing for speculative file accesses during
policy enforcement. Speculative file accesses allow the IDE or spreadsheet application
to create and modify temporary files, thereby permitting Alice useful access to her files.
4.2 Applicability of WSBAC
With the background above, we now address some common concerns on the applicability
of WSBAC.
Suppose that a user, Alice, accesses files from an untrusted client station.
How can she access files that are not in the working set extracted by Polex?
We consider separately the case of reads and writes. Writes to files that are not in the
working set, including the creation of new files, are handled speculatively by Polen;
changes made to such files are visible only to Alice. When Alice accesses these files
again from a trusted device, Polen commits the speculative accesses after they have
been verified by Alice.
To handle reads to files that are not in the working set, WSBAC supports the
inclusion of a reliable secondary authentication mechanism [30, 56, 29, 83] for Alice to
106
add files to her working set. The inclusion of this type of mechanism would ensure
that malware on untrusted devices cannot automatically add files to her working set.
Afterward, Alice can access the newly added files in her working set, thereby allowing
WSBAC to be practical even in scenarios where Alice does not have access to a trusted
device for extended periods of time, e.g., during travel.
Can Alice share speculative updates to files with other users? As described
earlier, WSBAC handles writes to files that are not in Alice’s working set using specula-
tion; these updates are normally only visible to Alice until she commits them. However,
there may be cases where these updates must be visible to other users. For example,
suppose that Alice is collaborating on a paper with others.
WSBAC offers Alice two choices to ensure that an update to the paper made from an
untrusted device is visible to her co-authors. Alice can include the file in her working set
using a reliable secondary authentication mechanism; because Polen does not restrict
accesses to files in the working set, updates to the paper will be visible to the entire
group. However, this approach has the disadvantage of committing possibly malicious
updates to the files, e.g., by malware on the untrusted client station, to the file system.
Alice can avoid this problem by instead using WSBAC’s mechanism to share specula-
tive file updates. Using this mechanism, Alice can share speculative updates to selected
files with her co-authors. However, this mechanism also ensures that all subsequent up-
dates to the file (including those made by her co-authors) will be speculative. Changes
are committed only when one of the group members (not necessarily Alice) working on
a trusted device verifies the file updates. In this way, by sharing speculative updates
with her co-authors, Alice is also delegating commit permission to them, should they
be working from trusted devices.
Can Alice defeat WSBAC protection by artificially inflating the size of
her working set? Yes, this is possible. For example, Alice could write a script that
runs overnight from a trusted terminal and accesses all her files, thereby forcing Polex
to include all her files into her working set. Alternately, Alice could add all her files to
her working set via the Web interface.
However, it is to Alice’s advantage to use WSBAC. Much as Alice can disable her
107
virus scanner at the risk of being infected, she can disable WSBAC protection at the
risk of exposing the files in her working set to malware. Even in this case, damage
is limited to Alice’s files, because WSBAC augments traditional network file system
access control.
Still, there are several procedural regulations that an administrator could use to
prevent her from artificially inflating her working set. For example, Polen could record
her accesses from an untrusted device and compare them against the Polex working
set. If these accesses differ significantly, the administrator could use this as an indication
that Alice is artificially inflating her working set, and issue her a warning.
One special case of this could be caused directly by a valid process that accesses
files while acting on Alice’s behalf, for example, a client-based virus scanner that scans
Alice’s mounted network file systems.2 This problem can be solved in two ways. One
way is to take advantage of a distributed Mandatory Access Control system [66], such
that any network file system messages issued by the virus scanner can be distinguished
by their accompanying labels and ignored by Polex. For legacy clients, the virus
scanner process can run in the context of a special user, and then all network file
system messages issued by that user ID can be safely ignored.
Does WSBAC compromise Alice’s privacy? Both Polex and Polen continu-
ously monitor Alice’s accesses. While an administrator could potentially use these tools
to compromise her privacy, such compromise is possible even otherwise. The network
file server, accesses to which WSBAC protects, is fully accessible to the administrator
even without Polex and Polen. WSBAC also requires that encrypted file accesses
originating from untrusted devices be decrypted at Polen (rather than at the network
file server). However, because both Polen and the network file server are presumably
administered by the same entity, decrypting file accesses at Polen compromises her
privacy no more than decrypting them at the file server.
In spite of these restrictions, Alice can protect her privacy by using a scheme that
only encrypts the contents of packets (and not their headers, which contain information
2We can safely ignore the effects of a server-based virus scanner since they operate locally atthe file server and do not cause network file systems messages to be issued.
108
that is used by Polex and Polen).
Why is virus scanning at the network file server not enough? Although is it
common for virus scanning to occur at network file servers, this technique is insufficient
to protect a user’s data. Virus scanning at the server can intercept file writes and
inspect the modifications to search for virus signatures, should a virus attempt to
propagate itself in the content of the writes. Virus scanning cannot completely protect
the integrity of a user’s data since it cannot detect malicious deletes made by a virus
from an untrusted device. Furthermore, it does not protect the confidentiality of user
data, since any virus masquerading as a legitimate user would have complete access to
all of that user’s data.
4.3 WSBAC Design
In this section, we provide a detailed overview of the design and architecture of our
WSBAC system.
4.3.1 Working Set-Based Access Control
We define a user’s file access working set (WS) to be the set of files (and directories)
the user has accessed over some recent period of time (typically 1 day). Within this set,
files belong to subsets that define the access permissions for that file. For example, all
the WS files for which a user has read permission are included in the read permission
subset of the WS. These subsets are not necessarily disjoint, as a file may be included
in multiple permission subsets (e.g., a file for which a user has both read and write
permissions). Therefore, a file included in any subset of the user’s WS implies that the
user possesses the permission defined by that subset for that file.
Since working sets are specific to each user and typical network file systems scale to
serve several hundred users, it is impractical for an administrator to manually define
the WS for each user of the system. Alternately, allowing users to self-define their WSs
defeats the primary purpose of the WSBAC system. Users will likely over-estimate their
WSs for fear of lacking access to files they may need, even if there is a low probability
109
that they will actually need to access the files while working from an untrusted client
station . To address these concerns, we approximate the per-user WSs automatically.
This removes the potential burden on administrators, while reducing the ability of a
user to over-estimate their WS. WS extraction is performed by the Polex agent of our
system.
Automatic extraction of user WSs may lead to inaccuracies because of two possi-
bilities. First, the WS may include files that the user will not need to access from an
untrusted device. Second, required files may be excluded from a user’s WS. In either
case, users will never gain access to a file that they do not already have access to since
WSBAC only augments the standard network file system access policy, and cannot
make a user’s access rights more permissive. In the limit, a user’s WS may only grow
to match the set of all files that she already has permission to access from a file server.
In general, there are two read cases and two write cases that must be handled by the
WSBAC system. File and directory reads may be attempted for files either included in
or excluded from a user’s WS. For these cases, WSBAC allows reads only for those files
included in a user’s WS and denies all other read attempts (although, a user is able to
add files to her WS using a reliable secondary authentication mechanism). Note that
this covers both data and meta-data reads. File and directory writes include both data
and meta-data writes (create, remove, rename fall into this category). Writes to files
and directories included in a user’s WS are performed normally, while writes to files
and directories not included in a user’s WS are performed speculatively (described in
Sections 4.3.4 and 4.4.2). WSBAC enforcement is performed by the Polen agent of
our system.
4.3.2 WSBAC Policy Extraction (Polex)
WSBAC working set extraction and policy formulation is performed by the Polex
agent. Polex resides in the trusted network domain and observes a user’s network
file system accesses when they are performed from a trusted device. These accesses,
which travel between network file system clients and servers in messages, are captured
by Polex and inspected. Polex utilizes the file system attributes contained in these
110
Requests from trusted (1) and untrusted (2 and 3) devices are shown. Request 3 is handledspeculatively.
Figure 4.2: WSBAC Overview
messages to construct and maintain per-user working set summaries.
Figure 4.2 illustrates how this occurs. In the figure, a trusted device performs a
network file system access, shown in the figure as a network message labeled 1. This
message travels through the network and ultimately reaches the network file server
where the file access is performed on the file system. Along the way, the message
is captured by a network element and a copy is sent to Polex for processing. Any
network element, such as a network switch, could perform this message capture and
copy forwarding function. To handle the case of encrypted or signed network traffic,
Polex (and Polen) shares the encryption keys with the network file server.
Polex maintains the per-user WS summaries on stable storage, as they are built
and updated. These summaries are built through the use of compact summary data
structures (Bloom filters, in our implementation) and they are exported by Polex for
use in Polen. Polex also utilizes the WS summaries to provide per-user virtual file
system namespaces. These virtual namespaces provide administrators a mechanism
to view and modify the WSBAC permissions for individual users as approximated by
Polex. Further discussion of Polex virtual namespaces is in Section 4.4.1.
111
4.3.3 WSBAC Policy Enforcement (Polen)
WSBAC enforcement is performed by the Polen agent. Polen resides in the trusted
network domain, interposed between the network file system clients and servers, and
intercepts all messages passed between them. Polen utilizes the file system attributes
contained within the messages and the per-user WS summaries to enforce WSBAC for
those users accessing the network file system from an untrusted device.
Figure 4.2 shows Polen interposed between network file system clients and a file
server. Messages from untrusted devices, such as message 2 in the figure, are evaluated
against the WSBAC policy. For file accesses that are allowed, Polen forwards them to
the file server (as is the case for message 2 in the figure), otherwise, Polen responds
directly with a “permission denied” message.
4.3.4 Polen Speculation
Writes from an untrusted client station to files not included in a user’s WS are allowed by
Polen, but are not committed to the network file system. Instead, Polen holds these
writes aside by logging them in a vault area. This area is a stable storage location where
speculative writes can be sequestered from the network file system. Access to the vault
is reserved for Polen only. This partitioning of speculative writes from the network
file system provides safety for these writes, while denying visibility of the speculative
accesses for all other users. Speculative writes are visible to the users who issue them.
All user accesses flow through Polen, which exports per-user virtual namespaces to
the users. These namespaces are the union of the real file system merged with the
speculative operations performed by the user.
Polen allows speculative writes to data and meta-data to be performed by a user
from an untrusted device for two reasons. First, the user may wish to create new or
temporary files. If Polen limits writes to files within the user’s WS, it will not permit
this. Second, although Polex may have observed reads to a file and included the file
in the WS for reads, Polex may not have observed any writes by that user to that file.
Since it is possible the user may also have write permission, we allow these writes to
112
occur speculatively.
Figure 4.2 shows a speculative access as it traverses the network from an untrusted
device to a network file server (shown as message 3). When the message is intercepted
by Polen, it is logged and stored in the Polen vault area, which may reside on any
stable storage accessible to Polen.
Speculative writes may pose a problem in the cases of write-after-write and read-
after-write sharing between users. This problem is mitigated by two factors, though.
First, for typical deployments of network file systems, both types of sharing have been
found to be very low (between 0.9% and 0.6% of all file systems operations as reported
in [71, 72, 102]). Second, network file systems, such as NFS [43], in the absence of
locking, do not provide strong file consistency between users. They typically provide
close-to-open consistency where update propagation is only guaranteed at the time of
file closure. In any event, there are likely to be cases where update delays due to
speculation pose a problem between users sharing files. To handle these cases, we
extend sharing to speculative accesses through our speculation sharing and delegation
mechanism. We expect (and in fact show in our evaluation) write speculation to be the
exception and not the common case in practice. Further description of this mechanism
is in Section 4.4.2.
Reconciliation of speculative accesses occurs when a user returns to a trusted device
and resumes interacting with the network file system. At this point, Polen starts
reconciliation for speculative changes stored for the user in the vault area. Polen
allows speculative creates and writes to temporary files to be automatically committed
to the server once reconciliation begins, since they will not potentially destroy or modify
any existing data. We assume that all network file servers perform virus scanning for all
file writes before committing them, as this is common practice. In the event that virus
scanning is not performed at the server, automatic reconciliation can be completely
disabled.
All other speculative updates to existing files must be manually verified by the
user, before Polen will proceed to commit them. This may occur in a number of
ways, including a web-based interface or an automated email service. Once verified,
113
The primary components of Polex are shown. Included are the Extraction Handler, AccessContext (state store), and the View Handlers.
Figure 4.3: WSBAC Implementation – Polex Components
speculative updates are presented to the network file server as if issued by the user, and
reconciled by the system in a manner similar to the Coda File System [72].
4.4 Implementation
We have implemented both Polex and Polen by extending FileWall [95, 40], a network
file system middlebox that we developed in prior work. Using a middlebox permits
WSBAC enforcement without modifying the file system. However, WSBAC can also
be implemented without a network middlebox by suitably modifying the file system.
4.4.1 Implementation of Polex
In this section, we describe the implementation of our policy extraction agent. We have
two primary requirements in designing this system. First, it must run online in order to
continuously and automatically adapt to changes in users’ network file system working
sets. Second, it should be non-intrusive to both clients and servers. By requiring
no server modifications, Polex can be easily deployed without impact (in terms of
software maintenance, or performance effects) to the critical resource being monitored.
114
We further restrict the system to not require any software modifications to the clients.
For this system to be most useful, it must be deployable in any scenario, including
situations that involve legacy deployments and borrowed devices.
Polex implements a framework to extract approximations of user network file sys-
tem working sets, which form the basis of WSBAC. We built Polex as a network agent
that receives and processes copies of network file system messages to examine message
attributes and extract per-user working sets. Figure 4.2 shows how Polex is deployed
for a typical network file system infrastructure, where copies of network file system mes-
sages are forwarded to Polex by a cooperating network element (e.g., network switch
port mirroring, Polen, etc.) The remainder of this section describes the working set
extraction mechanism, the administration interface provided by Polex, and WSBAC
state maintenance.
Working Set Extraction
As shown in Figure 4.2, and 4.3, Polex extracts per-user working sets by observing the
network file system messages that flow between trusted devices and file servers. This
is accomplished by using semantic knowledge about the network file system protocol.
Since Polex can observe the servers’ responses to the clients’ requests, it can discover,
over time, the file permissions users have to various portions of the file system (files and
directories). Once discovered, these permissions are stored in a set of per-user compact
summary data structures (Bloom filters). Polex creates and maintains six Bloom filters
per user, three for file permissions (read, write, and execute) and three for directory
permissions (read, write, and execute). The Bloom filters comprise the WSBAC user
policy summaries and are stored on local persistent storage. Once generated, they are
held by Polex for later use in Polen.
Figure 4.3 shows how network file system messages are handled by Polex. Mes-
sages from trusted devices are processed by the Extraction Handler, which executes
the extraction algorithm. Once the handler has completed processing a message, it is
dropped. Any messages received by Polex are copies of messages either forwarded
by a network middlebox (such as Polen in Figure 4.2) or forwarded by some other
115
Subset of the Policy View Namespace (PVN). For each user (e.g., Bob), there are controland WS view namespaces.
Figure 4.4: Policy View Namespace (PVN) for WSBAC
network element (e.g., a network switch). In any case, we assume that Polex only
receives messages that originated from trusted devices.
Policy View Namespace (PVN)
Polex defines a virtual namespace, called the Policy View Namespace (PVN), for
WSBAC working set summary administration. It is an interface that provides views of
users’ effective network file system access control policies. Through the PVN, adminis-
trators can interact with Polex over the network file system interface using a familiar
set of tools. In fact, one of the main purposes of using the standard file system protocol
as the policy view interface was to enable building tools that could easily take advan-
tage of this well-known interface. Access to the PVN is restricted to administrators. In
a secure deployment, such access would occur over a secured private network, reserved
for this purpose.
The functionality of the PVN is similar to that of the Linux /proc file system. View
116
The primary components of Polen are shown. Included are the Enforcement Handler,Speculation Handler, User Policy Summaries (access context), and Vault Area.
Figure 4.5: WSBAC Implementation – Polen Components
Handlers are invoked at Polex on receiving file system requests for virtual objects (see
Figure 4.3). For read-only requests, for example, read, readdir, getattr, etc., the handlers
query the PVN state and generate the file contents dynamically. Write operations
update the PVN state and are used to modify the Polex and PVN configuration
parameters, or manually modify per-user working set summaries. Figure 4.4 shows an
example PVN for user Bob. There is a similar pair of namespaces for every other user
in the system. The figure shows the two primary components to Bob’s PVN: the control
namespace and the WS namespace.
Through the PVN control namespace, administrators can tailor view configurations
to meet their needs. Additionally, they can modify WS estimation parameters and
start/stop the WS estimation process. These tasks can be performed for individual
users (e.g., Bob in the figure) or globally for all users. All objects in the PVN control
namespace are virtual and there are no files (or directories) at the network file server
that stores the content of these objects. Instead, View Handlers (see Figure 4.3) are
invoked to handle accesses to virtual objects. The PVN WS namespace provides a view
of the real exported network file system namespace filtered by the user WS summary
permissions. The names for objects in the WS namespace are derived directly from the
files they represent in the observed network file system, but only the files and directories
117
that exist in a user’s estimated working set are visible in the WS namespace. The WS
namespace provides an interface for administrators to query and modify the effective
permission assignments for each of a user’s files and to manually add and remove files
from a user’s estimated working set.
State Maintenance
Polex maintains two different forms of persistent state. First, it maintains the system
configuration based on any parameter/control changes issued through the PVN. Second,
Polex stores the WSBAC per-user working set summaries extracted from the network
file system messages it observes. Keeping the summaries as persistent state is more
for convenience rather than a strict requirement. Since this state is built through
observation of network file system messages, it can be continuously regenerated over
time. The primary penalty, in the case of lost state, is the time that it takes to
regenerate that state.
4.4.2 Implementation of Polen
In this section, we describe the implementation of the policy enforcement agent. Polen
includes mechanisms for WSBAC policy enforcement, write speculation, speculation
sharing and delegation, and update reconciliation.
WSBAC Policy Enforcement
Polen operates on network file system messages as they are exchanged between clients
and servers, as shown in Figure 4.5. As messages are captured, they are handled by
Polen for WSBAC evaluation and enforcement. Polen only operates on messages
from untrusted devices (see Figure 4.2).
Messages from untrusted devices are passed to the Enforcement Handler (see Fig-
ure 4.5). This handler extracts network file system attributes from each message to
determine the file system operation (fop), file identifier (fileid), user identifier (uid),
and request identifier (reqid). The handler then retrieves the user’s working set pol-
icy summary from a local persistent state store using the user’s uid, and checks if the
118
fileid is included in the WS of this user with the necessary permission to perform the
requested operation fop. For reads, the network file system message will either be for-
warded to the file server (as in the figure) or Polen will generate a “permission denied”
response message and forward it to the client. For writes, the message will either be
forwarded to the file server or will be speculatively allowed.
Write Speculation
Whenever Polen encounters a write operation to a file from an untrusted device that
is not explicitly allowed based on the WSBAC evaluation, Polen handles it specula-
tively. Such file system updates are stored within a predefined vault area, located on
separate stable storage. This vault area is similar in spirit to the caching mechanism
of the Coda File System [72], but it does not reside on the client as a typical Coda
cache would. Polen includes an interface for a user to view her speculative updates
from the untrusted client station that performed them. This interface can be accessed
via the standard network file system protocol or via a web-based mechanism, and is
implemented by the Speculation Handler as shown in Figure 4.5.
The Speculation Namespace mechanism provides seamless access for untrusted client
stations to their state updates. It does so by overlaying a virtual namespace on top
of the real namespace exported by a file server. Any network file system message that
is allowed by the WSBAC policy is checked to determine if it contains a file operation
targeting a file that has been speculatively updated. This check is performed by using
the file identifier contained in the message to search the per-user speculation map. For
performance, the vault performs whole file caching, similar to the Coda File System,
maintaining a distinct version of all speculatively updated files. Speculative updates
are applied to this version. This has two benefits, first, it reduces the load on the file
server due to speculative updates, and second, it maintains to consistent versions of
a file (base and speculative). Any network file system message that performs a file
operation on a speculatively updated file is passed from the Enforcement Handler to
the Speculation Handler as shown in Figure 4.5.
The Speculation Handler performs two functions. The Speculation Handler responds
119
to the current untrusted device request as if it were the network file server. It does
this by fetching the required file system state from the network file server (using the
user’s credentials) and sequentially applying the speculative updates to the state as
necessary. In this fashion, the Speculation Handler can generate an updated version of
the file on demand for the user. Since the vault area performs whole file caching similar
to the Code File System, it only needs to fetch each file from the file server once, at the
time of first speculation. Should the operation fail, then a network file system error is
generated by Polen and forwarded to the untrusted device.
Reconciliation
Reconciliation must occur when a user has any outstanding speculative updates stored
for her by Polen in the vault area. During reconciliation, speculative updates must
first be verified by the user who issued them (or by a user’s delegate), before they will
be committed to the server. Such verification guarantees that any speculative updates
submitted by malware will be identified by the user prior to commit.
Users manage their speculative updates through the same interface (network file
system or web-based mechanisms) provided by Polen for write speculation. Through
this interface, a user (or administrator) can manually inspect her speculative updates
currently stored in the vault area, approve the updates to be committed to the file
server, and handle any exceptional conditions that arise. The granularity of the update
is per file, and a user can view the individual changes prior to approving or denying
them. Finally, Polex is able to notify the user of the existence of pending reconciliation
when the user starts accessing her files from a trusted system, once again. It can do
so by sending periodic emails to the user whenever it detects the occurrence of trusted
accesses from the user, and speculative updates are pending reconciliation.
Speculation Sharing and Delegation
As previously mentioned in Section 4.3.4, to support the existing sharing model common
to modern network file systems, we provide mechanisms to allow speculative updates
to be shared between users. The first mechanism has been discussed already. A user
120
who has performed a speculative update can directly commit those updates through
the Polen-provided interface. Once committed, they are available to all other users
immediately.
For more tightly coupled sharing situations, though, it might be tedious for each
user to manually commit changes to a small set of files. For this case, we allow a user
to share a portion of their speculative updates with other untrusted devices. Using the
Polen-provided interface, a user can directly specify, per file, other untrusted devices
that should have immediate visibility to her speculative updates. Under this sharing
model, users experience traditional close-to-open network file system semantics and
are not burdened with manually committing updates. In this case, the users’ updates
remain speculative and WSBAC protection holds.
For trusted devices to access speculative updates from untrusted devices, we provide
a delegation mechanism. The owner of the speculative updates can allow a user of a
trusted device to commit the updates to the shared files (through the Polen user
interface). This gives a user the ability to commit updates as if she was the update
owner. Finally, for frequent sharing between trusted and untrusted client stations,
we allow a trusted device to connect to the file server through the same path as an
untrusted device, to gain visibility to the speculative update similar to an untrusted
device.3 Although this places additional requirements on users in order for them to share
speculative files, it enforces clean separation between trusted and untrusted accesses.
It does expose a trade-off between usability/transparency for users and administrative
security requirements.
4.5 Evaluation
In this section, we present the evaluation of the WSBAC system. Our experimental
evaluation of WSBAC answers six questions:
• What are the processing time and storage costs to perform working set extraction?
3For the purposes of our research, we assume any trusted device that requires such access caneither connect through the secure VPN to be treated as an untrusted device, or may connectto the file server through the Polen path.
121
Size of Trace Time to Analyze State Size1 day 52 min 145MB (1.16MB per user)1 hour 3 min 145MB (1.16MB per user)
Table 4.1: Working Set Estimation Time and Storage Costs for WSBAC
• Are any network file system performance overheads imposed by working set ex-
traction?
• How accurate is WSBAC working set extraction?
• How sensitive to time is WSBAC working set extraction accuracy?
• How much speculation occurs during WSBAC enforcement?
• What are the network file system performance overheads imposed by WSBAC
enforcement?
In our experimental setup, all systems are Dell SMP systems with two 2.4 GHz Intel
P4 CPUs, and 3 GB of RAM. All systems run a Linux 2.6 kernel and are connected
using a Gigabit Ethernet switch. Polex is configured to listen to all NFS v3 requests
and responses. This is accomplished by enabling port monitoring on the switch. Polen
is configured to interpose on all NFS v3 requests and responses.
4.5.1 Evaluation of Polex
Time and Storage Costs
We measure the costs for Polex in terms of the time it takes to process the network
file system messages it receives, as well as the size of the state that must be stored to
maintain a fixed amount of history. To quantify these costs, we perform offline analysis
using a set of large file system traces provided by Harvard University [55]. These traces
represent a month of network file system usage from the EE/CS Department at Harvard
University.
Table 4.1 shows the results in terms of processing time and the size of the resulting
state, once processing has been completed. We measure these costs for trace samples
of size corresponding to one day and one hour. One day of traces represents 3.3 GB of
122
0
20
40
60
80
100
untar configure compile install remove overall
Tim
e (s
ec)
Benchmark Phase
NFSPOLEX
Figure 4.6: OpenSSH Compilation Results for WSBAC (Polex)
trace storage space corresponding to 6, 308, 023 NFS request/response pairs for a group
of approximately 250 users. To process 1 day took 52 mins and generated 145 MB
(1.16 MB per user on average) of state as history. This equates to an approximate time
compression factor of 96%. Since we utilize Bloom filters to store per-user working set
state, the storage costs remain fixed at approximately 145 MB regardless of trace size.
Therefore, we observe that Polex imposes negligible costs in terms of processing time
and state storage requirements.
Performance–Software Build Benchmark
In the following, we compare the performance of NFS with Polex extraction against
default Linux NFS for an OpenSSH build benchmark similar to a modified Andrew
Benchmark [64]. The approximate round-trip time between hosts in the experiment is
300 µs, which is typical for most LAN environments. We measure the time taken to
complete each of five phases (untar, configure, compile, install, and remove) and report
the results in Figure 4.6.
This figure shows the average time over five runs with a cold client cache for each
123
Average Error Rate Over-Estimation RateRun 1 1.08% 31.6%Run 2 0.76% 41.2%Run 3 1.02% 42.5%Run 4 0.79% 36.5%Run 5 0.97% 42.9%Avg 0.92% 38.9%
Table 4.2: Working Set Error and Over-Estimation Results for WSBAC
phase of the benchmark from left to right. The bars in each group are base NFS and
NFS with Polex. We observe that Polex imposes no overhead when compared to the
normal base NFS case. This is expected, since Polex does not interact directly with
the message flows between the network file system client and server. Instead, copies of
the messages are sent by the switch to Polex for processing. These findings serve to
validate our expectations.
4.5.2 Evaluation of Polen
Accuracy
A key factor in the utility of Polen is the accuracy with which the system operates.
The accuracy is presented as the ratio of the set of file permissions that we approximate
incorrectly to the total that we observe (including correctly approximated permissions).
This provides the error or false positive rate for Polen. To quantify the accuracy, we
perform offline analysis using the Harvard traces.
To determine accuracy using the network file system traces, we choose two consec-
utive days worth of trace data. We randomly select ten users from those in the traces.
We use the traces from the first day to perform per-user working set extraction using
the Polex algorithm. Then we run a test against the WS summaries using the traces
from the second day, and measure the number of errors. An error is generated by a
file or directory access, if the access is to a file (or directory) for which the user does
not have the appropriate permission to execute the specific access, according to the
user’s WS summary. These errors represent file access attempts by the user that would
be denied by the WSBAC system, but allowed by the network file server. We repeat
124
Day 2 Day 3 Day 4 Day 5 Day 6User 1 0.26% 0.03% 0.02% 0.01% 0.1%User 2 0.31% 4.4% 0% 3.3% 0.27%User 3 0.39% 0.36% 0.82% 2.51% 0.61%User 4 0.48% 1.82% 0.55% 0.66% 0.11%User 5 0.18% 0.28% 0.18% 0.34% 0.27%Avg 0.32% 1.38% 0.31% 1.36% 0.27%
Table 4.3: Working Set Sensitivity Results for WSBAC
this experiment five times using a different two days worth of trace data and randomly
choosing a new set of ten users each time. The results are reported in Table 4.2.
The table shows the average error rate for each of the five runs. The maximum
error rate is 1.08%, the minimum is 0.76%, and the total average is 0.92%. From these
results, we observe that the average per-user accuracy is high (low error rates), and this
confirms that WSBAC is not overly restrictive.
We further assess the rate at which an approximated working set is overly permissive.
We measure this as the percentage of the estimated working set that is included during
the estimation phase, but never accessed in the testing phase. These results are reported
in the third column of Table 4.2. As shown in the table, the maximum over-estimation
rate is 42.9%, the minimum is 31.6%, and the average is 38.9%. Although WSBAC
is more restrictive than the standard network file system discretionary access control
system, the results of this experiment show that there is still room for improvement.
Sensitivity
To understand how frequently a user’s working set estimate must be updated, we per-
form a sensitivity analysis on the working set accuracy. For this experiment, we perform
offline analysis similar to the accuracy measurements. This time we choose six consec-
utive days worth of traces. We use the traces from the first day to perform per-user
working set extraction and test with the remaining five days worth of traces. Accuracy
measurements are determined as before, and are reported in Table 4.3.
The table shows the average error rate for five randomly selected users over the five
days following the working set extraction day. From these results, we observe that the
125
average per-user accuracy remains fairly stable over a reasonable period of time. Users
1 and 5 are very stable across the five days, while users 3 and 4 are stable four out of
five days. Finally, user 2 is the least stable fluctuating every other day, which possibly
indicates that a multi-day extraction period might benefit some users. In general, the
accuracy results are very promising, given the low error rates across the board.
Speculation
Since the amount of speculative accesses a user performs is related to the number of
updates that must be validated by the user when they return to a trusted device,
we measure the average rate of speculation for ten randomly chosen users from the
traces. For this experiment, the average speculation rate is 1.44%, the maximum is
2.4%, and the minimum is 0.018%. These results are promising since they imply a low
burden on the average user with respect to the amount of manual validation that must
be performed for speculative updates. Even for heavy users (500 or more requests per
day), the results imply relatively low levels of manual intervention (7 average speculative
requests per day). From these results, we conclude that WSBAC is highly automated,
and does not require an administrator or the end-user to laboriously configure additional
access control policies.
Performance–Microbenchmark
To study the fine-grained overhead of Polen with respect to the network file system, we
utilize our own microbenchmark. This benchmark is an NFS client that issues requests
without relying on the client file system interface. Using this benchmark eliminates
any noise due to the client buffer cache and allows fine-grained measurements to be
collected.
We present the operation latency of the default NFS protocol, as a baseline. Fig-
ure 4.7 shows the client observed latency for the most common NFS operations, as
reported by various file system workload studies [55]. In the figure, each group of bars
has four members, NFS and Polen in a minimal configuration, and NFS and Polen
in a typical LAN configuration. The average round-trip time is 30 µs for the minimal
126
0
100
200
300
400
500
600
700
800
getattr lookup access read write create
Res
pons
e La
tenc
y (u
sec)
NFS-minimalPOLEN-minimal
NFS-LANPOLEN-LAN
Figure 4.7: Microbenchmark Results for WSBAC (Polen)
configuration and 300 µs for the LAN configuration. The latency measurement for
the minimal configuration represents the average latency measured through a 1 Gbps
network switch. Each bar presents the average response latency over 1000 instances.
We observe that Polen imposes modest overhead when compared to the NFS case
for the minimal configuration. The largest overhead measured for the minimal case was
40 µs, which represents a 15% performance degradation. Since typical LAN round-trip
times are larger than 30 µs, this represents the worst case performance for our system.
Very little of the Polen processing time is hidden by the network latency. As we
introduce delay in the network, most if not all of the Polen processing time is hidden
due to the relative time of processing to network latency. In fact, at and beyond the
300 µs mark (as shown in the figure as the LAN bars) the relative performance between
base NFS and Polen is within 10 µs on average which corresponds to, at most, a 2%
overhead. For WAN users, the situation is even better (e.g., a remote access situation).
Since the typically observed network latencies in a WAN deployment are between 15 ms
- 30 ms, we expect there to be no perceived performance impact on WAN users due to
this system.
127
0
20
40
60
80
100
120
140
160
untar configure compile install remove overall
Tim
e (s
ec)
Benchmark Phase
NFSPOLEN
Figure 4.8: OpenSSH Compilation Results for WSBAC (Polen)
Performance–Software Build Benchmark
In the following, we compare the performance of NFS with Polen WSBAC enforcement
against the default NFS for an OpenSSH build benchmark similar to a modified Andrew
Benchmark [64]. We measure the time taken to complete each of five phases (untar,
configure, compile, install, and remove). To simulate the LAN conditions a typical user
would experience, we introduce additional delay in the network, such that we increase
the approximate round-trip time between hosts in the experiment to 300 µs. The results
are reported in Figure 4.8.
This figure shows the average time over five runs with a cold client cache for each
phase of the benchmark from left to right. The bars in each group are base NFS and
NFS with Polen. We observe that Polen imposes very low overheads (less than 2%
in all cases) when compared to the normal NFS case for remote users over a LAN. We
conclude from these and the microbenchmark results, presented earlier, that Polen
introduces no perceived performance overheads on network file system users.
128
4.6 Discussion
4.6.1 Network File System Traces
Although we utilize a well-understood set of network file system traces in our evaluation,
they unfortunately do not allow us to fully evaluate the effectiveness of WSBAC. In
particular, since the traces do not identify the types and capabilities of client devices,
(i.e., trusted vs. untrusted), there are a number of dimensions that we cannot assess
quantitatively in our evaluation. Although it is possible for differing capabilities in a
user’s device to affect how she accesses her file system data, it remains to determine
whether it also affects which data items she will access.
4.6.2 Working Set Reinforcement
One of the assumptions in our design of the WSBAC system has been that a user’s
network file system working set varies slowly over time. Although our accuracy re-
sults support this assumption, continuous and automatic WS adaptation must also
handle WSs with high variability over time. Therefore, it is important for the extrac-
tion process to include automatic and continuous reinforcement. Although our current
implementation does not provide support for reinforcement, it does not preclude it
either.
One approach to include reinforcement support in the WSBAC system is to use a
combination of Bloomier [46] and Counting [57] filters rather than traditional Bloom
filters. Bloomier filters allow for the storage of data with the keys. In these, we could
also store a timestamp that reflects the last access for the associated file identifier.
Counting filters allow for key deletions along with additions. Using these two filters
together, we add file identifiers to each (the Bloomier also includes the timestamps). A
file is considered to be in a user’s WS when it is in both filters and passes a timestamp
check. This approach allows for files to be directly removed from the WS (through
deletion from the Counting filter), and for files to be aged from the WS (through the
use of the timestamps in the Bloomier filter).
An alternate approach to include reinforcement support in the WSBAC system is
129
to maintain a more complex data structure on Polex for the purpose of supporting
reinforcement. Our current implementation assumes the use of Bloom filters at both of
the network agents (Polex and Polen). It is equally plausible to expand the amount
of state we are willing to store at Polex. With this additional state, Polex could
generate frequent, reinforced, updates for Polen to utilize. This exposes a possible
trade-off between accuracy of WS estimation and the cost in terms of state size that
must be kept at Polex.
4.6.3 File System Semantics with Speculation
It is important to point out that in certain situations where there is a large amount
of write sharing for a file, it is possible, perhaps even likely, that a remote user’s
speculative updates to such a file will become inconsistent before they can return to
a trusted location to commit these updates. The speculation mechanism in Polen is
best-effort and only applies to writes for files not in a user’s working set. A user who
anticipates such problems with certain files can access these files regularly from a trusted
client to ensure that the popular file is included in the user’s WS. It is also possible for
the user to have an administrator manually intervene and assist them directly.
One approach to avoid the problem of frequent write sharing is to employ versioning
file system support on the protected network file servers. With this support, Polen
would be able to access a version of the file that is consistent with the speculative
updates, and apply those updates to the file. It is a policy decision whether this
version should be brought forward and committed to the network file system (in effect
rolling back other users’ changes), but with this extension, a user would at least be
able to access a consistent version that included her updates. The consistency model
induced by this approach would be similar to close-to-open consistency in the absence
of mandatory file locking. The version of the file that is visible to all users is the one
last committed by any user.
It is also important to point out another area where speculation alters network file
system semantics. Although most file and directory meta-data can be altered by users,
the last access time for a file is managed directly by the file server and cannot be altered
130
by a user. Speculation introduces a slight change in the semantics, since the time a
user updates a file will differ, possibly by a large margin, from the time the updates
are committed to the server by Polen. For example, a user may speculatively update
a file at 12 AM at night, but these updates will not reach the file server until 8 AM in
the morning when the user is accessing the file server from a trusted device. Typically,
the last access time for a file would reflect the time the updates were sent to the server
by any client. In the speculative case, the last access time for a file actually reflects
the time of reconciliation and update commit from Polen. It is not clear how this
might affect the day-to-day operation of users or the file server, but the issue cannot be
addressed without extending network file systems to add support for a client to alter
the last access time.
4.6.4 Scaling, Availability, and Usability
One aspect of Polen that was not explored in this research is scalability. For general
deployment of the Polen network agent, it must be able to scale to many clients and
many servers. Alternately, since Polex operates outside of the critical performance
path of network file systems, scalability is not as large an issue. Though, timely gener-
ation of the per-user working set summaries is still important, so the issue cannot be
ignored completely.
To reduce the load on the Polen network agent, it is possible to deploy software
agents to clients that perform similar tasks. Even with these trusted client agents, the
Polen network agent would still be required to guarantee WSBAC enforcement for
trusted devices, or in case any user attempted to circumvent the access control system
by disabling their client agent. The client agents provide a way to offload WSBAC
enforcement for well-behaving users, which would reduce the load on the Polen network
agent. Allowing a client agent to enforce the WSBAC policy also reduces the latency of
WSBAC policy decisions at the client, such that denied or speculative operations could
occur more rapidly (especially for a typical WAN-based remote access scenario).
A second aspect of the system left unexplored is availability. The Polen prototype
was implemented as a single network middlebox, and so it represents a single point
131
of failure. Therefore, we should also consider ways to improve the robustness of the
architecture. For this, we propose a traditional distributed active-passive configuration
with failover. Although it would be more beneficial to propose an active-active config-
uration to more efficiently utilize the hardware resources, there are potential challenges
that must be overcome due to the speculation mechanism and the state sharing that
would occur between active peer Polen elements. It is possible that a shared locking
mechanism would suffice to ensure consistent access to speculative state, but we have
not explored this at this time.
Finally, it is unclear how WSBAC will impact the usability of network file systems.
Specifically, there are two aspects that we left unexplored: (i) the effects of WSBAC on
access transparency and (ii) the effects of speculation and reconciliation on file sharing
between users. The first aspect deals with the perceptions of users on their access rights
as they transition between trusted and untrusted scenarios. As they do so, they will
be subject to WSBAC restrictions based upon the trustworthiness of their accesses.
The second aspect involves the magnitude of the burden (or reduced transparency) of
sharing conditions between users. The open question is how much WSBAC mechanisms
will limit or impact such scenarios.
4.7 Related Work
As mentioned previously, the WSBAC vault is similar in spirit to the caching mechanism
of the Coda File System [72]. The WSBAC vault area also draws on some of Coda’s
design features, specifically in the areas of caching and delayed reconciliation of file
updates. The remainder of this section describes the other work related to WSBAC,
which we divide into two categories: (i) Policy Extraction and Inference, and (ii)
Context-Aware Access Control.
4.7.1 Policy Extraction and Inference
Role-Based Access Control (RBAC) [65, 58] has been proposed as a standard for net-
work file system access control. Although there are many attractive features in favor
132
of RBAC, legacy installations have to handle the onerous task of migrating their ex-
isting access control information (e.g., ACLs, access permissions, etc.) to Roles and
Object Permission Matrices. For large installations, this task is a major road block
towards acceptance of RBAC. Kuhlmann et al. [74] utilize Data Mining techniques to
address this problem automatically, by learning common patterns in the existing ACLs
or permissions lists in order to automatically define the roles in the RBAC system
and place the appropriate users into these roles. In this fashion, they are able to ex-
tract the RBAC policy principles from existing legacy data. There has also been work
to infer access control properties specified in the XACML language [33, 78], to infer
and confine process privileges through the observation of process syscall behavior [82],
and to automatically generate SELinux policies based on observing dynamic program
behavior [99].
Law Governed Interaction (LGI) [81] proposes a distributed policy definition and
enforcement framework for heterogeneous distributed systems. He et al. use the LGI
framework to implement RBAC for network file systems [63]. However, their system re-
quires the server to execute an access control agent to hook into the security framework.
It also requires specialized user agents at each client to communicate with the access
control system. Their server modifications and client agents may limit the deployability
of their system
Although there has been substantial work in the general area of firewall and packet
filter analysis, there are a number of works related specifically to firewall policy infer-
ence [62, 109]. Tongaonkar et al. [109], describe a method to infer high-level policies
from low level firewall rule sets. They describe a method to generate a flattened rule set
(high-level rules) by first generating an automaton based on the low-level rules. Golnabi
et al. [62] use data mining techniques to learn a set of firewall rules from packet logs,
based on packet frequencies. These observed rules are used to analyze the existing
rule set configurations for firewalls as an aid to determine a new, more efficient, set of
firewall rules.
Our work shares a similar goal to these works, in that we are attempting to deter-
mine efficient representations of the access control policies. We differ since we operate
133
on network file systems, rather than firewalls. Additionally, we are not attempting to
generate static rules sets, but are approximating the set of resources (files and direc-
tories) that a user needs to access in the near future based on their past accesses. It
is not clear that the working set approach generalizes to network resources other than
network file systems.
Finally, in the general area of policy inference and control, there has been work in
using gray-box techniques to monitor and control the enforcement of operating systems
policies (e.g., buffer cache, memory access control, file layout, etc.) [35]. The general
technique is to either understand the policy under control a priori, or to infer it through
external (to the system) observation. Additionally, it is acceptable to perturb the
system under observation, in order to aid the process or to actually enact control over
system policies. Our goal differs from typical gray-box techniques in that we do not
assume a priori to understand the effective access control policy, instead we determine
the WSBAC policy automatically per-user.
4.7.2 Context-Aware Access Control
Substantial work has been performed in the area of context-aware access control. The
concept has been applied in mobile and pervasive computing to provide secure col-
laborations [110] for wireless and mobile devices, to provide anonymous context-aware
access control for ubiquitous services [114], for ubiquitous service provisioning [53], and
adaptive context-aware access control for ad-hoc networks [86]. A number of works
have been proposed in the area of context-aware access control for web services [68, 39].
These works all attempt to include context in the access control decision-making pro-
cess, in some cases for mobile computing. Our work shares this general approach, but
we utilize different context and apply it in a different manner to a different domain.
First, we leverage a user’s network file system access behavior to further restrict their
access to those files that they are actually using. Second, we only apply this restriction
for user access from untrusted client stations.
134
4.8 Summary
In this chapter, we presented the Working Set-Based Access Control scheme for network
file systems. WSBAC is an access control technique that extracts per-user working sets
through the observation of users’ network file system accesses. We also presented the
design and implementation of our WSBAC system, which is composed of two network
agents: Polex and Polen. Polex monitors network file system accesses for users of
trusted devices, extracts per-user working sets, and produces compact per-user working
set summaries. The summaries are used by Polen to enforce WSBAC for user accesses
from untrusted client stations (e.g., opportunistically borrowed devices). We evaluated
our system using a set of real-world traces and our experiments validate our approach.
The average accuracy for working set estimation is high (low error rates) and the
costs in terms of Polex processing time and storage requirements are low. Additional
experiments show that Polex is completely non-intrusive to the critical performance
path of the trusted network file system clients. Finally, we measured the performance
overheads of Polen, which were shown to be very low for typical LAN deployments
and completely hidden for typical WAN deployment scenarios.
135
Chapter 5
Conclusion
In this dissertation, we identified challenges to user data access for a class of mobile com-
puting approaches we described as opportunistic mobile computing. We presented novel
approaches to address these challenges and demonstrated their effectiveness through
extensive experimentation. To improve the performance of data access for opportunis-
tic mobile computing, we introduced the concept of safe borrowing of local storage,
which we prototyped as the TransPart system. To improve the availability of data
access for opportunistic mobile computing, we introduced the concept of a self-cleaning
portable cache, which we prototyped as the Horatio system. Finally, to improve the
security of data access for opportunistic mobile computing, we introduced the Working
Set-Based Access Control (WSBAC) scheme, which applies the concept of the working
set to distributed file system access control.
The main conclusion of this research is that opportunistic mobile computing can be
improved to the point of providing a satisfactory user experience. Opportunistic mo-
bile computing represents an important step towards the ideal case, i.e., carry nothing
mobile computing that perfectly recreates the laptop experience in both accuracy and
performance. To go a step closer requires removing assumptions made about portable
storage performance, network performance and availability, and the trustworthiness of
borrowed hardware. These assumptions do not hold in the real world, and once re-
moved expose critical challenges to the usability of the opportunistic mobile computing
approaches.
Central to personal computing is that users have safe and efficient access to their
data (i.e., files, folders, applications, and preferences). Opportunistic mobile computing
does not alter this fact. Though users are free to borrow available hardware, at their
136
present site, they cannot simply borrow their data. It is the requirements of safety and
efficiency of data access combined with the reality of present-day computing technology
“in the wild” that motivates the need for the improvements along the dimensions of
performance, availability, and security, which we have presented in this dissertation.
Along the way, we have described the state-of-the-art in the field of mobile comput-
ing, and offered a taxonomy, which characterizes each approach according to the level of
opportunism inherent in it. The approaches vary from those that are not opportunistic
at all to those that are perfectly opportunistic. We also presented a set of criteria upon
which to evaluate the variety of approaches, and applied them to each taxonomic class.
The two most opportunistic classes, VM on USB Device and VM Delivered over
the Internet both represent approaches that encapsulate a user’s personal computing
environment using virtual machine technology (VMs). The two classes differ in the
mechanisms used to enable VM-based mobility. The VM on USB Device approach
relies on the user to carry a small, portable storage device from site to site. Since
VM execution performance is directly affected by the performance of the underlying
storage device, this approach is challenged by the poor performance characteristics
of small and cheap, portable storage devices. The VM Delivered over the Internet
approach critically relies on the network. In the absence of Internet connectivity or
adequate network bandwidth, this approach is challenged by poor availability. Finally,
in both approaches the user can never fully trust the borrowed hardware. Given the
prevalence of distributed file systems, local trust issues can impact remotely stored
data, for example, due to malware or malicious hardware on the borrowed PC.
To address the challenge in performance, we introduced the concept of safe borrowing
of local storage and leveraged this concept in a prototype system called TransPart. This
system identifies and aggregates the free disk blocks of the borrowed computer’s internal
disk to construct a virtual storage device. TransPart uses this virtual device as a means
to providing higher performing storage for a guest VM. An additional goal of the safe
borrowing concept is to ensure bilateral protection between the VM and borrowed PC by
isolating their disk accesses. As long as the integrity of the the USB device is preserved
(i.e., it is not modified), the integrity of its virtual storage device is also preserved.
137
Hence, the privacy and integrity of data in the non-free parts of the internal disk are
also preserved. Software running within a VM (malicious or not) cannot view or modify
the non-free parts of the internal disk. At the same time, all data stored on the virtual
storage device can be encrypted to preserve the confidentiality of the VM state. By
using the free space of the higher-performing local storage of borrowed hardware, the
speed at which performance-critical operations can be completed is increased, improving
the user experience during all session lifecycle phases. Our experimental evaluation
confirmed that the TransPart approach can result in significant user-visible performance
improvements. The results showed a benefit due to TransPart of up to a factor of
three improvement for small file workloads, up to a factor of ten improvements in
application launch latency and sequential writes, and up to a factor of four improvement
in sequential read workloads. Finally, even when the additional costs at startup and
shutdown were factored in, the results showed a net benefit to the user with TransPart.
To overcome the challenge in availability, we introduced the concept of a self-cleaning
portable cache, and instantiated this concept in a prototype system called Horatio.
Horatio turns normal smart phones into trusted personal assistants that serve as local
self-cleaning, read-through, write-back caches of user data. We leveraged smart phone
technology, in building Horatio, since it is portable, “light-weight”, has internal storage,
and offers multiple modes of connectivity. With Horatio, a user can suspend her session
and check in her VM state to the smart phone rather than directly to the VM state
server; similarly, she can resume from the smart phone. Even when Internet connectivity
is poor, the physical proximity of a user’s smart phone to a borrowed client station
ensures good connectivity between them. To reduce device vulnerability, the portable
cache opportunistically uses cellular, WiFi, or other networking technology to self-
clean; that is to asynchronously propagate modified VM state to VM state servers
while users are in transit. This self-cleaning aspect of Horatio distinguishes it from
VM on USB Device approaches that rely solely on passive USB storage, and are hence
vulnerable to device loss or damage. Our experimental evaluation showed that Horatio
reduced resume and suspend latencies by up to 98% and 97%, respectively. While the
performance of Horatio on existing phones was adequate, our experiments also showed
138
that improvements in the phones’ protocol stacks and software environments could
further improve Horatio’s performance by an order of magnitude.
To overcome the challenge in security, we applied the concept of working sets to
access control, specifically in the context of remote user data access to distributed file
system within trusted corporate intranets. Our solution is called Working Set Based
Access Control (WSBAC). WSBAC observes and extracts working sets for users when
they access files from trusted corporate devices and uses the working sets to restrict
user file accesses from untrusted (e.g., borrowed) devices. Since a user will tend to
access a file that she has recently accessed, using the working set does not overly
restrict file accesses, while malware accesses to the file system typically exhibit no such
access patterns. This novel access control scheme improves the security of user data
access under opportunistic mobile computing conditions by minimizing the risks to
the confidentiality and integrity of remote data, restricting user data access to those
items a mobile individual is likely to want to access in the near future. Damage caused
by malware is thus restricted to a user’s working set. Our experimental evaluation
using a set of real-world traces demonstrated that the average accuracy for working set
estimation is high (less than 1% average error rate) and the costs in terms of processing
time and storage requirements are low. Finally, performance overheads of enforcement
were shown to be very low for typical LAN deployments (10 µs) and completely hidden
for typical WAN deployment scenarios.
5.1 Future Work
Present approaches to opportunistic mobile computing are enabled by virtual machine
mobility. To increase the mobility of a user, these approaches adapt the location of ex-
ecution for a mobile user’s personal computing environment by weakening the binding
between the personal computing environment and the hardware on which it executes.
The contributions of this dissertation have added a further level of adaptability to
opportunistic mobile computing. TransPart incorporates a sense of transience to per-
sistent storage, allowing the location of VM state storage to adapt to match the location
139
of execution. Horatio provides an alternative adaptive path through which to propa-
gate VM state updates back to the primary replica server. Finally, WSBAC adapts the
restrictiveness of distributed file system security to better match the client environment
from which remote file servers are accessed.
In summary, two trends have at least in part motivated the work of this dissertation:
the increased prevalence of VM and user mobility. As these trends continue along their
present path we envision a number of possible research directions and challenges, beyond
those included in this dissertation. We describe them in this section.
5.1.1 Seamless Continuity of Mobile Sessions
In this dissertation, we have focused on a model of opportunistic computing that emu-
lated the laptop paradigm; one in which users suspend the execution of their personal
computing environment when they are about to leave a site and resume it at the next
site. This model assumes that a user will not wish to continue interacting with her per-
sonal computing environment while in transit between sites. In part, this assumption is
due to the limited availability of cost-effective, high-performance wireless Internet con-
nectivity. As such connectivity continues to evolve, mobile users will start to find that
good connectivity is the rule rather than the exception. Also, such good connectivity
will foster broader adoption of applications that can benefit from continuous connec-
tivity. For example, online gaming, mobile video communications, streaming video and
audio applications, etc.
Under the assumption of continuous connectivity, the cycle of suspend and resume
introduces a noticeable point of transition for a user. For example, a user may be
working on her home PC in numerous applications (e.g., Internet games, video chat,
web applications, etc.) Then, when she wishes to move to a new site, she must end or
pause all of her application sessions, suspend her VM and save the VM updates (either to
her portable USB device or to her VM state server). Once saved, she can leave the site.
Of course, at this point she could resume her personal computing environment on her
laptop, should she have good wireless connectivity. Once her VM has been resumed, she
now needs to resume all of her applications again. Even with continuous connectivity,
140
the user must endure this cycle of suspend and resume, each time she transitions from
one device to the next. Moreover, she also relies on her various applications to support
this mode of operation.
One goal of mobile computing should be to improving the user experience by pro-
viding the impression of seamlessness. That is moving from one device to the next
should not be obvious; rather it should be fluid. This model introduces a number of
difficult challenges to be addressed. Take a simple example of migrating a personal
computing session from a desktop PC to a laptop. Unless the two hardware platforms
are nearly identical, there will be issues brought about by the heterogeneity of these
devices. Different generations of processors support different ISAs. Also, migrating live
network connections is not trivial, especially when the source and target devices reside
on different network segments. At the application layer, such transference must handle
end-to-end session semantics properly. These are just a few of the potential challenges
to be faced in building such systems.
Work has been done to address some of these challenges within different contexts,
but existing session migration solutions are not enough. Solutions have been proposed
to support network connection endpoint migration, such as I-TCP [36]. Sultan et
al. [103] proposed a session migration technique, called Service Continuations, as a
reliability approach for Internet services. Live VM migration techniques, such as by
Clark et al. [49], have also been proposed. Finally, as mentioned numerous times in this
dissertation, the Internet Suspend/ResumeR© (ISR) system [73] was the first to propose
using VMs to encapsulate personal computing environments for mobile computing.
None of the prior work in the area adequately addresses the new set of challenges
brought about by the goal of providing the perception of seamlessness in mobility.
Moving between similar devices is challenging enough, but the situation is made worse
as we start to increase the diversity of devices included (e.g., desktops, laptops, tablets,
smart phones, etc.) Not only are the execution environments different, but now we start
to introduce differences in the user interface devices, such as display size and layout,
and input devices. Moreover, the same application may actually have a UI tailored to
specific devices. Therefore, we also have to deal with programmability and application
141
portability challenges to support such session transfers. When we can overcome these
and possibly other challenges user mobility may no longer constrain computational
capabilities and vice versa.
5.1.2 Safe Borrowing as a Storage Primitive
With TransPart, we introduced the concept of safe borrowing of free disk blocks in the
context of opportunistic mobile computing. We also believe that the safe borrowing
concept has broader application and can be extended beyond the mobile computing
domain.
For example, one possible use of safe borrowing is in the context of VM server farms,
as an efficient mechanism for transient VM provisioning. Today, as virtual servers (i.e.,
servers executing within VMs) become more densely concentrated on individual high-
end hardware platforms, maintenance of the hardware becomes a difficult task. The
criticality of a specific piece of hardware is multiplied by the number of critical virtual
servers that must maintain high availability. This poses a particularly onerous task for
administrators as they attempt to schedule downtime for each individual virtual server
in order to perform maintenance on the underlying hardware. Allowing a virtual server
to become transient, temporarily move to another existing hardware platform, and share
all existing resources by borrowing free disk blocks from existing permanent virtual
server residents has the potential to reduce all of the overheads originally introduced
by the VM migration model at scale. Implementing this requires a relaxation of one
of the design constraints introduced earlier, though, since under this context multiple
concurrently executing guest VMs will need to share access to the same set of free
blocks.
A broader question motivated by this example is how to support such transience
in general. TransPart introduces the safe borrowing primitive within the VMM, but
this does not preclude the primitive from existing in other locations. It would also
be possible to introduce this primitive as an operating system abstraction or perhaps
directly within the disk interface. It is not immediately obvious which position, if any,
provides the best position for the safe borrowing primitive. This requires thorough
142
exploration of the design space to understand the trade-offs that may exist based on
position. For example, moving from the VMM to the disk simplifies some aspects of the
design, since the disk continuously receives all requests. Although the recent addition
of the ATA TRIM command exposes some file system semantics to the disk, placing
the transient borrowing primitives within the disk interface is still challenging since it
requires careful consideration of precisely which additional semantics would be required
to support it.
5.1.3 Closing Remarks
In closing, this dissertation has put forth the claim that opportunistic mobile comput-
ing can be achieved if critical challenges in the performance, availability, and security of
user data access could be solved. To address these challenges we have introduced three
concepts: (i) safe borrowing of free disk blocks, (ii) self-cleaning portable caches, and
(iii) Working Set Based Access Control. This claim has been supported by the design,
implementation, and prototype evaluation of three independent systems (TransPart,
Horatio, and Polex/Polen) based on the concepts introduced. Each system demon-
strated that the necessary improvements in the performance, availability, and security
of user data access could be achieved, and along with the results of our evaluations has
validated the central claim of this dissertation.
In the future we anticipate the parallel trends of VM and user mobility to con-
tinue to increase, and we believe that there will be ample opportunity to explore new
directions for research and to address the associated challenges. Such directions will
likely start to blur the traditional boundaries that have existed between personal and
data center computing as the scope of what computing hardware users can leverage
opportunistically expands to encompass more than what is locally available. Going
forward, we have to look to alter the definition of the personal computing paradigm
to include more than smart phones, tablets, and PCs. Future challenges will include
marshaling the vast resources of the cloud (and beyond) in ways the average user can
easily leverage.
143
References
[1] Linux Device-Mapper. Device-Mapper Resource Page. http://sources.redhat.com/dm/, 2001.
[2] Linux-NTFS Project. Linux-NTFS. http://www.linux-ntfs.org/, 2007.
[3] LVM2. LVM2 Resource Page. http://sourceware.org/lvm2/, 2008.
[4] Nokia Energy Profiler home page. http://www.forum.nokia.com/Resources_and_Information/Explore/Development_Process_and_User_Experience/Power_Management/Nokia_Energy_Profiler_Quick_Start.xhtml, 2008.
[5] MojoPac home page. http://www.mojopac.com, 2009.
[6] SanDisk U3 home page. http://u3.sandisk.com, 2009.
[7] Buggy McAfee update whacks Windows XP PCs - CNN.com. http://www.cnn.com/2010/TECH/04/22/cnet.mcafee.antivirus.bug/index.html, 2010.
[8] Ceedo home page. http://www.ceedo.com, 2010.
[9] dm-crypt. dm-crypt: a device-mapper crypto target. http://www.saout.de/misc/dm-crypt/, 2010.
[10] Facebook home page. http://www.facebook.com, 2010.
[11] Google Storage for Devlopers home page. http://code.google.com/apis/storage, 2010.
[12] GoToMyPC home page. http://www.gotomypc.com, 2010.
[13] iomega v.Clone home page. http://protection-suite.iomega-web.com/vclone, 2010.
[14] KVM home page. http://www.linux-kvm.org/page/Main_Page, 2010.
[15] MySpace home page. http://www.myspace.com, 2010.
[16] SalesForce home page. https://www.salesforce.com, 2010.
[17] TrueCrypt. Free open-source disk encryption software for Windows 7/Vista/XP,Mac OS X, and Linux. http://www.truecrypt.org/, 2010.
[18] Twitter home page. http://twitter.com, 2010.
[19] TwitterAmazon Elastic Compute Cloud (Amazon EC2) home page. http://aws.amazon.com/ec2, 2010.
144
[20] vDesk by RingCube home page. http://www.ringcube.com/products/vdesk/features.html, 2010.
[21] VirtualBox home page. http://www.virtualbox.org, 2010.
[22] VMware home page. http://www.vmware.com, 2010.
[23] VMware ThinApp home page. http://www.vmware.com/products/thinapp,2010.
[24] Xen home page. http://www.xen.org, 2010.
[25] YUM - Yellowdog Updater Modified. YUM Package Manager Project Home Page.http://yum.baseurl.org, 2010.
[26] Citrix XenDesktop. http://www.citrix.com/lang/English/home.asp, 2011.
[27] Intel Wired for Management Technology Specifications page. http://www.intel.com/design/archives/wfm, 2011.
[28] Microsoft SMB Protocol and CIFS Protocol Overview. Microsoft. 2011-01-27. Retrieved 2011-02-21. http://msdn.microsoft.com/en-us/library/aa365233(VS.85).aspx, 2011.
[29] RSA Security Inc. RSA SecurID Authenticators web page. http://www.rsasecurity.com, 2011.
[30] Simple Distributed Security Infrastructure (SDSI) web page. http://groups.csail.mit.edu/cis/sdsi.html, 2011.
[31] Sun Ray Desktop. http://www.sun.com/software/index.jsp?cat=Desktop&tab=3&subcat=Sun%20Ray%20Clients, 2011.
[32] Virtual Network Computing. http://www.realvnc.com/, 2011.
[33] Anderson, A. XACML Profile for Role Based Access Control (RBAC). OASISAccess Control TC Committee Draft 1 (2004).
[34] Arbaugh, W. A., Farber, D. J., and Smith, J. M. A secure and reliablebootstrap architecture. In SP ’97: Proceedings of the 1997 IEEE Symposium onSecurity and Privacy (Oakland, CA, 1997).
[35] Arpaci-Dusseau, A. C., and Arpaci-Dusseau, R. H. Information and con-trol in gray-box systems. In Proceedings of the Eighteenth ACM Symposium onOperating Systems Principles (2001), SOSP ’01.
[36] Bakre, A., and Badrinath, B. R. I-TCP: indirect TCP for mobile hosts.In Proceedings of the 15th International Conference on Distributed ComputingSystems (1995), ICDCS ’95.
[37] Baratto, R. A., Kim, L. N., and Nieh, J. THINC: a virtual display architec-ture for thin-client computing. In Proceedings of the Twentieth ACM Symposiumon Operating Systems Principles (Brighton, United Kingdom, 2005), SOSP ’05.
145
[38] Beck, M., Moore, T., Plank, J.S. An End-to-End Approach to GloballyScalable Network Storage. In Proceedings of the ACM SIGCOMM Conference(Pittsburgh, PA, August 2002), SIGCOMM ’02.
[39] Bhatti, R., Bertino, E., and Ghafoor, A. A trust-based context-awareaccess control model for web-services. Distrib. Parallel Databases 18 (July 2005),83–105.
[40] Bohra, A., Smaldone, S., and Iftode, L. FRAC: Implementing Role-BasedAccess Control for Network File Systems. In Proceedings of the Sixth IEEE In-ternational Symposium on Network Computing and Applications (2007), NCA’07.
[41] Bray, T. Bonnie home page. http://www.textuality.com/bonnie/, 1996.
[42] Caceres, R., Carter, C., Narayanaswami, C., and Raghunath, M. Rein-carnating PCs with Portable SoulPads. In Proceedings of the 3rd InternationalConference on Mobile Systems, Applications, and Services (Seattle, WA, 2005),MobiSys ’05.
[43] Callaghan, B., Pawlowski, B., and Staubach, P. NFS Version 3 ProtocolSpecification, RFC 1813. IETF, June 1995. http://www.ietf.org/rfc/rfc1813.txt.
[44] Card, R., Tso, T., and Tweedie, S. Design and implementation of the secondextended filesystem. In Proceedings of the First Dutch International Symposiumon Linux (1994).
[45] Chandra, R., Zeldovich, N., Sapuntzakis, C., and Lam, M. The Col-lective: A Cache-Based System Management Architecture. In Proceedings of theSecond Symposium on Networked Systems Design and Implementation (Boston,MA, 2005), NSDI ’05.
[46] Chazelle, B., Kilian, J., Rubinfeld, R., and Tal, A. The bloomier filter:an efficient data structure for static support lookup tables. In Proceedings of theFifteenth Annual ACM-SIAM Symposium on Discrete Algorithms (2004), SODA’04.
[47] Chen, P. M., and Noble, B. D. When virtual is better than real. In Proceed-ings of the Eighth Workshop on Hot Topics in Operating Systems (2001), HotOS’01.
[48] Cipar, J., Corner, M. D., and Berger, E. D. Contributing Storage Usingthe Transparent File System. ACM Transactions on Storage 3, 3 (2007).
[49] Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C.,Pratt, I., and Warfield, A. Live migration of virtual machines. In Pro-ceedings of the 2nd Conference on Symposium on Networked Systems Design &Implementation (Boston, MA, 2005), NSDI ’05.
[50] Coker, R. Bonnie++ home page. http://www.coker.com.au/bonnie++, 2001.
146
[51] Conti, M., Giordano, S., May, M., and Passarella, A. From opportunis-tic networks to opportunistic computing. Comm. Mag. 48 (September 2010),126–139.
[52] Conti, M., and Kumar, M. Opportunities in Opportunistic Computing. Com-puter 43 (2010), 42–50.
[53] Corradi, A., Montanari, R., and Tibaldi, D. Context-based access controlfor ubiquitous service provisioning. In Proceedings of the 28th Annual Inter-national Computer Software and Applications Conference (Hong Kong, 2004),COMPSAC ’04.
[54] Corson, S., and Macker, J. Mobile Ad hoc Networking (MANET): RoutingProtocol Performance Issues and Evaluation Considerations. RFC 2501 (Infor-mational), Jan. 1999.
[55] Ellard, D., Ledlie, J., Malkani, P., and Seltzer, M. Passive nfs tracingof email and research workloads. In Proceedings of the 2nd USENIX Conferenceon File and Storage Technologies (2003), FAST ’03.
[56] Ellison, C. IETF RFC 2692: SPKI Requirements, September 1999.
[57] Fan, L., Cao, P., Almeida, J., and Broder, A. Z. Summary cache: ascalable wide-area web cache sharing protocol. IEEE/ACM Trans. Netw. 8 (June2000), 281–293.
[58] Ferraiolo, D. F., Sandhu, R., Gavrila, S., Kuhn, D. R., and Chan-dramouli, R. Proposed nist standard for role-based access control. ACM Trans.Inf. Syst. Secur. 4 (August 2001), 224–274.
[59] Garriss, S., Caceres, R., Berger, S., Sailer, R., van Doorn, L., andZhang, X. Trustworthy and personalized computing on public kiosks. In Pro-ceeding of the 6th International Conference on Mobile Systems, Applications, andServices (2008), MobiSys ’08.
[60] Geambasu, R., and John, J. P. Study of Virtual Machine Performance overNetwork File Systems. Tech. rep., University of Washington, 2006.
[61] Goldberg, R. P. Survey of Virtual Machine Research. IEEE Computer Mag-azine (June 1974), 34–45.
[62] Golnabi, K., Min, R. K., Khan, L., and Al-Shaer, E. Analysis of firewallpolicy rules using data mining techniques. In Proceedings of the Tenth IEEE/IFIPNetwork Operations and Management Symposium (2006), NOMS ’06.
[63] He, Z., Phan, T., and Nguyen, T. D. Enforcing enterprise-wide policies overstandard client-server interactions. In Proceedings of the 24th IEEE Symposiumon Reliable Distributed Systems (2005), SRDS’05.
[64] Howard, J. H., Kazar, M. L., Menees, S. G., Nichols, D. A., Satya-narayanan, M., Sidebotham, R. N., and West, M. J. Scale and perfor-mance in a distributed file system. ACM Trans. Comput. Syst. 6, 1 (1988), 51–81.
147
[65] International Committee for Information Technology. Role-based ac-cess control. ANSI/INCITS 359-2004, Feb. 2004.
[66] Jaeger, T., King, D. H., Butler, K. R., Hallyn, S., Latten, J., andZhang, X. Leveraging IPSEC for mandatory perpacket access control. In Pro-ceedings of the Second IEEE Communications Society/CreateNet InternationalConference on Security and Privacy in Communication Networks (2006).
[67] Kang, S., and Reddy, A. L. N. An Approach to Virtual Allocation in StorageSystems. ACM Transactions on Storage 2, 4 (2006).
[68] Kapsalis, V., Hadellis, L., Karelis, D., and Koubias, S. A DynamicContext-Aware Access Control Architecture for e-Services. Computers and Secu-rity 25, 7 (October 2006).
[69] Karat, C.-M., Halverson, C., Horn, D., and Karat, J. Patterns of entryand correction in large vocabulary continuous speech recognition systems. InProceedings of the SIGCHI Conference on Human Factors in Computing Systems(1999), CHI ’99.
[70] Katcher, J. Postmark: A new file system benchmark. Tech. Rep. TR3022,Network Appliance, 1997. http://communities.netapp.com/servlet/JiveServlet/download/2609-1551/Katcher97-postmark-netapp-tr3022.pdf.
[71] Kim, M., Cox, L. P., and Noble, B. D. Safety, visibility, and performancein a wide-area file system. In Proceedings of the 1st USENIX Conference on Fileand Storage Technologies (Monterey, CA, January 2002), FAST ’02.
[72] Kistler, J., and Satyanarayanan, M. Disconnected operation in the Codafile system. ACM Transactions on Computer Systems 10, 1 (February 1992).
[73] Kozuch, M., Satyanarayanan, M. Internet Suspend/Resume. In Proceedingsof the Fourth IEEE Workshop on Mobile Computing Systems and Applications(Callicoon, NY, June 2002), WMCSA ’02.
[74] Kuhlmann, M., Shohat, D., and Schimpf, G. Role mining - revealing busi-ness roles for security administration using data mining technology. In Proceed-ings of the Eighth ACM Symposium on Access Control Models and Technologies(2003), SACMAT ’03.
[75] Lampson, B., Abadi, M., Burrows, M., and Wobber, E. Authenticationin distributed systems: theory and practice. ACM Trans. Comput. Syst. 10, 4(1992), 265–310.
[76] Lee, D., Baer, J.-L., Bershad, B., and Anderson, T. Reducing startuplatency in web and desktop applications. In Proceedings of the 3rd Conference onUSENIX Windows NT Symposium (1999), WINSYM ’99.
[77] Lumb, C. R., Schindler, J., and Ganger, G. R. Freeblock scheduling out-side of disk firmware. In Proceedings of the Conference on File and Storage Tech-nologies (Berkeley, CA, 2002), FAST ’02.
148
[78] Martin, E., and Xie, T. Inferring access-control policy properties via machinelearning. In Proceedings of the Seventh IEEE International Workshop on Policiesfor Distributed Systems and Networks (London, Ontario, Canada, 2006).
[79] Martin, T. L., and Siewiorek, D. P. Non-ideal battery properties and lowpower operation in wearable computing. In Proceedings of the 3rd IEEE Interna-tional Symposium on Wearable Computers (Washington, DC, 1999), ISWC ’99.
[80] Menon, J., Pease, D. A., Rees, R., Duyanovich, L., and Hillsberg, B.IBM Storage Tank – A Heterogeneous Scalable SAN File System. IBM SystemJournal 42, 2 (2003).
[81] Minsky, N. H., and Ungureanu, V. Law-governed interaction: a coordina-tion and control mechanism for heterogeneous distributed systems. ACM Trans.Softw. Eng. Methodol. 9 (July 2000), 273–305.
[82] Provos, N. Improving host security with system call policies. In Proceedings ofthe 12th Conference on USENIX Security Symposium (Berkeley, CA, 2003).
[83] Pullar-Strecker, T. NZ bank Adds Security Online. http://www.smh.com.au, November 2004.
[84] Ravi, N., Narayanaswami, C., Raghunath, M., and Rosu, M. Towards se-curing pocket hard drives and portable personalities. IEEE Pervasive Computing6, 4 (2007).
[85] Saha, A. K., and Johnson, D. B. Modeling mobility for vehicular ad-hocnetworks. In Proceedings of the 1st ACM International Workshop on VehicularAd Hoc Networks (2004), VANET ’04.
[86] Saidane, A. Adaptive context-aware access control policy in ad-hoc networks. InProceedings of the Third International Conference on Autonomic and AutonomousSystems (2007), ICAS ’07.
[87] Sailer, R., Jaeger, T., Zhang, X., and van Doorn, L. Attestation-basedpolicy enforcement for remote access. In Proceedings of the 11th ACM Conferenceon Computer and Communications Security (Washington, DC, 2004), CCS ’04.
[88] Sailer, R., Zhang, X., Jaeger, T., and van Doorn, L. Design and imple-mentation of a tcg-based integrity measurement architecture. In Proceedings ofthe 13th Conference on USENIX Security Symposium (San Diego, CA, 2004).
[89] Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., and Lyon, B.Design and implementation or the sun network filesystem. In Proceedings of theSummer USENUX Conference (1985), USENIX ’85.
[90] Sapuntzakis, C., Chandra, R., Pfaff, B., Chow, J., Lam, M., Rosen-blum, M. Optimizing the Migration of Virtual Computers. In Proceedings of the5th Symposium on Operating Systems Design and Implementation (Boston, MA,Dec. 2002).
[91] Satyanarayanan, M. Pervasive computing: Vision and challenges. IEEE Per-sonal Communications 8 (2001), 10–17.
149
[92] Satyanarayanan, M., Gilbert, B., Toups, M., Tolia, N., Surie, A.,O’Hallaron, D. R., Wolbach, A., Harkes, J., Perrig, A., Farber, D. J.,Kozuch, M. A., Helfrich, C. J., Nath, P., and Lagar-Cavilla, H. A.Pervasive personal computing in an internet suspend/resume system. IEEE In-ternet Computing 11, 2 (2007), 16–25.
[93] Satyanarayanan, M., Smaldone, S., Gilbert, B., Harkes, J., andIftode, L. Bringing the cloud down to earth: Transient pcs everywhere. In Pro-ceedings of the First International Workshop on Mobile Computing and Clouds(October 2010), MobiCloud ’10.
[94] Seshadri, A., Luk, M., Shi, E., Perrig, A., van Doorn, L., and Khosla,P. Pioneer: verifying code integrity and enforcing untampered code execution onlegacy systems. In Proceedings of the Twentieth ACM Symposium on OperatingSystems Principles (2005), SOSP ’05.
[95] Smaldone, S., Bohra, A., and Iftode, L. FileWall: a firewall for networkfile systems. In Proceedings of the Third IEEE International Symposium on De-pendable, Autonomic and Secure Computing (2007), DASC ’07.
[96] Smaldone, S., Ganapathy, V., and Iftode, L. Working set-based accesscontrol for network file systems. In Proceedings of the 14th ACM Symposium onAccess Control Models and Technologies (2009), SACMAT ’09.
[97] Smaldone, S., Gilbert, B., Bila, N., Iftode, L., de Lara, E., and Satya-narayanan, M. Leveraging smart phones to reduce mobility footprints. InProceedings of the 7th International Conference on Mobile Systems, Applications,and Services (2009), MobiSys ’09.
[98] Smaldone, S., Harkes, J., Iftode, L., and Satyanarayanan, M. Safetransient use of local storage for VM-based mobility. Tech. Rep. CMU-CS-10-110, Carnegie Mellon University, March 2010.
[99] Sniffen, B. T., Harris, D. R., and Ramsdell, J. D. Guided policy genera-tion for application authors. Tech. rep., The MITRE Corporation, 2006.
[100] Soules, C. A. N., and Ganger, G. R. Connections: using context to en-hance file search. In Proceedings of the Twentieth ACM Symposium on OperatingSystems Principles (Brighton, United Kingdom, 2005), SOSP ’05.
[101] Soules, C. A. N., Goodson, G. R., Strunk, J. D., and Ganger, G. R.Metadata efficiency in versioning file systems. In Proceedings of the 2nd USENIXConference on File and Storage Technologies (2003), FAST ’03.
[102] Spasojevic, M., and Satyanarayanan, M. An empirical study of a wide-areadistributed file system. ACM Trans. Comput. Syst. 14 (May 1996), 200–222.
[103] Sultan, F., Bohra, A., Smaldone, S., Pan, Y., Gallard, P., Neamtiu,I., and Iftode, L. Recovering internet service sessions from operating systemfailures. IEEE Internet Computing 9 (March 2005), 17–27.
[104] Sun Microsystems, I. OpenOffice.org - The Free and Open Productivity Suite.OpenOffice.org Project Home Page. http://www.openoffice.org/, 2010.
150
[105] Surie, A., Perrig, A., Satyanarayanan, M., and Farber, D. J. Rapidtrust establishment for pervasive personal computing. IEEE Pervasive Computing6, 4 (2007), 24–30.
[106] Tolia, N., Harkes, J., Kozuch, M., and Satyanarayanan, M. IntegratingPortable and Distributed Storage. In Proceedings of the 3rd USENIX Conferenceon File and Storage Technologies (San Francisco, CA, 2004), FAST ’04.
[107] Tolia, N., Kaminsky, M., Andersen, D. G., and Patil, S. An architecturefor internet data transfer. In Proceedings of the 3rd Symposium on NetworkedSystems Design and Implementation (San Jose, CA, 2006), NSDI ’06.
[108] Tolia, N., Andersen, D., Satyanarayanan, M. Quantifying interactiveexperience on thin clients. IEEE Computer 39, 3 (Mar. 2006).
[109] Tongaonkar, A., Inamdar, N., and Sekar, R. Inferring higher level policiesfrom firewall rules. In Proceedings of the 21st Conference on Large InstallationSystem Administration Conference (2007), LISA ’07.
[110] Toninelli, R., Montanari, R., Kagal, L., and Lassila, O. O.: A seman-tic context-aware access control framework for secure collaborations in pervasivecomputing environments. In Collaborations in Pervasive Computing Environ-ments, 5th Intl. Semantic Web Conference (2006), ACM Press, pp. 5–9.
[111] Traeger, A., Zadok, E., Joukov, N., and Wright, C. P. A nine yearstudy of file system and storage benchmarking. Trans. Storage 4, 2 (2008), 1–56.
[112] Ts’O, T. E2fsprogs: Ext2/3/4 Filesystem Utilities. http://e2fsprogs.sourceforge.net/, 2010.
[113] Weiser, M. Human-Computer Interaction. Morgan Kaufmann Publishers Inc.,San Francisco, CA, USA, 1995, ch. The Computer for the 21st Century, pp. 933–940.
[114] Yokoyama, S., Kamioka, E., and Yamada, S. An anonymous context awareaccess control architecture for ubiquitous services. In Proceedings of the 7th In-ternational Conference on Mobile Data Management (2006), MDM ’06.