UBC Undergraduate Research

Fault Injection as a Web Service Song, Yilun 2016-11-26

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata

Download

Media
52966-Song_Yilun_CPEN499A_Fault_injection_web_2016.pdf [ 277.12kB ]
Metadata
JSON: 52966-1.0340547.json
JSON-LD: 52966-1.0340547-ld.json
RDF/XML (Pretty): 52966-1.0340547-rdf.xml
RDF/JSON: 52966-1.0340547-rdf.json
Turtle: 52966-1.0340547-turtle.txt
N-Triples: 52966-1.0340547-rdf-ntriples.txt
Original Record: 52966-1.0340547-source.json
Full Text
52966-1.0340547-fulltext.txt
Citation
52966-1.0340547.ris

Full Text

         Fault Injection as a Web Service Undergraduate Thesis for CPEN 499A     Student Name: Yilun Song Supervisor: Karthik Pattabiraman Date: November 26, 2016  i   Abstracts  LLFI is a LLVM based fault injection tool that injects faults into programs at the intermediate representation (IR) level. With increasing interest in the LLFI tool from industries, this project aims at providing LLFI as a web service, which makes LLFI easy to use and free of installation.  This paper talks about the overall design and high-level implementations of the LLFI web application, as well as steps to setup the development environment of the application.  The advantages of the web application and some potential improvements will be discussed in this paper.  ii  Table of Contents Abstracts ...................................................................................................................................... i Terminologies ............................................................................................................................. iii 1. INTRODUCTION ............................................................................................................... 1 1.1 Background .................................................................................................................... 1 1.2 Objective ........................................................................................................................ 1 1.3 Purpose and Scope ......................................................................................................... 1 2. DESIGN OVERVIEW ......................................................................................................... 2 2.1 User Interface ........................................................................................................ 2 2.2 Client and Server Interactions ................................................................................ 2 3 IMPLEMENTATION ........................................................................................................... 5 3.1 Development Framework ............................................................................................... 5 3.2 Front End Client ............................................................................................................. 5 3.3 Back End Server............................................................................................................. 6 4 DEVELOPMENT ENVIRONMENT SETUP....................................................................... 7 4.1 Dependencies ................................................................................................................. 7 4.2 Server Setup ................................................................................................................... 7 4.3 Front End Setup ............................................................................................................. 7 5 EVALUATION & FUTURE WORK .................................................................................... 9 5.1 Maintainability ...................................................................................................... 9 5.2 Feature Coverage ................................................................................................. 10 5.3 Service Latency ................................................................................................... 11 5.4 Feedback System ................................................................................................. 12 5.5 User Database ...................................................................................................... 13 5.6 Test Suites ........................................................................................................... 13 6 CONCLUSION.................................................................................................................. 14 7 REFERENCES .................................................................................................................. 15    iii  Terminologies GUI  Graphical user interface, refers to the visual interface of the application in this project IR  An Intermediate representation format LLFI  An Intermediate Code Level Fault Injector LLVM  A compiler framework designed to support program analysis.1   1. INTRODUCTION 1.1 Background LLFI is an LLVM based fault injection tool that is developed and maintained by Dependable Systems Lab at UBC [1], [2], [3], [4], [5]. To perform a fault injection with LLFI, users can either use command line inputs or install the LLFI graphical user interface (GUI). The LLFI GUI enables users to perform fault injection easily by allowing users to simply click on buttons rather than typing complicated command line inputs. However, both command line inputs and the GUI require users to install LLFI on their computers. This project will turn LLFI GUI to a web application that allows users to use LLFI without any installations. 1.2 Objective The objective of this project is to build a web application to provide LLFI fault injection as a service, which is free of download and installation. 1.3 Purpose and Scope This report will describe some high-level techniques used to build the web application as well as explain the high-level structure of the web application. The scope of this report will emphasize how the web application works, and conclude with an evaluation of the application.  2  2. DESIGN OVERVIEW In this section, I will talk about the overall design of the web application. 2.1 User Interface The user interface of the web application follows the GUI version of LLFI. The picture below is a screenshot of the web application.  Figure 1: LLFI Web Interface The user interface of the web application is similar to LLFI GUI. Users who are familiar with the GUI can use this web version without the need of learning anything new. 2.2 Client and Server Interactions The front-end web client has interactions with the server. The front-end client, the interface that the users see when visiting the web page, allows users to perform steps 3  of the fault injection as well as displays results and feedbacks. The back-end side of the web applications is composed of a server. The server stores all the files that users uploaded (for example, the source code), the intermediate files that result from fault injection steps (for example, the instrumented files), and the result files of the fault injection. The server also performs the actual fault injection steps that the users requested. The graph below illustrates the relationship between the front-end and back-end of the web application.  Figure 2: LLFI interaction model  As illustrated in the graph above, the client uploads a source file and requests to perform the fault injection steps. The server stores files, performs the fault injection 4  and returns the response to the client. Each client, distinguished by their IP address, will have their own directory named with their IP address. Each time a user starts a fault injection process, the server will empty the directory and clear the previous files generated by a previous injection.  5  3 IMPLEMENTATION In this section, I will talk about some high-level implementation choices I made for the web application. 3.1 Development Framework The development framework of this web application is React [6]. React is a component based framework where components are encapsulated to make complex UIs. The main advantage of React is that Re-rendering of UI elements is efficient, only the components in which the data got changed are updated. Except for the advantages offered by React above, I choose React because I have been using React in my other projects for more than one year, I am more familiar with React over any other frameworks. 3.2 Front End Client The front-end client is implemented with React framework. With the help of React, the UI components are encapsulated in a modular way, which enables it to maintain easily since each small UI component is implemented in a separate file.  Sharing stateful data among react components is accomplished by using reflux in this web application. For a common data set shared among multiple components, a store and a set of corresponding actions need to be defined. For example, the user input is required in both profiling and fault injection steps, if a user changes the input, the input component fires an action about the change and updates the user input data 6  in the local store. Then, all the components who subscribed to the user input store get the change immediately.   User requests are sent to the server through Ajax calls. The parsed results or file content that needs to be displayed are encapsulated in an object and sent back to the front end. 3.3 Back End Server The back-end server is implemented using NodeJs [7]. The back end has different endpoints to handle different requests. Each endpoint handler is implemented in a separate file so that it is easy to maintain. Configurations and utility functions are designed to be shared to improve the reusability of the code.  7  4 DEVELOPMENT ENVIRONMENT SETUP In this section, I will talk about the steps to set up the development environment. 4.1 Dependencies The web application is an open source project that can be downloaded from LLFI GitHub repository. The web application is in the LLFI web-app directory. After downloading the project, we need to install NodeJs, which is a popular JavaScript runtime environment used for this project. Once we have NodeJs installed, we can go to the web-app directory to install the libraries used in our application by running the command “npm install”. We also use Webpack [8] as the modular bundler for our front-end react application. We need to install Webpack globally by running the command “sudo npm install –g webpack”. 4.2 Server Setup With the dependencies installed, we can setup a local server by going to the web-app/server directory and running “node server.js”. For the local server to perform fault injection, LLFI needs to be installed locally as well. The path of the LLFI can be configured in the web-app/server/utils/config.js file. 4.3 Front End Setup The front end of the web application uses Webpack as the bundler. We can run the 8  command “webpack -w” in the web-app folder to compile the bundled react components automatically when a new change is saved. We can also run “webpack” to compile it manually every time we need the new changes to be reflected.   9  5 EVALUATION & FUTURE WORK The evaluation of the web application is conducted by comparing the maintainability and the usability of the web GUI with the Java GUI, and measuring the latency of the web services. The current version of the web application can be improved in many ways; suggestions about the improvement will be discussed based on the evaluation. 5.1 Maintainability The maintainability of this application is measured by comparing different metrics in the code base of the web version with the Java GUI version. There are 11 JavaScript source files on the server side of the web application, and 42 JavaScript source files on the front-end side of the web application; whereas, there are 15 Java source files in the Java GUI version. The number of files suggests that the web version splits its components to different files in a modular way; whereas, the Java GUI version may put complicated components or logics in one single file. The number of lines in a file can also be a measure for maintainability because it implies the level of readability of the code. More lines in a single file imply that the file is harder to read and maintain. The file with the greatest number of lines is Controller.java with 1952 lines of code in the Java GUI and another file with 341 lines in the web version. There are 4 out of 15 files having more than 400 lines of code in the Java GUI code base; in comparison, there are only 7 out of 53 files that have more than 100 lines of code in the web version. In terms of the number of lines, it implies 10  that the web GUI is easier to read and maintain compared with the Java GUI. 5.2 Feature Coverage The feature coverage is measured by comparing the functional features of the application in the web version with the Java GUI version. The web application provides a subset of the features offered in the Java GUI. It offers most the features in the Java GUI including all the main features. The table below illustrates the features offered in both versions.  Java GUI Web GUI Import Single File √ √ Import Project √  Import IR File √  CompileIR √ √ Instrument Hardware Mode √ √ Instrument Software Mode √ √ Instrument Software Batch Mode √  Instrument with Custom input.yaml √  Profiling √ √ Runtime Options Hardware √ √ Runtime Options Software √ √ 11  Inject Fault √ √ Trace Graph √ √ Trace Graph Batch Mode   Table 1: Web GUI Feature Set Comparison  As indicated by the table above, there are some features that are not supported in the Web version. The current implementation assumes that the user will go through all the steps of LLFI, which means that it will start with compiling the source code to IR [9] file. If a user uploads a file in the IR format, the web application will try to treat the IR file as a source code file, which will result in an error. The web should allow the upload of compiled IR file and skip the CompileIR step. The web application only supports the upload of a single file. To make the full use of the Makefile [10] system, we can easily upgrade the web application to use the Makefile to support project uploads. The software batch mode is disabled because of the time limit of the project. We only support one software fault to be instrumented at a time. Multiple software faults should be supported, which requires the use of batch mode. 5.3 Service Latency The latency is measured with an experiment. The experiment will simulate the normal workflow of the fault injection steps. The experiment uses a localhost server, 12  and a sample program named “factorial.c” as the input program. The latency of each service is measured by the time between a service is requested and a response is received by the front-end client. The table below indicates the latency of the injection steps in milliseconds.  Latency (MS) File Upload 9 CompileIR 62 Instrument 292 Profiling (with 5 as input) 68 Runtime Option 10 Fault Injection (10 runs) 209 Trace Graph (Selected all runs) 1321 Table 2: Service Latency The response time of the experiment is short. Most of the requests got instant responses. 5.4 Feedback System The current version of the web application does not have a robust feedback system. When an error occurred, the application does not tell what the error is. The system can be improved to show more information about the errors. 13  5.5 User Database The web application does not use any database. To provide a better user experience, we can implement a user database to keep track of the user activities. With a database, we may allow users to resume their last activities. Furthermore, we can monitor the user activities to prevent malicious attacks. 5.6 Test Suites No automated test scripts are implemented for this application. It is better to have some unit tests to make sure that the program runs as expected. Regression tests are also helpful when the program evolves.    14  6 CONCLUSION The LLFI tool has been extended as a web service and can be used by anyone without the need of downloading the tool. The web application is designed and built in a modular way and is easy to maintain and expand in the future. Both front end client and the back-end server have their individual components implemented separately such that it is easy to track and debug any problems. The main and important features have been implemented and are ready to use for this web application. The quality and user experience of the web application can be improved by expanding the suggested features.    15  7 REFERENCES [1] A. Thomas and K. Pattabiraman, “Error detector placement for soft computation,” in DSN, 2013, pp. 1–12. [2] J. Wei, A. Thomas, G. Li, and K. Pattabiraman, “Quantifying the Accuracy of High-Level Fault Injection Techniques for Hardware Faults,” in DSN, 2014, pp. 1-7 [3] M. R. Ailabadi, and K. Pattabiraman, “FIDL: A Fault Injection Description Language for Compiler-based SFI Tools,” in SafeComp, 2016, pp. 1-3 [4] Q. Lu, M. Farahani, J. Wei, A. Thomas, and K. Pattabiraman, “LLFI: An Intermediate Code Level Fault Injector for Hardware Faults,” in QRS, 2015, pp. 1-2 [5] "LLVM Language Reference Manual." LLVM Language Reference Manual — LLVM 4.0 Documentation. N.p., n.d. Web. 29 Nov. 2016.  [6] "A JavaScript Library for Building User Interfaces - React." Facebook.github.io. N.p., n.d. Web. 29 Nov. 2016. [7] Foundation, Node.js. "Node.js." Node.js. N.p., n.d. Web. 29 Nov. 2016 [8] Koppers, Tobias. "Webpack Module Bundler." Webpack Module Bundler. N.p., n.d. Web. 29 Nov. 2016. [9] C. Lattner and V. Adve, “LLVM: A compilation framework for lifelong program analysis & transformation,” in CGO, 2004, pp. 75–86. [10] "Overview | CMake." CMake. N.p., n.d. Web. 29 Nov. 2016. 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            data-media="{[{embed.selectedMedia}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.52966.1-0340547/manifest

Comment

Related Items