1

NoHype : Virtualized Cloud Infrastructure without the

Virtualization

Paper by : Eric Keller, Jakub Szefer, Jennifer Rexford, Ruby B.Lee

Presented by : Samarth Godara 14223004, Mtech 2nd semester

NIT Jalandhar, Punjab, India

2

NoHype : Virtualized Cloud Infrastructure without the Virtualization : Sections

1. Introduction2. Security Threats3. Virtualization Layer’s Role4. NoHype Architecture5. Security Benefit6. Hardware Support7. Related Work8. Conclusion

3

Introduction : Basic Cloud Functionality

4

Introduction : Basic Cloud Functionality

1. The output must not get affected by the change in the implementation

2. The change must be more secure

3. The change must be possible

5

Security Threats

In the new implementation the Vms should notbe able to :

• Inspect each other’s data or software

• Affect the availability of each other

6

How the attacks can be done?To exploit one of these vulnerabilities, an attacker needs:

• to gain access to a guest OS • run software that can attack the hypervisor or root context• since the guest OS interacts with both for many functions, there is a

large attack surface. • Getting access to a guest OS is simple as the malicious party can lease

a VM directly from the cloud provider. • Further, if the attacker is targeting a specific party, it can check

whether its VM is located on the same physical server as the targeted victim’s VM

• using network-based co-residence checks such as matching small packet round-trip times and numerically close IP addresses

7

Virtualization Layer’s Role

Generic Virtualization of one server

8

Virtualization Layer’s Role

• Scheduling Virtual Machines• Memory Management• Emulating I/O devices• Network Packet processing• Starting/Stopping/Migrating VMs

9

NoHype Architecture

Proposed Architecture of NoHype

10

NoHype Architecture

Proposed Architecture of NoHype

11

NoHype Architecture

CPU : One VM per core

• Each core can run only one VM• No over-subscribing is possible• Already 8-core devices are available• Over-subscribing is possible along with the proposed

architecture, but will reduce security

12

NoHype Architecture

Memory : Hardware Support for partitioning

• Each OS has a dedicated and guaranteed fraction of memory

• Memory access is not possible in restricted range• This is done by Multi-core Memory Controller• MMC can provide fairness to each core, as one 1 core

is assigned to each VM

13

NoHype Architecture

Devices : per VM virtualized devices and rate-limited I/O

• The device itself realizes multiple view of single device

• Guest OS handles its own interrupts• Problem of limited Bandwidth is solved by flow-

control mechanism• I/O devices controls the rate of transmission

14

NoHype Architecture

Networking : is done in the network

• Ethernet switches in the data center performs the switching and security functions

• No software is needed to switch the packets in the system• Vms have direct access to the network interfaces• It simplifies the management as it removes extra type of

switch• It frees up the processor from extra work• It allows to use all the functions of Ethernet switch

15

NoHype Architecture

Starting/Stopping/Migrating Virtual Machines : System Manager

• Management code is active before a VM is started and after it is stopped

• It first starts in hyper-privileged mode• It is responsible for accepting commands from the cloud manager

software and issue commands to the individual cores• Commands are issued via Inter Processor Interrupts (IPI)• Sending and masking of the IPIs is controlled through memory

mapped registers of the core’s local APIC (Advanced Programmable Interrupt Controller)

16

NoHype Architecture

17

NoHype Architecture

18

NoHype Architecture

19

NoHype Architecture

Live Migration of VM :

• Memory management unit track which pages have been modified.

• System manager uses an IPI to get the difference in the pages.

• The changes are sent to the target server• The target core manager make same updates• After the last difference, the VM on the source server shuts

down and the VM on target server starts execution by ‘migrate’ IPI.

20

NoHype Architecture

Proposed Architecture of NoHype

21

Security Benefits of NoHype

Availability attacks are possible by :

• altering the hypervisor’s scheduling of VMs• interrupting a core running a VM, or • performing extraordinary amounts of memory

or I/O reads/writes to gain a disproportionate share of the bus and therefore affect the performance of another VM

22

Security Benefits of NoHype

Availability attacks are prevented by:

• By dedicating a single core to a VM• Hardware masking is used for interrupt• Rate-limit access to the I/O devices

23

Security Benefits of NoHype

Confidentiality / integrity of data and software is preserved by :

• No cores are shared• No Hypervisor runs during the entire lifetime

of the Virtual Machine• No possible way to access the registers

24

Security Benefits of NoHype

Side channels occur whenever resources are shared among multiple pieces of software

Side channels are prevented by :

• No resource is shared among multiple piece of software. Every resource is accessed directly/through hardware support or under supervision.

25

Conclusion

• With NoHype architecture, virtualization gets more secured,

• With the cost of single core per VM. • Networking gets faster. • Accessing resources are easier. • Flexibility of scalable resources gets lost. • Each VM gets more privacy.• Over-subscription is not possible.

26

The End