Project Report - Adding PXE Boot Into Palacios

Total Page:16

File Type:pdf, Size:1020Kb

Project Report - Adding PXE Boot Into Palacios Project Report - Adding PXE Boot into Palacios Chen Jin Bharath Pattabiraman Patrick Foley EECS Department EECS Department EECS Department Northwestern University Northwestern University Northwestern University chen.jin@eecs. bharath@u. patrickfoley2011@u. northwestern.edu northwestern.edu northwestern.edu ABSTRACT PXE is a standard for booting an OS from the network. Most machines BIOSes support it. But, the BIOS used by Palacios guests did not. In our project, we tried various ways in which PXE network boot capability could be added to Palacios. We used a PXE-capable Etherboot ROM image from ROM-o-matic.net that has support for our emulated network card. We then used this small ISO image to build the guest and let it serve as a replacement PXE-boot ROM for the emulated network card. With passthrough I/O, the requests are handed over directly to the host, which are then sent to the DHCP and Boot servers to initiate the network boot process. The PXE capability will of vital importance in diskless nodes where the node is completely dependent on Figure 1: PXE system configuration the network for booting. 1. INTRODUCTION using PXE protocol and then boots the guest. PXE (Preboot eXecution Environment) allows us to boot Kitten/Palacios (and a test guest) remotely from a network server. Booting Palacios/Kitten over a network server is 2. SYSTEM already possible. In this research effort we have enabled So, as shown in Figure 1, in order to use PXE we need to Palacios to remote boot a guest OS using PXE. setup a PXE-server which can allow client systems to: PXE is defined on a foundation of Internet protocols, namely • TCP/IP, DHCP, and TFTP. In brief, the PXE protocol op- Request an IP address (via DHCP) erates as follows. The client initiates the protocol by broad- • Download a kernel (via TFTP) casting a DHCPDISCOVER containing an extension that identifies the request as coming from a client that imple- ments the PXE protocol. Assuming that a DHCP server 2.1 Server Configuration implementing this extended protocol is available, after sev- On the server end of the client-server interaction there must eral intermediate steps, the server sends the client a tempo- be available services that are responsible for providing redi- rary IP configuration and list of appropriate Boot Servers. rection of the client to an appropriate Boot Server. For our The client then discovers a Boot Server of the type selected purposes we used Knoppix (an operating system based on and receives the name of a bootloader file on the chosen Boot Debian) running on Qemu to behave as the DHCP server Server. The client uses TFTP to download the bootloader and the Boot (TFTP) server. Knoppix has DHCP server from the Boot Server. Finally, the client initiates execution and TFTP server pre-installed, so we just had to configure of the bootloader which boots the kernel. In our project the it in the following way. first request should be sent after Kitten and Palacios have booted up, so that Palacios gets the bootloader of the guest 2.1.1 DHCP Server Configuration subnet 172.21.0.0 netmask 255.255.0.0 f range 172.21.0.3 172.21.0.100; option broadcast−address 172.21.0.255; g group f next−server 172.21.0.2; host t e s t f f i x e d −address 172.21.0.50; qemu−image create −f qcow2 knoppix.img 4G hardware ethernet 52:54:00:12:34:57; filename "pxelinux.0"; g Now we launch a qemu command to start a virtual machine g with 128M memory, using the created hard drive image and booting from a CD-ROM image. Once the emulated ma- chine launched, we can start the regular installation process 2.1.2 TFTP Server Setup by first formating and partitioning the hard drive image and According to [3], when a client boots up it will check if then install knoppix on the hard drive image. there is a file corresponding to its own MAC address in the qemu −hda knoppix.img −cdrom knoppix. iso "/var/lib/tftpboot/pxelinux.cfg/" directory. However after −boot d −m 128 trying several options it will fall back to requesting a default su file. So, we simply changed to default file to contain the fdisk /dev/hda configuration we want. DEFAULT k i t t e n From the fdisk partition menu, create a primary Linux par- LABEL k i t t e n tition on partition 1 of 3600MB and a Linux Swap partition kernel bzImage on partition 2 of 400MB (remainder of the disk). Make par- append serial .baud=115200 console=serial tition 1 the active partition, but I'm not certain that because initrd=init t a s k of how QEMU boots a system on whether or not this make any difference. But that's how people do it with a normal 2.2 Client-Server Connection hard disk so let's do it that way here. Write out the changes To make the server and client Qemu's talk to each other we to the disk and then do a mkfs /dev/hda1. Once that is connected them together using vlans. The way this works complete, Halt the Knoppix image and restart it with the is that one qemu process connects to a socket in another above command line. Once you see the Knoppix prompt qemu process. When a frame appears on the vlan in the again like this type: first qemu process, it is forwarded to the corresponding vlan boot knoppix screen=1152x864 dma in the other qemu process and vice-versa. tohd=/dev/hda1 This way, the server and client Qemu's are connected using a socket interface connected to vlans. Thus, any frames and then feel the disk spin for a bit, with the screen looking transmitted by the client is received by the server, and vice somewhat like this. When it's all done, Knoppix will boot versa. normally. What this actually does is just copy over the di- rectory structure on the CDROM onto the Hard disk. Now, 3. IMPLEMENTATION when you boot from your cdrom, you can add fromhd=/dev/hda1 In this section, we will walk you through our implementation which will make it boot off the hard disk image. Given all process step by step from setting up a test bench for PXE efforts spent in this phase, this is probably worthwhile to booting testing and how we actually implemented it inside in create such a hard drive. The start line for qemu doesn't Palacios VMM. Actually, we spent quite an amount of time change from the previous run, but how we invoke Knoppix to understand what PXE booting is and how actually to is different. At the boot prompt, type: create the test environment for us eventually to work on the boot knoppix screen=1152x864 dma main part of this project. In the remainder of the section, fromhd=/dev/hda1 we will describe the test bench setup, how to execute our idea progressively and finally made it work. After using a HD install, knoppix boots considerably faster 3.1 Testbench setup than boot from iso image, however, it would take 10-15 Since PXE is a standard for network booting, it is critical minutes to populate all the devices. we looked at how we for use to set up the server-client system which allows us to could make QEMU boot a system much faster using the conduct the experiments. We started work from server side savevm/loadvm commands from the monitor. Once the which provides TFTP and DHCP services and the initial above system has booted, and we've got all the applications files for boot loaders. setup the way we want them, then type CTRL-ALT-2 to go into the QEMU monitor. Once inside the QEMU mon- 3.1.1 server itor, type "savevm knoppix-save.vm" and then "quit". The file knoppix-save.vm should be save. Note that not all file In order to avoid reconfiguring the system every time we use formats support this. raw does not, but qcow2 does. the Qemu, we decided to create a hard drive image which can save all the configuration changes we have made. We Restarting a QEMU savevm'd image initially tried to install ubuntu, however, the installation took so long. After trying several different linux kernels, we Once again, we add another parameter to the startup line picked knoppix that takes reasonable time to install, and for the qemu instance. To get the very quick restart of a provides both tftp and dhtp services. running image, we run: The following command allows users to create a qcow2 hard qemu drive image with size of 4G is −cdrom /vol/dev/rdsk/c1t0d0/knoppix Figure 2: Tap Device Diagram −m 512 Figure 3: VLAN Diagram −k en−us −boot d −hda knoppix.img −loadvm knoppix−save .vm and in about 10 seconds, my Knoppix instance is back where it was when I ran the savevm command from the QEMU monitor. After you restore an image like this, I found out that you should do a [CTRL-ALT-1] to reset the virtual machine's system state, which explains the weirdness I saw with the keyboard and restored image. I wish I had found this sooner. Waiting 10-15 minutes for something to bootup and enumer- ate all the devices is pretty hideous. Once the hard drive image is set up, the next problem we Figure 4: Socket Connection Diagram faced was to transfer the boot loader files to the server.
Recommended publications
  • Chapter 3. Booting Operating Systems
    Chapter 3. Booting Operating Systems Abstract: Chapter 3 provides a complete coverage on operating systems booting. It explains the booting principle and the booting sequence of various kinds of bootable devices. These include booting from floppy disk, hard disk, CDROM and USB drives. Instead of writing a customized booter to boot up only MTX, it shows how to develop booter programs to boot up real operating systems, such as Linux, from a variety of bootable devices. In particular, it shows how to boot up generic Linux bzImage kernels with initial ramdisk support. It is shown that the hard disk and CDROM booters developed in this book are comparable to GRUB and isolinux in performance. In addition, it demonstrates the booter programs by sample systems. 3.1. Booting Booting, which is short for bootstrap, refers to the process of loading an operating system image into computer memory and starting up the operating system. As such, it is the first step to run an operating system. Despite its importance and widespread interests among computer users, the subject of booting is rarely discussed in operating system books. Information on booting are usually scattered and, in most cases, incomplete. A systematic treatment of the booting process has been lacking. The purpose of this chapter is to try to fill this void. In this chapter, we shall discuss the booting principle and show how to write booter programs to boot up real operating systems. As one might expect, the booting process is highly machine dependent. To be more specific, we shall only consider the booting process of Intel x86 based PCs.
    [Show full text]
  • UEFI PXE and Ipxe Alternative Approaches to PXE Booting
    Installing ESXi Using PXE n gPXELINUX is a hybrid configuration that includes both PXELINUX and gPXE and supports booting from a Web server. gPXELINUX is part of the SYSLINUX package. If you use gPXELINUX to boot the ESXi installer, only the gpxelinux.0 binary file, mboot.c32, and the configuration file are transferred via TFTP. The remaining files are transferred via HTTP. HTTP is typically faster and more reliable than TFTP, especially for transferring large amounts of data on a heavily loaded network. NOTE VMware currently builds the mboot.c32 plugin to work with SYSLINUX version 3.86 and tests PXE booting only with that version. Other versions are likely to be incompatible. This is not a statement of limited support. For support of third-party agents that you use to set up your PXE booting infrastructure, contact the vendor. UEFI PXE and iPXE Most UEFI firmware natively includes PXE support that allows booting from a TFTP server. The firmware can directly load the ESXi boot loader for UEFI systems, mboot.efi. Additional software such as PXELINUX is not required. iPXE can also be useful for UEFI systems that do not include PXE in firmware and for older UEFI systems with bugs in their PXE support. For such cases you can try installing iPXE on a USB flash drive and booting from there. NOTE Apple Macintosh products do not include PXE boot support. They include support for network booting via an Apple-specific protocol instead. Alternative Approaches to PXE Booting Alternative approaches to PXE booting different software on different hosts are also possible, for example: n Configuring the DHCP server to provide different initial boot loader filenames to different hosts depending on MAC address or other criteria.
    [Show full text]
  • Network Boot and Exotic Root HOWTO
    Network Boot and Exotic Root HOWTO Brieuc Jeunhomme frtest [email protected] Logilab S.A. Revision History Revision 0.3 2002−04−28 Revised by: bej Many feedback inclusions, added links to several projects Revision 0.2.2 2001−12−08 Revised by: dcm Licensed GFDL Revision 0.2.1 2001−05−21 Revised by: logilab Fixed bibliography and artheader Revision 0.2 2001−05−19 Revised by: bej Many improvements and included Ken Yap's feedback. Revision 0.1.1 2001−04−09 Revised by: logilab First public draft. Revision 0.1 2000−12−09 Revised by: bej Initial draft. This document explains how to quickly setup a linux server to provide what diskless linux clients require to get up and running, using an IP network. It includes data and partly rewritten text from the Diskless−HOWTO, the Diskless−root−NFS−HOWTO, the linux kernel documentation, the etherboot project's documentation, the linux terminal server project's homepage, and the author's personal experience, acquired when working for Logilab. Eventually this document may end up deprecating the Diskless−HOWTO and Diskless−root−NFS−HOWTO. Please note that you'll also find useful information in the From−PowerUp−to−bash−prompt−HOWTO and the Thin−Client−HOWTO, and the Claus−Justus Heine's page about NFS swapping. Network Boot and Exotic Root HOWTO Table of Contents 1. Introduction.....................................................................................................................................................1 1.1. What is this all about?.......................................................................................................................1 1.2. Thanks...............................................................................................................................................1 1.3. Diskless booting advocacy................................................................................................................1 1.3.1. Buying is cheaper than building.......................................................................................1 1.3.2.
    [Show full text]
  • Tivoli Provisioning Manager for OS Deployment Version 7.1.1.9
    Tivoli Provisioning Manager for OS Deployment Version 7.1.1.9 Getting Started Tivoli Provisioning Manager for OS Deployment Version 7.1.1.9 Getting Started ii Tivoli Provisioning Manager for OS Deployment: Getting Started Contents Chapter 1. Getting started .......1 The deployment process ..........10 Product overview.............1 Universal images ............11 Components ..............1 Shared repository and its cleanup .......11 Product topology .............4 Setting up a system profile by unattended setup . 4 Chapter 2. Glossary .........15 Setting up a system profile by cloning ......5 Choosing the correct way to boot your target . 5 Chapter 3. Notices ..........21 Types of PXE network boot ........6 Network boot process ..........9 © Copyright IBM Corp. 2012 iii iv Tivoli Provisioning Manager for OS Deployment: Getting Started Chapter 1. Getting started Product overview The product is a database-driven, network-based deployment solution. Using an easy-to-use interface, the product provides Windows cloning and unattended setup, Linux cloning, and unattended setup, Solaris cloning and unattended setup, AIX® unattended setup, and VMWare ESX unattended setup, from Windows, Linux, Solaris, and IBM® AIX servers. In addition to BIOS targets, the product can also manage Unified Extensible Firmware Interface (UEFI) enabled targets. Support for UEFI targets is currently provided for Windows deployment only. Using industry standards such as Wake on LAN and vPro, PXE and OpenBOOT, ODBC and JDBC, DMI and PCI, Microsoft system preparation tool (Sysprep), Kickstart, Autoyast, Jumpstart and NIM, the product provides ready to use installation of operating systems and selected software on tens, or even hundreds, of computers simultaneously. The deployment source can be on the network (with either unicast or multicast downloading), on a CD or DVD, or on a disk partition.
    [Show full text]
  • PXE Boot User Guide for Use with Chelsio T3 Based Hardware
    PXE Boot User Guide For use with Chelsio T3 Based Hardware PXE Boot Release Version 1.0 Chelsio Communications, Inc. www.chelsio.com PXE BOOT USER GUIDE Copyright © 2008, 2009 by Chelsio Communications, Inc., 370 San Aleso Ave, Suite 100, Sunnyvale, CA 94085, U.S.A. All rights reserved. This document and related products are distributed under licenses restricting their use, copying, distribution, and reverse- engineering. No part of this document may be reproduced in any form or by any means without prior written permission by Chelsio Communications. S310, S320, S302, S304, N302, and N310 are trademarks of Chelsio Communications, Inc. THIS DOCUMENTATION IS PROVIDED “AS IS” AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE USE OF THE SOFTWARE AND ANY ASSOCIATED MATERIALS (COLLECTIVELY THE “SOFTWARE”) IS SUBJECT TO THE SOFTWARE LICENSE TERMS OF CHELSIO COMMUNICATIONS, INC. Release Version 1.0 ii Chelsio Communications, Inc. PXE BOOT USER GUIDE Contents 1 Introduction ......................................................................................................... 1 Features ............................................................................................................................. 1 Hardware Requirements ................................................................................................. 2 PXE Boot Process ...........................................................................................................
    [Show full text]
  • Vmware Esxi Installation and Setup
    VMware ESXi Installation and Setup 02 APR 2020 Modified on 11 AUG 2020 VMware vSphere 7.0 VMware ESXi 7.0 VMware ESXi Installation and Setup You can find the most up-to-date technical documentation on the VMware website at: https://docs.vmware.com/ VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 www.vmware.com © Copyright 2018-2020 VMware, Inc. All rights reserved. Copyright and trademark information. VMware, Inc. 2 Contents 1 About VMware ESXi Installation and Setup 5 Updated Information 6 2 Introduction to vSphere Installation and Setup 7 3 Overview of the vSphere Installation and Setup Process 8 4 About ESXi Evaluation and Licensed Modes 11 5 Installing and Setting Up ESXi 12 ESXi Requirements 12 ESXi Hardware Requirements 12 Supported Remote Management Server Models and Firmware Versions 15 Recommendations for Enhanced ESXi Performance 15 Incoming and Outgoing Firewall Ports for ESXi Hosts 17 Required Free Space for System Logging 19 VMware Host Client System Requirements 20 ESXi Passwords and Account Lockout 20 Preparing for Installing ESXi 22 Download the ESXi Installer 22 Options for Installing ESXi 23 Media Options for Booting the ESXi Installer 24 Using Remote Management Applications 35 Customizing Installations with vSphere ESXi Image Builder 35 Required Information for ESXi Installation 74 Installing ESXi 75 Installing ESXi Interactively 75 Installing or Upgrading Hosts by Using a Script 79 PXE Booting the ESXi Installer 95 Installing ESXi Using vSphere Auto Deploy 102 Troubleshooting vSphere Auto Deploy 191 Setting Up ESXi 198 ESXi Autoconfiguration 198 About the Direct Console ESXi Interface 198 Enable ESXi Shell and SSH Access with the Direct Console User Interface 202 Managing ESXi Remotely 203 Set the Password for the Administrator Account 203 VMware, Inc.
    [Show full text]
  • Network Boot Protocol Hp
    Network Boot Protocol Hp Beaded and Thomism Rube travails so economically that Hallam collar his Edom. Prent still ensuring on-the-spot while hornish Pinchas unnaturalises that propylite. Is Miguel mossiest or lacklustre after tailored Fabio gasp so apishly? For Windows virtual machines Remote Desktop Protocol is nonetheless available. You must program DMI on an HP commercial name with real legacy BIOS. Built for performance and optimal data centre density. To see global limited number? Only using rufus simply not allow for hp boot network in our machines on absaroka storage tab, then usb options and operating system or linux is that provide all. Short on hp smart array raid. Thanks for contributing an internal to Super User! Please configure it is reset your food and share code is quite slow down arrow key press both computers one you must not plugged into startup. Bios so you are a protocol which contain whitespace when i specify boot up. Get persistent boot selection. Sata virtual desktop computers have changed and basic guidance based on this flag will not need it is a network protocols that. Pxe network protocols that networking devices before you will appear in network environments, if something went well. Do you to major organizations such an answer site with our free us from your pc hardware rather than legacy network boot protocol for the latest version and then. The following script allows you to save, making you can use or own server setups and directory structures. When the computer is connected to various network, graphics cards, system will add a fucking name.
    [Show full text]
  • Netbooting Microsoft Windows 7 and XP
    Netbooting Microsoft Windows 7 and XP Chris Holman∗ Centre for Advanced Internet Architectures, Technical Report 130226A Swinburne University of Technology Melbourne, Australia [email protected] Abstract—This tutorial shows how to set up Microsoft and testing the Windows PE are detailed in Section VI. Windows 7 and XP to be booted using network attached Installing to the iSCSI drive is covered in Section VII. storage. iSCSI support is built in to a Windows 7 installer The report concludes with Section IX and an appendix. using the Windows 7 Automated Installation Kit. DHCP, an iSCSI server and a TFTP server are configured on the II. BACKGROUND server to provide a PXE client and an iSCSI target. Once A. DHCP set up, a client PC will be able to operate entirely without a local disk. Dynamic Host Configuration Protocol’s (DHCP) [2] Index Terms—Windows 7, Windows XP, PXE, netboot- primary purpose is to assign IP addresses and other ing network configuration details to hosts. It is used in this tutorial for the purposes of providing network and PXE I. INTRODUCTION booting configuration details, including TFTP server PXE (“Preboot eXecution Environment”) [1] booting, settings and configuration filenames. or net booting, can be used to load an operating system B. TFTP over the network without using the local hard drive. While FreeBSD and Linux Operating Systems (OSes) Trivial File Transfer Protocol (TFTP) [3] is a simple support a number of different PXE boot methods (includ- protocol to transfer files. It is commonly used in PXE ing NFS, TFTP, HTTP, iSCSI and more), Windows only scenarios because of its simplicity.
    [Show full text]
  • Implementing PXE Boot Using Intel® BLDK for Intel® Atom™ Processor Based Boards
    White Paper Dmitry Tarakanov Implementing PXE John A. D. Mallinder Regis Cheval Boot using Intel® Steve Cutler Technical Marketing Engineers BLDK for Intel® Intel Corporation Atom™ Processor based Boards March 2012 1 326995-001 Implementing PXE Boot using Intel® BLDK for Intel® Atom™ Processor based Boards Executive Summary Intel provides an EFI-standard based Boot Loader Development Kit (BLDK) for various Intel® Atom™ processors. This white paper discusses how to modify the Intel® BLDK code base to support network booting (PXE boot). The resulting BLDK image is programmed onto an Intel® Atom™ Processor E6xx Series with Intel® Platform Controller Hub EG20T evaluation board codenamed Crown Bay. The process involves installing the BLDK Integrated Development Environment (IDE) on a computer running Microsoft* Windows 7* to create the modified BLDK image. It also involves setting up a host computer from which the target unit remotely boots. The target unit boots into a MeeGo* image installed on the host computer running Fedora 16* as the server OS. The final image boots the machine over the network via PXE boot. In this configuration a Linux* kernel is downloaded onto the target machine’s volatile memory and a root file system residing on the host is mounted over an NFS link. This layout enables a versatile environment for developing embedded systems. The resulting BLDK image is programmed onto an Intel® Atom™ Processor E6xx Series with Intel® Platform Controller Hub EG20T evaluation board codenamed Crown Bay. Although this paper is based on a particular Linux release and the Elilo operating system loader, the same principles can be 2 Implementing PXE Boot using Intel® BLDK for Intel® Atom™ Processor based Boards applied to other UEFI compliant operating systems and other loaders.
    [Show full text]
  • SRM Firmware Howto SRM Firmware Howto
    SRM Firmware Howto SRM Firmware Howto Table of Contents SRM Firmware Howto.......................................................................................................................................1 David Mosberger and Rich Payne...........................................................................................................1 1.What is SRM?.......................................................................................................................................1 2.The Raw Loader....................................................................................................................................1 3.The aboot Loader..................................................................................................................................1 4.Sharing a Disk With DEC Unix............................................................................................................2 5.Document History.................................................................................................................................2 1. What is SRM?......................................................................................................................................2 1.1 How Does SRM Boot an OS?............................................................................................................2 1.2 Loading The Secondary Bootstrap Loader........................................................................................2 2. The Raw Loader...................................................................................................................................3
    [Show full text]
  • PSUMAC203: Deployment Getting Tired of Us Yet?
    PSUMAC203: Deployment Getting Tired of us yet? • Justin Elliott, Penn State University • IT Manager, Classroom and Lab Computing • Rusty Myers, Penn State University • IT Support Specialist, College of Education Overview • What is Deployment • Deployment Methods • Deployment Tools • Demo Time Quick Audience Survey • New to Deployment for Macs? • How many Macs do you need to image? • Have more than 1 network segment? • Have Mac OS X Server(s)? • Have Windows (SMB) Servers? Deployment System Image System Image Deploying System Images! Considerations • Frequency of Imaging • Amount of Data to Restore • Number of Macs to Image • Number of Staff • Budgetary Restrictions Booting Methods Local Disk Booting • Local Volumes • DVDs - Cheap, Slow • FireWire, USB Hard Drives • Fast • Relatively Inexpensive Network Booting • Network (NetBoot) • Requires fast switched networks, DHCP, Local NetBoot Server or router HelperIPs • Very convenient when it all works correctly • Sometimes difficult network requirements Image Sources Local Image Sources • Second Partition • Firewire, USB Drives • Great for larger images • Hassle to manage portable disks Network Image Sources • Network Shares • AFP, SMB, HTTP • ASR Multicast Server Prep for HTTP • Segment images served by Apache (before version 2.0) Web Server $ hdiutil segment -segmentSize 1.9g -o Image.dmg • Keep all of the .dmgpart files in the same directory Prep for ASR Multicast • Images must be “Scanned For Restore” • Re-orders and optimizes image for multicast • Images should not be compressed Deployment Tools Apple Software Restore • ASR is at the heart of all OS X system restore utilities • Disk Utility, System Image Utility • Blast Image Config, DeployStudio • Can be scripted at the command line too • Located at /usr/sbin/asr Multicast ASR Server • ASR can run as a multicast server for one image • Start asr with server mode, config, image path % asr server --source master.dmg --config configuration.plist • Can literally kill your networks.
    [Show full text]
  • Secure and Resource-Efficient Network Boot System for Flexible
    sensors Article FLEX-IoT: Secure and Resource-Efficient Network Boot System for Flexible-IoT Platform Keon-Ho Park 1,† , Seong-Jin Kim 1,† , Joobeom Yun 1 , Seung-Ho Lim 2,* and Ki-Woong Park 1,* 1 Department of Computer and Information Security, and Convergence Engineering for Intelligent Drone, Sejong University, Seoul 05006, Korea; [email protected] (K.-H.P.); [email protected] (S.-J.K.); [email protected] (J.Y.) 2 Division of Computer Engineering, Hankuk University of Foreign Studies, Yongin 17035, Korea * Correspondence: [email protected] (S.-H.L.); [email protected] (K.-W.P.); Tel.: +82-2-6935-2453 (K.-W.P.) † These authors contributed equally. Abstract: In an internet of things (IoT) platform with a copious number of IoT devices and active variation of operational purpose, IoT devices should be able to dynamically change their system images to play various roles. However, the employment of such features in an IoT platform is hindered by several factors. Firstly, the trivial file transfer protocol (TFTP), which is generally used for network boot, has major security vulnerabilities. Secondly, there is an excessive demand for the server during the network boot, since there are numerous IoT devices requesting system images according to the variation of their roles, which exerts a heavy network overhead on the server. To tackle these challenges, we propose a system termed FLEX-IoT. The proposed system maintains a FLEX-IoT orchestrater which uses an IoT platform operation schedule to flexibly operate the IoT devices in the platform. The IoT platform operation schedule contains the schedules of all the IoT devices on the platform, and the FLEX-IoT orchestrater employs this schedule to flexibly change the mode of system image transfer at each moment.
    [Show full text]