Towards an for the Campus

Pengfei Yuan, Yao Guo, and Xiangqun Chen Key Laboratory of High-Confidence Software Technologies (Ministry of Education) School of Electronics Engineering and Computer Science, Peking University {yuanpf12, yaoguo, cherry}@sei.pku.edu.cn

ABSTRACT data center or even the whole as a computer, we can Almost every computing device runs an operating system, envision that many applications are “actually” running on which is responsible for managing different resources on the network of computers. Consequently, many researchers the device and providing higher-level programming abstrac- have proposed various operating systems for cloud or even tions. This paper proposes CampusOS, an operating system the Internet. For example, Tim O’Reilly proposed his vision which is responsible for managing networked resources on of an Internet Operating System [7]. At the same time, university campuses, including data of students, teachers, many other operating systems have been proposed for cloud courses, organizations, and even data generated from users’ computing [10], networked home appliances [3], commercial computing devices. CampusOS provides flexible support for buildings [2], and even connected city blocks [4]. campus application development with SDKs consisting of In contrast, this paper focuses on the evolvement of campus-related APIs. CampusOS features and SDK APIs applications and services running on closely-connected com- can also be extended by developers easily. We discuss the munities such as a university campus, especially mobile design of CampusOS, as well as its challenges. applications targeting community members and activities. Developing applications for communities like university cam- puses requires a lot of trivial work. A developer would Categories and Subject Descriptors typically need to figure out how to retrieve and manage D.2.2 [Software Engineering]: Design Tools and Tech- users’ personal information, schedules, social relations, etc. niques—software libraries; D.4 [Operating Systems]: Or- Large amount of time is spent on these lower-level details, ganization and Design instead of focusing on implementing and improving the key functionalities of the applications. For a closely-connected community such as a university General Terms or a similar organization, different applications have much Design, Management in common at the lower level. Providing higher-level APIs for commonly used lower-level features can improve the Keywords development process significantly. For example, identifying a specific place (such as a building on campus) with a Internet operating system, Middleware, Campus application smartphone requires access to the sensors on the device development, Internetware and the campus building layout information, as well as a positioning algorithm. As many campus applications 1. INTRODUCTION will require the same identification feature, we can provide Operating systems are running on almost all modern common APIs or services for outdoor (or even indoor) computing devices, such as PCs, smartphones, embedded location identification, such that all location-based campus systems and even sophisticated sensors. The key function- applications do not need to reinvent the wheel. alities of an operating system are managing various kinds In order to support the existing (and emerging) appli- of resources (CPU, storage, peripherals, etc.) and providing cations on campus, we argue that an operating system programming and runtime support. is needed to provide sufficient support during application With the prevalence of the Internet, many computers are development, deployment, execution and maintenance. We connected together, forming a grid or cloud, in order to design CampusOS as an open, community-oriented operat- support more complex applications. If we treat a cluster, a ing system for university campuses. Just like traditional operating systems, CampusOS provides programming inter- faces, libraries, and runtime management of applications, although at a higher level. Many components of CampusOS Permission to make digital or hard copies of all or part of this work for depend on traditional operating systems like Windows and personal or classroom use is granted without fee provided that copies are , as well as networked resources in the cloud and on not made or distributed for profit or commercial advantage and that copies the Internet. bear this notice and the full citation on the first page. To copy otherwise, to Many people may wonder why we need another operating republish, to post on servers or to redistribute to lists, requires prior specific system as many features provided by CampusOS can be permission and/or a fee. Internetware ’13 October 23–24 2013, Changsha, China implemented separately. We illustrate the necessity of an Copyright 2013 ACM 978-1-4503-2369-7/13/10 ...$15.00. operating system, as well as the contributions of CampusOS, from the following aspects. Service Campus Campus Application • CampusOS can provide support for students who are Daemon Store App Development interested in building personalized applications and Client excited to share them with friends. CampusOS SDK • CampusOS can provide support for courseware and Feature Service Driver Development course-related applications with course-specific cus- Server tomizations. • CampusOS can help manage different communities on CampusOS Core System campus, such as student union, student clubs, interest Development groups, sports teams, etc. • CampusOS can also serve as a research platform Figure 1: The development architecture of Cam- where researchers can distribute applications for ex- pusOS perimental purposes and collect user information with permission. CampusOS belongs to a larger ongoing project, in which we are constructing a prototype of an Internet operating system, which is a development and runtime supporting Service Interface …… Service Interface environment for Internetware [5, 6]. Syscall over Network CampusOS SDK Network Communication 2. CAMPUSOS DESIGN Network We adopt a hierarchical architecture in CampusOS, which Network Communication is similar to traditional operating systems. In this section, Syscall over Network & Dispatcher CampusOS Core we first present our design goal to make CampusOS an open VFS Dispatcher and extensible ecosystem. Then we describe the specific Service Driver …… Service Driver design of CampusOS. Underlying Implementation 2.1 Goal CampusOS is intended to serve as an open platform Figure 2: The runtime architecture of CampusOS for campus applications, which means that not only can developers publish new applications to CampusOS, but they can also add new features to CampusOS. CampusOS is computing platforms in CampusOS, the CampusOS SDK designed with the principle of extensibility in mind, such supports multiple programming languages, such as C, C++, that new features can be easily added into it. When some , C#, JavaScript, etc. developers come up with interesting new features, they can For better extensibility, we adopt two abstractions that choose to share the features with other developers by adding are originated from traditional operating systems and use them to CampusOS. With more and more features added them in CampusOS. One is the system call (syscall) and the into CampusOS, more complex campus applications can other is the virtual file system (VFS). be built, which will in turn attract more users and more Figure 2 shows the hierarchical runtime architecture of developers, thus forming an ecosystem. CampusOS. It illustrates the relation between the Cam- Besides its open and extensible characteristics, Cam- pusOS SDK and the CampusOS Core. The top layer pusOS supports multiple computing platforms to better consists of various service interfaces, which provide campus adapt to the development and deployment of campus ap- applications with APIs for accessing various features. The plications, including traditional PCs, smartphones, tablet service interfaces invoke CampusOS syscalls, which are computers and web browsers. In the meanwhile, CampusOS encoded and passed to the CampusOS Core via network. should protect the security and privacy of users’ data against The CampusOS Core running on the server side accepts attackers and malicious campus applications. syscalls, decodes and dispatches them accordingly. The VFS layer maps service interfaces to their corresponding service 2.2 Architecture drivers. This mapping actually correlates feature invoca- Figure 1 shows the hierarchical development architecture tions in campus applications to feature implementations in of CampusOS. The bottom layer is the CampusOS Core CampusOS. and the underlying implementations of the whole system. This layer corresponds to the development of the CampusOS 2.3 Feature Extension system. The middle layer consists of service drivers on the In our design, CampusOS features are attached to VFS server side and the CampusOS SDK and service daemons on nodes and accessed via syscalls. In this way, we achieve the client side. This layer corresponds to the development the principle of extensibility. On the one hand, we provide and extension of CampusOS features. The top layer is uniform interfaces for accessing different features in the based on the CampusOS SDK, including CampusStore and CampusOS SDK. On the other hand, we provide a general campus applications. The development of various campus approach to organizing different CampusOS features. In applications belongs to this layer. short, syscall is the interface for VFS manipulation, i.e., Just like SDKs in traditional operating systems, the Cam- actual CampusOS feature invocation. pusOS SDK is the key component that provides development Since all developers can contribute features to CampusOS, support for campus applications. To support multiple we design four different approaches to service driver imple- mentation, where syscalls are handled to extend CampusOS CampusStore. The authentication process works reversely features, to better adapt to the goal of extensibility. Dif- as the campus application logs into CampusOS with the ferent approaches correspond to different levels of isolation password and exercises the subset of privileges granted to between the service drivers and the CampusOS Core. the password on behalf of the user via certain service drivers. 1. Service drivers can be statically linked into the Cam- More sophisticated mechanisms for protecting cooperative pusOS Core. privacy and colocation privacy are currently under research. 2. Service drivers can be dynamic libraries and loaded by They can provide more fine-grained privacy protection than the CampusOS Core at startup. this basic access control mechanism. 3. Service drivers can be separate processes running on the same server as the CampusOS Core. 3. DISCUSSIONS AND RELATED WORK 4. Service drivers can also be hosted on separate virtual In this section, we discuss challenges beyond our design, machines or servers. relations and differences between CampusOS and traditional In the first three approaches, the service drivers share the operating systems and middleware, and related work. same runtime environment with the CampusOS Core, so the service drivers should be audited and tested before actual 3.1 Challenges deployment. In Approaches 1 and 2, the service drivers share One major challenge in CampusOS involves its open the same virtual address space with the CampusOS Core, so and extensible characteristics. Since many features in the services drivers should be tested more carefully to avoid CampusOS will be contributed by application developers crashes, which will directly affect the CampusOS Core. In instead of system developers, how to test these features on the first approach, which has the lowest level of isolation, CampusOS without service downtime or broken functional- service drivers can even access internal data structures of the ities is critical and very challenging. CampusOS Core. This approach is only used in a limited As there are already many campus applications developed number of features, such as session management. In our and running, we need to consider how to migrate these design, the last approach, which has the highest level of existing services and applications to CampusOS. Because isolation, should be the main approach in which community CampusOS is designed as an open community project, user developers contribute features to CampusOS. and developer involvement is critical to its success. How Based on the architecture of CampusOS shown in Figures to promote CampusOS in order to increase community 1 and 2, we summarize three patterns for feature implemen- involvement can also become an imminent challenge once tation, which cover most common scenarios where features the initial development and deployment are completed. of CampusOS are extended. 1. Features encapsulate existing services provided by 3.2 OS Evolution the third party, such as cloud storage service, social Since the first working operating system was developed network service, etc. This pattern is illustrated in on IBM mainframes, many operating systems have been Figure 3(a) for cloud storage service. built in the last 50 years. However, ever since Windows 2. Features involve data related to users, such as users’ and Linux dominated the market, the main functionalities location information. This pattern is illustrated in and structures of traditional operating systems running on Figure 3(b) for location service. single machines have kept unchanged for many years. 3. Features involve public data, such as campus news or As we enter the Internet era, many people have proposed notifications. This pattern is illustrated in Figure 3(c) to build an operating system for the “Internet as a com- for campus news service. puter” concept. O’Reilly has proposed the idea of Internet The difference between Figures 3(b) and 3(c) is that the Operating System in 2010, arguing that an Internet OS service daemon in Figure 3(b) runs on every CampusOS should contain new information subsystems and provide user’s device and the crawler in Figure 3(c) only runs on higher levels of abstraction [7]. Although we have not one server. seen a working operating system for the entire Internet, we have witnessed various approaches to developing operating 2.4 Security and Privacy Protection systems for software running on the Internet. For example, In our design, we take a variety of measures to protect the TransOS [10] is proposed to manage the cloud from the view- security of CampusOS and the privacy of user information. point of transparent computing. Urban OS [4] is proposed Firstly, all the encoded syscall data transmitted over as a software platform for accelerating the development and network is tunneled through Secure Socket Layer/Transport deployment of urban technology and devices. HomeOS [3] Layer Security (SSL/TLS). So user data is protected against provides a centralized and holistic control of devices in the man-in-the-middle attack during transmission. User data home. CleanOS [9] uses trusted, cloud-based services to stored on the server is encrypted and can only be directly limit exposure of sensitive data on Android. BOSS [2] accessed by the CampusOS Core and trusted service drivers, provides a set of operating system services which supports i.e., service drivers that have lower levels of isolation to the applications on top of the distributed physical resources CampusOS Core. present in large commercial buildings. We also design an access control mechanism, which is These “new” operating systems still provide basic key based on application-specific passwords, for other service functionalities similar to traditional operating systems, i.e., drivers and campus applications to access user data with managing various resources and providing services to ap- permission. The authorization process works as the user plications and/or users. In this sense, CampusOS is an grants a subset of his/her privileges to a password and operating system serving the campus community, managing delivers the password to a campus application. This process campus-related data and resources, while providing devel- can be applied when campus applications are installed from opment and runtime support for campus applications. Campus Syscall Request Campus Campus Campus Campus Fetch Location Campus Fetch News AppCampus AppCampus AppCampus App App App App CampusOS App App Syscall Response

