Eleni Gessiou
email: gessiou@cis.poly.edu

Vasilis Pappas
email: vpappas@cs.columbia.edu

Elias Athanasopoulos

Angelos D Keromytis
email: angelos@cs.columbia.edu

Sotiris Ioannidis
email: sotiris@ics.forth.gr

Towards a Universal Data Provenance Framework using Dynamic Instrumentation

The advantage of collecting data provenance information has driven research on how to extend or modify applications and systems in order to provide it, or the creation of architectures that are built from the ground up with provenance capabilities. In this paper we propose a universal data provenance framework, using dynamic instrumentation, which gathers data provenance information for real-world applications without any code modifications. Our framework simplifies the task of finding the right points to instrument, which can be cumbersome in large and complex systems. We have built a proof-of-concept implementation of the framework on top of DTrace. Moreover, we evaluated its functionality by using it for three different scenarios: file-system operations, database transactions and web browser HTTP requests. Based on our experiences we believe that it is possible to provide data provenance, transparently, to any layer of the software stack.

Introduction

All systems occasionally store their activity in log files, a process we usually refer to as logging. A log file can contain error messages, warnings, and important information for a user debugging a problem or investigating the condition of a running process. However, traditional logging is very limited. It lacks of semantic and critical information related to the internal state of an object. For example, a log file can hardly represent the state change for a database executing a particular query. Thus, we seek of tools and technologies that can monitor an object and collect intrinsic information associated with its internal state. More precisely, instead of having a collection of log files containing warning and error messages we are interested in the data provenance information.

Data provenance -describing how an object came to be in its present state -is an area that has drawn much research attention lately. There is a number of schemes that have been proposed on how to apply it in practice and in widely used applications. Some representative provenance schemes have been proposed for file systems [START_REF] Muniswamy-Reddy | Provenance-aware storage systems[END_REF], databases [START_REF] Cheney | Provenance in Databases: Why, How, and Where[END_REF], web applications [START_REF] Geetika | Guest editors' introduction: Provenance in web applications[END_REF][START_REF] Michaelis | Towards provenance aware comment tracking for web applications[END_REF][START_REF] Theoharis | On provenance of queries on semantic web data[END_REF], cloud computing [START_REF] Muniswamy-Reddy | Provenance for the cloud[END_REF], smart phone operating systems [START_REF] Dietz | Quire: Lightweight provenance for smart phone operating systems[END_REF], and web browsers [START_REF] Margo | The case for browser provenance[END_REF]. One could argue that applying data provenance at a low level, e.g. at the system call-level, would be sufficient. However, that is not always the case. Applying data provenance to different layers of the software stack can provide different levels of information. In the database case, for example, it would be much more efficient to apply it at the query-level, where all the data, along with any metainformation (like ownership) is available, than at the system call-level, where one would get very limited information like I/O operations on file blocks. Also, in the web browser case, data provenance provided solely at the system-call level will be unable to capture and record higher-level information. This can be the URLs the browser renders, in the case the communication channel is over HTTPS. On the other hand, the function-call level, as provided by OpenSSL [START_REF] Viega | Network security with OpenSSL[END_REF], has access to the encrypted data stream used by an HTTPS connection.

By looking at these examples it becomes clear that depending on the case, data provenance must be provided at the layer closest to the information we would like to capture and document. This may prove to be a very challenging task, especially when dealing with large and complex software applications such as web browsers and databases. For example, Firefox 4 consists of more than 5M lines of code, spread in almost 40,000 files. In the case of MySQL 5.5, there are 1.2M lines of code, in almost 3,000 files.

In this paper, instead of exploring how we can extend an application to provide data provenance, we take an alternate route. We propose, and build, a universal data provenance framework using dynamic instrumentation. The main goal of our framework is to provide an easy way to prototype any data provenance scheme, no matter the size and complexity of the system it is applied on. We argue that lightening the implementation burden of such data provenance applications would lead research on this field forward, allowing researchers to test and evaluate their ideas more easily. Our framework is built on dynamic instrumentation, and especially on DTrace. Its key feature is that it can greatly assist the user in discovering paths in the system that interesting data pass through. For example, all URLs and search keywords that flow inside a browser. After the discovery phase, the user can dynamically instrument these points to record provenance about this transit data. Moreover, in cases where the source code of a system is available, our framework could be used for simply discovering points of interest in the system and evaluating a data provenance application. Then, prototyping a low-overhead source-code level implementation of the data provenance application at production level is trivial, as the user knows exactly which points to instrument in the system.

The choice of dynamic instrumentation for such cases seems ideal as it provides several advantages. First of all, it requires no changes to the source code of the system that data provenance capabilities are going to be added in. Second, it can be easily enabled or disabled, even at runtime in some cases, as we shall see later on. Finally, it removes the requirement of having the source code, although having it could be helpful during the discovery phase. On the other hand, the main disadvantage of dynamic instrumentation is its runtime overhead. However, this is not an issue in our case as we perform system-call and function-level, but not instruction-level instrumentation, which can be extremely expensive.

Contribution. The contributions of this paper are the following.

-We deliver a generic instrumentation framework for acquiring information at the system-call and function-call level. The collected information can reveal data provenance information. -We design techniques for easily discovering the important points, which are associated with particular state changes of a process. For example, our framework can automatically discover the functions that process SQL queries in SQLite. -We provide three case studies with real world systems: (a) a file system , (b) a database (SQLite), and (c) a web browser (Safari).

Background

Tracing is the process of observing the execution of a program for collecting useful information of diagnostic and systemic nature. Various techniques have been developed for supporting this facility throughout the development cycle as well as after the deployment of a system. Instrumentation is one such technique that allows someone to augment the execution of a program with new, userprovided, code that aids in collecting data for analyzing the behavior of a system. DTrace is a dynamic instrumentation utility that focuses on production systems. It allows the instrumentation of both user-level as well as kernel-level code in a unified and safe manner and has absolutely zero performance cost when disabled. Initially, DTrace was developed for Sun's Solaris 10, but it has been integrated also into Apple's Mac OS X/Darwin (since 10.5/9) [START_REF]Apple. dtrace(1) Mac OS X Manual Page[END_REF], FreeBSD (since 7.1) [START_REF] Freebsd | DTrace -FreeBSD Wiki[END_REF], as well as into other microkernel designs such as QNX (i.e., the Unix-like, real-time OS for embedded systems) [START_REF] Qnx | The community portal for qnx software developers[END_REF]. Moreover, Oracle Linux latest version included a port of DTrace for Linux [START_REF]Trying out dtrace[END_REF].

Since the primary focus of DTrace is production systems, it was designed around two key properties: (a) zero performance cost when disabled and (b) absolute system safety when enabled. Its dynamic nature allows to be injected on demand into virtually every place of a running system without suffering from the performance burden of static "disabled probes". Systems that support static instrumentation typically induce some disabled probes overhead. Dynamic instrumentation allows truly zero cost, since the probes are dynamically attached and detached on demand, and hence, they are "absent" when the instrumentation is disabled. User-provided instrumentation code, also known as analysis code is written in a high-level language, named D, that is subjected to a set of run-time checks for guaranteed safety. D is C-like but it also resembles AWK [START_REF] Aho | The AWK Programming Language[END_REF] a lot in terms of structure. It has support for all ANSI C operators, it allows access to user-and kernel-level variables and data structures, and offers dynamic user-defined variables, structs, unions, and associative arrays. The scoping rules of the language, its intrinsic data types, as well the program structure are explained in great detail in [START_REF] Cantrill | Dynamic instrumentation of production systems[END_REF].

The core part of DTrace lies inside the OS kernel and includes all the necessary facilities for providing an infrastructure for dynamic, arbitrary, tracing. User-level processes become DTrace consumers by communicating with that inkernel component and enabling instrumentation. However, the DTrace framework does not perform any instrumentation of the system. This functionality is provided by the providers; kernel-level parts, typically loadable modules, that communicate with the core engine using a well-defined API. Providers declare to DTrace the points that can potentially instrument by providing a callback function. All in all, DTrace provides merely a skeleton for supporting future instrumentation methodologies. Nonetheless, it comes with a set of ready-to-use providers that have no observable overhead when disabled.

Design

The goal of the framework is to extract and gather provenance information related to the activity of complex systems, such as a web browser or a database. The collection of information is carried out by monitoring a process at the system-call and function-call level. This task requires the knowledge of all valid entry points, where data flows inside the running process. We refer to all system and function calls, which process critical information as valid entry points. For example, a modern web browser, such as Mozilla Firefox, has a function that processes each input URL. This function is critical, since each processed URL denotes a semantic transition in the state of the web browser during its life cycle. The framework is generic enough for allowing information gathering from multiple valid entry points. The core engine of the framework is based on DTrace, which gives all low-level primitives for dynamic instrumentation of running processes. Furthermore, we provide two basic features for reducing the complexity associated with identifying interesting valid data entries. First, we provide a highly configurable logging component and, second, we provide assisted discovery. We now analyze both of these features in detail.

Configurable Logging

The logging component delivers the core functionality of our framework as it is responsible for generating provenance information. By default, the component monitors all system calls of all running process. For each monitored system call the following information is collected: (a) system-call arguments, (b) return value, (c) user id, (d) process name, (e) process id and (f) timestamp. The component provides an interface where a user can configure which processes and which system calls are monitored. This component can also be configured to log library function calls, by specifying the library's name along with the name of the function. For example, a security researcher who wants to monitor all symmetric cryptographic operations of a running program, can specify a monitoring set of valid entry points composed by: EVP EncryptInit ex, EVP EncryptUpdate ex, and EVP EncryptFinal ex. All these three functions can be found in the OpenSSL [START_REF] Viega | Network security with OpenSSL[END_REF] library which is used as the de facto standard for cryptographic operations.

