Goals for Today Learning Objective: Understanding how operating - - PowerPoint PPT Presentation

▶
goals for today
SMART_READER_LITE
LIVE PREVIEW

Goals for Today Learning Objective: Understanding how operating - - PowerPoint PPT Presentation

Apr 06, 2023 557 likes •872 views

Goals for Today Learning Objective: Understanding how operating systems support containers and modern cloud computing paradigms Announcements, etc: MP4 due May 6th Get started ASAP! HW1 available! Due May 8th Just an

slide-1
SLIDE 1

CS 423: Operating Systems Design 1

Goals for Today

  • Learning Objective:
  • Understanding how operating systems support

containers and modern cloud computing paradigms

  • Announcements, etc:
  • MP4 due May 6th
  • Get started ASAP!
  • HW1 available! Due May 8th
  • Just an “appetizer” for the final exam
  • Multiple attempts allowed, but first attempt is graded

Reminder: Please put away devices at the start of class

slide-2
SLIDE 2

CS 423: Operating Systems Design

Professor Adam Bates Spring 2018

CS 423
 Operating System Design: OS Support for Containers

slide-3
SLIDE 3

CS 423: Operating Systems Design 3

Advanced Configuration and Power Interface (ACPI)


Part of UEFI since 2013

Part of UEFI since 2013:

■ Exposes different power saving states in a

platform-independent manner

■ The standard was originally developed by

Intel, Microsoft, and Toshiba (in 1996), then later joined by HP, and Phoenix.

■ The latest version is "Revision 6.3” published

in January 2019!

slide-4
SLIDE 4

CS 423: Operating Systems Design

ACPI Global States

4

■ G0: working ■ G1: Sleeping and hibernation (several degrees available) ■ G2:, Soft Off: almost the same as G3 Mechanical Off,

except that the power supply still supplies power, at a minimum, to the power button to allow wakeup. A full reboot is required.

■ G3, Mechanical Off: The computer's power has been

totally removed via a mechanical switch (as on the rear

  • f a power supply unit).
slide-5
SLIDE 5

CS 423: Operating Systems Design

ACPI Global States

5

■ G0: working ■ G1: Sleeping and hibernation (several degrees available) ■ G2:, Soft Off: almost the same as G3 Mechanical Off,

except that the power supply still supplies power, at a minimum, to the power button to allow wakeup. A full reboot is required.

■ G3, Mechanical Off: The computer's power has been

totally removed via a mechanical switch (as on the rear

  • f a PSU).

Processor-specific

slide-6
SLIDE 6

CS 423: Operating Systems Design 6

ACPI “Sleep” States

C-States:

■ C0: is the operating state. ■ C1 (often known as Halt): is a state where the processor is

not executing instructions, but can return to an executing state instantaneously. All ACPI-conformant processors must support this power state.

■ C2 (often known as Stop-Clock): is a state where the

processor maintains all software-visible state, but may take longer to wake up. This processor state is optional.

■ C3 (often known as Sleep) is a state where the processor

does not need to keep its cache, but maintains other state. This processor state is optional.

Core-specific

slide-7
SLIDE 7

CS 423: Operating Systems Design 7

C-States:

■ C0: is the operating state. ■ C1 (often known as Halt): is a state where the processor is

not executing instructions, but can return to an executing state instantaneously. All ACPI-conformant processors must support this power state.

■ C2 (often known as Stop-Clock): is a state where the

processor maintains all software-visible state, but may take longer to wake up. This processor state is optional.

■ C3 (often known as Sleep) is a state where the processor

does not need to keep its cache, but maintains other state. This processor state is optional.

ACPI “Sleep” States

slide-8
SLIDE 8

CS 423: Operating Systems Design 8

  • Yes. Run at minimum

frequency.

  • No. Run at max

frequency.

  • Yes. Find Critical

F r e q u e n c y t h a t minimizes energy…

Last Class…

