Edge Computing Systems and Architectures
Praveen Kumar Ummidi
Undergraduate Student
Computer Science and Engineering
Lovely Professional University, Phagwara
Abstract—Edge and fog computing will become more
common in the upcoming years as a result of the advantages
they have over standard cloud computing in a variety of
specialized use-case scenarios. However, the security issues
that Fog and Edge Computing raise have not yet been
properly considered and addressed, especially when
considering the supporting technologies (such virtualization)
necessary to enjoy the rewards of the adoption of the Edge
paradigm. Containers, Real Time Operating Systems, and
Unkennels are far from being sufficiently resilient and safe.
In this paper, we introduce the key technologies supporting
the Edge paradigm, survey existing issues, introduce
pertinent scenarios, and discuss the advantages and
limitations of the various existing solutions in the scenarios.
Our goal is to shed some light on current technological
limitations and to offer some guidance on future research
security issues and technological development. Lastly, we
explore the security concerns that currently exist in the
setting that was just described and attempt to identify
potential future research areas in both security and
technological development in various Edge/Fog scenarios.
Keywords-Edge Computing; Containers; Unikernels; RTOS;
Security.
I. INTRODUCTION
Despite its widespread acceptance, resource centralization is
a major drawback of cloud computing, which makes it far
from a universally applicable solution. Because delay-
sensitive applications like gaming, augmented reality, and e-
health demand low latency and jitter as well as context
awareness and mobility support, this in turn results in an
increase in the distance between user devices and their
clouds, causing large average network latency and jitter. By
shifting computing and storage away from centralized
locations, the distributed computing paradigm known as edge
computing was developed to alleviate some of the problems
[2].
By shifting computing and storage away from centralized
locations, the distributed computing paradigm known as
"Edge Computing" was developed to address some of the
problems [2]. Edge computing moves data, services, and
applications closer to the locations where such services are
needed. Fog Computing, in particular, makes use of Edge
devices to do the majority of local processing, storage, and
communication. These gadgets range in size from tiny
Internet of Things (IoT) or Internet of Everything (IoE) [3]
platforms with a single CPU core and less than a Megabyte
of Memory to fully
functional servers with multiple CPU cores, numerous GPU
cores, and gigabytes of RAM.
Although the two current network paradigms (Cloud and
Edge/Fog) have relatively similar use-cases, the context of
usage for the apps and various types of devices used in the
architecture could be extremely different. Because of this, it
is necessary to assess the security risks associated with
virtualization, which have been thoroughly researched for the
cloud environment.
In order to reduce the Time-to-Market for both hardware and
software developers, edge and fog devices increasingly rely
on Linux technology, whether it be a regular server
distribution or an embedded operating system. This is due to
Linux's demonstrated dependability, extensive ecosystem,
and wide range of available technology solutions (such as
virtualization). Although there are other technologies
available today, the tendency in software is towards
consolidation, so it is frequently more practical to reuse as
much of the tried-and-true solutions, especially when it is
possible to remove extraneous components.
In order to provide more dependable and effective services,
resources on Edge/Fog servers are rapidly being produced
employing virtualization technologies. Notwithstanding the
above listed advantages, one should not forget the potential
security risks generated by the very use of virtualization; if
such issue is not adequately addressed, they could hamper the
full realization of Edge potential.
Contribution: This paper's major goal is to analyse the
effects of virtualization technologies on the Edge/Fog
network architecture, outlining their benefits and exposing
the security risks they provide. To do this, we first grouped
the equipment utilised at the Edge and Fog levels and
assessed how well it supported virtualization. We next
assess those technologies in the context of four typical real-
world Edge Computing use-case scenarios after reviewing
the general security issue of both the most popular
virtualization technologies (i.e., containers and unikernels)
and the rival non-virtualized method (RTOS). Lastly, we
try to clarify potential future research areas and workable
solutions that might have an impact (either positively or
negatively) on the overall security of the Edge/Fog
paradigm.
Roadmap. The rest of this essay is structured as follows.
The Edge and Fog architectures are discussed in Section II,
while Section III describes the current supporting
technologies. The real-world scenarios that we consider
throughout the remainder of the paper are illustrated in
Section IV. The security concerns relating to the auxiliary
technologies covered in the preceding sections are discussed
in Section V. Section VI offers a thorough analysis along
with intriguing potential possibilities for the future, and
Section VII makes some closing observations.
II. ARCHITECTURAL BACKGROUND
In this section we provide an overview of both the Edge and
Fog Computing architectures, discussing their properties,
differences, and hardware requirements.
These two paradigms do not have a single, widely
acknowledged definition; instead, they have numerous, errant
descriptions that occasionally overlap. This ambiguity is
most likely caused by the fact that both systems aim to move
the computation closer to the data source. In fact, the
traditional cloud architecture, in which data are transferred
across long distances to be processed, has to be changed in
order to provide the low latency performance that modern
end-user applications demand. Data are processed (also
partially) in the same device that produced them or in an
external device, but at the edge of the same network,
according to the Edge Computing architecture. Instead, in the
Fog network model, data are processed outside the network,
yet extremely close to where they were originally collected.
Both names are used interchangeably throughout the
remainder of this essay because we will be discussing both.
In the section that follows, we categorize the hardware that
could be utilized at the Edge and Fog levels, as shown in Fig.
1, to properly comprehend the effects of virtualization
technologies on the Edge/Fog network paradigm. Based on
the hardware design and the current implementations, we
discuss the virtualized support that each device category
currently offers. Collaboration: Cloud-based tools allow for
easier collaboration among team members, regardless of their
location.
Edge/Fog hardware Devices that produce raw data (e.g.,
sensors), receive processed data (e.g., end-user devices like
smartphones), and provide computational power or other
services make up the three sorts of devices that are part of the
edge computing level (i.e., servers). In contrast, the Fog
network concept simply consists of servers because data are
created and used at levels below.
1) Edge Devices: Every device that produces data
and/or runs an end-user application falls under this
category. These devices can be divided into three
basic kinds, as shown in Table I: restricted devices,
single-board computers, and mobiles. Any IoT
device utilized for various purposes, such as
domotics, surveillance, automotive, and many
others, falls under the category of restricted
devices. Virtualization technology is not supported
by this.
Figure 1. Edge/Fog Devices and their relative placement
Category Architecture Example Devices
Virtualization
Support
Constrained MSP430,
Arduino,
✗
Telos,
Devices Arm
Open Mote
Single board x86-64, Raspberry Pi,
computer Armv8 Intel NUC
✓
Mobile
Arm,
Armv8
Android/IOS
Smartphones
Not yet
Table I
ARCHITECTURAL SOLUTION FOR EDGE COMPUTING DEVICES
device category. In actuality, these devices have
extremely few resources accessible because of some
limitations, including production costs or physical
restrictions on characteristics like size, weight, and
available power and energy (at most 50Kb of RAM and
250Kb of storage) 1. Instead, due to their architecture
and the resources at their disposal, single-board
computers like the Raspberry Pi or the Intel NUC fully
support both hardware and software virtualization.
Despite having an architecture that fully enables
virtualization, mobile devices do not currently have any
implementations that do.
2) Edge/Fog Servers: General purpose servers (i.e.,
the same servers used in cloud environments), new
platforms especially created for the Edge/Fog
requirements, and other platforms created for specific
use-cases (i.e., auto- motive), are three major categories
in which to place the devices that could be used as
servers in both the Edge and Fog levels. Table II lists
these categories, provides samples of products that may
be purchased, and emphasizes the support for
virtualization that is provided. Existing Edge/Fog
servers, sometimes known as cloudlets, are scaled-down
variants of cloud servers that are primarily built on CPUs
and one or more GPU co-processors. These devices are
primarily designed for batch processing of in-memory
data, making it difficult for them to deliver stable or
predictable performance while processing streaming
data from I/O channels. To process streaming data from
 diverse I/O channels at low power consumption and