Another example is the following. Suppose that we want to log all the write() system calls issued by the text editor vi. In that case, the following script is generated by our framework (note that the predefined variable arg0 holds the return value in the second probe):

syscall::write:entry /execname == "vim"/ { self->arg1 = arg1; } syscall::write:return /execname == "vim" && self->arg1/ { printf("%Y %s (%d) uid %d write: %s -> %d", walltimestamp, execname, pid, uid, copyinstr(self->arg1), arg0); self->arg1 = 0; }

Assisted Discovery

Complex systems, such as web browsers and databases, are composed by a huge code base. While these systems run, there are many different transitions that can significantly alter their state. For example, each query processed by a database can trigger a group of transitions that will drive the database in a completely new state. It is challenging to identify all valid entry points, which initiate all these state transitions. A key feature of our framework is that it can greatly reduce the search space of such points. This is achieved by first instrumenting all the functions and checking for a specific value that the user has given as input in the argument list of the monitored system. If found, the name of the function, the call stack, or both, are logged. Then, the user can decide which of the collected functions qualify as valid entry points. The subset of functions narrowed down by our technique is significantly reduced compared to the overall size of the system in the average case.

Example: We now present a real-world example for a better understanding of how assisted discovery works. Suppose that we have a new application for data provenance in a database system. To evaluate its efficiency, we first need to log all the queries. Normally, we have two options. We can either download the source of the database and find the appropriate places in the code for logging the queries, or, we can proxy the inputs (queries) of the database system using an external software component. The first approach can be very difficult, depending on the size and complexity of the system, or completely infeasible, in case the source code is not available. The second one would be difficult to enable/disable as it would require restarting the database system. In addition, a proxy can hardly provide any information associated with internal states of the system. For example, consider a SQL query which is triggered by a user-generated query and it is initialized and executed internally in the database for optimization purposes. This query cannot be captured by the external proxy, since it is generated internally inside the database. On the other hand, our framework can easily discover the appropriate points for monitoring and logging any information we need transparently and on demand. This is achieved by instrumenting all the functions within the database system and search for a special argument value, at runtime. This argument value should be a query string, like 'SELECT assisted FROM discovery;', and the output of our framework will be a set of function names that had this character sequence as an argument.

Case Studies

To demonstrate the effectiveness of our framework, we evaluated it in three scenarios, namely file-system, database and web browser data provenance. The reason behind choosing these applications is because they have been already studied in the literature [START_REF] Muniswamy-Reddy | Provenance-aware storage systems[END_REF][START_REF] Cheney | Provenance in Databases: Why, How, and Where[END_REF][START_REF] Margo | The case for browser provenance[END_REF]. The case studies are presented in order of increasing complexity for our framework and, interestingly, the most complex one revealed some limitations that we consider in Section 5.

File-system

Data provenance in the context of file-systems was introduced in PASS [START_REF] Muniswamy-Reddy | Provenance-aware storage systems[END_REF]. To gather provenance information, PASS was implemented in the Linux kernel. Here, we show how we can gather similar information using our framework, without having to dig and alter the code of the kernel. We define the set of system calls that create or change the current state of data, as provenance in a file-system. This set includes the following systems calls: creat, write, chmod, chown and unlink. We also include the open system call for completeness. The output includes a timestamp (indicating the exact moment that the system entered a system call), the executable's name, the process id and the user id that makes the system call. Also, in case that the system call's arguments contain useful information, like the location of file, or the file's permissions, we log this information too.

An example of the information that is recorded by our framework when a user edits a file using the TextEdit application on Mac OS X is shown bellow: This scenario shows that using the powerful logging capabilities of our framework we can gather system call level information about the file-system by simply specifying the set of the file-system related system calls, without performing any changes in the operating system itself.

Database (SQLite)

The second scenario we consider is in the context of databases and demonstrates the assisted discovery feature of our framework. Our goal is to locate the appropriate point (i.e., function) to log queries in SQLite [START_REF]Sqlite[END_REF]. Initially, we created a simple table with a few columns and added some test data. Then, our framework instrumented all the functions in libsqlite3.dylib4 at runtime.

Then, while assisted discovery was enabled, we performed a few different types of queries (insertions, deletions, updates, etc.). Each time the given query string appears in the argument list of an instrumented function, assisted discovery logs it. An example of these logs is the following:

sqlite3 (27426) libsqlite3.dylib:sqlite3_prepare_v2 'create table ..'
Our framework logged several functions, but, just by looking at their names, it was obvious that sqlite3 prepare v2 was the most appropriate function to instrument in order to log all the queries. Then, given the syntax of each SQL command, we parsed them in order to keep track of any changes made to the database. Generally, the provenance information about the database entries include the creation (create) and deletion (drop) of tables and their contents Discovery (functions in use)

Instrumentation (functions in use)

Extraction and Parsing

(SQL statements) Output (Provenance records) Fig. 2. The steps extracting provenance information from the SQLite database system using assisted discovery.

(inserts) with corresponding timestamps. Also, the process name and id combined with the user id are logged for every SQL command that is executed. The procedure described above is also depicted in Figure 2.

We also calculated the performance overhead of logging provenance information using dynamic instrumentation versus logging the same information by altering the source code. We modified the sqlite3 prepare v2 function to record every SQL query made. Then, we measured the total time needed to perform one million insert operations in both versions of SQLite, the non-modified but dynamically instrumented and the modified one. On average, the performance overhead of dynamic instrumentation in this case was around 0.8%. Thus, for simple operations, like logging, there is no much difference performance-wise.

Web browser (Safari)

Another example for applying the idea of provenance is that of the browser. We treat the notion of data provenance in a browser as it has been proposed in [START_REF] Margo | The case for browser provenance[END_REF]. The main idea is the correlation between a search term and the URL that the user finally follows from the search engine. In other words, a search term is the provenance of the URL that the user asks for.

We implement this scenario by tracking the system calls that are called, such as read, write, send and recv using our framework. Although sufficient as a proof-of-concept implementation, we have to note that system call level tracking produces redundant information. It becomes too hard to separate the useful information for provenance from "noise". Moreover, the system call level instrumentation cannot be used when data are encoded, encrypted, etc. Finally, assisted discovery failed to locate functions, in a higher level than system calls, where the search keywords and the URLs could be logged. We discuss more about this in Section 5.

Discussion and Future Directions

The last usage scenario, extracting provenance information from a web browser, revealed some interesting limitations of our framework against very large and complex systems. These limitations are mostly due to the restricted instrumentation actions of DTrace. Combining a more powerful tool in our framework, like the dynamic binary instrumentation of Pin [START_REF] Luk | Pin: building customized program analysis tools with dynamic instrumentation[END_REF], seems sufficient to overcome these limitations, but in some extra cost. Also, tools implemented on top of Pin, like libdft [START_REF] Vasileios | libdft: Practical dynamic data flow tracking for commodity systems[END_REF] which provides byte-level data flow tracking, could potentially add more features to our framework.

Although Pin does not come built-in in any operating system, it can be installed in many of them, like Microsoft Windows, Linux and Mac OS. As DTrace, Pin can also be used to instrument arbitrary functions and system calls, but not on demand. The program to be instrumented has to be executed through Pin. The main advantage of Pin over DTrace though is that there is no limit in what an instrumentation actions can be. Although that may not seem very important, there are at least two cases that this feature extends the functionality of our framework. First off, we can better track the data in the assisted discovery phase when it is encoded, or encapsulated inside a complex type. As an example, suppose that we want to track a string value in a large software system that happens to use a custom string class and we know nothing about its internal representation. By using Pin during the assisted discovery phase though we can either convert them to simple character sequences or use any specific compare function they provide. The second advantage of unconstrained instrumentation actions is the ability to alter the state and the data of the program.

To better understand and demonstrate the extra functionality that such a tool adds to our framework, let us consider again the example of implementing data provenance in a browser. More precisely, suppose that in order to implement a hypothetical data provenance scheme we want to log all the URLs that a user navigated to in the Safari web browser. Safari uses the WebKit open source HTML rendering engine, where URLs are represented by class KURL.

To successfully track a user-input URL during the assisted discovery phase, the instrumentation action has to compare KURL objects with the input string. Then, after we locate the appropriate function to instrument in order to log all the URLs, our framework will convert the KURL object to a simple string and then log it along with a timestamp, etc. Data provenance has been a very active field of research lately, focusing both on theoretical and practical issues. We discuss below the works most related to our dynamic data provenance framework.

Most of the recent work has been on data provenance in database systems [START_REF] Buneman | Provenance in databases[END_REF]. Also, more theoretical aspects of the provenance notions (where, why and how) have been studied [START_REF] Cheney | Provenance in Databases: Why, How, and Where[END_REF]. In our work we focus on the practical aspects of data provenance, on any software application and not simply databases.

The authors of [START_REF] Margo | The case for browser provenance[END_REF] describe how a browser enabled with provenance capabilities can improve user experience. They provide several scenarios for history search, web search and download management, that a browser with provenance can offer. In Section 4.3 we show an example of how this kind of data provenance application could be achieved using our framework, without any modification to the actual web browser.