When should we perform dynamic voltage scaling?

Can reduce Frequency and Voltage Can reduce Frequency, but Voltage is Fixed

DVS?

When processor is idle, it has option to sleep When processor is idle, it must stay awake When processor is idle, it has option to sleep

slide-9
SLIDE 9

CS 423: Operating Systems Design

Cloud Computing (Gen 1)

9

  • Dominated by Infrastructure-as-a-Service

clouds (and storage services)

  • Big winner was Amazon EC2
  • Hypervisors that virtualized the hardware-

software interface

  • Customers were responsible for provisioning

the software stack from the kernel up

slide-10
SLIDE 10

CS 423: Operating Systems Design

Hypervisors

10

slide-11
SLIDE 11

CS 423: Operating Systems Design

Hypervisors

11

  • Strong isolation between different customer’s

virtual machines

  • VMM is ‘small’ compared to the kernel… less

LoC means less bugs means (~)more security.

slide-12
SLIDE 12

CS 423: Operating Systems Design 12

  • ‘Practical’ attacks on IaaS clouds relied on side

channels to detect co-location between attacker and victim VM

  • E.g., we could correlate the performance of a shared

resource

  • network RTT’s, cache performance
  • After co-resident, make inferences

about victim’s activities

Hypervisors

slide-13
SLIDE 13

CS 423: Operating Systems Design 13

  • Strong isolation between different customer’s

virtual machines

  • VMM is ‘small’ compared to the kernel… less

LoC means less bugs means (~)more security.

  • High degree of flexibility… but did most

customers really need it?

Hypervisors

slide-14
SLIDE 14

CS 423: Operating Systems Design

Enter Containers

14

  • Rather than virtualize both user space and kernel

space… why not just ‘virtualize’ user space?

  • Meets the needs of most customers, who don’t

require significant customization of the OS.

  • Sometimes called ‘operating system virtualization,’

which is highly misleading given our existing taxonomy of virtualization techniques

  • Running natively on host, containers enjoy bare

metal performance without reliance on advanced virtualization support from hardware.

slide-15
SLIDE 15

CS 423: Operating Systems Design

Enter Containers

15

slide-16
SLIDE 16

CS 423: Operating Systems Design

Enter Containers

16

Looks like a VM from the inside! Acts like a process from the

  • utside!
slide-17
SLIDE 17

CS 423: Operating Systems Design

OS Support for Containers

17

  • Linux Containers (LXC):
  • chroot
  • Kernel Namespaces
  • PID, Network, User, IPC, uts, mount
  • cgroups for HW isolation
  • Security profiles and policies
  • Apparmor, SELinux, Seccomp
slide-18
SLIDE 18

CS 423: Operating Systems Design

containers = chroot on steroids

18

  • chroot changes the apparent root directory for a

given process and all of its children

  • An old idea! POSIX call dating back to 1979
  • Not intended to defend against privileged attackers…

they still have root access and can do all sorts of things to break out (like chroot’ing again)

  • Hiding the true root FS isolates a lot;

in *nix, file abstraction used extensively.

  • Does not completely hide processes,

network, etc., though!

slide-19
SLIDE 19

CS 423: Operating Systems Design

Namespaces

19

  • The key feature enabling containerization!
  • Partition practically all OS functionalities so that

different process domains see different things

  • Mount (mnt): Controls mount points
  • Process ID (pid): Exposes a new set of process IDs

distinct from other namespaces (i.e., the hosts)

  • Network (net): Dedicated network stack per

container; each interface present in exactly 1 namespace at a time.

  • ….
slide-20
SLIDE 20

CS 423: Operating Systems Design

Namespaces

20

  • The key feature enabling containerization!
  • Partition practically all OS functionalities so that

different process domains see different things

  • Interprocess Comm. (IPC): Isolate processes from

various methods of POSIX IPC.

  • e.g., no shared memory between containers!
  • UTS: Allows the host to present different host/domain

