DOCSLIB.ORG

Criptografar Sua Atual Partição Root Usando Dm-Crypt Com Luks

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Criptografar sua atual partição root usando dm-crypt... http://www.vivaolinux.com.br/artigos/impressora.p... Criptografar sua atual partição root usando dm-crypt com luks Autor: Aline de Freitas <aline_aaline at riseup.net> Data: 11/01/2008 Introdução Há muita discussão pela rede sobre o por quê da necessidade de se criptografar discos. O mais importante a se pensar ao criptografar os discos é não se comprometer com os dados que você possa ter em seu sistema. Não vou entrar no mérito político dos porquês. Acredito que quem procura por documentação sobre criptografia já está decidida/o a fazer uso da mesma. Atualmente há vários métodos de criptografia disponíveis dos quais por exemplo loop-aes. Minha escolha por cryptsetup-luks com dm-crypt se deu por ser considerado o método adequado para grande volume de dados (criptografei meu quase que meu disco todo), por não ter uma perda muito grande na performance (o ganho com a segurança me parece compensar esta eventual perda) e por ser considerado o mais seguro. Há muito tutoriais na rede sobre o assunto, o principal, pelo qual me baseei é Security System Encryption DM-Crypt with Luks Alguns métodos de criptografia da partição root incluem o uso de um pendrive com uma senha criptografada no qual nem mesmo você poderá saber qual a senha. O problema em relação a este tipo de método é que se você perder o pendrive ou ele parar de funcionar, você não poderá NUNCA MAIS descriptografar seu sistema. Assim eu optei por uma alternativa menos severa mas nem por isso insegura, que é utilizar um cdrom para bootar o sistema e manter uma partição de boot não-encriptada para o caso de perda ou danificação do cdrom. Este método é baseado neste antigo e ultrapassado howto: Encrypted Root Filesystem HOWTO. Preparativos iniciais 1 de 12 11-04-2011 10:26 Criptografar sua atual partição root usando dm-crypt... http://www.vivaolinux.com.br/artigos/impressora.p... Requerimentos Kernel: >= 2.6.20 Suporte para udev Partição de boot separada. Algum mecanismo para backup. No meu caso utilizei um velho disco rígido de 20GB Paciência e persistência. Preparando o kernel O seu kernel deve estar configurado com as opções a seguir: # make menuconfig General setup ---> [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support () Initramfs source file(s) (Deixe este campo em branco!) Device Drivers ---> [*] Multiple devices driver support (RAID and LVM) ---> <*> Device mapper support <*> Crypt target support --- Cryptographic API ---> <*> SHA256 digest algorithm <*> SHA384 and SHA512 digest algorithms <*> Blowfish cipher algorithm <*> Serpent cipher algorithm <*> AES cipher algorithms se estiver usando um sistema amd64 troque a opção acima por <*> AES cipher algorithms (x86_64) Então, # make && make modules modules_install # mount /boot # make install 2 de 12 11-04-2011 10:26 Criptografar sua atual partição root usando dm-crypt... http://www.vivaolinux.com.br/artigos/impressora.p... Para quem usa Debian: # make-kpkg kernel-image # dpkg -i <o novo kernel> Obtenha as ferramentas Verifique se você possui cryptsetup-luks instalado. # emerge -avn cryptsetup-luks ou # apt-get install cryptsetup Fazendo backup dos dados (obrigatório) Primeiro precisamos fazer o backup da partição root. Digamos que seu disco principal seja /dev/sda e sua partição root seja /dev/sda3 e que o disco para backup seja /dev/sdb. Esta será a referência no decorrer do tutorial. Não se esqueça de trocar estes valores para a sua situação. Criamos uma partição única para armazenar os dados que futuramente serão encriptados: # fdisk /dev/sdb O número de cilindros para este disco está configurado para 2491. Não existe nada de errado, mas isto é maior que 1024, e pode em certas configurações causar problemas com: 1) programas que executam em tempo de inicialização (versões velhas do LILO) 2) inicialização e programas de particionamento de outros OSs (p.ex., DOS FDISK, OS/2 FDISK) Comando (m para ajuda): n Comando - ação 3 de 12 11-04-2011 10:26 Criptografar sua atual partição root usando dm-crypt... http://www.vivaolinux.com.br/artigos/impressora.p... l lógica (5 ou superior) p partição primária (1-4) p Número da partição (1-4): 1 Depois enter + enter para utilizar todo o disco e então para salvar: Comando (m para ajuda): w # mkfs.ext3 /dev/sdb1 Agora vamos fazer o backup dos dados: # mkdir /mnt/crypt # mount /dev/sdb1 /mnt/crypt # cd / # cp -avx / /mnt Aproveite para comer algo enquanto os dados são transferidos... Vamos preparar a nova partição: # vi /mnt/crypt/etc/fstab Troque a partição de root atual por /dev/sdb1. /dev/sdb1 / ext3 noatime 0 1 Edite também seu gerenciador de inicialização, no caso do grub, edite /boot/grub/menu.lst. kernel /vmlinuz root=/dev/sda3 Troque pelos valores da sua nova partição (lembre-se estes são exemplos. Substitua pelas SUAS partições). kernel /vmlinuz root=/dev/sdb1 # reboot Depois da inicialização, verifique se realmente está na nova partição: # mount | grep 'on / type' 4 de 12 11-04-2011 10:26 Criptografar sua atual partição root usando dm-crypt... http://www.vivaolinux.com.br/artigos/impressora.p... Deve apresentar a partição de backup, no meu caso /dev/sdb1. Preparando as partições root e swap a criptografar Agora vamos preparar a "antiga" root. O primeiro passo é encher toda a partição com 'lixo' de forma que um possível atacante não tenha como saber o quanto de dados foram escritos partição: # shred -vn 1 /dev/sda3 Agora aproveite para dar uma cochilada, caminhar, ler ou espere bastante dependendo dos recursos da sua máquina. Encriptar a partição swap Digamos que sua partição swap seja /dev/sda2. # cryptsetup -c blowfish -h sha256 -d /dev/urandom create swap /dev/sda2 # mkswap /dev/mapper/swap # swapon /dev/mapper/swap Agora vamos criar a nova partição root. Criando a nova partição root Você precisa de uma senha. Segura. Bem Segura. Você pode gerar alguma senha aleatória a partir de algum gerador de senhas aleatório. (veja apg, gpw ou visite http://www.diceware.com/). Você pode escolher uma senha complexa e anotar em um papel secretamente em seu poder. Quando memorizar queime este papel. # cryptsetup -y --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda3 WARNING! ======== 5 de 12 11-04-2011 10:26 Criptografar sua atual partição root usando dm-crypt... http://www.vivaolinux.com.br/artigos/impressora.p... This will overwrite data on /dev/sda3 irrevocably. Enter LUKS passphrase: (insira a senha) Verify passphrase: (repita a senha) Agora você pode abrir sua partição LUKS: # cryptsetup luksOpen /dev/sda3 root Enter LUKS passphrase: key slot 0 unlocked. A partir de agora sua partição de root passa a ser denominada /dev/mapper /root. Vamos criar um sistema de arquivos na mesma: # /sbin/mkfs.ext3 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/root (espere vários minutos...) mke2fs 1.35 (28-Feb-2004) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 36634624 inodes, 73258400 blocks 732584 blocks (1.00%) reserved for the super user First data block=0 2236 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 39 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. Monte a agora a partição: 6 de 12 11-04-2011 10:26 Criptografar sua atual partição root usando dm-crypt... http://www.vivaolinux.com.br/artigos/impressora.p... # mount -t ext3 /dev/mapper/root /mnt/crypt Agora vamos transferir os dados da sua partição root temporária para a nova partição criptografada: # cd / # cp -avx / /mnt/crypt (espere novamente bastante...) E quando terminar: # cd /mnt/crypt/dev # MAKEDEV generic Criando a imagem initramfs A initramfs é um ramfs no qual um arquivo initramfs é desempacotado antes que o kernel efetue tarefas tais como montar a partição root. Este arquivo pode ser inserido junto com a imagem do kernel, no momento da confecção do mesmo ou como um arquivo separado. Para nossa initramfs precisamos do busybox. Busybox é um conjunto de utilitários comuns em sistemas UNIX em um único e minúsculo executável. Para usuários de Gentoo: # mkdir /usr/local/src/build_initramfs # ROOT="/usr/local/src/build_initramfs/" USE="-pam make-symlinks static" emerge -av busybox Edite /etc/portage/savedconfig/sys-apps/busybox-<version> e tenha certeza de que a linha CONFIG_BUSYBOX_EXEC_PATH está como abaixo: CONFIG_BUSYBOX_EXEC_PATH="/bin/busybox" Senão altere e construa o busybox novamente com a USE savedconfig. # ROOT="/usr/local/src/build_initramfs/" USE="-pam savedconfig make-symlinks static" emerge -av busybox # cd /usr/local/src/build_initramfs # rm -r {etc,usr,lib,lib64,var} 7 de 12 11-04-2011 10:26 Criptografar sua atual partição root usando dm-crypt... http://www.vivaolinux.com.br/artigos/impressora.p... Usuários Debian ou outra distribuição devem baixar as fontes diretamente de http://www.busybox.net/. # tar -xjvf busybox-<versão> # cd busybox-<versão> # make menuconfig E selecione as opções conforme: http://gentoo-wiki.com/...-Crypt_with_LUKS#Building_BusyBox make Vamos gerar um kmap (mapa do teclado): # dumpkeys > default_keymap # loadkeys br-abnt2 # /usr/local/src/build_initramfs/bin/busybox dumpkmap > br-abnt2-<ARCH>.bin Ou, se você compilou as fontes do pacote oficial do busybox: <caminho para as fontes do busybox>/busybox dumpkmap > br-abnt2-<ARCH>.bin Como eu uso amd64 no lugar de ARCH inseri amd64 ficando br-abnt2- amd64.bin Se for i386, idem. # loadkeys default_keymap O arquivo init do initramfs Quando você boota seu sistema, o kernel irá extrair o initramfs para o rootfs e verificará se um arquivo chamado "init" existe, e se encontrado o executará.
Recommended publications
  • The Linux Kernel Module Programming Guide

    The Linux Kernel Module Programming Guide

    The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman 2007−05−18 ver 2.6.4 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the Open Software License, version 1.1. You can obtain a copy of this license at http://opensource.org/licenses/osl.php. This book is distributed in the hope it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. The author encourages wide distribution of this book for personal or commercial use, provided the above copyright notice remains intact and the method adheres to the provisions of the Open Software License. In summary, you may copy and distribute this book free of charge or for a profit. No explicit permission is required from the author for reproduction of this book in any medium, physical or electronic. Derivative works and translations of this document must be placed under the Open Software License, and the original copyright notice must remain intact. If you have contributed new material to this book, you must make the material and source code available for your revisions. Please make revisions and updates available directly to the document maintainer, Peter Jay Salzman <[email protected]>. This will allow for the merging of updates and provide consistent revisions to the Linux community. If you publish or distribute this book commercially, donations, royalties, and/or printed copies are greatly appreciated by the author and the Linux Documentation Project (LDP).
  • Trusted Docker Containers and Trusted Vms in Openstack

    Trusted Docker Containers and Trusted Vms in Openstack

    Trusted Docker Containers and Trusted VMs in OpenStack Raghu Yeluri Abhishek Gupta Outline o Context: Docker Security – Top Customer Asks o Intel’s Focus: Trusted Docker Containers o Who Verifies Trust ? o Reference Architecture with OpenStack o Demo o Availability o Call to Action Docker Overview in a Slide.. Docker Hub Lightweight, open source engine for creating, deploying containers Provides work flow for running, building and containerizing apps. Separates apps from where they run.; Enables Micro-services; scale by composition. Underlying building blocks: Linux kernel's namespaces (isolation) + cgroups (resource control) + .. Components of Docker Docker Engine – Runtime for running, building Docker containers. Docker Repositories(Hub) - SaaS service for sharing/managing images Docker Images (layers) Images hold Apps. Shareable snapshot of software. Container is a running instance of image. Orchestration: OpenStack, Docker Swarm, Kubernetes, Mesos, Fleet, Project Docker Layers Atomic, Lattice… Docker Security – 5 key Customer Asks 1. How do you know that the Docker Host Integrity is there? o Do you trust the Docker daemon? o Do you trust the Docker host has booted with Integrity? 2. How do you verify Docker Container Integrity o Who wrote the Docker image? Do you trust the image? Did the right Image get launched? 3. Runtime Protection of Docker Engine & Enhanced Isolation o How can Intel help with runtime Integrity? 4. Enterprise Security Features – Compliance, Manageability, Identity authentication.. Etc. 5. OpenStack as a single Control Plane for Trusted VMs and Trusted Docker Containers.. Intel’s Focus: Enable Hardware-based Integrity Assurance for Docker Containers – Trusted Docker Containers Trusted Docker Containers – 3 focus areas o Launch Integrity of Docker Host o Runtime Integrity of Docker Host o Integrity of Docker Images Today’s Focus: Integrity of Docker Host, and how to use it in OpenStack.
  • Providing User Security Guarantees in Public Infrastructure Clouds

    Providing User Security Guarantees in Public Infrastructure Clouds

    1 Providing User Security Guarantees in Public Infrastructure Clouds Nicolae Paladi, Christian Gehrmann, and Antonis Michalas Abstract—The infrastructure cloud (IaaS) service model offers improved resource flexibility and availability, where tenants – insulated from the minutiae of hardware maintenance – rent computing resources to deploy and operate complex systems. Large-scale services running on IaaS platforms demonstrate the viability of this model; nevertheless, many organizations operating on sensitive data avoid migrating operations to IaaS platforms due to security concerns. In this paper, we describe a framework for data and operation security in IaaS, consisting of protocols for a trusted launch of virtual machines and domain-based storage protection. We continue with an extensive theoretical analysis with proofs about protocol resistance against attacks in the defined threat model. The protocols allow trust to be established by remotely attesting host platform configuration prior to launching guest virtual machines and ensure confidentiality of data in remote storage, with encryption keys maintained outside of the IaaS domain. Presented experimental results demonstrate the validity and efficiency of the proposed protocols. The framework prototype was implemented on a test bed operating a public electronic health record system, showing that the proposed protocols can be integrated into existing cloud environments. Index Terms—Security; Cloud Computing; Storage Protection; Trusted Computing F 1 INTRODUCTION host level. While support data encryption at rest is offered by several cloud providers and can be configured by tenants Cloud computing has progressed from a bold vision to mas- in their VM instances, functionality and migration capabil- sive deployments in various application domains. However, ities of such solutions are severely restricted.
  • Chapter 3. Booting Operating Systems

    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.
  • Version 7.8-Systemd

    Version 7.8-Systemd

    Linux From Scratch Version 7.8-systemd Created by Gerard Beekmans Edited by Douglas R. Reno Linux From Scratch: Version 7.8-systemd by Created by Gerard Beekmans and Edited by Douglas R. Reno Copyright © 1999-2015 Gerard Beekmans Copyright © 1999-2015, Gerard Beekmans All rights reserved. This book is licensed under a Creative Commons License. Computer instructions may be extracted from the book under the MIT License. Linux® is a registered trademark of Linus Torvalds. Linux From Scratch - Version 7.8-systemd Table of Contents Preface .......................................................................................................................................................................... vii i. Foreword ............................................................................................................................................................. vii ii. Audience ............................................................................................................................................................ vii iii. LFS Target Architectures ................................................................................................................................ viii iv. LFS and Standards ............................................................................................................................................ ix v. Rationale for Packages in the Book .................................................................................................................... x vi. Prerequisites
  • Linux Boot Loaders Compared

    Linux Boot Loaders Compared

    Linux Boot Loaders Compared L.C. Benschop May 29, 2003 Copyright c 2002, 2003, L.C. Benschop, Eindhoven, The Netherlands. Per- mission is granted to make verbatim copies of this document. This is version 1.1 which has some minor corrections. Contents 1 introduction 2 2 How Boot Loaders Work 3 2.1 What BIOS does for us . 3 2.2 Parts of a boot loader . 6 2.2.1 boot sector program . 6 2.2.2 second stage of boot loader . 7 2.2.3 Boot loader installer . 8 2.3 Loading the operating system . 8 2.3.1 Loading the Linux kernel . 8 2.3.2 Chain loading . 10 2.4 Configuring the boot loader . 10 3 Example Installations 11 3.1 Example root file system and kernel . 11 3.2 Linux Boot Sector . 11 3.3 LILO . 14 3.4 GNU GRUB . 15 3.5 SYSLINUX . 18 3.6 LOADLIN . 19 3.7 Where Can Boot Loaders Live . 21 1 4 RAM Disks 22 4.1 Living without a RAM disk . 22 4.2 RAM disk devices . 23 4.3 Loading a RAM disk at boot time . 24 4.4 The initial RAM disk . 24 5 Making Diskette Images without Diskettes 25 6 Hard Disk Installation 26 7 CD-ROM Installation 29 8 Conclusions 31 1 introduction If you use Linux on a production system, you will only see it a few times a year. If you are a hobbyist who compiles many kernels or who uses many operating systems, you may see it several times per day.
  • Dell EMC Poweredge Systems Running Red Hat Enterprise Linux 7 Release Notes Notes, Cautions, and Warnings

    Dell EMC Poweredge Systems Running Red Hat Enterprise Linux 7 Release Notes Notes, Cautions, and Warnings

    Dell EMC PowerEdge Systems Running Red Hat Enterprise Linux 7 Release Notes Notes, cautions, and warnings NOTE: A NOTE indicates important information that helps you make better use of your product. CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid the problem. WARNING: A WARNING indicates a potential for property damage, personal injury, or death. © 2014 - 2019 Dell Inc. or its subsidiaries. All rights reserved. Dell, EMC, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners. 2019 - 03 Rev. A15 Contents 1 Overview........................................................................................................................................................6 System configuration requirements................................................................................................................................. 6 Memory......................................................................................................................................................................... 6 Installation and upgrade instructions............................................................................................................................... 6 2 Known issues—To be fixed in future releases.................................................................................................7 Unable to create or modify namespace for NVDIMM..................................................................................................
  • Linux for Zseries: Device Drivers and Installation Commands (March 4, 2002) Summary of Changes

    Linux for Zseries: Device Drivers and Installation Commands (March 4, 2002) Summary of Changes

    Linux for zSeries Device Drivers and Installation Commands (March 4, 2002) Linux Kernel 2.4 LNUX-1103-07 Linux for zSeries Device Drivers and Installation Commands (March 4, 2002) Linux Kernel 2.4 LNUX-1103-07 Note Before using this document, be sure to read the information in “Notices” on page 207. Eighth Edition – (March 2002) This edition applies to the Linux for zSeries kernel 2.4 patch (made in September 2001) and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright International Business Machines Corporation 2000, 2002. All rights reserved. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Summary of changes .........v Chapter 5. Linux for zSeries Console || Edition 8 changes.............v device drivers............27 Edition 7 changes.............v Console features .............28 Edition 6 changes ............vi Console kernel parameter syntax .......28 Edition 5 changes ............vi Console kernel examples ..........28 Edition 4 changes ............vi Usingtheconsole............28 Edition 3 changes ............vii Console – Use of VInput ..........30 Edition 2 changes ............vii Console limitations ............31 About this book ...........ix Chapter 6. Channel attached tape How this book is organized .........ix device driver ............33 Who should read this book .........ix Tapedriverfeatures...........33 Assumptions..............ix Tape character device front-end........34 Tape block
  • NOVA: a Log-Structured File System for Hybrid Volatile/Non

    NOVA: a Log-Structured File System for Hybrid Volatile/Non

    NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile Main Memories Jian Xu and Steven Swanson, University of California, San Diego https://www.usenix.org/conference/fast16/technical-sessions/presentation/xu This paper is included in the Proceedings of the 14th USENIX Conference on File and Storage Technologies (FAST ’16). February 22–25, 2016 • Santa Clara, CA, USA ISBN 978-1-931971-28-7 Open access to the Proceedings of the 14th USENIX Conference on File and Storage Technologies is sponsored by USENIX NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile Main Memories Jian Xu Steven Swanson University of California, San Diego Abstract Hybrid DRAM/NVMM storage systems present a host of opportunities and challenges for system designers. These sys- Fast non-volatile memories (NVMs) will soon appear on tems need to minimize software overhead if they are to fully the processor memory bus alongside DRAM. The result- exploit NVMM’s high performance and efficiently support ing hybrid memory systems will provide software with sub- more flexible access patterns, and at the same time they must microsecond, high-bandwidth access to persistent data, but provide the strong consistency guarantees that applications managing, accessing, and maintaining consistency for data require and respect the limitations of emerging memories stored in NVM raises a host of challenges. Existing file sys- (e.g., limited program cycles). tems built for spinning or solid-state disks introduce software Conventional file systems are not suitable for hybrid mem- overheads that would obscure the performance that NVMs ory systems because they are built for the performance char- should provide, but proposed file systems for NVMs either in- acteristics of disks (spinning or solid state) and rely on disks’ cur similar overheads or fail to provide the strong consistency consistency guarantees (e.g., that sector updates are atomic) guarantees that applications require.
  • Linux Kernel and Driver Development Training Slides

    Linux Kernel and Driver Development Training Slides

    Linux Kernel and Driver Development Training Linux Kernel and Driver Development Training © Copyright 2004-2021, Bootlin. Creative Commons BY-SA 3.0 license. Latest update: October 9, 2021. Document updates and sources: https://bootlin.com/doc/training/linux-kernel Corrections, suggestions, contributions and translations are welcome! embedded Linux and kernel engineering Send them to [email protected] - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 1/470 Rights to copy © Copyright 2004-2021, Bootlin License: Creative Commons Attribution - Share Alike 3.0 https://creativecommons.org/licenses/by-sa/3.0/legalcode You are free: I to copy, distribute, display, and perform the work I to make derivative works I to make commercial use of the work Under the following conditions: I Attribution. You must give the original author credit. I Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. I For any reuse or distribution, you must make clear to others the license terms of this work. I Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. Document sources: https://github.com/bootlin/training-materials/ - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 2/470 Hyperlinks in the document There are many hyperlinks in the document I Regular hyperlinks: https://kernel.org/ I Kernel documentation links: dev-tools/kasan I Links to kernel source files and directories: drivers/input/ include/linux/fb.h I Links to the declarations, definitions and instances of kernel symbols (functions, types, data, structures): platform_get_irq() GFP_KERNEL struct file_operations - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/470 Company at a glance I Engineering company created in 2004, named ”Free Electrons” until Feb.
  • Firecracker: Lightweight Virtualization for Serverless Applications

    Firecracker: Lightweight Virtualization for Serverless Applications

    Firecracker: Lightweight Virtualization for Serverless Applications Alexandru Agache, Marc Brooker, Andreea Florescu, Alexandra Iordache, Anthony Liguori, Rolf Neugebauer, Phil Piwonka, and Diana-Maria Popa, Amazon Web Services https://www.usenix.org/conference/nsdi20/presentation/agache This paper is included in the Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’20) February 25–27, 2020 • Santa Clara, CA, USA 978-1-939133-13-7 Open access to the Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’20) is sponsored by Firecracker: Lightweight Virtualization for Serverless Applications Alexandru Agache Marc Brooker Andreea Florescu Amazon Web Services Amazon Web Services Amazon Web Services Alexandra Iordache Anthony Liguori Rolf Neugebauer Amazon Web Services Amazon Web Services Amazon Web Services Phil Piwonka Diana-Maria Popa Amazon Web Services Amazon Web Services Abstract vantage over traditional server provisioning processes: mul- titenancy allows servers to be shared across a large num- Serverless containers and functions are widely used for de- ber of workloads, and the ability to provision new func- ploying and managing software in the cloud. Their popularity tions and containers in milliseconds allows capacity to be is due to reduced cost of operations, improved utilization of switched between workloads quickly as demand changes. hardware, and faster scaling than traditional deployment meth- Serverless is also attracting the attention of the research com- ods. The economics and scale of serverless applications de- munity [21,26,27,44,47], including work on scaling out video mand that workloads from multiple customers run on the same encoding [13], linear algebra [20, 53] and parallel compila- hardware with minimal overhead, while preserving strong se- tion [12].
  • Network Boot and Exotic Root HOWTO

    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.