Story Book is a system that adds provenance in different systems [START_REF] Spillane | Story book: an efficient extensible provenance framework[END_REF]. It runs in user space and treats provenance events as a generic event log. It collects application-specific provenance and supports a file system and a database. PASS [START_REF] Muniswamy-Reddy | Provenance-aware storage systems[END_REF] supports provenance at the system level and is a layer grafted in a file system. It gathers provenance for all file activities by inspecting system calls. Again, an example of how this could be implemented using our framework is given later on. As an advantage, our approach requires no modifications to the file system, or any other layer for that matter.

Another system that combines both static and dynamic analysis to trace provenance is Garm [START_REF] Demsky | Garm: cross application data provenance and policy enforcement[END_REF]. While our framework is transparent, Garm has to rewrite the binary when the binary executed. The main advantage of our approach over Garm's is that our framework can be applied to any level of the system, capturing even very high-level information. On the other hand, Garm only operates on low level data operations.

Recently, the notion of provenance has also been introduced in cloud infrastructures [START_REF] Muniswamy-Reddy | Provenance for the cloud[END_REF]. Our framework could be successfully applied in such environments as well, as it is execution environment agnostic.

Transient provenance [START_REF] Jones | Tracking emigrant data via transient provenance[END_REF] keeps information about emigrant data, like files that were moved, who moved them, and when they were moved, aiming at facilitating the administrators in case of a leak. The authors propose the creation of ghost objects so as to be able to record when a file is leaked from the central system, and moreover by whom, by logging the user ID. This way, after an information leakage happens, the suspects, the timeline and the objects of leakage can be reduced up to the people, timestamps and files, recorded by the ghost objects, giving administrators a valuable hint.

iLeak [START_REF] Vasileios | iLeak: A lightweight system for detecting inadvertent information leaks[END_REF] is a system proposed for detecting inadvertent information leaks. Although not related to data provenance, iLeak is related to our work as it is also implemented on top of DTrace. Any sensitive data within a system have to be initially marked with the appropriate tags. Then, iLeak constantly monitors for their leakage by dynamically instrumenting the system's communication channels (sockets, SSL connections, etc.) using DTrace.

We designed and implemented a data provenance framework that can be used for rapid prototyping of any data provenance scheme. Our framework is built on dynamic instrumentation and provides an easy way to locate the right points to instrument, as well as a configurable logging component.

Our experience from implementing three real-world examples of data provenance applications, already proposed in the literature, demonstrated the easiness and practicality of our framework. Moreover, some limitations that were revealed under very large and complex systems open room for improving our framework by integrating more powerful dynamic instrumentation tools.

Fig. 1 .

 1 Fig.1. A complex scenario where provenance information from different sources is combined.

2012

  Jan 7 23:44:52 TextEdit (23624) uid 501 open: .../paper.txt -> 15 2012 Jan 7 23:44:52 TextEdit (23624) uid 501 write: 15, My paper -> 9 2012 Jan 7 23:44:52 TextEdit (23624) uid 501 close: 15 -> 0

.dylib is the filename extension for dynamically loaded libraries in Mas OS X.

Acknowledgements

The project was being co-financed by the European Regional Development Fund (ERDF) and national funds, was a part of the Operational Programme "Competitiveness & Entrepreneurship" (OPCE II), Measure "COOPERATION" (Action I). This work was also supported in part by DARPA Contract FA8650-11-C-7190, NSF Grant CNS-09-14312, FP7-PEOPLE-2010-IOF project XHUNTER and Marie Curie Actions -Reintegration Grants project PASS. Any opinions, findings, conclusions or recommendations expressed herein are those of the authors, and do not necessarily reflect those of the US Government, DARPA, or the NSF.


Shuhao Li

Xiaochun Yun
email: yunxiaochun@iie.ac.cn

Zhiyu Hao

Yongzheng Zhang

Xiang Cui

Yipeng Wang

Modeling Social Engineering Botnet Dynamics across Multiple Social Networks ⋆

Keywords: network security, social network, social engineering attack, botnet, propagation model

In recent years, widely spreading botnets in social networks are becoming a major security threat to both social networking services and the privacy of their users. In order to have a better understanding of the dynamics of these botnets, defenders should model the process of their propagation. However, previous studies on botnet propagation model have tended to focus solely on characterizing the vulnerability propagation on one infection domain, and left two key properties (crossdomain mobility and user dynamics) untouched. In this paper, we formalize a new propagation model to reveal the general infection process of social engineering botnets in multiple social networks. This proposed model is based on stochastic process, and investigates two important factors involved in botnet propagation: (i)bot spreading across multiple domains, and (ii)user behaviors in social networks. Furthermore, with statistical data obtained from four real-world social networks, a botnet simulation platform is built based on OMNeT++ to test the validity of our model. The experimental results indicate that our model can accurately predict the infection process of these new advanced botnets with less than 5% deviation.

Introduction

Botnets, which are considered to be the platforms of cyberattacks, have the ability to send spams, launch DDoS attacks and steal sensitive information. They have become a growing risk with the potential to severely impact important infrastructure components like communication systems. In recent years specifically, the rapid development of social networking services (SNS) [START_REF] Kwak | What is Twitter, a social network or a news media?[END_REF] and the diversification of social engineering attacks (SEA) [START_REF] Abraham | An overview of social engineering malware: Trends, tactics, and implications[END_REF] demonstrate that new widely spreading botnets have become an emerging threat to social networking services and personal privacy in social networks (SN). Comparing to traditional botnets, the evolved variety have the ability to not only steal and abuse social network users' digital identities, but also to disseminate a large number of advertising messages in social networks. In addition, they can also employ SEA to spread bots across multiple social networks. Therefore, the infection scope is significantly expanded by these new botnets. For example, the Koobface botnet [START_REF] Thomas | The Koobface botnet and the rise of social malware[END_REF], which was initially launched in the scope of Facebook and MySapce, is one of the most popular botnets in social networks. Up to now, it has generated 56 variants and infected more social networks than originally anticipated ones.

We believe that new advanced SEA botnets (similar to Koobface, but more destructive) will emerge in large numbers, resulting in wide-scale damage to social networks. This belief is based on the following observations:

1) These botnets have the ability to capture bots by using SEA, which is much easier than other intrusion means. SEA greatly reduces attacking difficulty for hackers, although it requires the participation of users to complete the injection of bot programs.

2) With the characteristic of cross-domain propagation, the botnets are able to disseminate bot programs from one social network to another, which makes the infection rate of the bot programs much wider and faster.

In order to know more about the evolution and dynamics of botnets and how to mitigate them effectively, defenders should first be able to measure and predict the size of botnets. Therefore, modeling botnet propagation has become an important research direction. In this paper, we propose a propagation model based on stochastic process, to describe the complex infection process of new botnets in social networks. In order to develop a more accurate description than those in previous attempts, both the properties of botnet cross-domain spreading and user dynamics (the variation of active users and users' responses) in social networks are investigated in our model. We believe the proposed model in this paper could be a practical and effective tool for social network administrators and botnet defenders, who are currently struggling against such botnets (e.g., Koobface).

Our contributions are summarized as follows:

1) We have formalized a new propagation model to predict the general infection process of new social engineering botnets in social networks based on stochastic process. Two factors (the cross-domain spreading and user dynamics) found to significantly influence the infection of botnets, are well investigated in our proposed model. It was able to predict the infection process of these new botnets with a small deviation.

2) We have provided a botnet simulation platform based on OMNeT++ [START_REF] Varga | An overview of the OMNeT++ simulation environment[END_REF] with the statistical data obtained from real-world social networks. It was applied to simulate and evaluate the propagation process of these new botnets. In the proposed platform, multiple behaviors of social network users are simulated with a guarantee of efficacy, which is considered to be superior to other botnet simulators [START_REF] Ruitenbeek | Modeling peer-to-peer botnets[END_REF] in the ability of generalization.

The remainder of this paper is organized as follows: Some related work is discussed in Section 2; and Section 3 is dedicated to the background on these new botnets; the proposed propagation model is introduced in Section 4; the simulation evaluation and experimental results are provided in Section 5; several limitations of our work are discussed in Section 6. Finally, we conclude the paper while highlighting the scope of future work.

Related Work

Several propositions in the literature exist for modeling malware propagation. In [START_REF] Zou | Email worm modeling and defense[END_REF], Zou et al. presented an email worm model, which revealed the significance of user behaviors by considering email checking time and the probability of opening email attachments. In [START_REF] Yan | Malware propagation in online social networks: nature, dynamics, and defense implications[END_REF], Yan et al. identified some parameters that are related to malware propagation in social networks. In [START_REF] Cheng | On Modeling Malware Propagation in Generalized Social Networks[END_REF], Cheng et al. proposed an equation-based model to analyze the mixed behaviors of delocalized and ripple based propagation, which is related to hybrid malware in generalized social networks. According to our knowledge, most of previous work introduced the propagation models based on a single infection domain, leaving cross-domain spreading and user dynamics unconsidered. However, there are a few exceptions. For example, Dagon et al. [START_REF] Dagon | Modeling botnet propagation using time zones[END_REF] used time zones to model the propagation process of some botnets, arguing that victims turn their computers off at night, which leads to diurnal properties in botnet activity. But their study represents only one factor involved in user dynamics.

Scene Analysis

Background

An SNS is an online service, platform, or site which focuses on the building and reflecting of social networks or social relations among people. There are many popular social networks (e.g., Facebook, Twitter, Gmail and Tencent QQ) with hundreds of millions of registered users connected through friendship links. The friendship link is generally a binary relationship, representing two users as friends. Usually, social network users connect, express themselves, or share information with social network messages. These messages may have different forms in different social networks, but typically have a similar function. Meanwhile, social network messages can be also exploited for the purpose of spreading malwares by attackers, especially social engineering hackers. These malwares can launch SEA, which relies on social disguises, cultural ploys and psychological tricks to persuade computer users in assisting hackers with their illegal intrusion or use of computer systems and networks [START_REF] Abraham | An overview of social engineering malware: Trends, tactics, and implications[END_REF].

