A lightweight secure cyber foraging infrastructure for resource-constrained devices

Resource-constrained embedded and mobile devices are becoming increasingly common. Cyber foraging, which allows such devices to offload computation to less resource-constrained surrogate machines, enables new and interesting applications for these
of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A Lightweight Secure Cyber Foraging Infrastructure for Resource-ConstrainedDevices Sachin Goyal and John CarterSchool of ComputingUniversity of Utah   sgoyal, retrac  Abstract  Resource-constrained embedded and mobile devices arebecoming increasingly common. Cyber foraging, which al-lows such devices to offload computation to less resource-constrained surrogate machines, enables new and interest-ingapplicationsfor these devices. In this paperwe describea surrogate infrastructure based on virtual machine tech-nology that allows resource-constrainted devices to utilizea surrogate’s compute, network, and storage resources. Af-ter describingthe designof our surrogate infrastructure, wedemonstrate how it can be used to support real-time speechrecognitionanda synthetic web services application. Usinga surrogate reduces the response time of speech recognitionby a factor of 200 while reducing the energy drain on theclient device by a factor of 60. Using a surrogate reducesthe response time and energy drain on the client by factorsof 21 and 25, respectively, for the web services application. 1. Introduction In recent years, there has been an explosion of smallcomputing devices, e.g., PDAs, cell phones, sensors, anda plethora of embedded devices. At the same time,network connectivity has become ubiquitous, even forthese small devices. Such devices are typically resource-constrained, with limited energy, computation, memory,storage, and/or network resources. However, these lim-itations can be masked by utilizing the resources of lessresource-constrainedcomputers, a concept called  surrogatecomputing  or  cyber foraging  [15]. In a cyber foraging sys-tem, a surrogate machine makes its resources available toclient devices to perform tasks on their behalf. We proposetousecyberforagingtolet resource-constraineddevicesrunapplicationsand services that cannotbe runon the small de-vices themselves due to lack of some resource(s). This pa-per describes a surrogate infrastructure that we are buildingto support this kind of cyber foraging.Cyber foraging enables resource-constrained devices to“run”interestingresource-intensiveapplicationsthatarebe-yond their own capabilities. For example, suppose youwanted to use speech or gesture recognition as inputs toa future PDA. Unfortunately, speech and gesture recogni-tion are compute- and power-intensive operations, runningfar slower than real time on low-power devices [11]. Us-ing cyber foraging, a PDA could capture the voice or ges-ture data and send it to a powerful surrogate computer to dothe recognition. Alternatively,consider a future smart homeenvironment,where tiny special-purposeembeddeddevicescan utilize the resources of powerful desktop computers toperforminteresting tasks that the devices themselves are in-capable of performing. In addition to enabling new applica-tions, cyber foraging can decrease the storage, battery, andcomputation requirements of embedded or mobile devices,thereby decreasing their size, complexity, and cost. Suchdevices would need only enough local resources to performtheir common tasks, and could use surrogate resources toperform more complex or less common tasks.Utilizing theideaofcyberforagingrequiresseveralchal-lenges to be overcome, including:1. developing mechanisms whereby a potential surrogatecan make some of its resources available to resource-constrained clients,2. providing a means for surrogates to advertise theiravailability and clients to locate surrogateswith appro-priate available resources,3. developing a mechanism whereby clients can transfertasks to the surrogate,4. making the remote execution of surrogate tasks be(largely) transparent and easy to program, and  5. developing security and trust mechanisms so that sur-rogates can be assured that they (and their neighbors)will not be abused by surrogate computations.We envision cyber foraging being used as follows. APDA user clicks on the icon associated with an applicationconfigured to run, at least partially, on a surrogate machine.If the OS has not already obtained access to a surrogate,it invokes a surrogate acquisition module, which locates anappropriatesurrogate,establishesaservicecontractwiththesurrogate for a particular amount of resources, and estab-lishes a security context so that only the client can accessthe surrogate. In our system, the client is given  root  ac-cess to a virtual machine instance, and can download, in-stall, and execute arbitrary applications or services, subjectto negotiated resource limits. To invoke an application onthe surrogate, the client ships a small program to a daemonlistening at a known port on the surrogate, which runs theprogram on behalf of the client. Typically, this program isa shell script that downloads the real application over theInternet, installs it, and runs it. Once the surrogate portionof the application is installed on the surrogate, the appli-cation launches the client interface on the device (if any),transparentlyships input data to the surrogate portion of theapplication, collects responses, and outputs them throughthe client user interface. We provide more details on theexecution environment in Section 3.A major goal of our work is to support cyber foragingona conventional platform, without a large middleware layer,anddemonstrateits useonrealapplicationsandsystems. Todo so, we build our surrogate framework on top of widelyavailable technology. We use machine virtualization tech-nology (VServer [1] and Xen [4]) to provide basic isola-tion. We use publicly available encryption technologies,both public and private key, as the foundation of our secu-rity and authentication infrastructure. We use a lightweightdiscovery protocol to locate potential surrogates.To demonstrate the value of our cyber foraging frame-work, we evaluate it using a Sharp Zaurus PDA as a clientand a RedHat Linux PC as a surrogate. We use cyber for-aging to enable the Zaurus to perform continuous speechrecognition using the sphinx2 [8] system from CMU andto perform a synthetic web services application wherein thesurrogate sifts through 19 megabytes of data on behalf of the client. We find that using a surrogate reduces the re-sponse time of the compute-intensive speech recognizer bya factor of 200, while reducing the energy drain on the Za-urus by a factor of 60. For the network-intensive syntheticweb services, using a surrogate reduces the response timeby a factor of 21, while reducing the energy drain on theZaurus by a factor of 25.Our main contributions are as follows:   We build a practical system to support cyber foragingwith realistic notions of trust, security, and usability.   We demonstrate the value of using virtual machinetechnology as the basis for building a surrogate infras-tructure.   We show that interesting applications can be enabledeven using only trusted computers available to us (e.g.,our home PC or nearby office PC).   We demonstrate experimentally the performance andenergy saving potential of cyber foraging for a simplesystem involvinga SharpZaurusclient anda LinuxPCsurrogate. 2. Related Work The basic idea of using surrogates to support pervasivecomputingwas introducedinSatyanarayanan’spaperonthechallenges of pervasive computing [15]. To support this vi-sion, Flinn  built Spectra [5, 6], a remote executionen-vironmentthat allows a mobile device to use the processingpower of a nearby surrogate computer. Spectra runs on topof Coda [9] and Odyssey[13]. Spectra monitors applicationresource usage and the availability of resources in the localenvironment to decide when and where to utilize cyber for-aging. Balan  [3] extended Spectra to support applica-tion partitioning, and show that application-specific knowl-edge regarding how to partition an application between aclient and a surrogate can be captured in a compact form.Our work is orthogonal to these efforts. Our focus is onbuilding a cyber foraging infrastructure out of commoditysystems and establishing secure surrogate sessions dynam-ically. We do not require clients and surrogates to share afile system (e.g., Coda) or require the client to run a rel-atively heavyweight middleware system. Our clients andsurrogatesdo not share a commonfile system, so we relyonthe surrogate being connected to the Internet to locate anddownload client application code. We also address securityissues to allow only authorized users to utilize the servicesof the surrogates.Messer [12] developed a system for dynamically parti-tioning Java programs and offloading pieces of them to sur-rogates based on memoryand processing constraints. How-ever, their approach entails significant networking over-head, and thus energy consumption, because the client andsurrogate portions of program are highly coupled.In contrast to prior work on automatic application parti-tioning, we rely on application writers to partition applica-tions at development time and assume that applications aresplit in a way that mitigates client-surrogate communica-tion. Thin clients have limited resources and IO interfaces,so developers writing applications for these devices alreadytune them carefully. Using our simple surrogate-enabling  library, developerscan easily build two versions of their ap-plications, a low-fidelity option for when no surrogate isavailable and a high-fidelity one that exploits surrogates.We expect that a common strategy will entail running mostof the application on the surrogate and using the client forinput-output. Cyber foragingis most useful for applicationsthatcan be dividedinto loosely-coupledcomponents;other-wise the cost of communication between the client and thesurrogate will offset the performance or energy benefits of using a surrogate. Conveniently,many applications fall intothis category, including perception processing (e.g., speechand gesture recognition), data mining (e.g., semantic weband web services operations), sensor aggregation, distilla-tion proxies, and many smart home applications. 3. System Design Our goal is to create a system that can be deployed inexisting computing environments to enable cyber foragingwithout requiring a heavyweight middleware system. 3.1. Overview In our system, there are  clients  and  surrogates . Clientsare typically resource-constrained devices with some formof networking capability, e.g., a PDA, mote, or cell phone.Potentially constrained resources include energy, computepower, storage, and network bandwidth. Note that whilethe examples in this paper assume clients with limited ca-pabilities, a client could be a desktop computer that wishesto harness the compute capabilities of hundreds of otherdesktop computers, ala the “Grid.” Surrogates are typi-cally resource-rich devices that are willing to run programsand/or provide storage on behalf of clients. Surrogatesmight be a desktop PC available via the local wireless LAN(e.g., in a smart home, office, or commercial hotspot envi-ronment) or might be your home PC or a commercial sur-rogate connected via the Internet. For our work, we assumethat the surrogate is connected to the Internet via a high-speed network. Figure 1 shows a simple cyber foragingscenario where a PDA client moves some subtask to a lo-cal surrogate machine.For this design to be useful and gain wide acceptance,many challenges must be overcome, including:1. Clients shouldbe able to specifytheir requirementsfora surrogateservereasily and locate a suitable surrogatein real time.2. Surrogates must be able to limit the use of their re-sources (e.g., cpu time, memory, file storage, and net-work bandwidth) by client applications.3. Clients should be able to install and execute arbitraryapplications and services. Figure 1. A cyber foraging scenario 4. Theapplicationinterfacesforcyberforagingshouldbesimple and easy to use.5. There must be sufficient security and privacy guaran-tees that both clients and surrogates will be willing totake part in the infrastructure.We discuss our solutions to these challenges throughouttheremainder of this section. We are investigating solutions toother challenges, such as developing a trust model that al-lows entities to decide how to operate based on how muchtheytrust each other anddevelopinga cost model to supportresource management and enable commercial surrogates,but this work is beyond the scope of this paper. 3.2. Surrogate Design Surrogates can be implemented in multiple ways. Wechoose to use  virtual machine  technology. Virtual ma-chine technology allows a single surrogate machine to runa configurable number of independent  virtual servers  withgreater greater  isolation ,  flexibility ,  resource control , and ease of cleanup than simply runningsurrogateprocesses di-rectly on top of a standard Unix box. In terms of isolation,client applications running on different virtual machinescannot directly interfere with one another, nor can they ac-cess resourcesreservedforthesurrogatemachine. Differentclients can install arbitraryapplications,packages, and evenkernel patches, without interfering with other clients or thebase surrogate. Letting clients install arbitrary code on theirvirtual machine providestremendousflexibility – what theycan do is not limited by what some middleware layer sup-ports. The virtual machine monitor can enforce resourcecontrols (e.g., disk quota, cpu share, and physical memory  allocation)on a per-VM basis, which allows allows individ-ualclients toshare thesurrogatemachinefairly. Thisdesignallows normal work to proceedon the surrogatewithout un-due impact by surrogate clients. Finally, it is easy to cleanup after a client – the surrogate host system simply shutsdown the virtual server instance and restores the associateddisk partition to its srcinal (clean) state.Currently we support two types of virtual machines:  Linux-Vserver   [1] and  Xen  [4]. Virtual servers underLinux-Vserver share a single kernel instance. Isolation is providedby OS modifications that encapsulate groups of processescalled contexts. Each virtual server runs in its own rootfile system ( chroot ’ed), is provided its own IP address,and can only access the files, processes, and IPC primitivesowned by it. Xen para-virtualizes an x86 platform, whichallows multiple independentOS kernels (currentlyLinux orBSD 1 ) to run on a single machine. Each OS instance ac-cesses hardware through virtualized device drivers.In general, Xen providesa higherdegree of isolation andsecurity than Vserver, at the cost of additional run timeoverhead and a slower startup. The Xen VM monitor al-lows us to allocate physical memory between various vir-tual servers and supports CPU schedulers that fairly sharethe CPU cycles. Vserver currently provides only basichard limit controls for CPU and memory sharing, but ef-forts are underway to add functionality developed as partof the class-based kernel resource management (CKRM)project [2]. We plan to use Xen when clients and surrogatesdo not fully trust one another or we require more compre-hensive resource controls and to use Vserver for mutuallytrusting clients and surrogates.Language based virtual machines, e.g. Java, can providesome of the same features, but restricts the flexibility of thesystem to use programs written in that language only. 3.3. Service Discovery To utilize the surrogate infrastructure, clients must firstlocate a suitable surrogate with the help of a service discov-ery system. We employ a simple service discovery serverthatallows surrogatesto registerthemselvesusingan XML-like description of their capabilities, e.g., <service> surrogate<OS> Linux<distribution> Redhat<version> 9.0 </version></distribution><distribution> Debian<version> 3.0 </version></distribution></OS></service> 1 A Windows XP version exists, but is not publicly available. In this example,the surrogateoffersclients instances of twoLinux distributions, Redhat 9.0 and Debian 3.0. Clientslocate surrogates by querying the service discovery serverusing a similar XML-like notation. The service discoveryserver matchs requests against registered surrogates. In thefuture,we plan to adoptanexisting servicediscoverymech-anism, e.g., the Service Location Protocol [7] and extendour lookup mechanism to consider issues such as surrogateload.Currently we expect programmers to make conservativeestimates of applicationresource requirementsbased on ap-plication knowledge or simple profiling. For example, forthe speech recognition application a coarse estimate couldbe obtainedby running top and observingtypicalCPU andmemory usage patterns, and then a modest margin of error(e.g., 25-50%) could be added to the request. In the fu-ture, we plan to investigate the value of more sophisticatedprofiling and history-based tools. Accurately predicting theresource requirements of an application is an area of activeongoing research area in both the embedded and computa-tional grid domain that we plan to follow closely. 3.4. Control Flow Figure 2 shows a typical client-surrogate control flow:1.  Service Discovery Request : The client sends a mes-sage to the service discovery server to find an appro-priate surrogate.2.  Service Discovery Reply : The service discoveryserver responds with the IP Address and port numberof the surrogate’s  surrogate manager process , whichlistens for client connection requests.3.  Service Start Request : the client connects to the sur-rogate manager process and requests a virtual serverwith specific resource guarantees. The surrogate man-ager first authenticates the client (see Section 4). If the client is authorized to use this surrogate, the surro-gatemanagerprocessesthe client resourcerequest(de-scribed via an XML-like notation) and, if adequate re-sources are available, establishes a contract to provideservice for a fixed duration. The maximum number of virtual server instances and the maximum machine re-sources that a surrogate is willing to provide to clientsare configurable.4.  Virtual Server Start : The surrogate manager main-tains root partition images for each available OS (e.g.,Linux Redhat 9 or BSD). In response to an authorizedclient request, it dynamically initializes a preallocatedrootpartitionwiththeappropriaterootimageandstartsa new virtual server. It takes more than a minute to ini-tialize a one GB root partition. To reduce this setup  Figure 2. A typical client-surrogate control flow overhead, we maintain a pool of preinitialized parti-tions to hide the root image copy time in the commoncase. Each virtual server is allocated its own IP ad-dress.5.  Service Start Response : Once the new virtual serveris running, the surrogate manager returns the IP ad-dress of the virtual server to client.6.  SubTask ConfigurationRequest : Eachvirtualserveris configured to run a  virtual server manager   (VSM)that handles requests for surrogate operations from itsclient. To invoke an operation on a surrogate, theclient sends a Sub Task Configuration Request to thevirtual server manager. Client requests consist of aURL that points to a program that the client wantsthe VSM to run on its behalf. Typically, the programis a shell script that downloads the necessary soft-ware/packages, installs them, and then invokes them.For example, in Section 5 we describe an experimentthat installing a Sphinx2 voice recognition server onthe surrogateand having it accept client voice recogni-tion requests on a well known port. In addition theVSM, the virtual server runs a secure shell daemon( sshd ) set up so that the client can log on as  root and manually install and invoke any operations theywish.7.  Service Termination : When the client explicitly ter-minates the surrogateor when the reservedinterval ex-pires, we clean up the virtual server by reinstallingits root file system with a clean image. Wiping thepartition removes any changes made by the surro-gate, thereby preserving privacy and protecting futureclients from any malicious software installed by theclient.We anticipate that some clients will use the same sur-rogate to perform the same operation multiple times, e.g.,a mobile user may use their home PC as a surrogate whentraveling. To improve the performanceof this common sce-nario,welet trusteduserssavecustomizedrootpartitionim-ages with all necessary packages, applications, and systemboot up scripts on the surrogate. We allow the same user(identified by their public key) to use request this image beinstalledwhentheyrequestavirtualserver. We areplanningto add a surrogate cache whereby surrogates cache pack-ages that are often downloadedso that they can be retrievedlocally. Both of these optimizationsreduce the startup over-head of instantiating a surrogate virtual server. 3.5. Client Interface To supportthe functionalitydescribedabove,we providea simple client library that supports the following opera-tions:   get surrogate() : Takes as inputtheIP addressofa sur-rogate server and a service description string. Returnsa success code. If successful, the IP address of the vir-tual server is also returned. If the client has an activesurrogate server, its IP address is returned. Otherwise,a new virtual server is allocated as described in Sec-tion 3.4 and its IP address is returned.   subtask conf request : Takes as input the URL wherea program that the client wishes to run can be found,which is sent as a subtask configuration request to ap-propriate virtual server manager. Returns a successcode.   get virtual server ip : Returns the IP address of theactive surrogate virtual server, if any.

Ghabri Sedki

Jan 7, 2019
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks