comp075-os2 booting (cont.)

25
COMP075-OS2 Booting (cont.)

Upload: medge-cruz

Post on 31-Dec-2015

33 views

Category:

Documents


1 download

DESCRIPTION

COMP075-OS2 Booting (cont.). El Torito. Standard to allow bootable CD/DVD/BR Extension of ISO 9660 Issued in 1995 with floppy emulation mode Usually used in no emulation mode El Torito means little bull and refers to a restaurant chain where the spec was maybe developed - PowerPoint PPT Presentation

TRANSCRIPT

COMP075-OS2Booting (cont.)

El Torito

• Standard to allow bootable CD/DVD/BR

• Extension of ISO 9660

• Issued in 1995 with floppy emulation mode

• Usually used in no emulation mode

• El Torito means little bull and refers to a restaurant chain where the spec was maybe developed

• Inserts pointer to boot catalog right after pointer to first ISO9660 volume

El Torito Modes

• Floppy emulation mode

– Boots from a floppy disk image

• Hard disk emulation mode

– Boots from a hard disk image

• No emulation mode

– Preferred on newer computers

– Boots from the native ISO 9660 file system

ISOLINUX, SYSLINUX

• Loaders to allow booting linux from USB, CD etc

• ISOLINUX can boot linux (or GRUB) from El Torito CD in no emulation mode

• SYSLINUX can boot linux from FAT or NTFS file systems such as Floppy disks or USB keys or El Torito CD in emulation mode

– Installs loader in MBR and LDLINUX.SYS in root of filesystem

– Parameters passed to kernel tell it where linux filesystem or image is

ISOLINUX

• A modified syslinux

• Create directory with contents of ISO9660 filesystem

• Put directory /isolinux or /boot/isolinux in the image

• Put isolinux.bin and isolinux.cfg plus kernel files and images there

• mkisofs then used to create El Torito compatable file system image which can be burned to the CD/DVD/BR disk

ISOLINUX hybrid mode

• isohybrid command can create image bootable from CD or USB

• Encapsulates ISO9660 filesystem in an image with an MBR bootloader

• Image can be burned to CD or dd'd to USB

Booting from Read only Media

• Most OS's require write access to the disk to allow writing of log files, swap files and other data structures

• CD's are read only so special steps must be taken

• Linux loaders set up filesystems that read from CD but write to RAM disk as a single file system

– unionfs, aufs

• Windows uses Enhanced Write Filter (EWF)

Booting Windows from CD

• Aside from installation and rescue disks this is not a standard mode for windows

– Although booting Windows Embedded from CD using EWF and EWF loader is supported

• Various third party products are available to create bootable windows CD's or USB's from an existing windows installation plus some downloadable images.

PXE Booting

• Preboot Execution Environment

• Allow booting from a network

• Developed by Intel in 1998

• Relies on DHCP, TFTP and others

• Implemented in NIC BIOS or UEFI

• Provides simple network drivers, bare bones UDP/IP stack plus DHCP and TFTP

• Loads an NBP (Network Boot Program)– Name obtained by DHCP

UEFI

• The original IBM PC BIOS and MBR booting system has been replaced by UEFI on recent computers

• MBR and BIOS runs in 16 bit processor mode with original 8086 instruction set and 1 MB of memory

• This imposes severe limits on what the BIOS can do

– No filesystem drivers, just raw disk access

• Also, the size of the MBR/VBR limits the amount of code in the loaders

Unified Extensible Firmware Interface

• Original EFI spec developed by Intel beginning in 1998

• July 2005 renamed UEFI and taken over by UEFI forum

– EFI was very windows centric

• UEFI firmware does not have the limitations of BIOS (memory, instructions set etc)

• Can boot from GUID Partition Table (GPT) partitions

GPT Partitions

• Part of the UEFI specification

• GPT = GUID Partition Table

• GUID = Globally Unique Identifier– Usually includes random numbers– 128 bits, 32 hex digits– {21EC2020-3AEA-4069-A2DD-08002B30309D}

• Larger LBA allows larger partitions

• 128 partition entries

• Includes a Protective MBR for compatibility

GPT Details

• GUID used to ID individual partitions and as partition types

– EFI System Partition (ESP) is type {C12A7328-F81F-11D2-BA4B-00A0C93EC93B}

• 64 bit LBA allows for larger partitions

• LBA 0 contains Protective MBR which prevents MBR partitioning utilities from corrupting the disk format and provides compatibility

• LBA 1 is the start of the partition table header

GPT Partition Tables

• Header in LBA 1 and backup in last sector on the disk

• Partition table starts in LBA 2– Minimum 128 entries of 128 bytes = 16KiB– Copy at end of disk before backup of header