To demonstrate the efficacy of our proposed model, we deployed several SNS crawlers to capture the statistical data of social network users' behaviors, which includes access time, online duration, and the interval time prior to users' responses. Finally, based on the social network generation algorithm in [START_REF] Toivonen | A model for social networks[END_REF], we built a simulation platform based on multiple virtual social network domains, which allows us to evaluate our propagation model in a controlled environment. In our experiment, we designed the user model according to real statistics obtained from our SNS crawlers, and then simulated the whole infection process of these new botnets. Our experimental results show that our model can yield an accurate prediction on the size of the new botnets, on the condition of the topology information obtained from related social networks and the information of the initial infected nodes detected in the social networks.

The SS-botnet Propagation Process

To more clearly describe this issue, we first provide two key definitions:

Definition 1.
A trap message is a social network message which is constructed with either bot programs already embedded within, or with a means of accessing them ( e.g., download URL). This message is forged with a social engineering approach, and designed to appear attractive to victims.

Definition 2. The botnet making use of trap messages for the purpose of spreading bots in one or more social networks is referred to as a Social network & Social engineering botnet (SS-botnet for short).

It can be seen that SS-botnets represent a class of advanced widely spreading botnets. Generally, the propagation process employed by SS-botnets can be divided into four steps. Fig. 1 illustrates the infection process of an SS-botnet across three social networks.

Step 1 Botmasters fabricate a trap message, which is similar to normal social network messages and attractive to receivers.

Step 2 Botmasters construct the command (marked as CMD in Fig. 1) with the trap message, and send CMD to the bots under the control of them.

Step 3 The target bot extracts the trap message from CMD, and then impersonates the victim user to send the trap message to all the friends of the user. We set this time to t s .

Step 4 The victim's friends start to deal with the trap message after a uncertain time interval (assume this time is t r ). Generally, they have two choices: believing the trap message (by activating the bot program within the trap message), or avoiding it (by recognizing it as a threat). In the former case, if the antivirus software can't detect this threat, their computers will be infected and become bots, attacking other computers (Step 3). In the latter case, the users' computers become immune to the botnet infection due to the users' security awareness and exercise in judgement.

For the initial stage of SS-botnets' propagation, botmasters can anonymously register several accounts in one or more social networks to disseminate trap messages and capture the first group of initial bots. In addition, if the propagation is blocked by an effective defense, botmasters have the ability to design new bot programs and trap messages for the purpose of bypassing this defense. As such, the SS-botnet can continue with high-speed infection, and maintain their ability to attack.

Affecting factors

We believe that there are two key factors affecting the propagation of SS-botnets as follows.

1) Cross-domain spreading A cross-domain node is a social network node with the ability to allow its user to use more than one social networking service. Since the users of cross-domain nodes have access to multiple social networking services, they typically have different friends in different social networks. To illustrate the threat involved with this, envision the following scenario: botmasters design the bot program to disseminate the trap message from one social network to another. This will make the infection radius of SS-botnets wider and the rate faster. Therefore, cross-domain spreading should be taken into full account while developing the SS-botnet propagation model.

2) User dynamics The variation of active users. Intuitively, if a social network node is not active (i.e., its user isn't online in any social network at this time), it is impossible to infect others or to be infected by others. Therefore, the time of users' visiting social networks, and how long they remain active on each network, have a great impact on the infection process of SS-botnets.

Users' responses. The general process of the SS-botnet propagation requires users' responses to the trap messages propagated by bot programs, although the response behaviors are often unintentional. It would seem that when the receivers deal with the trap message and the probability that users are deceived by trap messages also have a great effect on the infection process of SS-botnets.

Modeling Methodology

Related Notations

The related notations of our propagation model are provided in Table 1. The node with index i V

The set of all nodes under considersion K

The number of social network domains D k

The social network domain with index k e ij,k

The variable indicating the relationship between ni and nj in D k pi,t

The probability that ni is infected at time t It

The set of bots at time t twi

The time interval before ni's response αij,t

The connectivity between ni and nj at time t Act(i,k,t)

The function indicating whether ni is active in D k at time t βi

The immunity to bots for ni S0

The set of the original infected nodes

Theoretical Description

We assume an SS-botnet can spread bots in K social network domains and the topologies of these domains are known. The set V is given by

V = K ∪ k=1 D k (1)
There are cross-domain nodes in the set of V , which belong to more than one domain. We can formulate this case as follows:

∃k 1 , k 2 ∈ [1, K] → D k1 ∩ D k2 ̸ = ∅ (2)
A cross-domain node has the ability to be active in more than one domain simultaneously, a single domain, or no domain at any time. In the propagation process of SS-botnets, it is possible that a node is in the offline state at a given time (because the user may not be online in any social network). Obviously, the infection can't work for the offline nodes. Without loss of generality, we assume D 0 is a special domain where offline nodes reside.

We assume the time interval from sending the trap message (t s ) to the receiver's response (t r ) is tw. And tw = t rt s . From a statistical point of view, it can be found that tw follows a heavy-tailed distribution according to [START_REF] Barabási | The origin of bursts and heavy tails in human dynamics[END_REF] P r(tw

) = τ (tw) τ +1 (3)
Where tw > 1 and τ > 0. In addition, τ determines the mean of tw, which have different values for different social networks.

We employ the discrete-time stochastic process to model the propagation process of SS-botnets. The justification for employing the stochastic process is as follows: (i)The cycle time of sending a trap message, which has been fixed in the design of bot programs, can be discretized. (ii)The parameter tw can be discretized, which won't alter the characteristics of the tw distribution. n i is not infected at time t if and only if it was not infected at time (t -1), and effectively blocked or ignored all trap messages sent by its friends in the same social network domain at time (ttw i ). These events are independent, therefore p i,t can be expressed as

1 -p i,t = (1 -p i,t-1 ) • ∏ j̸ =i (1 -β i • α ij,t • p j,t-twi ) (4)
We use the approximation equation (1x)(1y) ≈ 1xy (when x ≪ 1, y ≪ 1) to simplify Equation 4. Since p i,t-1 ≪ 1 and p j,t-twi ≪ 1, we can get

p i,t = p i,t-1 + β i • ∑ j̸ =i (α ij,t • p j,t-twi ) (5)
From Equation 5, it is seen that the current state of n i depends on both the state of n i at time (t -1) and the states of its friends at time (ttw i ). In addition to this, the parameter α ij,t indicates the connectivity between n i and n j at time t, dictating the probabilistic behavior of the stochastic process; while the parameter β i indicates the immunity to bots for n i , affecting the result of the infection process.

First, we analyze α ij,t , which can be stated as

α ij,t = K ∑ k=1 Act(i, k, t) • Act(j, k, t -tw i ) • e ij,k (6)
Then the function Act() is given by

Act(i, k, t) = { 1 if n i is active in D k at t , 0 otherwise. (7)
Additionally, the value of e ij,k in Equation 6 can be determined according to the given topology of relationships in social network domains. From Equation 6, we can see that if n i and n j are friends in one or more domains, and n i is active at t while n j is active at (ttw i ), α ij,t 1; 0 otherwise. And α ij,t ∈ [0, K].

Next, we describe β i , which expresses the ability of a user to assess and judge the trap message, along with the anti-bot capability of n i . For simplifying the calculation, we set β i ∈ (0, 1]. The smaller the value of β i is, the larger the probability that the user remains uninfected will be. When β i approaches to zero, n i is hardly infected by bot programs, and if β i = 1, n i will be captured as long as it is attacked by other infected nodes with the trap message.

For the propagation process of an SS-botnet, we are concerned about the total number of bots at a given time (i.e., the future size of an SS-botnet). Let I t denote the set of infected nodes at time t, and the expectation of |I t | is given by

E(|I t |) = |V | ∑ i=1 p i,t (8)
The propagation process is initiated by infecting a given number of nodes, which belong to the set S 0 . And the initial condition can be stated as

p i,0 = |S 0 | |V | (9)
Where |S 0 | 1.

Evaluation

In this section, we firstly introduce the statistical investigation for determining α ij,t . Subsequently, we examine the ability of our proposed model to predict the propagation process of an SS-botnet, with a goal of achieving early warning. Finally, we analyze the effects of the cross-domain spreading and user dynamics.

Statistical Investigation

In order to apply the proposed model to the prediction of the real-world SSbotnet dynamics, we should make the value of the parameter α ij,t in accordance with realistic situations. For the topological information of social networks, there are two factors affecting the value of α ij,t : (i)the visiting time and (ii)the duration of active users. The former can be determined by the number of active users in target social networks at given time point, while the latter can be modeled by a heavy-tailed distribution [6] [7]. Assume that the total number of users in a social network is more or less constant over a short period of time, and let N t k represent the total number of users in D k . Furthermore, we use N a k,t to represent the number of active users in D k at time t.

In our investigation, we design some crawlers for fetching the number of active users in four popular social networks. The whole operation process lasted about three months with a sampling cycle of one hour. The studied social networks are: the BBS of Graduate University of Chinese Academy of Sciences (KYXK BBS) [START_REF] Kyxk Bbs | [END_REF], the BBS of Tsinghua University (SMTH BBS) [START_REF] Smth Bbs | [END_REF], QQ Game and QQ Instant Message (QQ IM) [START_REF] Tencent | [END_REF]. Fig. 2 shows the statistical results. From Fig. 2 it can be found that the number of active users is typically at a low level from midnight to 8:00, and at a higher level from 13:00 to 22:00. The minimum value (at 5:00) is about 1/3 of the maximum. Furthermore, we find that the diurnal variation trends of active users in these four social networks are very similar. Therefore, our equation assessing the visitation time and the duration of users is as follows:

N a 1,t N t 1 ≈ N a 2,t N t 2 ≈ ... ≈ N a K,t N t K = R t (10)
Where R t denotes the ratio of N a k,t and N t k . Thus α ij,t can be calculated as follows: Where Dc ij indicates the common social network domains of n i and n j , and the value can be determined with the given topological information of the target social networks.

α ij,t = (R t ) • (R t-twi ) • ( D k ∈Dcij ∑ k e ij,k ) (11

Simulation Experiment

OMNeT++ is an extensible, modular, component-based C++ simulation framework used for building network simulators. We've built a simulation platform based on OMNeT++ for the purpose of evaluating our propagation model. The simulation is made comparable to real-world situations by adjusting the values of the property parameters (e.g., the out-degree and in-degree of nodes and the small average shortest path length). Thus, we can claim the three following characteristics of our simulation platform:

1) High extensibility: this platform can simulate several virtual social networks simultaneously, and every virtual social network is generated according to the algorithm in [START_REF] Toivonen | A model for social networks[END_REF].

2) Fine-grained: the platform can simulate multiple behaviors of nodes, such as when to deal with the trap message.