CampusOS CampusOS

Update Location Update News Upload Cloud Location Campus Storage Service News Download Provider Daemon Crawler (a) (b) (c)

Figure 3: Patterns for CampusOS features

3.3 CampusOS vs. Middleware OS that could manage all computers and computing envi- Traditionally, middleware [1] is based on the operating ronments connected to the Internet may be too ambitious, system kernel, providing a glue layer between the operating CampusOS can serve as one tiny case within such a big goal. system and applications. Although the boundary between operating system and middleware is to some extent arbi- ACKNOWLEDGMENT trary, one could view CampusOS as a middleware system This work is supported by the National Basic Research when its dependence on traditional operating systems is Program of China (973) under Grant No. 2009CB320703, taken into consideration. the High-Tech Research and Development Program of China However, from a higher-level view, CampusOS is more under Grant No. 2011AA01A202, and the National Natural like an operating system, because its management of campus Science Foundation of China under Grants No. 61103026, data and services can be compared to the management of 61121063, U1201252. various resources in traditional operating systems. 3.4 Centralized vs. Decentralized References The Internet is a huge decentralized network. Managing [1] Bernstein, P. A. Middleware: a model for distributed data on the Internet in a centralized way is not possible. system services. Commun. ACM 39, 2 (Feb. 1996), 86– However, data on university campuses is quite limited com- 98. pared with that on the Internet, so centralized management [2] Dawson-Haggerty, S., Krioukov, A., Taneja, J., is feasible and will save much time and effort for campus Karandikar, S., Fierro, G., Kitaev, N., and application developers and users. Furthermore, we can also Culler, D. BOSS: building operating system services. manage decentralized Internet services, such as cloud storage In NSDI’13, pp. 443–458. and social network, in a centralized manner. [3] Dixon, C., Mahajan, R., Agarwal, S., Brush, In CampusOS, centralized management of data and ser- A. J., Lee, B., Saroiu, S., and Bahl, P. An vices conforms to the UNIX philosophy [8], like a monolithic operating system for the home. In NSDI’12, pp. 25– kernel. The modularity is achieved via the VFS abstrac- 25. tion and the unified syscall interface. The hierarchical Living PlanIT SA architecture also provides good separation and transparency [4] . The Urban Operating System. between campus applications and the underlying implemen- http://living-planit.com/UOS_overview.htm. tations of the whole system. [5] Mei, H., and Guo, Y. Network-oriented operating systems: status and challenges. Scientia Sinica Informationis 43, 3 (2013), 303–321. in Chinese. 4. CONCLUDING REMARKS [6] Mei, H., Huang, G., and Xie, T. Internetware: A In this paper, we argue that an operating system is software paradigm for internet computing. Computer needed for applications targeting communities like university 45, 6 (2012), 26–31. campuses. We present our design of CampusOS, which aims [7] O’Reilly, T. The State of the Internet Operating at providing an ecosystem that supports campus application System, 2010. http://radar.oreilly.com/2010/03/ development, deployment and maintenance. In our design, state-of-internet-operating-system.. CampusOS is not restricted to being used in only one Raymond, E. S. university. It can span multiple universities and provide [8] The Art of UNIX Programming. a universal computing platform for general-purpose campus Pearson Education, 2003. applications. Operating systems similar to CampusOS can [9] Tang, Y., Ames, P., Bhamidipati, S., Bijlani, A., be developed for organizations other than universities as Geambasu, R., and Sarda, N. CleanOS: limiting well. mobile data exposure with idle eviction. In OSDI’12, With the development and prosperity of Internetware, pp. 77–91. current operating systems and middleware systems should [10] Zhang, Y., and Zhou, Y. TransOS: a transparent collaborate to provide a common infrastructure to support computing-based operating system for the cloud. IJCC the development, deployment, execution and maintenance 1, 4 (2012), 287–301. of various Internet-based applications. While an Internet