• Data partitions could start anywhere after this, but for performance reasons and compatibility reasons alignment with cylinder boundaries is desirable

– MS aligns with 1 Mib boundaries to achieve this

UEFI Booting• Based on EFI System Partition (ESP)

• FAT 32 or FAT 16/12 (removable media) or El Torito

• ESP contains parameters, boot loaders and other required files

• UEFI can detect boot loaders in standard locations

– /EFI/BOOT/BOOTX64.EFI

• Can present menu to user based on discovered loaders

• This is called UEFI-GPT boot

UEFI Compatibility

• Like any change to a fundamental technology backwards compatibility is essential

• UEFI supports GPT partitions or MBR partitions

– Some BIOS also can support GPT or MBR partitions

• UEFI exists for x86 and ARM in 32 or 64 bit and Itanium

– OS usually must match firmware 32 or 64 bit, although linux can boot 64 bit from 32 bit UEFI

UEFI CSM

• Compatibility Support Module

• Allows UEFI booting from MBR disk

• Provides BIOS compatibility

• Can allow a traditional BIOS boot from an MBR disk or from the MBR of a GPT disk

– BIOS-MBR boot

• Or, can boot from ESP on MBR disk– UEFI-MBR boot

GRUB and GPT

• GRUB uses sectors 2 through 62 on MBR disks for its stage 1.5

– These are unused sectors before the first partition

• GPT disks don't necessarily have these empty sectors

• If boot type is UEFI-GPT then entire GRUB loader is in the EFI System Partition

• If boot type is BIOS-MBR GRUB (or parted or gparted) creates a 1 Mib BIOS Boot Partition to use like ESP

– GUID {21686148-6449-6E6F-744E-656564454649}

= “Hah!IdontNeedEFI:” in ASCII

Secure Boot

• Meant to provide protection against pre-boot compromises

• BIOS and UEFI both give control to whatever software is in the right place.

– With UEFI it has to have the right name

• Compromised boot loaders could load compromised OS or OS components

• These pre-boot attacks are hard to defend against

Measured Boot

• Came before Secure Boot

• Doesn't prevent compromised components from being loaded

– But makes detection easier

• Starting with firmware, and then each loader or other component loaded before Anti-malware software, measurements of the components are taken and stored in the Platform Configuration Registers of the Trusted Platform Module

– Requires TPM

Secure Boot Mechanism

• Based on UEFI

• Firmware stores public keys of trusted software providers

– And blacklisted suppliers

• Firmware and all subsequent loaders and kernel components must be signed by one of these trusted suppliers

• Unsigned software can't be loaded

• Mechanism can be disabled– But not if UEFI supplier has prevented this

Secure Boot and Windows

• Implemented starting with W8

• W8 certified hardware manufacturers must have Microsoft keys in the firmware

• Must ship with secure boot enabled

• On x86 and x86-64 computers is must be possible to disable secure boot

• On ARM processors it must be impossible to disable

Secure Boot and Linux

• Easiest solution is to disable– Sometimes hard to determine how

• Microsoft is willing to sign third party loaders with their key but

– Takes a while– They won't sign GPL licensed software – Have to repeat with each change to the software– Loaders are open source, what if you compile it

yourself?

• You can try to load your own keys into the firmware and then sign your loaders yourself

Fedora Shim

• Meant to make dealing with secure boot a little easier

• Has a microsoft signature

• Will use any keys it finds in firmware

• Has a compiled-in key for loaders like GRUB

• Has a simplified mechanism to support Machine Owner Keys

– Simpler than loading your own keys into the UEFI firmware

• Linux Foundation's preloader is similar

References

• http://www.mossywell.com/boot-sequence/

• http://sysadmin-e.com/bitlocker-win7

• http://technet.microsoft.com/en-us/library/cc721886%28v=ws.10%29.aspx

• http://social.technet.microsoft.com/wiki/contents/articles/11341.the-windows-7-boot-process-sbsl.aspx

• http://technet.microsoft.com/en-us/library/bb457123.aspx

• http://en.wikipedia.org/wiki/GNU_GRUB

• http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf

• http://www.syslinux.org/wiki/index.php/The_Syslinux_Project

• http://msdn.microsoft.com/en-us/library/ms932879%28v=WinEmbedded.5%29.aspx

• http://www.debian-administration.org/articles/478

• http://technet.microsoft.com/en-us/library/cc739412%28WS.10%29.aspx#w2k3tr_basic_how_fgkm

• http://www.uefi.org/specifications

• http://www.rodsbooks.com/efi-bootloaders/secureboot.html

• http://technet.microsoft.com/en-us/library/hh824987.aspx