3) High flexibility: in our platform, the interval between discrete time points can be adjusted to simulate the infection processes of different SS-bontets.

In our platform, we designed a virtual SS-botnet that can spread across two social network domains, and then simulate the propagation process of the SSbotnet. Additionally, we assume β i follows the uniform (0, 1) distribution. The values of related parameters are shown in Table 2. Fig. 3 shows the comparison between our model and the results of two simulations for the propagation process of the SS-botnet in one and two domains. The comparison indicates that our model can accurately predict the size of an SS-botnet with less than 5% deviation.

Furthermore, we experiment with MATLAB for evaluating the influence of different factors on the infection of the SS-botnet according to our model, which yielded some intriguing results (as shown in Fig. 4).

Fig. 4(a) illustrates the influence of the diurnal variation of active users on the propagation process of SS-botnets. Since the starting time of our simulation is 5:00, it can be found that the infection speed in the daytime is much faster than in the night, presumably because more users are offline at night. Fig. 4(b) illustrates the influence of the factor tw. If tw is not taken into consideration, the infection rate will be faster but not realistic. Fig. 4(c) presents the propagation processes of different numbers of cross-domain nodes [START_REF] Ruitenbeek | Modeling peer-to-peer botnets[END_REF][START_REF] Tencent | [END_REF]100). It can be found that the proportion of cross-domain nodes can also affect the infection rate of the SS-botnet. In other words, the more cross-domain nodes available for infection are, the faster the SS-botnet will spread. Fig. 4(d) illustrates the influence of both the degree and the number of initial infected nodes. In this figure, a popular node is the node with a high in-degree, which is different from a normal node. It's shown that choosing popular nodes as initial nodes or increasing initial nodes can accelerate the infection rate.

Limitations and Discussion

In this section, we discuss some limitations of our propagation model. Firstly, in the proposed model we assume that social networks are static when considering their topological characteristics and the initial set of infected nodes. In reality, however, the number of registered users and the relationships in real-world social networks are always changing, which makes the propagation process of SSbotnets more complex. We believe these real-life variations are very important factors which should be considered in future work. Secondly, the parameter β i follows a uniform (0, 1) distribution in our model, while in reality it may follow other distributions (such as a beta distribution). In future work, we plan to investigate the distribution of β i to optimize our model. Finally, since SS-botnets are emerging and our work is a prospective study, there is no real attack data available for the validation of our model. In addition, fetching the information of an SS-botnet's bots is more related to the detection technologies, which is beyond the scope of this paper.

Conclusion

In this paper, we present a new propagation model for SS-botnets which represent an new type of emerging botnets and have a growing risk to social networking services. By exploiting the general infection process of SS-botnets, we reveal two key factors that affect the infection of SS-botnets: (i)the cross-domain spreading of bots and (ii)the dynamics of social network users. Next, we propose the theoretical description of the proposed model based on stochastic process, and determine the values of some important parameters in our model with statistical data obtained from real-world social networks. Furthermore, we built a platform based on OMNeT++ for simulating the propagation process of SS-botnets to evaluate our model. The experimental results indicate that our model has the ability to accurately predict the size of SS-botnets with a small deviation. In future, we would like to make our simulation platform more comprehensive to support the further study of the SS-botnet dynamics. And then, we will focus more research on the ways to fight against SS-botnets. Our ultimate goal is to utilize the proposed model and our simulation platform to help defenders design effective containment mechanisms of SS-botnets.

4 Fig. 1 .

 41 Fig. 1. The general process of SS-botnets' propagation

Fig. 2 .

 2 Fig. 2. The diurnal variation of active users in social networks

Fig. 3 .

 3 Fig. 3. The comparison between our model and the simulation results

Fig. 4 .

 4 Fig. 4. The influence of different factors

Table 1 .

 1 The notations in the proposed model

	Notation	Explanation
	ni

Table 2 .

 2 The values of the relative parameters in the simulation

	Parameter	Value
	N t k	10000
	|V |	10000 and 20000
	K	1 and 2
	|S0|	1 and 100
	τ in the distribution of tw	1 and 1.5
	the max out-degree in D k	100
	the mean of βi	0.7
	the starting time	5:00

⋆ This work was supported by "The National High Technology Research and Development Program of China"(863 programs: No.2007AA010501) and "The National Natural Science Foundation of China" (No.60703021, No.61003261 and No.61070185).


Feifei Wang

Ping Chen

Bing Mao

Li Xie

RandHyp: Preventing Attacks via Xen Hypercall Interface

Keywords: Xen, Hypercall, Protection, Randomization

Virtualization plays a key role in constructing cloud environments and providing services. Although the main jobs of the hypervisors are to guarantee proper isolation between domains and provide them services, the hypercall interface provided by the hypervisor for cross-layer interactions with domains gives attackers the possibility to breach the isolation or cause denial of service from inside the domains. In this paper, we propose a transparent approach that uses randomization technique to protect the hypercall interface. In our approach, even facing a total compromise of a domain, the security of the virtualization platforms can be guaranteed. We have built a prototype called RandHyp based on Xen. Our experimental results show that RandHyp can effectively prevent attacks via Xen hypercall interface with a small overhead.

Introduction

Nowadays, virtualization has gained an increasingly concern in both industry and academic world. Cloud hosting providers have exploited the abstraction and isolation provided by the hypervisor to allow individual paying customers to share large-scale datacenter facilities, such as Amazon EC2 [2], and Linode [3]. A lot novel projects also take advantage of hypervisor's supervision property in intrusion detection systems [START_REF] Wang | HyperSafe: A Lightweight Approach to Provide Lifetime Hypervisor Control-Flow Integrity[END_REF], workload isolation [START_REF] Gupta | Enforcing Performance Isolation Across Virtual Machines in Xen[END_REF], attack investigation and debugging [START_REF] Kamble | Evolution in kernel debugging using hardware virtualization with xen[END_REF], and system monitoring [START_REF]Xenaccess library[END_REF].

However, all these applications are based on the belief that the hypervisor is sufficiently trustworthy to provide services and maintain isolation. But is it really like that? While the hypervisor itself can be regarded as secure due to its small size and a well-defined narrow interface, a number of different commodity operating systems are coresident on the same host [START_REF] Ristenpart | Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds[END_REF], numerous vulnerable applications communicate with the uncertain outside world [START_REF] Hoang | Protecting Xen Hypercalls. Intrusion Detection/Prevention in a Virtualized Environment[END_REF]. Under these circumstances, it is very likely that by exploiting the vulnerabilities of applications and operating systems, attackers can compromise a domain in the same way as they do in conventional operating systems. After that, attackers can escalate priviledges by applying to the hypervisor for illegitimate resources, which may lead to information leakage or denial of service. Specifically, if dom0 is compromised, attackers are able to access other domains' memory and I/O informations, and even create or shutdown other domains at will. In situations where dom0 is simplified to reduce the vulnerabilities exposed [START_REF] Steinberg | NOVA: a Microhypervisor-Based Secure Virtualization Architecture[END_REF], attackers can turn to compromise domUs. And according to CVE bug reports (e.g. CVE-2011-1898, CVE-2010-4238)[1], domU users can gain dom0 privileges and can either cause a denial of service or read arbitrary files in dom0. Further, any domain can be dominated to keep requesting critical resources, such as cpu and memory, which may lead to denial of services to other domains.

Since the hypercall interface is used to access hardware resources and execute sensitive instructions, the malicious goals listed above have to be achieved by invoking hypercalls. Therefore, preventing the hypercall interface from being used is very essential.

In this paper, we present solutions to protect domains by using Xen hypercall interface randomization technique. In our approach, all hypercall invocations are classified into trusted ones or untrusted ones. For the trusted ones, we randomize each hypercall's arguments, including its hypercall number. We also add paddings to the arguments and permute both the paddings and the arguments to further make our approach less breakable. The untrusted ones do not get randomized and are regarded as invalid by the hypervisor. In such a case, even attackers can get into a domain, he can not further elevate his priviledges by exploiting the hypercall interface, and thus avoid more serious damage to the whole system.