names to different containers.

  • There’s also a User ID (user) and cgroup namespace
slide-21
SLIDE 21

CS 423: Operating Systems Design

User Namespace

21

  • Like others, can provide a unique UID space to the

container.

  • More nuanced though — we can map UID 0 inside the

container to UID 1000 outside; allows processes inside

  • f container to think they’re root.
  • Enables containers to perform administration actions,

e.g., adding more users, while remaining confined to their namespace.

slide-22
SLIDE 22

CS 423: Operating Systems Design

cgroups

22

  • Limit, track, and isolate utilization of hardware resources including

CPU, memory, and disk.

  • Important for ensuring QoS between customers! Protects against

bad neighbors

  • Operate at the namespace granularity, not per-process
  • Features:
  • Resource limitation
  • Prioritization
  • Accounting (for billing customers!)
  • Control, e.g., freezing groups
  • The cgroup namespace prevents containers from viewing or

modifying their own group assignment

slide-23
SLIDE 23

CS 423: Operating Systems Design

Container Security?

23

“Containers do not contain.” - Dan Walsh (SELinux contributor)

  • In a nutshell, it’s real hard to prove that every feature of

the operating system is namespaced.

  • /sys? /proc? /dev? LKMs? kernel keyrings?
  • Root access to any of these enables pwning the host
  • Solution? Just don’t forget about MAC; at this point

SELinux pretty good support for namespace labeling.

  • SELinux and Namespaces actually synergize nicely; much

easier to express a correct isolation policy over a coarse-grained namespace than, say, individual processes

slide-24
SLIDE 24

CS 423: Operating Systems Design

Wait, how is this possible?

24

?? ?? ??

If containers are all about virtualizing user space, how can containers have

  • perating systems??
slide-25
SLIDE 25

CS 423: Operating Systems Design

Wait, how is this possible?

25

?? ?? ??

If containers are all about virtualizing user space, how can containers have

  • perating systems??

Answer: These aren’t kernels; they’re the system utilities of the distro that have been tricked by process namespaces!

slide-26
SLIDE 26

CS 423: Operating Systems Design

  • Start by looking in include/linux/*/*_namespace.h

Namespaces in the Linux kernel

26 struct user_namespace { struct uid_gid_map uid_map; struct uid_gid_map gid_map; struct uid_gid_map projid_map; atomic_t count; struct user_namespace *parent; int level; kuid_t owner; kgid_t group; struct ns_common ns; unsigned long flags; /* Register of per-UID persistent keyrings for this namespace */ #ifdef CONFIG_PERSISTENT_KEYRINGS struct key *persistent_keyring_register; struct rw_semaphore persistent_keyring_register_sem; #endif };

slide-27
SLIDE 27

CS 423: Operating Systems Design

How Docker fits in

27

  • Not an OS thing. ; )
  • Utilities that allow you to leverage (e.g.) LXC to build

a portable, self-sufficient application using containers.

  • Assures that all libraries and dependencies are

packaged inside of a container image

slide-28
SLIDE 28

CS 423: Operating Systems Design

Above the clouds…

28

  • Container (~PaaS clouds) are strictly easier to

manage than traditional IaaS VMs.

  • The era of Container hype has somewhat

come and gone… containers still expose more flexibility than most users need!!

  • Th hype now is about Function-as-a-Service

cloud; individual programs/functions executed by invocation, great for event-driven stuff.

  • Enabled by containers
  • Instruction-as-a-Service next? ; )
slide-29
SLIDE 29

CS 423: Operating Systems Design

Takeaways

29

  • Container support has existing in Linux for many years
  • Foundations of containerization has been around for

decades!

  • Automating LXC for portability (i.e., Docker) has

revolutionized cloud computing

  • Lasting legacy of containers may be enabling the

Function-as-a-Service revolution… cloud customers can now pay by the method invocation without any idle costs.