good energy efficiency, future Edge servers will require
a new general-purpose computing system stack [4]. The
Openfog Consortium outlines the Fog reference
architecture in [5]. Despite the lack of a standard Fog
device, Intel created the Fog Reference Design (FRD), a
device that complies with the reference architecture. The
FRD and Cisco Edge Compute Devices IOx [6] both use
the Field-Programmable Gate Array technology (FPGA)
to cast proprietary hardware in a chassis, allowing users
to both configure and program it after production [7].
Both the general-purpose servers and the Edge/Fog
bespoke platforms fully support virtualization due to their
reliance on an x86-64 architecture. Nevertheless, the
virtualization possibilities for other platforms depend on
the vendor support offered. For instance, the manufacturer
offers a hypervisor for the Nvidia drive board listed in
Table II that can run either an operating system or a bare
metal application2.
Category Product
CPU Virtualization
Architecture Support
Automotive
Nvidia Drive
Armv8-A Vendor Limited
PX 2 (Tesla)
Intel Fog
Edge/Fog Reference x86-64
Customize Design
d Platform Unit IOx Edge
Cisco
Compute Devices
x86-64
Cloud Device Generic Server x86-64
Table II
ARCHITECTURAL SOLUTIONS FOR E DGE /F OG S ERVER
. restriction in order to be called real-time . A first classification
III. SUPPORTING TECHNOLOGIES
This section gives a high-level overview of the virtualization-
supporting technologies now available that can be
incorporated into the Edge Computing networking
architecture. We consider the concepts and technologies of
containerization, unkennel, and Real Time Operating
SySystemsas shown in Figure 2. The use of these
technologies in the Edge/Fog network model is then covered.
Figure 2. Supporting HW/SW Architectures
Containerization: The encapsulation of applications into
particular recipients, known as containers, is made possible
by containerization, a lightweight alternative to complete
virtualization. The idea of a container is not new; it has
evolved over time to take on many forms depending on the
level of isolation it offers. In contrast to virtualization,
containers provide performance that is almost equal to that
of bare metal since they are standardised software units
that contain both the running code and its associated
dependencies [8], [9]. This logical packaging approach
separates programmes from the infrastructure, making it
possible to deploy container-based applications
consistently and effectively independent of the
environment (e.g., a data center, a laptop, a raspberry Pi, to
name a few). Like regular processes, containers are able to
share libraries with the host and execute directly on the
host kernel to avoid duplicating code [9]. The most popular
software container platform in the world, Docker, offers a
systematic technique to automate the deployment of
applications inside portable containers [10].
Real-Time Operating Systems (RTOSes): We use the term
"real-time operating systems" to refer to any operating
system that can run real-time applications, or programmes
that need both a high level of reliability and exact timing
[11]. Despite some open-source initiatives, the majority of
RTOS developments are proprietary solutions. They typically
✓
have a very slim and straightforward kernel that controls the
✓ underlying hardware alone (i.e., they are bare metal in that
✓ they do not support virtualization mechanisms). Every key
function carried out by the Operating System (such as OS
calls and interrupt handling) must have a maximum time
of real-time operating systems (RTOS) is made as a result of this
time management (see also [12]): a Hard Real-Time Operating
System (HRTOS) is always able to guarantee a maximum time for
each of the critical operations, whereas a Soft Real-Time Operating
System (SRTOS) is able to guarantee a maximum time for each of
the critical operations the majority of the time [13]. Moreover,
RTOSes have two standard designs: I event-driven, where job
switching is based on higher priority occurrences, and (ii) time-
sharing, where task switching is based on regular clock activity. For
services that demand constrained response times, RTOSes may be
advantageous for Edge Computing [14].
Unikernels: The Unikernel method, also known as Library
OS [15], develops customized, single-purpose, single-
address-space images by relocating the OS services that
applications are based upon into the same address space as
the applications themselves. The plan is to completely
overhaul the way virtual machines are built, replacing "fat"
machine images with compact, safe, quick, and reusable
ones. The concept is founded on the observation that most
internet services, such DNS servers, are built on bulky
images with libraries that are never used by the service
itself. The "thinning out" of the libraries produces safer
pictures (i.e., a significantly smaller attack surface), which
ultimately results in the resource optimization of the
computers that host them. The developer must select the
bare minimum set of operations required for the application
to function in order to deploy the application within an
image. In order to create sealed images that can operate
directly on the hardware or a hypervisor (i.e., without an
intermediary Operating System), these libraries are
compiled into the application executable using a library
operating system [16].
Virtualization at the Network's Edge: The Edge/Fog servers
can employ the virtualization-supporting technologies
discussed in earlier sections to deliver services that are more
scalable, dependable, and performant. Figure 3 shows a
typical use-case. Instead of sending raw data to the cloud,
IoT sensors deliver it to Edge/Fog servers where they can
then receive orders (solid lines). These servers are physically
adjacent to or directly connected to the IoT network gateway
(Edge) or to a location outside the IoT network (Fog). In
order to create on-demand services, virtualization
technologies are employed to assure the network's scalability
by launching a tailored VM or container now of the request.
If the end-user service is not locally hosted, the servers
elaborate and aggregate the data collected before delivering
the results to the cloud. Instead of sending requests to the
cloud, end-user applications running on smartphones and
other client devices deliver them to Edge/Fog servers (dotted
lines), which reduces latency and enhances user experience.
Figure 3. Virtualization on Edge/Fog Computing Architecture
IV.USAGE SCENARIOS
We introduce four real-world use-cases in this section—
Cloud Gaming and Augmented Reality, Smart Homes and
Cities, E-Health, and Network Function Virtualization,
respectively—that support the application of virtualization
technologies. We examine the adoption of the Edge
Computing paradigm for each use-case and highlight
potential advantages over the conventional cloud
architecture.
Cloud Gaming and Augmented Reality: The number of video
gamers who are actively playing games worldwide is
predicted to reach 2.73 billion by 2021 [17], representing a
market worth more than $50 billion globally [18]. This
sparked the development of ground-breaking applications
that allowed the blending of computer-generated data with
actual reality [19], also known as augmented reality
applications. Nevertheless, the spread of these kinds of
applications has been hampered by the current network,
storage, and processing constraints. Due to network capacity
restrictions and the excessive delay brought on by the
infrastructure's geographic remoteness, the currently used
Internet infrastructure is not suited for augmented reality.
Edge computing usage has the potential to change the
situation. In fact, by allowing data to travel a shorter
distance, this network infrastructure would provide a more
immersive and participatory gaming experience (i.e., with
reduced latency and lag times) [18].
Smart Homes and Cities: Sensor devices and actuators are
becoming more common in our homes and cities. Distributed
intelligence that can scale along with the number of managed
devices without affecting functionality and usability is
required for managing and orchestrating data and controlling
such an ubiquitous and diverse landscape. For these kinds of
needs, edge computing can be crucial because it speeds up
response times to external stimuli by performing local
computations and data buffering/caching.
E-health: The word "e-health" can refer to systems and
services that allow for the real-time monitoring and exchange
of patient data, as well as events brought on by gadgets that
are either attached to or extremely near the patients
themselves. Several of these gadgets can ask for human
intervention from medical professionals or (re)act
automatically. Examples of applications include remote
diagnosis and therapy, direct patient care delivery, and
remote monitoring of patients' functions. A network
connection to other systems is a requirement for such
intelligent medical devices. Failures or delays in the
operation of these devices and/or the supporting network may
result in patient harm or injury, or even death. As a result,
dependable and low latency services and devices must be
used to deliver e-health. Due of its ability to shorten patient-
hospital interaction periods, edge computing can be crucial to
meeting this need.
Network Function Virtualization: Network Function
Virtualization (NFV) is a technology introduced to
overcome the limitations of classic network architectures,
characterised by proprietary heterogeneous devices that are
usually very expensive both to deploy and manage.
Leveraging virtualization technologies, NFV decouples
software from hardware, allowing the execution of modular
applications on standardised server platforms. Every
network service may be broken down using this technology
into a collection of virtualized services that are implemented
in software and operate on regular physical servers. Then,
instead of having to buy and install new hardware, those
virtualized functions might be moved and instantiated at
geographically distinct network sites [20]. In addition to cost
reductions, NFV offers a flexible method for designing,
developing, distributing, and managing network
applications. Similar technology may be applied to edge
computing to deliver services that are more effective and
scalable.
VIRTUALIZATION-ORIGINATED
SECURITY ISSUES
In this section, we examine the security ramifications of
using the techniques described in Section III. We assess the
security analysis provided in the literature for each of the
enabling technologies, namely containerization, Real Time
Operating Systems, and unkennels, and we identify new,
intriguing security challenges that the adoption of each
technology could bring. Table III shows a scenario-driven
examination of potential assaults. Each row in the table
illustrates a scenario that might occur and lists the destructive
activities that an attacker might take to compromise privacy
or disrupt the system, depending on the underlying
technology that has been implemented. Because RTOS do
not enable numerous application images or their dynamic
(re)deployment, the Real Time Operating Systems column is
missing from the table given above. They are more
vulnerable to any vulnerability brought on by the lack of
security patches or updates than containerization and
unkennels.
Containerization – Docker: The widespread adoption of
containerization in recent years, particularly Docker, has
paved the way for a number of research targeted at
identifying the potential security risks and related
vulnerabilities. Table III additionally shows a few potential
pertinent assaults connected to the literature-researched
Docker use-cases. Security is one of the main objections to
the use of containers, and the quantity and severity of the
identified attacks provide an explanation.
One of the earliest studies that examines Docker's security
is [21], where the author evaluates Docker's security as
well as its relationship to the Linux Kernel's security
features. The authors of [9] offer a thorough analysis of the
vulnerabilities in the Docker ecosystem. As their initial
contribution, they classify related studies in the literature
into several macro-categories, including comparisons of
containers and virtualization, security features of
containers, protection against specific attacks, vulnerability
analysis, and use-cases-driven vulnerability analysis. Then,
using several use-cases—each of which explains a distinct
way to utilise Docker—they look into security problems
associated to the Docker ecosystem. As a result of their
research, the authors classify vulnerabilities into five
categories: unsafe production system configuration; image
distribution; verification; and decompression. vulnerability
in the image storage process, a vulnerability that is directly
related to Docker, a vulnerability inside the image, and a
vulnerability in the Linux kernel, respectively. Protect
container from applications, protect container from other
containers, protect host from containers, and protect
containers from host are the four basic use-cases that
authors in [22] consider. The authors analyse potential
solutions and identify potential associated threats for each
use-case. The terms semi-honest and malicious are taken
from [22]; according to the authors, a malicious adversary
is one who has the ability to deviate from the protocol in
order to both obtain information and compromise the
system, while a semi-honest adversary is a passive
adversary who can cooperate to obtain information but
cannot do so. to both get information and hack the system,
stray from the protocol.
RTOS: RTOSes must keep the complexity of controlling
hardware and applications to a minimum in order to
guarantee constrained execution times. They are mostly event
driven and quick to respond to occurrences as a result.
Despite this, due to their simplicity, RTOSes are still
susceptible to a number of attacks [12], including DoS attacks
(where a running process can block shared memory and
cannot typically be stopped), code injection (where the
command flow is changed to execute malicious code), and
data exfiltration (where memory isolation is typically not fully
enforced by RTOSes, relying instead on a straightforward
shared memory layout.
Unikernel: To the best of our knowledge, [32] is the only
piece of writing that offers a thorough analysis of the
security concerns with the unikernel strategy. The author of
this study first discusses the history of virtual machines,
unikernels, and hybrids, respectively, before analysing the
security isolation features of each technology.
Table III
MOST RELEVANT SCENARIO-DRIVEN ATTACK IDENTIFICATION
Scenario Description Possible Attacks (Docker) Possible Attacks (Unikernel)
Protecting Each ap pl ication can be. Remote code execution; unauthorized access. Unikernels ru n t h e im age at ring 0 (or
from untrusted malicious, semi-honest, or honest, network-based intrusions; virus, worm, trojan, ransomware; equivalent). As such are fully exposed to malicious
applications inside respectively. Fur- thermore, it is information disclosure, tampering, and privacy issues; privilege code in images. Nevertheless, the isolation provided by
images assumed there are applications escalation, denial of service ([9], [21]– [23]). the hypervisor us- ing hardware-assisted virtualization
that require root privileges. helps reducing the tampering and data access, as well
as privilege escalation issues [24].

Inter-image protection Images can be semi- DoS on other images; ARP spoofing; MAC flooding. DoS and other attacks on images are fea-
honest or malicious and placed port/vulnerability scanning; remote code execution ([ 9], [22], sible. Nevertheless, the isolation provided by ring -1
inside one or different hosts. [23]). (or equivalent) might be used to contain the attack.

Protecting host It is assumed that at least. Attacks on unnecessary services; container escape The h o s t s y s t e m ( hypervisor) r u n s a t a
from images one image is semi-honest or attacks; DoS; data tampering ([9], [22]). higher privilege level, as such the possible attack are
malicious within a host. related to hypervisor vulnera- bilities as in the regular
VM+hypervisor scenarios.

Protecting image Images are honest but the Profiling in-image application activities; unauthored access for Unikernels here have the same issues as
from host host is either semi-honest or image data; changing the image behavior ([22]). containers, unless SGX [25] or similar tech- nology is
malicious used.
Microservices- Each image hosts a single Zip-bomb-like attacks; remote code execution; virus, Unikernels are vulnerable as well, but priv-
like service in a single process. warm, trojan, ransomware; privilege escalation; ac- count ilege escalation is more difficult and it has to resort to
hijacking; network communication tampering ([9]) some kind of hypervisor vulner- ability.

Application Image Using Docker as a way Data leakage; DoS; DoS on other containers; attacks Unikernels are equally vulnerable to third-
Distribution of shipping virtual on the container integrity; privilege escalation; con- trainer escape party image hosting. Only privilege escala- tion is
environments. attacks ([9]) harder (unless some CPU backdoor is leveraged by the
hosted code [26]).
Image Docker integration pro- Data leakage; DoS; DoS on other containers; Zip- Same as above, like containers but
deployment on the vided by the main Cloud bomb-like attacks, remote code execution; virus, warm, trojan, potentially more isolated when deployed.
Cloud Providers. ransomware; privilege escalation; ac- count hijacking; network
communication tampering ([9]).

Image repository Each image has been pro-. Zip-bomb-like attack; remote code execution; virus, Same as above, similar to containers but
vided by a repository through a warm, trojan, ransomware; privilege escalation; data leakage ([9], potentially more isolated when deployed.
distribution process [22], [27]– [30]).

Table III
MOST RELEVANT SCENARIO-DRIVEN ATTACK IDENTIFICATION

Table IV

EDGE-IOT SCENARIOS, REQUIREMENTS, AND SECURITY IMPACT [31]

Scenarios Tech Performance Fitness Security Impact

Cloud Gaming RTOSes and containers fit better as they provide slightly less overhead (read:latency) Low security impact, as attacks would mostly just cause a DoS
Virtual Reality than unikernels in the game being played.

Smart home Containers and unikernels are equivalent, with a small advantage of unikernels for Here the consequences of a successful attack can be more serious
Smart Cities security isolation and an advantage of containers for the ease of setup. RTOSes are e.g., up to the house catching fire or some DoS in the
relevant only for constrained devices surveillance cameras.

E-Health Unikernels have a small advantage over containers due to the increased security Vital is the keyword, as DoSes and malicious soft- ware/device
isolation/resilience that is crucial in this contest. RTOSes could be adopted only in can possibly cause harm to the patient.
some corner case on constrained devices.

NFV Containers and unikernels are roughly equivalent, with a small advantage of unikernels The impact on security is relevant as Malicious/altered software
for security isolation and an advantage of containers for the ease of configuration; might cause relevant DoSes to other applications relying on the
RTOSes are still relevant but suffer from difficult updates network.
VI. DISCUSSION AND FUTURE DIRECTIONS
This section compares the supporting technologies provided
in Section III to the real-world use cases introduced in
Section IV. The objective is to comprehend how the use of
these technologies might impact the particular scenario in
relation to two key factors: performance and security. In
table IV, the findings of this investigation are enumerated.
The issue of security software upgrades is common to all
the use-case situations. Deploying security fixes must really
be made easier and more automated over time since new
vulnerabilities must be fixed often and, ideally, with the least
amount of delay possible. The flexibility provided by the
extra layers between application images and the hardware
may be used by containers, but even more unikernels, to offer
seamless patching. RTOSes can theoretically be upgraded,
however this procedure often calls for physical access to the
hardware and direct involvement. Hence, the scalability of
software updates is somewhat constrained.
As cloud gaming and virtual reality use cases become more
prevalent (see the initiatives by Google and others [35]),
assuring speed is more important than protecting the integrity
of the code and data. To maximise this dimension, methods
like RTOSes and unikernels can be appropriate. On the one
hand, RTOSes, such as proprietary solutions, are often more
expensive and, as was already said, have more difficult
software upgrades, even though they are suitable for large
businesses. A microservices container-like method, on the
other hand, might help to reduce the requirement for updates
and could be practical where digital right management is not
a crucial limitation, such as when verifying the video game's
code integrity for billing purposes. Moreover, using
unikernels would guarantee a smaller attack surface, assisting
in ensuring code integrity, simplicity of updates, and
acceptable speed (i.e., reduced latency).
Robustness and dependability are very important in terms of
performance and simplicity of updates for the use-case
scenario of Smart Homes and Cities. As a result, using
unikernel technology can be more and more practical, unless
the devices in question are so basic and inexpensive that
hardware virtualization support cannot be ensured. Current
bare metal RTOSes may be the only (or most practical)
choice in this latter scenario. Nevertheless, because it is
challenging to maintain such gadgets updated, this method
would be more vulnerable to assaults. This may result in
significant DoS attacks or other serious problems that might
call for the re-deployment of devices.
Reliability, security, and privacy are required for the E-
Health use-case. Unikernels therefore seem to be the most
appropriate option, utilising the smaller attack surface and
simplicity of updates, and the performance improvements of
RTOSes and unikernels may be left aside. The option that
was just made implies that in order to sustain, develop, and
ensure the success of this technology, increasing amounts of
work will be required to streamline image development,
upgrading, and administration of unikernels [36].
Some thorough examples of the Network Function
Virtualization scenario are given below.
The Domain Name System (DNS), a decentralised
hierarchical system that provides translation services between
users and Internet-connected resources, is the subject of the
first illustration. The IP address of the requested resource is
given to the user by the DNS server in its conventional
implementation, in accordance with its database. The DNS
and end-user services are two examples of the new class of
sophisticated services that may be developed thanks to NFV.
This technique may be used to operate microservices, which
are only operational after a DNS resolution. Jitsu [37], a DNS
server that immediately boots virtualized instances of the
resource the user has requested, is a nice example. A virtual
machine is immediately started when Jitsu gets a DNS
inquiry, and then the query result is delivered back to the
client. This technique might be implemented at the network's
edge, offering effective and scalable on-demand systems that
execute a unique picture for each URL. Performance-wise,
both the container and the unikernel technologies are viable
(i.e., boot time). Unikernel images, however, can give a
relatively restricted attack surface when designed properly
(i.e., by removing any extraneous functionality), which is
further reinforced by the separation among services provided
by the hypervisor. As a result, the inability to completely
remove all unwanted/unnecessary code from images is one of
the key problems with unikernels' security. Automated
intelligent technologies for picture production are desperately
needed to achieve this (see also [36]).
Another example is the dynamic nature of virtual networks,
which implies new security requirements that conventional
firewalls cannot address for a variety of reasons. First off,
conventional firewalls offer reliable protection on
predetermined and static network topologies. However, in a
highly dynamic environment where Virtual Machines (VMs)
are scattered and regularly transferred among various
network segments, they lack the flexibility and adaptability
to provide the same security level. Firewalls might be
deployed as a software instance to alleviate this issue by
removing the reliance on fixed network topology and
supplying the essential adaptability to safeguard virtual
networks [38]. The differences between containers and
unikernels in this use case are minimal. Nevertheless,
because containerization technology may be set up more
quickly and easily than unikernels, it may be preferred. As
with the prior use-case, it is uncertain if automated, simpler
delta-based image update procedures would enhance the
usability of the Unikernel [36].
VII. CONCLUSIONS
First, we looked at how the Edge/Fog paradigm relies on
virtualization technologies to deliver the high performance
and scalability that are the cornerstones of its success. We
later investigated potential attacks against the most important
virtualization technologies. After that, we contextualised
these dangers into four distinct Edge/Fog Computing
scenarios. We have highlighted the benefits and downsides of
adopting each virtualization technique that has been taken
into consideration for each scenario, as well as the potential
consequences of the identified attacks. We have also
suggested some intriguing future research paths and potential
technical advancements.
ACKNOWLEDGEMENT
Awards NPRP- S-11-0109-180242, UREP23-065-1-014, and
NPRP X-063-1-014 from the QNRF-Qatar National Research
Fund, a subsidiary of The Qatar Foundation, helped to
partially fund the publication. The opinions and facts
included in this article are those of the authors and may not
accurately represent the official QNRF position.
REFERENCES
[1] R. Roman, J. Lopez, and M. Mambo, "Mobile Edge
Computing, Fog, and Other Technologies: A Survey and
Analysis of Security Threats and Challenges," Future
Generation Computer Systems, vol. 78, pp. 680-698, 2018.
[2] "Fog computing: Present research and future problems,"
KuVS- Fachgesprach Fog Comput, vol. 1, pp. 1-4, 2018. J.
Gedeon, J. Heuschkel, L. Wang, and M. Muhlhauser.
[3] "Fog Orchestration for Internet of Things Services," IEEE
Internet Computing, vol. 21, no. 2, pp. 16–24, 2017. Z. Wen,
R. Yang, P. Garraghan, T. Lin, J. Xu, and M. Rovat- sos.
[4] S. Biookaghazadeh, M. Zhao, and F. Ren, “Are fpgas
suitable for edge computing?” in {USENIX} Workshop on
Hot Topics in Edge Computing (HotEdge 18), 2018.
[5] The OpenFog Consortium's Tech. Rep. from 2017 is
titled "Openfog standard architecture for fog computing."
[6] The "Cisco IOx Documentation" docs/iox/#!introduction-
to-iox/what-is-iox at developer.cisco.com.
[7]. The summary of the Intel Fog reference design is at
https://www.intel.com/content/dam/www/public/us/en/docum
ents/design-guides/fog-reference-design-overview-guide.pdf.
[8] “What is a container?”
https://www.docker.com/resources/ what-container, 2018.
[9] "Docker ecosystem-vulnerability study," Computer
Communications, vol. 122, pp. 30-43, 2018. A. Martin, S.
Raponi, T. Combe, and R. Di Pietro.
[10] D. Bernstein, “Containers and cloud: From lxc to docker
to kubernetes,” IEEE Cloud Computing, vol. 1, no. 3, pp. 81–
84, 2014.
[11] P. Hambarde, R. Varma, and S. Jha, “The Survey of
Real Time Operating System: RTOS,” in International
Conference on Electronic Systems, Signal Processing and
Computing Technologies, 2014, pp. 34–39.
[12] L. Pike, P. Hickey, T. Elliott, E. Mertens, and A. Tomb,
“TrackOS: A Security-Aware Real-Time Operating System,”
in Runtime Verification, 2016, pp. 302–317.
[13] “What is a real-time operating system (rtos)? – white
paper,”
http://www.ni.com/en-lb/innovations/white-papers/07/ what-
is-a-real-time-operating-system--rtos--.html, 2012.
[14] A. Manzalini and N. Crespi, “An edge operating system
enabling anything-as-a-service,” IEEE Communications
Mag- azine, vol. 54, no. 3, pp. 62–67, 2016.