We present RandHyp, a modified version of Xen with para-virtualized Linux platforms as dom0 and domUs. Our experimental results show that RandHyp can successfully prevent untrusted hypercalls from executing while incurring low performance penalty.

The rest of this paper is organized as follows. The next section presents a short related work section about existing security machenisms in virtualization platforms. Section 3 identifies the threat model, explicits our design goals, and gives the design overview. After that, the implementation of RandHyp is described, following by a brief security analysis. The evaluation results are given in section 6, and section 7 concludes this paper.

Related Work

Existing security measures, like mandatory access control (MAC) [START_REF] Mccune | Shamon: A System for Distributed Mandatory Access Control[END_REF] and trusted platform module (TPM) [START_REF] Garfinkel | Terra: A Virtual Machine-Based Platform for Trusted Computing[END_REF], can not be directly applied to protecting the Xen hypercall interface. Most previous efforts concentrate on reducing the probability of domains being compromised by monitoring domains from the hypervisor level [START_REF] Chen | Ports: Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating System[END_REF][START_REF] Wang | Countering Kernel Rootkits with Lightweight Hook Protection[END_REF]. However, designers may not know all threats, and new exploitation techniques can appear, and attack vectors cannot be totally eradicated, thus domains are still untrustable.

Other solutions are based on the assumption that dom0 is malicious (dom0 is a high-valued attack target, resulting from its control over other domains), and aim at protecting domUs against a malicious dom0. For example, CloudVisor [START_REF] Zhang | CloudVisor: Retrofitting Protection of Virtual Machines in Multi-tenant Cloud with Nested Virtualization[END_REF] introduces a tiny security monitor to protect resources, Xoar [START_REF] Colp | Breaking Up is Hard to Do: Security and Functionality in a Commodity Hypervisor[END_REF] breaks the control domain into single-purpose components to reduce the damanage attackers can introduce, Chunxiao Li et al. [START_REF] Li | Jha: A Trusted Virtual Machine in an Untrusted Management Environment[END_REF] removed the control domain from TCB, and so on.

However, all these solutions are difficult to implement in the commercial products for the reason that they need to modify the existing virtualization architectures, which requires professionals and may lead to problems in updating systems.

Hoang [START_REF] Hoang | Protecting Xen Hypercalls. Intrusion Detection/Prevention in a Virtualized Environment[END_REF] has proposed two innovative approaches, authenticated hypercalls (MAC) and hypercall access table (HAT), that aim at protecting the hypercall interface. The MAC approach is not practical given the limitation of the number of arguments that can be passed to the hypervisor. The HAT approach records the addresses of trusted hypercall invocations and stores them in an HAT table in the hypervisor. However, in kernels of the same version, the addresses are fixed. Hence, getting the addresses of the trusted hypercall invocatons are easy. Moreover, the size of the HAT table stored in the hypervisor will increase as the number of domains increases, which contradicts the design concept of Xen [START_REF] Barham | Xen and the Art of Virtualization[END_REF].

Unlike existing solutions, RandHyp maintains the design concept of Xen with a small modification of the Xen hypervisor and guest operating systems and is transparent to guest applications. Besides, since the changes of the operating systems are mainly in some head files, they would not hinder updating systems or inserting of modules.

Xen Architecture, Threat Model, and Design Goals

Since RandHyp is based on Xen, this section first describes the architecture of Xen, especially the hypercall interface. Then the threat model is identified, and our design goals are articulated.

Architecture Overview

In Xen architecture, the hypervisor is the most priviledged software layer that virtualizes the hardware resources and partitions them dynamically to the overlying domains. A single administrative domain (dom0) has the ability to manage all other domains (domU).

Since the hypervisor is responsible for monitoring all privileged state, domains have to transfer control into the hypervisor when executing sensitive instructions, which is realized by using hypercalls [START_REF]Xen Interface Manual[END_REF]. Hypercalls are made to execute high-priviledged operations, such as exception handling, scheduling, physical memory management, access-control of disks and network devices, virtual CPU operations, and inter-domain communications.

Hypercalls are similar to system calls in conventional operating systems. A software interrupt INT $0x82 transfers the control from the domain into the hypervisor, where operations are validated and applied, and when completed, the control is returned to the calling domain [START_REF] Barham | Xen and the Art of Virtualization[END_REF]. The particular hypercall to be invoked is contained in rax with all the arguments contained in rbx, rcx, rdx, rsi, rdi (x86 64 Linux) or eax, ebx, ecx, edx, esi, edi (x86 32 Linux).

An example use of hypercall is to update an individual segment descriptor in the GDT or LDT by using hypercall HYPERVISOR update descriptor(unsigned long ma, unsigned long word).

Threat Model

We assume the hardware and hypervisor are trusted, which means that we are not concerned with the violation of security by the service providers. We focus on the threat when a well-behaved domain is compromised and used as an entry to breach isolations among domains.

In a virtualization environment, since domains are usually commodity operating systems with vulnerabilites, it is prudent to assume that they may be compromised to behave with evil intentions. Thus, the attacker in our model is a domain aims at violating the security of other domains, including violating the data integrity or confidentiality of the target domains or causing denial of service to other domains with whom it is sharing the same underlying resources.

In order to achieve the malicious goals, the attacker inevitably has to go through the hypercall interface to achieve hardware resources. For example, domains cannot directly apply for extra memory space or modify critical data structures such as page tables, but these operations can be done through hypercall requests. In such a case, the attacker needs to invoke a series of dedicately arranged hypercalls to make his malicious goals realized.

Since hypercalls are much similar to system calls, hypercall attacks could be in any form known for system call attacks such as argument hijacking or mimicry [START_REF] Hoang | Protecting Xen Hypercalls. Intrusion Detection/Prevention in a Virtualized Environment[END_REF]. Faking a series of hypercalls to sniff other domains' information or cause denial of service is applicable.

Information Leakage Attack. Information leakage attacks are mainly caused by a malicious dom0, for the reason that dom0 can access memory and I/O informations belonging to domUs. Given the evidence that information leakage may bring more profits to attackers, dom0 turns out to be a high-valued attack target.

Most projects assume a small-sized dom0 and deduce that the vulnerabilities exposed to be rare. However, this is undesirable as demonstrated by Colp[9] that dom0 in a mature virtualization platform is actually larger than a conventional server operating system for it is often relied on to provide additional shared services, such as drivers for physical devices, device emulation, and administrative tools.

The potentially malicious dom0 is often ignored in discussing the security of virtualization systems. Once dom0 is compromised, personal informations of customers can be stealed, which would be a total disaster. Denial of Service Attack. Both dom0 and domUs can launch denial of service attacks through keeping occupying resources. Further, dom0 can cause a denial of service to certain domains by changing the scheduling flows.

Design Overview

Rather than exploring techniques to construct a bug-free system, a more pragmatic goal is to provide an architecture that can prevent the hypercall interface from being used, so that attackers in subverted domains cannot further mount successful attacks against other domains. With this in scheme, RandHyp is designed to guarantee that a malicious domain cannot issue arbitrary control transfers into the hypervisor and the execution context cannot be faked. Fig. 1 shows the architecture of RandHyp. The general idea is to make the untrusted hypercall invocations unrecognized by the hypervisor, thus avoid attackers to execute priviledged operations. The method we choose is to randomize trusted hypercall invocations without the attackers' consciousness, and derandomize them in the hypervisor where attackers cannot access.

Implementation

In this section, we present our design of randomization and de-randomization schemes in RandHyp. RandHyp protects domains against all other domains, including dom0. Hypercall HYPERVISOR update descriptor is used as an example to typify all the rest hypercalls.

Randomization

In x86 64 XenLinux, the hypercall number of HYPERVISOR update descriptor is 10, the arguments are ma and word. What we need to do is re-assign the numbr and the arguments new values generated by some algorithm to make them not only unaccessable by attackers, but also difficult for them to guess. The randomization process is described as below.

Kernel-Level Randomization. Kernels, including loadable kernel modules and drivers, invoke hypercalls directly by calling the function HYPERVISOR update descriptor (unsigned long ma, unsigned long word), so that is the place we do randomization operations.

Firstly, we add paddings to maximum the number of arguments. After that, the function looks like HYPERVISOR update descriptor(ma, word, pad1, pad2, pad3).

Secondly, every argument is encrypted to make a new, randomized argument using the following equation:

arg ′ i = R K (arg i , key) . (1)
R K is our randomization algorithm using a key key. In RandHyp, we choose RC4 [START_REF] Rivest | The RC4 Encryption Algorithm[END_REF] encryption algorithm which is one of the most secure symmetric encryption algorithms in the world. Other algorithms are also applicable. After this step, the hypercall invocation would be HYPERVISOR update descriptor(arg1', arg2', arg3', arg4', arg5').

Thirdly, to make our scheme more aggressive, RandHyp permutes the roles among rbx, rcx, rdx, rsi, rdi (ebx, ecx, edx, esi, edi in x86 32 Linux) registers.

Lastly, due to the design of Xen [START_REF] Barham | Xen and the Art of Virtualization[END_REF], hypercall numbers are limited between 0 and 128, so it is impossible for RandHyp to randomize hypercall numbers in the way it does to hypercall arguments. In this way, RandHyp adjusts by choosing a number between 0 and 128 randomly for each hypercall.

User-Level Randomization. Hypercalls may be indirectly used in user-level. The randomization operations in user-level are the same as in kernel-level, while the difference lies in where the operations are done. To invoke hypercalls in user-level, a structure privcmd hypercall t, which contains the hypercall arguments and number, are passed to the kernel by a kernel driver privcmd. In function privcmd ioctl the arguments are written into registers and the software trap INT $0x82 is executed. Consequently, the hypercall arguments and number should be randomized when privcmd hypercall t is constructured.

De-randomization

No matter where a hypercall comes from, the execution of the hypercall instruction INT $0x82 generates a software trap into the Xen hypervisor, where the hypercalls are validated and executed by the same handler. Note that we have randomized trusted kernel-level hypercalls and trusted user-level hypercalls in the same method, so we don't need to differentiate the de-randomization scheme.

RandHyp has constructed a correlation between the hypercall numbers in domains and the hypercall numbers in the Xen hypervisor. Thus, when the hypercall interrupt handler catches a hypercall, the hypervisor can pass it to the right handle function according to its number, in our cases, it is the do update descrip tor function.

In order to avoid the randomized hypercall arguments from being used by the hypervisor, RandHyp de-randomizes the hypercall arguments immediately when entering the do update descriptor function.

Firstly, real arguments are selected from the paddings. Secondly, given the encryption algorithm we use is symmetrical, the derandomization algorithm is the same as the randomization algorithm. RandHyp recovers the original hypercall arguments arg i = R -1 K (arg ′ i , key) using the same key used during the randomization process. After that, Xen can do what the hypercall requires to do.

Security Discussion

Attacks Using Direct Hypercall Invocation. An attacker may directly invoke hypercalls in kernel-level or user-level. RandHyp can defeats such straigntforward attacks.

Since hypercalls created by attackers are untrusted, they are not randomized before trapping into the hypervisor, so that they will be de-randomized into meaningless informations and fail to execute.

Attackers may attempt to acquire the randomization key directly, which is also defeated by RandHyp. The reason is that the randomization key is stored in the memory space of Xen, where attackers in domains can't access. Attackers are forced to scan the kernel code memory and collect the semantics of the instructions to get the key, which is hard to perform.

Even if the attacker can successfully get the key, the probability of him to create a right argument would be very small, for the reason that there are 38 hypercalls in a system, and each hypercall contains 5 arguments, the possibility for an attacker to get the right arguments of HYPERVISOR update descriptor is 1 C(5,2)×38 , which is about 0.26%. Attackers may try to construct plaintext-ciphertext pairs to brute-force the key. RandHyp makes this very difficult. Firstly, a strong encryption algorithm and a long key makes it almost impossible to crack the key. Secondly, because we have added paddings to the arguments, and permuted the roles among the registers, and the hypercall number is re-assigned, the attackers face difficulties in constructing plaintext-ciphertext pairs. Attacks Using Indirect Hypercall Invocation. Instead of invoking hypercalls directly, an attacker may try to reuse existing hypercalls. In this situation, an attacker has to achieve the memory address of the desired hypercall instructions accurately, and then jump there to eventually invoke the intended hypercalls. Although RandHyp cannot directly prevent this kind of attacks currently, existing techniques such as address space layout randomizatoin (ASLR) [START_REF] Shacham | On the Effectiveness of Address-Space Randomization[END_REF], which makes the memory location of pre-existing code hard to predict, can be utilized to enhance security. Moreover, even if attackers can successfully hijack the control flow of a process, the hypercalls used by kernel only can accomplish basic and simple functionalities. Combining them to achieve malicious goals is almost impossible.

EVALUATION

In this section, we first present RandHyp latency measurement results, and then present a number of attack experiments that cover all hypercalls.

Experimental Setup

Our experiments were run on a Lenovo desktop PC with a 2.53GHz Intel(R) Core(TM)2 Duo CPU processor and 2GB of RAM. All Xen modifications necessary for RandHyp were implemented on Xen 4.0.1 and Linux 2.6.32.13 kernel with Xen patches applied. The changes required to Xen were minimal, spanning only a handful of source files including the files containing the hypercall service routines and several head files. On the guest domain kernel, we modified the files containing the routines which invoke hypercalls and the file that defines hypercall number. For convience, we give the modified system an alias, Rand-Domain, to distinguish the unmodified system, Orig-Domain.

Performance Evaluation

The performance of RandHyp should be evaluated in the following aspects: 1) Disk I/O throughput; 2) Network I/O throughput; 3)Overall system performance.

Disk I/O performance. Disk performance is tested by using dd. Fig. 2 shows the results of these tests with different configuration parameters. Overall, disk throughtput is down by 1-4.5%. The reading and writing latency incurred by small files is larger than that by big files, which may be caused by more frequent transversions into the hypervisor.

Network I/O performance. Netperf is used to test network performance. Fig. 3 shows the results. RandHyp only causes 1.5-3% drop in throughput when using TCP, and less than 0.2% drop while using UDP. Because TCP is a connection-oriented protocol, more hypercalls have to be used to keep the connection.

Fig. 2. Disk I/O performance using dd (higher is better)

! # $ % & ' ( ) * + , -. ! # $ % & ' ( ) * / , , - . ! # $ % & ' ( ) * + , , - . 0 1 # $ % & ' ( ) * + , -. 0 1 # $ % & ' ( ) * / , , - . 0 1 # $ % & ' ( ) * + , , - .
Fig. 3. Network I/O performance using Netperf (higher is better) Fig. 4. Real-word benchmarks (lower is better)

Real-world Benchmarks. We use several popular applications for RandHyp latency measurement, including Linux kernel compilation, Apache ab benchmarking tool and tar. As Fig. 3 shows, the kernel compiling overhead added by RandHyp is about 30%, the Apache web server serving a 4KB static webpage 10000 times for 500 simultaneous clients adds only 0.4% overhead, and the tar operation adds about 0.36% overhead.

Effectiveness Evaluation

The commonly received approach to evaluate a security measure is to subject it to existing attacks. We have discussed the possible attack scenario in Section 2. However, attacks target at crushing virtualization platforms from the overlying domains have not gained widely applied in reality, which makes evaluating security a challenging job. Moreover, constructing the attacks is out of our boundaries. Given this situation, we make an attempt to demonstrate the improvement to the state of security for hypervisors by exposing them to loadable kernel modules (LKM) that are used to imitate the intrusion attacks. Each LKM tries to execute one or a set of non-randomized hypercalls as a real attacker may do. We assume that such LKMs could be successfully injected into the domain through conventional operating system security breaches in real world.

We have tested all hypercalls, and the experiment results show that these hypercalls cannot execute correctly, which verifies that the hypercalls which are not in our protection coverage can be caught by RandHyp.

These simple experiments are, though very specific and even quite contrived, they serve the purpose of verifying the effectiveness of our prototype nevertheless.

CONCLUSION

While virtualization is becoming widely accepted in both industry and academic world, its security is put on the agenda. Enhancing the security of virtualization platforms would bring more values to their popularity and usability. Although the sizes of hypervisors are a lot smaller than that of conventional operating systems, the domains running on is untrusted, and can perform illegal operations through the hypercall interface. This paper focuses on protecting the hypercall interface so as to maintain normal services to domains and guarantee the isolation between them. A transparent approach, namely RandHyp, was proposed on Xen. In RandHyp, any hypercall out of our protect range will be detected and refused to execute. RandHyp achieved this by using randomization techniques. Both hypercall's number and arguments are randomized in order to mess the attackers. Experiments show that RandHyp can effectively counter illegal hypercalls while incurring only a small overhead.

  Fig. 1. RandHyp architecture

Acknowledgments. This work was supported in part by grants from the Chinese National Natural Science Foundation (61073027, 60773171, 90818022, and 61021062), and the Chinese 973 Major State Basic Program(2009CB320705).


Angela Gerlach
email: angela.gerlach@tu-berlin.de

Paul Uwe Thamsen

Flemming Lykholt-Ustrup

Experimental Investigation on the Performance of a Vortex Pump using Winglets

Keywords:

This paper covers the experimental examinations of the influence of attaching winglets to the blade tips of vortex pump impellers. The head, efficiency and power consumption as well as cavitation behavior are analyzed. At first, a series of tests compared an impeller with winglets with a semi-open impeller without winglets and to an impeller with a front shroud. The results suggest that an impeller with winglets leads to the highest head and the greatest efficiency. The impeller with front shroud generates higher head and efficiency than the semi -open impeller, which is frequently used for vortex pumps. A second test series investigates the cavitation performance when blade depth and diameter of impeller are varied compared to the first test series. It could be demonstrated that an impeller with winglets has a similar NPSH characteristic as an impeller without winglets. Thus winglets clearly improve the performance of vortex pumps.

INTRODUCTION

Vortex pumps can impel fluids that contain solid and fibrous materials at a minimized risk of clogging. Figure 1 shows an example of a vortex pump. A recessed impeller and a large volute width at its front chamber characterize vortex pumps, whose operating principle is assumedly a vortex that is formed in the front chamber. Compared with conventional centrifugal pumps, the efficiency of vortex pumps is overall low. Not surprisingly, many attempts have been made to improve the efficiency of vortex pumps by varying the "classical" parameters, such as the impeller diameter, the blade depth and the number of blades (e.g. Ohba et al. [1 and 2]; Lubieniecki [START_REF] Lubieniecki | Some Performance Characteristics of a Centrifugal Pump with Recessed Impeller[END_REF]). Another attempt is to add winglets to the blade tip. This addition separates a large part of the impeller channel from the front chamber of the pump. The resulting design resembles a front shroud (cf. Figure 2). The publicly available literature on how winglets affect performance is, however, contradictory. On the one hand, Cervinka [START_REF] Cervinka | Computational Study of Sludge Pump Design with Vortex Impeller[END_REF] investigated the operation of winglets using a numerical model that compared an impeller with winglets with a geometrically similar impeller without winglets. He concluded that an impeller with winglets deteriorates the pump characteristic and efficiency. On the other hand, Dalian et al. [START_REF] Dalian | A Numerical Simulation of and Experimental Research on Optimum Efficiency of Vortex Pumps[END_REF] and Rongsheng et al. [START_REF] Rongsheng | Numerical Simulation and Experiment of Influence of Hem on Performance of Vortex Pump[END_REF] presented numerical studies on how winglets influence the pump characteristic. The authors compared one impeller without winglets with two other geometrically similar impellers with different winglet depths. In both cases increasing the winglet depths led to greater pump heads and improved efficiency. Their results are further bolstered by commercially available vortex pumps whose added winglets supposedly prevent back flows on the blade top and thereby improve the pump characteristic [START_REF]Grundfos SEV and SE1 pumps -SuperVortex Impeller[END_REF].

METHODS 1.1 Study 1

Three different impellers were investigated on a closed test rig design (according to ISO 9906): A semi-open impeller; an impeller with winglets; and an impeller with a front shroud (Figure 3). The latter allowed examining whether there was an upper limit to the depth of the winglets and how the winglets influence the potential vortex in the front chamber. All other geometric parameters of the impeller and the casing remained constant for all measurements.

The semi-open impeller served as the main body onto which the winglets respectively the support disk were attached.

The semi-open impeller itself was cast and had four curved blades. Winglets and front shroud were of similar thickness and made of PVC. For simplification of manufacturing, the front shrouds as well as the winglets were straight.

The ratio of the suction mouth of the impeller with the front disc to the suction pipe diameter was 1:1.25. For the smaller suction mouth diameter, a blockage at the impeller inlet was assumed. The casings corresponded to the industrial standard and had a ball passage of 80 mm. The surface was untreated and had a rough cast. Measures included temperature, volume flow, electric power consumption, suction pressure and the pressure difference between the suction and the pressure side of the pump. We reported the performance curves, aggregated efficiencies and power consumption. The presentation of head and flow rate is done by means of the pressure coefficient and the flow coefficient. These are dimensionless values of the head and the flow rate. The pressure coefficient ψ is defined by:

𝜓 = 2 • 𝑔 • 𝐻 𝜋 2 • 𝑛 2 • 𝐷 2 (1)
where g the gravitational acceleration in m/s², H the head in m, n the rotational speed in 1/s and D the impeller diameter in m.

The flow coefficient φ is described by:

𝜑 = 4 • 𝑄 𝜋² • 𝑛 • 𝐷³ (2)
where Q the flow rate in m³/s, n the rotational speed in 1/s and D the impeller diameter in m. In addition, the power coefficient λ is considered. It is a dimensionless representation of the power and defined as follows:

𝜆 = 𝜑 • 𝜓 𝜂 (3)
where φ the flow coefficient, ψ the pressure coefficient and η the efficiency.

Study 2

In an additional series of tests we examined a set of impellers whose blade depth and diameter were different from those of study 1. In study 2, the set of impellers contained an impeller with winglets and casting surface; a semi-open impeller; and an impeller with winglets and smoothed surface (Figure 4). For maximum comparability of the obtained results, we used the same test rig design as study 1 and we measured the characteristics curve and the aggregate efficiency as well as the power consumption of all impellers similar to those in study 1. In addition, we carried out NPSH 3% measurements for different volume flows.

RESULTS

Study 1

Figure 6 illustrates the results of the three impellers of study 1. It pictures the pressure coefficient over flow coefficient. As Figure 6 suggests, the addition of winglets improved the head. The impeller with front shroud led to a similar characteristic, but lower than the impeller with winglets. The semi-open impeller was associated with lowest pressure coefficients. The impeller with winglets also reached the highest flow rates in overload as compared to the other impellers.

Figure 7 shows the efficiency over the flow coefficient. The impeller with winglets led to highest values of efficiency.

The impeller with front shroud reached higher efficiencies than the semi-open impeller.

Figure 7 suggests that the best efficiency point for the impeller with the front shroud and the semi-open impeller moves to smaller flow rates as compared with the impeller with winglets. Figure 8 shows the power consumption over the flow rate for the tested impellers of study 1. The semi-open impeller has the lowest power consumption. The impeller with the front shroud has the highest demand for power, followed by the impeller with winglets. All curves are rising: With increasing flow rates power consumption increases.

Study 2

To ensure the comparability of impellers with different degrees of surface roughness, the characteristic curves, the power consumption and the aggregate efficiency were measured. Figure 9 illustrates a comparison of the pressure coefficients over flow coefficients. (Note: Figure 9, 10 and 11 hide the individual measuring points because otherwise optical distinctions between the different curves are difficult.) Figure 9 shows that the pressure coefficient of the impeller with rough winglets resides slightly above the curve of the impeller with the smoothed winglets. As expected, the impeller without winglets led to significantly lower values of the pressure coefficient in comparison with the other two impellers.

Figure 10 pictures the aggregate efficiencies over flow coefficient. The efficiency curves suggest that the efficiency of the impellers with rough and smoothed winglets is almost identical. The impeller without winglets has again significantly lower values of efficiency than the impeller with winglets.

Figure 11 shows the power coefficient over flow coefficient. The impeller with rough winglets is the highest, followed by the impeller with smoothed winglets. The impeller without winglets has the lowest values.

DISCUSSION

Study 1 demonstrated that an impeller with winglets yields both the highest lifting height as well as the highest efficiency. Surprisingly, even the impeller with front shroud led to a higher head and a higher efficiency than the semiopen impeller. Overall, the impeller with winglets proved to be the best design.

A widely held view is that the working principle of a vortex pump is comparable to that of hydraulic coupling: The impeller of a vortex induces a vortex, which in turn handles the pumping (hereafter called vortex view). This view can be contrary to one that sees a vortex pump as a standard centrifugal pump: The flow streams through the impeller, which directly causes the pumping process itself, similar to a standard centrifugal pump. In this case, a vortex pump has an enlarged front gap, which leads to the excessive exchange losses and thus the poor efficiency of the pump (hereafter called centrifugal view).

Our experiments provide evidence that neither view is entirely correct on its own. On the one hand, the vortex view wrongly predicted the semi-open impeller supports the forming of a vortex, which again would lead to the best heads and efficiencies. However, this was not shown by the tests. On the other hand, the centrifugal view wrongly predicted that an impeller with a front shroud would support the working principle. In this case, best heads and efficiencies would be expected for the impeller with front shroud. Again, this was not the case. Taken together, the results suggest a synthesis of the two views approximates the true working principle best: An impeller with winglets lies geometrically between a semi-open impeller and an impeller with a shroud and therefore it optimizes both working principles at the same time. Yet, the closer characteristics of the impeller with the front shroud and with winglets as compared with the semi-open impeller and those with winglets suggest that the centrifugal view describes the working horse of the two working principles: The main flow passes through the impellernot the vortex. This is consistent with the transient, numerical simulation of flow lines by Steinmann et al. [START_REF] Steinmann | Numerical and Experimental Investigations of the Unsteady Cavitating Flow in a Vortex Pump[END_REF], who obtained similar results, i.e. that the main flow passes through the impeller. Study 2 compared an impeller with winglets and a rough cast surface with an impeller with winglets and smooth surface. An impeller without winglets similar in geometric design was included in this study and showed again lowest pressure coefficients and efficiencies. Contrary to what was expected, the impeller with the rough winglets led to minimally higher flow characteristics. This suggests the rough surface causes a light carrier effect. The cavitation results showed an interaction effects between the design and the flow coefficient. Thus no clear conclusions can be drawn. Further investigations, such as the consideration of NPSH inception, seem necessary. Overall, it can be concluded that winglets have a clear positive effect on the performance of vortex pumps.

Figure 1 .

 1 Figure 1. Schematic view of a vortex pump with recessed impeller and enlarged front chamber

Figure 2 .

 2 Figure 2. Schematic view of the impellers of a vortex pump without winglets (left) and with winglets (right)

Figure 3

 3 Figure 3 Impellers of study 1: Semi-open impeller (left), impeller with winglets (middle), impeller with front shroud (right)

Figure 6 . 1 Figure 7 .Figure 4 Figure 8 .

 61748 Figure 6. Pressure coefficient over flow coefficient for study 1

Figure 9 .Figure 10 . 2 Figure 11 . 2 Figure 12 .

 910211212 Figure 9. Pressure coefficient over flow coefficient for study 2

  Zheng et al.[START_REF] Zheng | Influence of Structural Parameter of a Vortex Pump on its Performance[END_REF] compared vortex pumps with a semi-open impeller with an impeller with front shroud and otherwise similar designs. The impeller provided with the front shroud improved the head and efficiency.

	The above points show that there are inconsistencies in
	relation to the use of winglets at vortex pumps especially
	due to the absence of experimental data. It leaves open
	whether winglets improve or deteriorate the pump
	performance. A systematic investigation on how winglets
	affect pump performance as well as the cavitation
	behaviour is missing. Therefore, this paper covers the
	experimental examination of the influence of winglets on the
	pump characteristics of vortex pumps including all above-
	mentioned characteristics.

ACKNOWLEDGMENTS

The authors would like to thank Dorian Perlitz for his support. We are also grateful to the workshop staff of the department of Fluid System Dynamics for the technical support.