Uefi built in efi shell что это

The EFI, EFI Shell and BMC(boardbased management controller)

When I touched server like datacenter. I experienced a various thing that I didn’t know whan I was in univercity.

So, before I forget the keyword and concept. I am going to summarize those things !

The EFI Sytem partion(ESP) is a partition on a data storage device (usually a hard disk drive or solid-state drive) that is used by computer adhering to the unified Extensible Firmware Interface (UEFI).

when a computer is booted. UEFI firmware loads files stored on the EXP to start installed operating systems and various utilities.

An ESP needs to be formatted with a files system.

EFI shell

Extensible firmware interface (EFI) brings new flexibility and opportunities to users by allowing them to work in the layer between their OS and BIOS, without altering either one.

I think some device has nor memory, So user can do programming on this nor memory to do something in firmware level.

at that time, user have to use the EFI shell.

This is what I understad when I dealt with server of SSD.

So, When I used server of SSD with the CentOS, sometimes I would boot into EFI shell mode or normal booting mode.

at that time. in order to fit this problem. I entered “booting menu”, and then, I chaged booting device to where I want to boot.

In my case, when I configure priority of booting, firts is hard disk that I installed CentOS 7

IPMI (Intelligent Platform Management Interface)

The Intelligent Platform Management Interface (IPMI) is a set of computer interface specifications for an autonomous copmture subsystem that provides management and monitoring capabilities independently of the host system’s CPU, firmware(BIOS or UEFI) and operationg system.

as a message-based, hardware-level interface specification, IPMI operates independently of the operating system(OS) to allow administrators to manage a system remotely in the absence of an operating system or of the system management software.

Thus IPMI functions can work in any of three scenarios.

before an OS has booted(allowing, for example, the remote monitoring or changing of BIOS settings)

when the system is powered down

After OS or system failure — the key characteristic of IPMI compared with in-band system management such as by remote login to the operating system using SSH.

IPMI use a dedicated management LAN connection, So if you can not access server, probably you can access server with IPMI.

That is because IPMI has another LAN connection.

BMC (boardbased management controller)

The baseboard management controller (BMC) provides the intelligence in the IPMI architecture. And this is embedded on motherboard of a computer.

Differenct types of sensors built into the computer system report to the BMC on parameteres such as temperature, colling fan speed, power status, operating system(OS) status, etc.

The BMC monitors the sensors and can send alerts to a system administrator via the network, if any of the parameters do not stay within pre-set limits, indicating a potential failur of the system.

The administrator cas also remotely communicate with the BMC to take some corrective actions — such as resetting or power cycling the system to get a hunf OS running again.

If you want to check up power state of the remote machine, Use this tools, IPMIUTIL.

In windows, if you use that tool, that is easy,

IPMI Consists of BMC and so on, So you can controll server remotely. And For IPMI has the dedicated LAN connection.

each of LANs has different IP address, So, when you can not access server, I think you’d better use IPMI probaly, You can access server remotely using IPMI.

At that time you can access server remotely using IPMI, You can power server on, and then you can use server remotely again.

let’s see example to check status of power.

command that I used to check up status of machine.

On windows 7, after installing the ipmiutil, if you don’t configur path.

once, move to sourceforge directory

First, If you don’t have path of ipmiutil.

in sourcforge directory,

enter “ipmiutil.exe”, after that, you can see types of command

one of the commands, we see health command to check up power status of server.

but In my case, I mainly see Power Status.

And You can also power server down using health command

IP-ADDRESS of SERVER and BMC is different, in other words, server has two IP ADDRESS.

one is for server itself, the other is for BMC which checks power state up.

So If you use data server, like server-name-console and server-name, two IP ADDRESS exist.

If that is not working. I just recommend you one more check with ping

If you don’t have domain name to fit to IP-ADDRESS.

You had better configure file of windows.

the path of that file is c:\Windows\System32\drivers\etc\hosts.

Be careful 1

If you cannot access BMC, You have to check if IP address is changed with “ipmitool”

If that tool is not installed,

In order to check ip Address of BMC

as you can see the above, IP Address is important.

if this address is changed, you have to change the host file’s console address with IP Address of ipmitool lan print

Be careful 2

using domain name, you cannot access server. in emergency method, You chang the host file

on Windows, where is hosts file ?

• C:\Windows\System32\drivers\etc\hosts

And if you want to chang the hosts file. You have to get cmd in administrator

What is the EFI shell?

My BIOS offers me the option to launch an EFI shell, but I have no idea what that is. Does it allow me to turn on CPU flags like VT-x or something similar? Why would I want to use it?

1 Answer 1

The EFI Shell is a "shell" (think of a command prompt or a terminal shell) that a (U)EFI BIOS can boot directly into (instead of your OS), allowing control and scripting of many items including booting scenarios.

Installing an EFI shell in an "EFI System" partition (type EF00) formatted with a VFAT file system and properly named shellx64.efi for a 64-bit system will allow you to boot directly into it from your BIOS.

laris / EFI_EFI_SHELL_intro.md

After selecting a device, the bootloader finds the system partition on the disk (EFI System partition) and downloads a file from it that is responsible for further loading of the operating system. This file is always located at the same address. For amd64, this is /efi/boot/bootx64.efi

ESR is determined by the loader by a specific GUID and formatted in the FAT system.

After transferring control to the OS loader from the ESR system partition, the further process continues as usual and depends on the operating system.

Description by Redhat

GRUB loads itself into the memory in stages:

UEFI platforms read the partition table and connect an ESP partition (EFI System Partition) — a VFAT partition with a unique GUID (Globally Unique Identifier). ESP contains EFI applications — loaders and utilities. In Red Hat Enterprise Linux 6, this is a section /boot/efi/ , and EFI programs are located at /boot/efi/EFI/redhat/ .

/boot/efi/EFI/redhat/ содержит grub.efi — версию загрузчика, скомпилированную специально для EFI. В самом простом случае менеджер загрузки EFI выбирает этот файл в качестве загрузчика и загружает его в память.

Если раздел ESP содержит другие программы EFI, менеджер загрузки предложит выбрать программу для выполнения.

Как только GRUB определит операционную систему или ядро для загрузки, они будут загружены в память и им будет передано управление.

Так как производители оборудования обычно добавляют собственные каталоги в раздел ESP, необходимо создать условия для цепной загрузки. Менеджер загрузки EFI может запустить загрузчики любых операционных систем, если они расположены в ESP.

Booting an OS using UEFI ****

UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS**.** UEFI has support for reading both the partition table as well as understanding filesystems.

The commonly used UEFI firmwares support both MBR and GPT partition table**.** EFI in Apple-Intel Macs are known to support Apple Partition Map also apart from MBR and GPT**.** Most of the UEFI firmwares have support for accessing FAT12 (floppy disks) , FAT16 and FAT32 filesystems in HDD and ISO9660 (and UDF) in CD/DVDs**.** EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones**.**

UEFI does not launch any boot code in the MBR whether it exists or not**.** Instead it uses a special partition in the partition table called «EFI SYSTEM PARTITION» in which files required to be launched by the firmware are stored**.** Each vendor can store its files under /EFI// folder and can use the firmware or its shell (UEFI shell) to launch the boot program**.** An EFI System Partition is usually formatted as FAT32**.**

Under UEFI, every program whether they are OS loaders or some utilities (like memory testing apps) or recovery tools outside the OS, should be a UEFI Application corresponding to the EFI firmware architecture**.** Most of the UEFI firmware in the market, including recent Apple Macs use x86_64 EFI firmware**.** Only some older macs use i386 EFI firmware while no non-Apple UEFI system is known to use i386 EFI firmware**.**

Note: Some older Intel Server boards are known to operate on Intel EFI 1**.**10 firmware, and require i386 EFI applications.

A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike the 64-bit Linux and Windows which include such support**.** Therefore the bootloader must be compiled for that architecture correctly**.**

Multibooting on UEFI ****

Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS’s bootloader**.** This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes**.**

Linux Windows x86_64 UEFI-GPT Multiboot ****

Windows Vista (SP1+) and 7 pr 8 x86_64 versions support booting natively using UEFI firmware**.** But for this they need GPT partitioning of the disk used for UEFI booting**.Windows x86_64 versions support either UEFI-GPT booting or BIOS-MBR booting.Windows 32-bit versions support only BIOS-MBR booting.** Follow the instructions provided in the forum link given in the references sections as to how to do this**.** Seehttp://support.microsoft.com/default.aspx**?**scid=kb;EN-US;2581408 for more info**.**

This limitation does not exist in Linux Kernel but rather depends on the bootloader used**.For the sake of Windows UEFI booting, the Linux bootloader used should also be installed in UEFI-GPT mode if booting from the same disk.**

Boot Process under UEFI ****

1. System switched on — Power On Self Test, or POST process**.**
2. UEFI firmware is loaded**.**
3. Firmware reads its Boot Manager to determine which UEFI application to be launched and from where (ie**.** from which disk and partition).
4. Firmware launches the UEFI application from the FAT32 formatted UEFISYS partition as defined in the boot entry in the firmware’s boot manager**.**
5. UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a bootloader like GRUB) depending on how the UEFI application was configured**.**

Detecting UEFI Firmware Arch ****

If you have a non-mac UEFI system, then you have a x86_64 (aka 64-bit) UEFI 2**.x firmware.**

Some of the known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio, Insyde H2O**.**

Some of the known systems using these firmwares are Asus EZ Mode BIOS (in Sandy Bridge P67 and H67 motherboards), MSI ClickBIOS, HP EliteBooks, Sony Vaio Z series, many Intel Server and Desktop motherboards

Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi**.** All macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1**.**x firmware.

To find out the arch of the efi firmware in a Mac, boot into Mac OS X and type the following command

If the command returns EFI32 then it is i386 EFI 1**.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple’s EFI implementation is not fully compliant with UEFI Specification.**

UEFI Support in Linux Kernel ****

Linux Kernel config options for UEFI ****

The required Linux Kernel configuration options for UEFI systems are :

UEFI Runtime Variables/Services Support — ‘efivars’ kernel module . This option is important as this is required to manipulate UEFI Runtime Variables using tools likeefibootmgr****.

Note: This option is compiled as module in Arch core/testing kernel**.**

Note: For Linux to access UEFI Runtime Services, the UEFI Firmware processor architecture and the Linux kernel processor architecture must match**.** This is independent of the bootloader used**.**

Note: If the UEFI Firmware arch and Linux Kernel arch are different, then the «noefi» kernel parameter must be used to avoid the kernel panic and boot successfully**.** The «noefi» option instructs the kernel not to access the UEFI Runtime Services**.**

GUID Partition Table GPT config option — mandatory for UEFI support

Note: All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos**.**

UEFI Variables Support ****

UEFI defines variables through which an operating system can interact with the firmware**.UEFI Boot Variables are used by the boot-loader and used by the OS only for early system start-up.** UEFI Runtime Variables allow an OS to manage certain settings of the firmware like the UEFI Boot Manager or managing the keys for UEFI Secure Boot Protocol etc**.**

Note: The below steps will not work if the system has been booted in BIOS mode and will not work if the UEFI processor architecture does not match the kernel one, i.e. x86_64 UEFI + x86 32-bit Kernel and vice-versa config will not work**.** This is true only for efivars kernel module and efibootmgr step**.** The other steps (ie. upto setting up /EFI/arch/refind/ ) can be done even in BIOS/Legacy boot mode**.**

Access to UEFI Runtime services is provided by «efivars» kernel module which is enabled through the CONFIG_EFI_VAR=m kernel config option**.** This module once loaded exposes the variables under the directory /sys/firmware/efi/vars . One way to check whether the system has booted in UEFI boot mode is to load the «efivars» kernel module and check for the existence of /sys/firmware/efi/vars directory with contents similar to :

The UEFI Runtime Variables will not be exposed to the OS if you have used «noefi» kernel parameter in the boot-loader menu**.** This parameter instructs the kernel to completely ignore UEFI Runtime Services**.**

There are few tools that can access/modify the UEFI variables, namely

1. efibootmgr — Used to create/modify boot entries in the UEFI Boot Manager —efibootmgr or efibootmgr-git
2. uefivars — simply dumps the variables — uefivars-git — uses efibootmgr library
3. Ubuntu’s Firmware Test Suite — fwts — fwts-git — uefidump command — fwts uefidump

Non-Mac UEFI systems ****

Warning: Using efibootmgr in Apple Macs will brick the firmware and may need reflash of the motherboard ROM**.** There have been bug reports regarding this in Ubuntu/Launchpad bug tracker**.** Use bless command alone in case of Macs. Experimental «bless» utility for Linux by Fedora developers — mactel-boot .

Note: efibootmgr command will work only if you have booted the system in UEFI mode itself, since it requires access to UEFI Runtime Variables which are available only in UEFI boot mode (with «noefi» kernel parameter NOT being used). Otherwise the message Fatal: Couldn’t open either sysfs or procfs directories for accessing EFI variables is shown**.**

Initially the user may be required to manually launch the boot-loader from the firmware itself (using maybe the UEFI Shell) if the UEFI boot-loader was installed when the system is booted in BIOS mode**.** Then efibootmgr should be run to make the UEFI boot-loader entry as the default entry in the UEFI Boot Manager**.**

To use efibootmgr, first load the ‘efivars’ kernel module:

If you get no such device found error for this command, that means you have not booted in UEFI mode or due to some reason the kernel is unable to access UEFI Runtime Variables (noefi**?).**

Verify whether there are files in /sys/firmware/efi/vars/ directory**.** This directory and its contents are created by «efivars» kernel module and it will exist only if you have booted in UEFI mode, without the «noefi» kernel parameter**.**

If /sys/firmware/efi/vars/ directory is empty or does not exist, then efibootmgr command will not work**.** If you are unable to make the ISO/CD/DVD/USB boot in UEFI mode try#Create_UEFI_bootable_USB_from_ISO.

Note: The below commands use gummiboot-efi boot-loader as example**.**

Assume the boot-loader file to be launched is /boot/efi/EFI/gummiboot/gummibootx64.efi . /boot/efi/EFI/gummiboot/gummibootx64.efi can be split up as /boot/efi and /EFI/gummiboot/gummibootx64.efi , wherein /boot/efi is the mountpoint of the UEFI System Partition, which is assumed to be /dev/sdXY (here X and Y are just placeholders for the actual values — eg:- in /dev/sda1 , X=a Y=1).

To determine the actual device path for the UEFI System Partition (should be in the form /dev/sdXY ), try :

Then create the boot entry using efibootmgr as follows :

In the above command /boot/efi/EFI/gummiboot/gummibootx64.efi translates to /boot/efi and /EFI/gummiboot/gummibootx64.efi which in turn translate to drive /dev/sdX -> partition Y -> file /EFI/gummiboot/gummibootx64.efi .

UEFI uses backward slash as path separator (similar to Windows paths).

The ‘label’ is the name of the menu entry shown in the UEFI boot menu**.** This name is user’s choice and does not affect the booting of the system**.** More info can be obtained from efibootmgr GIT README .

FAT32 filesystem is case-insensitive since it does not use UTF-8 encoding by default**.** In that case the firmware uses capital ‘EFI’ instead of small ‘efi’, therefore using \EFI\gummiboot\gummibootx64.efi or \efi\gummiboot\gummibootx64.efi does not matter (this will change if the filesystem encoding is UTF-8).

Linux Bootloaders for UEFI ****

Create an UEFI System Partition in Linux ****

Note: The UEFISYS partition can be of any size supported by FAT32 filesystem**.According to Microsoft Documentation, the minimum partition/volume size for FAT32 is 512 MiB.** Therefore it is recommended for UEFISYS partition to be at least 512 MiB**.Higher partition sizes are fine, especially if you use multiple UEFI bootloaders, or multiple OSes booting via UEFI, so that there is enough space to hold all the related files.If you are using Linux EFISTUB booting, then you need to make sure there is adequate space available for keeping the Kernel and Initramfs files in the UEFISYS partition.**

For GPT partitioned disks ****

• Using GNU Parted/GParted: Create a FAT32 partition**.** Set «boot» flag on for that partition**.**
• Using GPT fdisk (aka gdisk): Create a partition with gdisk type code «EF00». Then format that partition as FAT32 using mkfs.vfat -F32 /dev/<THAT_PARTITION>

Note: Setting «boot» flag in parted in a MBR partition marks that partition as active, while the same «boot» flag in a GPT partition marks that partition as «UEFI System Partition».

Warning: Do not use util-linux fdisk, cfdisk or sfdisk to change the type codes in a GPT disk**.** Similarly do not use gptfdisk gdisk, cgdisk or sgdisk on a MBR disk, it will be automatically converted to GPT (no data loss will occur, but the system will fail to boot).

For MBR partitioned disks ****

• Using GNU Parted/GParted: Create FAT32 partition**.** Change the type code of that partition to 0xEF using fdisk, cfdisk or sfdisk**.**
• Using fdisk: Create a partition with partition type 0xEF and format it as FAT32 using mkfs.vfat -F32 /dev/<THAT_PARTITION>

Note: It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot**.**

The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders**.** Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc**.**

UEFI Shell download links ****

You can download a BSD licensed UEFI Shell from Intel’s Tianocore UDK/EDK2 Sourceforge.net project**.**

Shell 2.0 works only in UEFI 2.3+ systems and is recommended over Shell 1.0 in those systems. Shell 1**.0 should work in all UEFI systems irrespective of the spec.** version the firmware follows**.** More info at ShellPkg and this mail

Launching UEFI Shell ****

Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called «Launch EFI Shell from filesystem device» . For those motherboards, download the x86_64 UEFI Shell and copy it to your UEFI SYSTEM PARTITION as <UEFI_SYSTEM_PARTITION>/shellx64.efi (mostly /boot/efi/shellx64.efi ) .

Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either F6, F11 or F12 key**.**

Note: If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with Shell.efi copied as (USB)/efi/boot/bootx64.efi . This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you**.**

Important UEFI Shell Commands ****

UEFI Shell commands usually support -b option which makes output pause after each page**.** map lists recognized filesystems ( fs0 , ...) and data storage devices ( blk0 , ...). Run help -b to list available commands**.**

BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options**.** This command is described in detail in page 83 (Section 5**.**3) of «UEFI Shell Specification 2.0» pdf document.

Note: Users are recommended to try bcfg only if efibootmgr fails to create working boot entries in their system**.**

Note: UEFI Shell 1**.0 does not support bcfg command.**

To dump a list of current boot entries —

To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu

where fs0: is the mapping corresponding to the UEFI System Partition and \EFI\arch\refind\refindx64.efi is the file to be launched**.**

To remove the 4th boot option

To move the boot option #3 to #0 (i**.**e. 1st or the default entry in the UEFI Boot menu)

For bcfg help text

EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional**.** It handles UTF-8 encoding and takes care or LF vs CRLF line endings**.**

To edit, for example rEFInd’s refind.conf in the UEFI System Partition (fs0: in the firmware)

Type Ctrl-E for help**.**

Create UEFI bootable USB from ISO ****

Note: The instructions below are specifically for Archiso /official media; Archbootpreparation is identical, with this refind.conf instead of the one mentioned below (which is for Archiso) and without the filesystem label requirement**.**

Note: The USB can use either MBR or GPT partition table**.** The filesystem should be either FAT32 (recommended) or FAT16**.** FAT12 is designed for floppy drives and therefore not recommended for USB drives**.**

First create a MBR partition table in the USB using fdisk**.** Mount the USB partition and create a FAT32 filesystem with LABEL as used in the Archiso configuration**.**

Obtain the label from /mnt/iso/loader/entries/archiso-x86_64.conf ; this is used by the archiso hook in initramfs to identify the udev path to the installation media**.**

If you find the error: «No loader found**.** Configuration files in /loader/entries/*.conf are needed**.**« A possible fix is to use a different uefi bootloader to the included one, gummiboot**.**

Download refind-efi pkg and extract the file /usr/lib/refind/refind_x64.efi from within the package to (USB)/EFI/boot/bootx64.efi (overwrite or rename any existing (USB)/EFI/boot/bootx64.efi file).

Then copy this text to EFI/boot/refind.conf . Take care that the label in the Arch menu section ( ARCH_201302 here) matches that of your usb’s**.**

You should now be able to successfully boot, and you can choose which EFI you’d like to load**.**

Remove UEFI boot support from ISO ****

Warning: In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using the USB stick instructions in the previous section

Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD**.** If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first**.**

Mount the official installation media and obtain the archisolabel as shown in the previous section**.**

Rebuild the ISO using xorriso from libisoburn :

/archiso.iso to optical media and proceed with installation normally**.**

Posted by [20.02.2013

EFI及EFI SHELL简介 http://smilejay.com/2011/05/efi_efi-shell/ 05/16/2011MASTER 5 COMMENTS 今天升级Sandy Bridge EP测试机的BIOS，可谓是曲折啊，尝试各种方法、遇到各种软硬件问题问题。其中一种方法是按照Intel的官方BIOS文档中的说明，用在EFI Shell中升级。所以稍微了解了一下EFI和EFI Shell。 大致来说，EFI是Extensible Firmware Interface的缩写，是介于平台固件和操作系统之间的一层软件接口（及其详细规格说明文档）。EFI是Intel在1998年开始的一个项目演变而来，而在2005年Intel将EFI 1.10开源并交由Unified EFI开源社区去维护和开发，Intel自己的EFI也就不单独做了，都和开源社区共用一个。现在也通常用EFI来代指UEFI，二者不再有意区分。 EFI Shell是EFI提供的一个交互式的命令行Shell环境，在这里你可以执行一些efi应用程序，加载efi设备驱动程序，以及引导操作系统，从引导菜单项中选择”efi shell”，回车，待出现”shell]”提示符时即表明你已进入efi shell环境中，下面对一些常用的efi shell环境下的命令作些简要介绍：

Introduction Extensible firmware interface (EFI) brings new flexibility and opportunities to users by allowing them to work in the layer between their OS and BIOS, without altering either one. This paper explains how to use EFI shell commands, create a script file and set up the boot menu with shells and scripts. In addition, this paper demonstrates dual boot selection for the 64-bit Red Hat Linux* 7.1 and 64-bit Microsoft Windows* XP Professional operating systems.

EFI Shell Commands The following is the list of the EFI 0.99[12.29] shell commands:

Commands Descriptions help [-b] [internal command] Displays this help guid [-b] [sname] Lists known GUID (Global Unique Identifiers) set [-bdv] [sname] [value] Gets or sets environment variable alias [-bdv] [sname] [value] Gets or sets alias settings dh [-b] [-p prot_id] | [handle] Dumps handle information unload [-nv] HandleIndex Unloads a protocol image map [-bdvr] [sname[:]] [handle] Maps shortname to device path mount BlkDevice [sname[:]] Mounts a file system on a block device cd [path] Updates the current directory echo [[-on | -off] | [text] Echoes text to stdout or toggle script echo if [not] condition then Script-only: IF THEN construct endif Script-only: Delimiter for IF THEN construct goto label Script-only: Jump to label location in script for var in < /td> Script-only: Loop construct endfor Script-only: Delimiter for loop construct pause Script-only: Prompt to quit or continue ls [-b] [dir] [dir] . Obtains directory listing mkdir dir [dir] . Makes directory mode [col row] Gets or sets current text mode cp [-r] file [file] . [dest] Copies files/directories comp file1 file2 Compares two files rm file/dir [file/dir] Remove files/directories memmap [-b] Dumps memory map type [-a] [-u] [-b] file Types file dmpstore Dumps variable store load driver_name Loads a driver ver Displays version information err [level] Sets or displays error level time [hh:mm:ss] Gets or sets time date [mm/dd/yyyy] Gets or sets date stall microseconds Delay for x microseconds reset [/warm] [reset string] Cold or warm reset vol fs [Volume Label] Sets or displays volume label attrib [-b] [+/- rhs] [file] Sets or displays file attributes cls [background color] Clears screen bcfg -? Configures boot driver and load options edit [file name] Edits a file Edd30 [On | Off] Enables or disables EDD 3.0 device paths dblk device [Lba] [Blocks] Hex dump of BlkIo devices pci [bus dev] [func] Displays PCI device(s) information mm Address [Width] [;Type] Modifies memory: Mem, MMIO, IO, PCI mem [Address] [size] [;MMIO] Dumps memory or memory mapped IO EddDebug [BlockDeviceName] Dumps EDD information from adapter card Table 1: EFI 0.99[12.29] shell commands

This list appears when you type the command «help» at the shell prompt. However, it does not contain all of the EFI shell commands; the commands «attrib» and «exit» are absent. Not all commands can be used in script files. For example, the command «exit» missing from the list cannot be used in a script file. To exit out of a script, simply jump to the end of the file. Conversely, some of the commands like «if. then,» «for. in,» «goto» can only be used inside the script file.

To execute a command, type it at the shell prompt, which can be as follows:

fs0:> (If there is a disk in the floppydrive before the PC is turned on, then the current media defaults to the floppy disk. If not, then the current media is the first hard disk partition.) fs1:> (The first hard disk partition if fs0 is the floppy disk.) fs2:> (Indicates the CD-ROM drive.)

This environment is similar to Microsoft DOS* (MS-DOS) in that the user types in commands and presses «Enter» to execute the commands. As demonstrated below, changing to another drive is easy: type the name of the drive and then press «Enter». («» is a «carriage return» which translates to «press Enter.»)

Shell> fs0: Fs0:> fs2:

If the user is unfamiliar with the use of a command, they simply type it at the shell prompt and the computer displays the correct syntax and meaning of each of the switches.

EFI Shell Scripts In basic terms, a script file is one that contains a sequence of shell commands that the user would like the computer to execute. Rather than entering them at the shell prompt, the user places the appropriate shell commands into a file and names the file «filename.nsh» to create a script file. This is extremely useful for repetitive tasks.

The script file resembles a batch file in MS-DOS; in EFI, a file called «startup.nsh» automatically runs every time a shell environment is opened. You can create the script using any ASCII or Unicode text editor. The following are shell commands frequently used in a script:

3.1 Echo: Syntax:echo [-on |

The first line in a script is usually «echo -off.» This prevents subsequent batch file commands from displaying on the screen so that only results display.

For example, in a script file, there are such commands:

Batch commands:echo -on

When you run that script, you see the following lines on the screen:

The first two lines in bold are batch commands from the script, and the third line is the result of the second batch command. Note the display when the echo command is turned off:

The batch command «echo This is a test» no longer displays onscreen because the echo has been turned off. You always see the batch command «echo -off» because the echo does not disable after this line has been executed.

3.2 If Syntax:if [not] exist filename then. endifif [not] string1 == string2

. endif The first form checks for file existence. Type either just the file name or the path and the file name. For example:

The second form is the comparison between strings:

Note: Spaces need to be inserted at both ends of the «= auto»>3.3 For Syntax:for %index in

This is a «for» loop. The index here is any single character, like a, b, c and so on, but it can’t be a digit like 1, 2 or 3 because they can be misinterpreted as «argument» variables. Groups can be made up of strings or file names separated by the use of spaces. Consider the following examples:

Result: The list of all files with extension «nsh» in the current directory.

Note: Spaces need to be inserted at both ends of the %index. Otherwise, the shell generates an error.

Dual Boot Selection Consider the procedure for setting up dual boot on an Intel Itanium processor-based system. If Windows* 9x and Windows NT* or Windows* 2000 is installed on an Intel® Itanium® platform, you can set up a dual boot under Windows NT or Windows 2000. If Windows 9x and Linux are installed, you can set up a dual boot under Linux.

On the Intel Itanium platform, there is a layer between the firmware and the OS—that layer is the EFI. You can boot to any installed OS from the EFI layer as long as the OS is EFI-compliant.

Below is a demonstration of dual booting 64-bit versions of Red Hat Linux* and Microsoft Windows* 2000.

Before starting to build the boot menu:

A) You must disable the file «startup.nsh.» This script runs automatically when you turn on the system and select the «Boot OS» option. When you install Windows 2000, it creates the «startup.nsh» file. This file executes a file called «launcher.efi,» which boots directly to Windows 2000. Perform the following steps to disable the startup.nsh file:

During the Windows booting process, press any key to interrupt it.

Change the access right of the startup.nsh file to modify or delete it. From the shell prompt, «Shell>,» go to the main partition:

Shell> fs1: The choice between «fs0» and «fs1» depends on whether a disk is in the floppy drive.

Note: To use the floppy drive, a floppy disk must be inserted. Otherwise, the floppy drive is not recognized; the same caution applies to the CD-ROM drive.

fs0:> attrib -r startup.nshfs0:> edit startup.nsh In edit mode, type a # sign at the beginning of the line containing the word «launcher» to comment it out.

B) Make sure the BIOS build 89B is flashed. One way to establish the correct build number is to look at the EFI version when you first turn on the PC; if it’s correct, you see something like:

EFI Version 0.99[12.31].

There are instances in which an incorrect BIOS version has been preloaded to the Software Development Vehicle (SDV). If you see «EFI Version 1.0[12.25]. » displayed on the screen, reflash the BIOS with build 89B or 99.

Assume you want the following multiple boot menu:

Windows XP* Professional Red Hat Linux* EFI Shell You can create it using any of these methods:

boot maintenance menu BCFG command script 4.1 Using Boot Maintenance Menu: Follow these steps to create a boot menu:

Turn on the system.

At the shell prompt, type «exit» and press Enter.

Shell> exit 4) The screen displays a boot menu similar to the following:

EFI Boot Manager ver. 0.99[12.29]

Select boot option

EFI Shell [built in]

Boot option maintenance menu 5) Select the boot option maintenance menu.

Select «Add a boot option.»

Select the partition containing the OS loader. In this case, it is the first hard disk partition. Something similar to the following appears onscreen:

NO VOLUME LABEL [VenHw(Unknown D evice:80)/HD(Part1, Sig948939)]

Removable Media [VenHw(Unknown Device:01)]

Removable Media [VenHw(Unknown Device:FF)]

Load File [Acpi(PNP0A03,0)/Pci(4|0)/mac(009027E4A0F4)]

Load File [EFI Shell [Built-in]]

Select the first item, «NO VOLUME LABEL. «

The screen displays the files of the directory of the selected partition.

Select the file «eli.efi.» This is the Linux loader file.

Type the title you wish to display on the boot menu when asked for the description: «Red Hat Linux*.»

When prompted with:

«New boot option data: ASCII/Unicode string only Enter Boot option Data type[A- SCII U- Unicode N- No BootOption],» select «N.»

Next, select the option «Save Changes to NVRAM[Y-yes N-No]:» and type «Y.»

When you have no other OS to set, select «exit» to return to the previous menu.

Select «Cold Reset» to reboot the system.

To create an EFI shell prompt, select option «EFI Shell[built in]» from step 7 and type «EFI Shell» at step 10.

Type «exit» at the shell prompt «Shell>» to go to the boot menu.

4.2 Using the BCFG Command The «Bcfg» is the boot configuration shell command. Assuming that «fs0» is the main partition, type the following statement to create the boot menu:

fs0:> bcfg boot add 2 eli.efi «Red Hat Linux*»

Note: You cannot create an EFI shell prompt using this method; you must use the previous method.

4.3 Using Script Since there is no user-prompt command under the EFI shell to accept users’ selected input, you must use an alternative method:

a) If the file startup.nsh does not exist,

create it or modify it to

contain strictly the following line:

Menu b) Create a file and name it menu.nsh with the following:

There is no option for the shell prompt since the command «nshell» is not on the list.

The current partition is set to «dblk3» instead of «fs0» or «fs1.» This is because if there is a floppy disk in the floppy drive, then «fs0» is the floppy disk and «fs1» is the first hard disk partition. Otherwise, «fs0» is the first hard disk partition .

c) Create a file and name it «2.nsh» with the following contents:

eli Note: The «2.nsh» script is used to boot to Red Hat Linux*. Conclusion This represents only the beginning of the uses and benefits of EFI shell commands and scripts. Not only can EFI be used similarly to a MS-DOS device driver, its capabilities also remove the hassle of modifying the OS. Disk utility vendors can use EFI to craft powerful tools like platform-independent disk partitioning. Another of EFI’s benefits is that the same device drivers can be used by many EFI-compliant platforms, thus providing a good return on investment. EFI allows users to create device drivers to access hardware directly without having to go through the OS, making the process both simpler and faster.

For more complete information about compiler optimizations, see our Optimization Notice. 4 commentsTop BADAR S. said on May 19,2017

BADAR S.’s picture This is first time learning about EFI Shel. So, I was wondering how can I create a bootable EFI shell USB key?

murala s. said on Nov 14,2016

murala s.’s picture Hi,

I need small help,

I want to run following content using EFI shell script file like script.nsh.

But when i run script.nsh it is treating as like below,

Please help me how to pass # also ,

Shi Hao C. (Intel) said on Jun 3,2015

Shi Hao C. (Intel)’s picture It would be most helpful if there’s a link to further describe/expand on the commands in the table at the end of this page here. Or where/how to access the user manuals of EFI shell itself. All in all this documentation does provide basic functionality of EFI shell. Thanks.

О UEFI

Статья сфокусирована на объяснении понятий и принципов, а также важных и интересных возможностях UEFI. Более детально сам процесс установки и настройки загрузки Ubuntu в UEFI режиме описан в этой статье или в этой.

Практически все современные компьютеры оснащены системной прошивкой позволяющей загрузиться через UEFI. На более старых компьютерах за загрузку отвечал BIOS. В чем разница и как с этим всем жить — давайте разберемся.

Старый добрый BIOS отвечает за первичное тестирование (POST), инициализацию практически всего аппаратного обеспечения компьютера и за инициализацию загрузки ОС с дискового носителя (хотя сегодня уже не все носители имеют в своей конструкции диск ). Собственно вся процедура инициализации загрузки ОС заключалась в двух шагах:

За все остальное (даже за работу с таблицей разделов, которая располагается в конце MBR) отвечает тот самый маленький код, который расположен в первых 446 байтах MBR.

Проблемой BIOS принято считать то, что много работы он делает зря (чем затягивает процесс загрузки системы). Практически всю его работу по инициализации и поддержке оборудования компьютера все современные ОС попросту игнорируют и повторно инициализируют и далее работают через свои драйвера. Все, что дает BIOS, было реально востребовано только в ранних версиях DOS…

Другой проблемой являются ограничения, которые установлены для поддержки BIOS: это 16-разрядный реальный режим работы процессора с набором команд i8086, 1Мб адресуемого пространства памяти и периферия (клавиатура, видео адаптер, контроллер прямого доступа в память) совместимая с IBM AT. На сегодняшний день, требовать от 64-х разрядного многоядерного, многопоточного процессора совместимости с одноядерным и однопоточным 16-разрядным i8086 — уже немного смешно, а требование совместимости по периферии с IBM PC-AT(компьютер 1984-го года выпуска) уже даже не смешно, а очень грустно.

Идеи отказаться от всего того ненужного, что делает BIOS, снять архаичные ограничения BIOS и сделать процесс инициализации и загрузки более гибким возникали уже очень давно, и различные попытки сделать это предпринимались, но IT-индустрия реально созрела к принятию нового общего стандарта загрузки персональных компьютеров только в начале этого века. В 2005 был создан консорциуму UEFI Forum, которому INTEL передал свою наработки по проекту Intel Boot Initiative (позже переименованному в EFI — Extensible Firmware Interface), начатому еще середине 90-х. Помимо Intel в консорциум вошли AMD, Apple, IBM, Microsoft и многие другие крупные IT-компании. Вместе с созданием консорциума спецификация EFI была переименована в UEFI (Unified Extensible Firmware Interface) 1) .

Основные концепции положенные в основу UEFI — «минималистичность», «модульность» и поддержка разных процессоров. Прошивка UEFI может быть собрана под 32-битный или 64-битный процессоры Intel, 32- или 64-битный процессор ARM, а также для процессоров Intel Itanium. Кроме того UEFI имеет собственный менеджер загрузки и умеет работать с файловыми системами на диске (по умолчанию только FAT32), а также умеет загружать драйверы для поддержки различного оборудования и любых файловых систем.
После включения компьютера и проведения первичного теста оборудования (на этом этапе разницы с BIOS нет) инициализируются только те подсистемы, которые необходимые для загрузки.

В некоторых режимах загрузки, которые обычно называют Fast-boot (или Fast-Startup), даже клавиатура может оставаться не инициализированной, пока не загрузится ОС. Некоторые настройки Fast-boot могут отключать работу со всеми USB устройствами и не будет возможности даже выбрать с чего грузиться компьютеру, ведь клавиатура не работает до тех пор, пока не загрузится ОС.

Причем, в отличии от BIOS, все компоненты которого записаны в постоянную (флеш) память, UEFI может хранить часть своего кода на диске — в специальном разделе ESP 2) . Это позволяет легко расширять, менять и обновлять код поддерживающий различные устройства компьютера без необходимости перепрограммировать постоянное ЗУ компьютера. А кроме драйверов для поддержки устройств на ESP разделе может хранится и поддержка протоколов, утилиты и даже собственная EFI-оболочка (shell), из-под которой можно запускать собственные EFI-приложения. Т.е. UEFI по сути — маленькая ОС (или псевдо-ОС). При этом загрузчик операционной системы становится обычным приложением, которое исполняется в окружении, предоставляемом псевдо-ОС UEFI. Подробнее о EFS разделе мы поговорим в главе ESP раздел.

UEFI реализует свой менеджер загрузки, он поддерживает мульти-загрузку: позволяет выбирать загрузку из нескольких ОС и/или утилит. Загрузчик ОС — это просто efi-приложение, которое хранится на ESP разделе. В ESP может храниться много приложений, и пункты меню загрузки могут ссылаться каждый на свое приложение (или на одно, но с передачей разных параметров). Кроме того, UEFI поддерживает ассоциацию нажатия клавиш с пунктами загрузки (выбор пункта загрузки осуществляется в зависимости от того какая нажата клавиша в момент загрузки). Т.о. UEFI берет на себя большую часть задач, которые раньше могли решать только загрузчики ОС (типа GRUB). Более подробно мы поговорим о менеджере загрузки UEFI в разделе Менеджер загрузки UEFI

Архитектура UEFI позволяет также загрузить драйвера устройств (необходимые для работы ОС и для процедуры загрузки). Да и само ядро ОС можно загрузить (по крайней мере ядро Linux, собранное с опцией UEFISTUB) непосредственно из UEFI (т.е. устранить загрузчик из процесса загрузки). Такую возможность мы разберем более детально чуть позже в разделе Загрузка ядра Linux непосредственно из UEFI.

Как и в случае с BIOS, UEFI — это стандарт, практической реализацией которого занимаются разные поставщики решений. Поэтому в реализации стандарта UEFI в прошивках разных поставщиков могут значительно отличаться (как визуально так и функциональным наполнением). Могут встречаться сильно урезанные по функционалу реализации (чаще в компьютерах выпущенных в 2000-х годах). Но базовые принципы работы UEFI в процессе загрузки различаться сильно не должны (он был определен и зафиксирован в самых ранних стандартах UEFI). Интерфейсы утилиты настройки могут сильно различаться, но значение имеет не способ оформления интерфейса, а те настройки, которые доступны для изменения через этот интерфейс.

Совместимость

Само собой, современные прошивки умеют эмулировать работу BIOS. Отвечает за совместимость с BIOS модуль CSM (Compatibility Support Module иногда он еще называется Legasy support). Когда CSM включен и при загрузке загрузиться в UEFI не удалось, то CSM пытается найти загрузчик ОС в первом секторе диска (MBR) или в специальном служебном разделе (при GPT разбивке диска). Если код загрузчика найден, то CSM считает, что установлена ОС, требующая поддержки режима BIOS, и, прежде чем загрузить и запустить код из MBR, CSM проделывает все те же шаги инициализации оборудования, что предусмотрены для BIOS.

Если вы планируете использовать только загрузку в варианте UEFI, то работу этого модуля лучше запретить в системной утилите вашей материнской платы (Firmware setup utility). Кроме того, загрузка в режиме SecureBoot (о ней будет рассказано ниже) явно требует, что бы работа модуля CSM была запрещена.

ESP раздел

Отдельно стоит рассмотреть служебный раздел UEFI. Раздел обязательно должен иметь специальный идентификатор UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B (или тип EF если он создан на диске с таблицей разделов в MBR). По стандарту этот раздел должен иметь файловую систему FAT32 (в принципе стандарт допускает использование других ФС, но на практике это не распространено). Предусмотренная в стандарте структура каталогов довольно проста.

При установке UBUNTU (с загрузкой через UEFI) служебный раздел ESP монтируется в /boot/efi. И на ESP разделе создается каталог EFI\ubuntu в котором размещается загрузчик 4) GRUB и/или Shim (о них — чуть позже).

MBR и GPT

Еще одно «новшество» в индустрии относится к таблице разделов диска.

Во времена IBM-PC/AT и BIOS таблица разделов размещалась в первом секторе на диске, т.е. в MBR (Master Boot Record). В MBR хранится и исполняемый код загрузчика ОС и таблица разделов. Т.к. в 512 5) байт много не запихнешь, то таблица разделов была рассчитана только на 4 раздела. Изначальное ограничение на 4 раздела позже было обойдено через внедрение расширенного раздела — внутри него можно было создать множество логических разделов 6) .

Другой недостаток 7) : на указатели начала и конца раздела было зарезервировано 32 бита, что позволяло адресовать 2 терабайта (что в те давние времена казалось просто астрономически много ).

Однако уже к началу 2010-х на рынке стали появляться диски более 2Тб. Но к этому времени уже набрал популярность стандарт таблицы разделов GPT (GUID Partition Table). В GPT число разделов практически не ограничено (по умолчанию 128, но можно и больше) и установлена новая планка для размера диска: 9,4 ЗБ, т.е 9,4 × 10^21 байт (на сегодня этот размер вновь выглядит астрономически большим… )

К чему я упомянул про таблицы разбиения дисков? А к тому, что, несмотря на то, что первоначально UEFI планировалось использовать только с GPT, а BIOS умел работать с MBR (вернее код в MBR работает с таблицей разделов расположенной в конце MBR), но в реальной жизни и BIOS (вернее сказать CSM) научили понимать GPT, и для UEFI предусмотрели использование таблицы разделов из MBR.

Получившаяся в результате «солянка» (из 4-х допустимых вариантов: UEFI + MBR, UEFI + GPT, BIOS/CSM + MBR и BIOS/CSM + GPT) создает некоторую путаницу и недопонимание. Давайте попробуем во всем этом разобраться более детально.

Что нужно для того что бы ОС грузилась через BIOS?

Несмотря на то, что загрузка в режиме BIOS уже не современна, не модна , а главное — технологически устарела, но, уверен, будет еще много сторонников этого пути, на протяжении долгих лет… Однако я не могу найти ни одного разумного довода использовать этот вариант если и ОС и компьютер поддерживают загрузку через UEFI.

В первую очередь, для загрузки через BIOS, в утилите настройки вашего компьютера должна быть разрешена работа модуля CSM. Само собой, режим SecureBoot (о нем рассказано чуть ниже) в таком варианте организовать невозможно в принципе.

Если разбивка диска — c таблицей разделов в MBR (вариант «BIOS/CSM + MBR»), то ничего дополнительно не нужно (это сочетание собственно и есть оригинальная конфигурация для варианта загрузки через BIOS).

А вот если у вас диск размечен через GPT (вариант «BIOS/SCM + GPT»), то возникают некоторые сложности.
В первую очередь: не совсем ясно — куда разместить код, который ранее размещался в MBR. Да, в GPT первый блок размером в 512 байт зарезервирован и в нем даже есть защитная версия таблицы разделов (в формате принятом для MBR). В защитной таблице разделов записан единственный раздел размером на все адресуемое пространство диска 8) и с типом EE. Само собой, с единственной фейковой записью в таблице разделов никакой код в MBR не сможет корректно отработать процесс загрузки 9) .
Еще одно проблемное место возникает когда загрузчик использует для размещения своего кода сектора на первом треке диска за MBR (к примеру так поступает GRUB). В GPT на этом месте уже идут служебные записи (заголовок таблицы разделов и сами записи о разделах).
Для решения обоих этих проблем предусмотрен специальный бинарный (он не форматируется ни в какую ФС) раздел BIOS-Boot (Тип = EF02 или UUID = 21686148-6449-6E6F-744E-656564454649). Установщик ОС может прописать на этот раздел весь тот код, который ранее размещался в MBR и на незанятом пространстве за MBR. Этот раздел должен иметь установленный флаг boot. Размер этого раздела может быть совсем маленьким, ведь MBR — это всего 512 байт, а размер неиспользуемого пространства за MBR, составляет всего 31Кb или 1023,5Кb 10) . Однако, некоторые современные загрузчики требуют раздел BIOS-Boot размером в 10-30Мb.
В процессе загрузки CSM модуль (эмулирующий работу BIOS) отвечает за то, что находит в GPT раздел BIOS-Boot, загружает первые 512 байт с этого раздела, и передает управление загруженному коду. За дальнейший процесс загрузки отвечает этот код, а CSM берет на себя задачу эмулировать обращение к секторам диска за MBR (вместо этих секторов производится подстановка секторов из раздела BIOS-Boot).

Пожалуй вот на этом и закончим обсуждать CSM и BIOS, все дальнейшее будет относится только к UEFI.

Что нужно для установки ОС, что бы она грузилась через UEFI?

На самом деле все не так сложно как кажется. Как уже было сказано UEFI требует специального раздела ESP (с файловой системой FAT32 и флагами boot и esp). И, несмотря на то, что для этого раздела был предусмотрен специальный длинный идентификатор (UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B) для GPT, который в таблицу разделов MBR ну никак не запихнешь, этому разделу дали еще и короткий идентификатор (EF), который можно «впихнуть» в таблицу разделов в MBR. Т.е. ESP раздел можно создать и на диске с GPT и на диске с таблицей разделов в MBR (однако такой вариант поддерживает не любая ОС).

Т.о. при установке системы, помимо создания нужных для работы ОС разделов, нужно создать специальный раздел ESP:

— для варианта «UEFI + MBR» : c типом EF

— для варианта «UEFI + GPT» : c типом EF00 и UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B

Этот раздел должен быть отформатирован в FAT32 и иметь установленные флаги boot и esp. Размер раздела можно выбрать небольшим 200-300Мб (занято там будет, скорее всего, гораздо меньше, но делать его совсем маленьким, при современных объемах дисков — просто бессмысленно).

Если ESP раздел создается из установщика Ubuntu, то нужный формат, точку монтирования и необходимые флаги установщик сделает сам: нужно только выбрать тип раздела «EFI Boot» и задать его размер.

Если на компьютере уже стоит ОС загружающаяся через UEFI, то ESP раздел уже должен быть на диске и новый ESP создавать не нужно. В установщике Ubuntu надо только убедиться, что этот раздел используется как «EFI Boot». Более того, если создать несколько разделов ESP (на одном диске), то некоторые прошивки UEFI могут «окриветь» из-за такого неожиданного разнообразия. Общее правило — на диске должен быть только один раздел ESP. На разных устройствах ESP разделов может быть несколько — это вполне штатная ситуация для UEFI.

Для загрузки через UEFI модуль CSM не нужен, и, если все установленные на компьютере ОС грузятся через UEFI, то CSM лучше отключить. А вот если вы организуете загрузку в режиме SecureBoot, то CSM модуль отключить просто необходимо: без этого, обычно, просто не включить режим SecureBoot или включение SecureBoot автоматически запрещает работу CSM.

Менеджер загрузки UEFI

Кроме кода отвечающего за первичную инициализацию системы UEFI имеет свой менеджер загрузки. Работу менеджера загрузки задают переменные UEFI, хранящиеся в энергонезависимой памяти NVRAM 11) .

Переменные, которые задают работу менеджера загрузки это:

, где #### — шестнадцатеричный номер записи.

Переменные Driver#### инициализируют загрузку UEFI драйверов. Переменная DriverOrder определяет последовательность загрузки драйверов.

Драйвера остаются в памяти после своей инициализации. Однако загруженные драйвера сразу не связываются с устройствами, которые они обслуживают. Процесс такого связывания необходимо инициализировать отдельно. Но нужно отметить, что происходит не просто связывание загруженных драйверов, а повторное связывание, т.к. некоторые драйвера уже были связаны со своими устройствами в процессе первичной инициализации системы. За запуск процесса инициализации отвечает флаг LOAD_OPTION_FORCE_RECONNECT, который можно установить в поле атрибутов загрузочной записи Driver####. Если хоть у одного из загруженных драйверов этот флаг установлен, то после окончания загрузки всех драйверов менеджер загрузки UEFI инициализирует процедуру пере-связывания всех драйверов и устройств.

Переменные SysPrep#### инициализируют загрузку системных утилит. Переменная SysPrepOrder определяет последовательность утилит. Системных утилита должна выполнить свои действия и вернуть управление менеджеру загрузки UEFI. Утилиты не остаются в памяти, если нужен резидентный код, то его нужно загружать как Driver####.

Переменные Boot#### отвечают за загрузку загрузчиков ОС. Переменная BootOrder определяет приоритет загрузки загрузчиков ОС. Загрузчик обязан определить возможность загрузки ОС и принять решение — будет он загружать ОС или нет. Если ОС не будет загружаться, то загрузчик должен просто вернуть управление менеджеру загрузки UEFI. Если же ОС будет загружаться, то загрузчик должен уведомить об этом менеджера загрузки UEFI специальным вызовом. Этот вызов имеет принципиальное значение, т.к. те услуги которые UEFI обеспечивает для ОС гораздо уже и более ограничены чем те, которые доступны в процессе инициализации системы. И Именно для переключения режима услуг необходимо такое уведомление от загрузчика.

На работу менеджера загрузки влияют как переменные DriverOrder, SysPrepOrder и BootOrder, так и значение флага LOAD_OPTION_ACTIVE устанавливаемого в поле атрибутов загрузочной записи (Driver####, SysPrep#### или Boot####). Загрузочные записи с неактивным флагом LOAD_OPTION_ACTIVE игнорируются менеджером загрузки UEFI даже если эти записи указаны в переменной задающей порядок/приоритет (DriverOrder, SysPrepOrder или BootOrder). Также игнорируются записи с активным флагом LOAD_OPTION_ACTIVE, но не включенные в переменную задающую порядок/приоритет.

Менеджер загрузки UEFI в нормальном режиме работы сначала загружает все активные Driver#### упомянутые в DriverOrder и в том порядке, в котором они записаны в DriverOrder, затем загружает все активные SysPrep####, указанные в SysPrepOrder, в указанном там порядке, а после этого пытается загрузить активный загрузчик ОС (Boot####) в порядке указанном в BootOrder. А вот если ни одна из активных записей упомянутых BootOrder не смогла загрузить ОС (все вернули управление менеджеру загрузки UEFI), то запускается процесс восстановления.

Процесс восстановления настраивается переменными OsRecovery#### и PlatformRecovery####. Если эти переменные не заданы, то менеджер загрузки UEFI пытается произвести загрузку по умолчанию: загружается загрузчик хранящийся по пути \EFI\BOOT\BOOT.EFI, где — одно из:

Если загрузка по умолчанию не прошла, то менеджер загрузки UEFI сдается и выводит сообщение о невозможности дальнейшей загрузки системы.

Если заданы OsRecovery#### и/или PlatformRecovery####, то сначала выполняются OsRecovery#### и после этого менеджер загрузки UEFI пробует снова загрузить одну из Boot#### указанных в BootOrder и пробует загрузку по умолчанию.

Если и после этого ни один загрузчик не начал загрузку ОС, то выполняются PlatformRecovery####, но после выполнения записей PlatformRecovery#### загрузка начинается сначала: с Driver####, затем SysPrep####, а только после этого пробует снова загрузить одну из Boot#### указанных в BootOrder и загрузку по умолчанию. И вот если уже и после этого не удалось запустить загрузку ОС, то менеджер загрузки UEFI сдается и выводит сообщение о невозможности дальнейшей загрузки системы.

Отдельно нужно упомянуть возможность манипуляции приоритетом загрузки ОС заданным в BootOrder. Если задана переменная BootNext (в ней указывается номер одной из записей Boot####, которая должна быть активной), то менеджер загрузки пробует сначала загрузить запись Boot#### указанную в BootNext, и только если загрузить ОС по этой записи не удалось, то менеджер загрузки переходит к загрузке в соответствии с BootOrder. При этом BootNext удаляется в любом случае.

Еще один способ изменения приоритета загрузки ОС — выбор записи Boot#### по нажатию кнопки на клавиатуре в процессе загрузки. Для реализации такого механизма нужно привязать кнопку к записи Boot####. И если кнопка будет нажата, то менеджер загрузки пробует сначала загрузить запись Boot#### привязанную к кнопке, и только если загрузить ОС по этой записи не удалось, то менеджер загрузки переходит к загрузке в соответствии с BootOrder.

Практически все функции и настройки менеджера загрузки UEFI позволяет настроить утилита efibootmgr (смотрите man efibootmgr что бы узнать как).

Вот такие серьезные возможности обеспечивает менеджер загрузки UEFI. Фактически в нем реализован весь функционал классических менеджеров загрузки ОС поддерживающих мультизагрузку (загрузку нескольких ос или нескольких версий одной ОС). Причем в вопросах восстановления функционал менеджера загрузки UEFI даже шире за счет того, что он реализуется в процессе инициализации системы.

Таким образом UEFI делает такие загрузчики (например GRUB) фактически ненужными. И ниже мы поговорим о том, как можно организовать загрузку ОС Linux из UEFI без дополнительных загрузчиков.

Secure Boot

Особого упоминания требует такая особенность UEFI как Secure Boot.

Как уже было сказано EFI раздел (ESP) находится на диске, к которому может быть организован доступ во время работы ОС. Это означает не только легкость в изменении загрузки и инициализации оборудования системы, но и то, что туда можно подсунуть заведомо зловредный код, который (О. УЖАС. ) будет загружен еще ДО!! загрузки ОС. На самом деле, перепрограммировать микросхемы BIOS или подменить код в MBR из запущенной ОС тоже можно было, но на это практически никто раньше не обращал внимания .

Закрыть эту «ужасающую дыру» в безопасности и призван Secure Boot. Вот как он работает:

При программировании системной памяти UEFI загрузчика (firmware), производители, вместе с кодом, записывают и сертификаты (содержащие ключи), и при загрузке в режиме Secure Boot UEFI проверяет по этим ключам подписи у любого исполняемого кода, который он загружает из ESP раздела (подписи добавляются к коду). Если верификация не прошла — такому коду отказывают в запуске.

Однако, довольно быстро шумиха улеглась. Во-первых Secure Boot практически все производители компьютеров разрешают отключать (Microsoft позже насколько переформулировал свои требования: от оборудования сертифицированного под Windows 8 не требуется запрещать загрузку без Secure Boot, зато требуется сообщить загрузчику Windows 8, что загрузка была не в SecureBoot режиме, и уже самой Windows решать — грузится ей дальше или нет). А во-вторых, в рамках консорциума UEFI были предусмотрены интерфейсы для управления ключами. «Подсуетились» и Canonical, и RedHat вместе с фондом FSF (Free Software Foundation). Как результат всех этих мероприятий и событий — и GRUB, и другие загрузчики обзавелись методами загрузки в режиме Secure Boot, а кроме того, стали доступны утилиты по управлению ключами UEFI. Вы даже можете свой собственный код подписать своим собственным ключом, загрузить ключ в UEFI (утилитами из пакета efitools) и это позволит загружать ваш собственный код в Secure Boot режиме.

Чуть хуже дело обстоит с планшетами и телефонами с предустановленной Windows — в прошивках этих устройств SecureBoot может быть не отключаем, а иногда нет и управления ключами.

Все дистрибутивы Ubuntu поддерживающие загрузку через UEFI уже имеют в своем составе все необходимое для загрузки в Secure Boot режиме практически на любом компьютере. Но, если загрузка с установочной флешки или диска не идет, то Secure Boot следует отключить (конечно же Secure Boot — не единственная причина по которой может не происходить загрузка с установочной флешки или диска).

Ключи системы Secure Boot

На самом деле в энергонезависимой памяти компьютера (NVRAM) рассчитанного на работу с UEFI предусмотрено место не на один сертификат, более того, сертификаты хранятся в специально организованной, иерархической системе. Давайте рассмотри этот вопрос более детально, но начнем с того, что определим — что такое сами ключи, о которых мы тут говорим.

Ключи

Что же представляют собой эти ключи? На самом деле хранятся все ключи UEFI в сертификате — бинарном файле контейнере специального формата (специальное расширение стандарта x.509). Внутри сертификата могут содержаться открытый ключ, информация о владельце ключа, удостоверяющий ключ подписи и иная информация. Сами используемые ключи — это пары ключей (открытый/публичный и закрытый/секретный) сформированные алгоритмом RSA. UEFI стандарт рекомендует использовать ключи длинной 2048 bit.

Набор ключей системы SecureBoot

UEFI стандарт предусматривает следующие ключи (или списки ключей):

Кроме того в NVRAM UEFI могут быть созданы кастомные списки ключей. Примером такого списка служит список ключей MOK (Mashine Owner Keys). MOK ключи используются не самим UEFI, а загрузчиком Shim. Shim (подписанный ключем из db) загружается как обычное UEFI приложение и сам проверяет подпись загружаемого им кода по ключам из MOK.

Состояния системы SecureBoot

Работа с ключем PK сильно зависит от состояния в котором находится UEFI. В спецификации UEFI v2.5 предусмотрено 4 состояния, на два из них наиболее важны, а еще два — служебные (они могут быть вовсе не реализованы в некоторых прошивках UEFI). Состояния определяются значениями глобальных переменных UEFI (хранящимися в NVRAM). При этом, в разных состояниях меняется не только значение переменных, но и возможность записать в эти переменные новое значение. Далее будет использоваться следующая нотация: <Переменная>=<значение>/[RO|RW], где признаки RO и RW говорят о доступности переменной для изменения (RO, от ReadOnly — только чтение; RW, от ReadWrite — чтение и запись).

KEK ключ может быть добавлен в состояниях Setup (без подписи или само-подписанный) и User (обязательно подписанный секретным ключем от PK).

С ключами в db* (db, dbx, dbt, dbr) — все значительно проще и одновременно сложнее: Т.к. существует огромное количество операционных систем и их различных версий, а также загрузчиков этих ОС, драйверов и утилит от разных поставщиков, то поставить (от производителя) систему сразу со всеми нужными ключами — просто нереально. То же касается и ключей, которые были скомпрометированы и ключей восстановления. Поэтому предусмотрен режим добавления этих ключей. При этом если система находится в состоянии Setup, то ключи в db* можно добавлять без подписей или само-подписанные, а если в User, то добавляемые ключи должны быть подписаны приватной ключем от одного из KEK ключей или от PK.

Причем в ключи в db (dbt) могут добавляться и автоматически (если это предусмотрено конкретной реализацией UEFI): когда подпись загружаемого модуля не может быть проверена, то могут быть предусмотрены механизмы (поиск в массиве на диске или интерактивное подтверждение от авторизованного пользователя), которые разрешат добавить публичный ключ от подписи (подпись содержит публичный ключ для своей проверки) в db (или dbt).

Собственные ключи

Так как все ключи/сертификаты UEFI (PK, KEK, db) построены на основе открытых стандартов, то и весь набор этих ключей можно сформировать самостоятельно. Далее рассмотрим как это можно сделать, а вот тут описано все тоже другим толковым автором.

Для работы нам потребуются утилита openssh (практически во всех дистрибутивах Linux эта утилита уже установлена) и утилиты из пакета efitools (доступна в репозиориях ubuntu 14) ).

Создание ключей

Для начала создадим наш тестовый ключ и само-подписанный сертификат:

Для дальнейших действий нам потребуется GUID для идентификации нашего ключа. Его очень просто сформировать через утилиту uuidgen, а для удобства новый GUID мы запишем в переменную.

Создание UEFI ключей

Для того что бы установить наш ключ в базу ключей UEFI, нам потребуется специальны контейнер EFI_SIGNATURE_LIST, в котором будет задана переменная EFI_VARIABLE_AUTHENTICATION_2. Для упрощения, ключи в контейнере будут само-подписанными.

Сначала мы создаем контейнер EFI_SIGNATURE_LIST содержащий сертификат:

Далее создадим подписанные ключи для последующей загрузки в энергонезависимую память UEFI. Наши файлы будут содержать сертификат с префиксом в виде EFI_VARIABLE_AUTHENTICATION_2 описателя. Описатель будет подписывать ключ, и содержать название переменной и другие атрибуты. Т.к. в файл будет включено название переменной (PK, KEK and db), нам придется создать отдельный контейнер для каждой переменной.

Кроме того, все известные сертификаты от разработчиков linux (Canonical, Fedora, AltLinux, openSUSE и др.) — тоже само-подписанные, их вы можете найти в на сайте проекта rEFInd или в проекте UEFI-Boot на github

Создание хранилища ключей

Далее нам потребуется создать хранилище ключей в стандартном месте, где утилита sbkeysync будет их искать.

На самом деле вы можете создать хранилище где угодно и указать утилите sbkeysync где оно находится в значении ключа –keystore.

Загрузка ключей

Через утилиту прошивки

Загрузка ключей в UEFI может быть выполнена из утилиты настройки вашей материнской платы. Там нужно будет найти раздел (обычно Security) где задаются параметры SecureBoot. Возможно потребуется явно разрешить работу с ключами — выбрать режим управления ключами custom или как либо еще. Попав в окно утилиты по управлению ключами, первым делом сохраните (на всякий случай) фабричные ключи 15) . После этого удалите все фабричные ключи, и по одному добавляйте ключи из вашего хранилища ключей (скорее всего, его придется перенести на ESP раздел, т.к. только этот раздел доступен для UEFI).

PK ключ желательно записывать последним (почему? — детально описано в финальной части раздела "Ключи системы SecureBoot").

Следует также отметить, что формат, в котором прошивка умеет загружать ключи может разниться в разных прошивках UEFI. Например прошивка AMI из недавно купленного мини-PC может взять сертификат и из подготовленного контейнера, и непосредственно из файла .pem. Т.о. вся эта возня со специальными контейнерами, в этом случае, вовсе не нужна: один и тот же само-подписанный сертификат можно загрузить и в PK, и в KEK, и в db.

Используя sbkeysync

Если UEFI находится в Setup режиме, то ключи можно загрузить и из ОС, используя утилиту sbkeysync. Но для начала воспользуйтесь опцией –dry-run, что бы убедится, что у вас все верно настроено и готово к этому важному процессу:

Вывод покажет списки ключей найденных в базе данных UEFI, ключей найденных в хранилище ключей и список синхронизации (какой ключ куда будет загружен).

Если все выглядит правильно, удалите –dry-run параметр из команды для фактического обновления ключей в UEFI базе данных.

Подписывание загрузчика

Т.к. мы активировали SecureBoot, то теперь нам нужно подписать наш загрузчик что бы он мог быть загружен UEFI в этом режиме. В нашем примере мы подпишем код загрузчика GRUB2.

Теперь, можно скрестить пальцы, плюнуть три раза через левое плечо и попробовать перегрузиться

Возврат в режим Setup

Хотя лучше убедиться, что вернуть UEFI в режим Setup можно из самой прошивки (утилиты настройки) перед тем как прописывать PK.

Как Ubuntu загружается в режиме Secure Boot

Как уже было сказано выше, сертификаты с ключами для загрузки в режиме Secure Boot записываются производителем оборудования (довольно подробно о ключах UEFI (англ.)). И, как правило, набор сертификатов состоит из: сертификата производителя, KEK и db ключей от Microsoft (конечно же). Крайне редко, но все же попадаются такие машины, у которых в db есть и ключ от Canonical и/или RedHad. Как же на машине c ключами только от Microsoft загрузить Ubuntu в режиме SecureBoot?
Решение было найдено: Microsoft согласился (не без активности со стороны Canonical) подписать своим ключом простенький загрузчик от Red Hat — shim (есть еще мини-загрузчик — PRELoader, о его подписании ключом Microsoft похлопотал фонд FSF). Shim, в свою очередь, содержит (в MOK) UEFI сертификат от Canonical и проверяет подпись GRUB2 (версия которого, распространяемая через репозитории Ubuntu, подписана ключем Canonical). А GRUB2 проверяет подпись ядра (из пакета linux-signed-generic, которое подписано Canonical).

Введение дополнительного звена в виде shim продиктовано тем, что GRUB довольно часто обновляется и каждый раз после обновления его надо подписывать. Само собой, его гораздо проще подписать собственным ключом Canonical нежели каждый раз снова договариваться с Microsoft.

Если вы не хотите оставлять сертификаты Microsoft и производителя на своей машине 16) , то из утилиты настройки вашей материнской платы или с помощью утилит efitools можно стереть сертификаты прописанные производителем, и записать в UEFI (db) ключ от Canonical, тогда уже Grub (так же как и само ядро Linux) сможет загружаться в режиме Secure Boot, и shim (со своим MOK) — не нужен.

Если вам не хочется даже сертификат от Canonical оставлять в своем компьютере 17) , то вы можете создать свои собственные ключи и сертификаты (как описано выше), подписать grub или само ядро Linux (утилитой sbsign из пакета sbsigntool) и записать ключи в базу данных ключей EFI (утилитами efitools). Подробно этот процесс описан выше и тут (англ.).

ВНИМАНИЕ, если ваш компьютер не позволяет отключить Secure Boot режим, то все манипуляции с ключами и подписями нужно проделывать с предельной осторожностью, т.к. любая ошибка может привести к тому, что ваш компьютер превратится в «кирпич».

Проверяйте все ваши настройки, проверяйте, что в UEFI записаны именно те ключи, что вы хотели и не забудьте проверить правильность подписей.

Хорошая идея: проделать все сначала на виртуальной машине.

EFS раздел (необходимый для загрузки в UEFI режиме) прописан и в таблицу разделов в MBR, и в каталог разделов iso9660 формата. По UEFI стандарту загрузчик по умолчанию должен находится в EFS разделе по пути: EFI\BOOT\BOOTx64.EFI

Такой «винегрет» позволяет грузиться с такого образа в следующих режимах:

Кстати в EFI\BOOT\BOOTx64.EFI (EFI\BOOT\BOOTia32.EFI для 32-х битных платформ) лежит не сам GRUB, а SHIM. Сам grubx64.efi/grubia32.efi (начальная стадия grub-efi) лежит рядом (в EFI\BOOT\) и его запускает SHIM. SHIM имеет валидную подпись ключом от Microsoft для загрузки в режиме SecureBoot, что позволяет загрузиться из образа на большинстве компьютеров.

Такой образ легко записать на флешку простой командой:

Второй параметр — именно девайс, а не раздел. Посмотреть диски и разделы можно в выводе команды

Образ Ubuntu копируется начиная с первого сектора устройства, MBR и таблица разделов ISO9660 стандарта попадают в необходимые для их правильной работы места, что позволяет с загрузиться с такой флешки как c USB-СD/DVD и как с USB-HDD/USB-Flash. Причем в обоих вариантах доступна загрузка как в UEFI, так и в BIOS/CSM режимах.

Другие интересные возможности UEFI

UEFI Shell

UEFI shell часто уже установлен в разделе ESP или прямо в прошивке UEFI. Некоторые UEFI прошивки умеют загружать командный интерпретатор UEFI прямо из консоли настройки UEFI (BIOS).

Если вы ставили Ubuntu на чистый диск, а в прошивке нет встроенного UEFI shell, то его можно доставить руками. Сам бинарный файл легко находится через любой поисковик. Вам нужно будет только скопировать его в корень ESP раздела с именем shellx64.efi (для 32-х битных платформ: shellx32.efi). Само собой копировать надо через sudo (т.е. с правами root).

Если из настроек UEFI нет возможности запустить UEFI shell, то можно его прописать как вариант загрузки (как вы помните UEFI поддерживает мульти-загрузку). Для этого воспользуемся утилитой efibootmg:

После этой команды у вас появится новый пункт меню загрузки UEFI, и это новый пункт станет первым по приоритету. Если такой приоритет загрузки вас не устраивает, то поменяйте его с помощью опции «-o» утилиты efibootmgr.

Справочник по командам UEFI shell встроенный — команда help. Если вы хотите останавливать вывод постранично (некий аналог more) то используйте в командах ключ -b. Кроме того поддерживается история вывода на 3 страницы которые можно просмотреть используя кнопки PageUp и PageDown.

Команда map покажет известные UEFI диски и разделы. Обычно диск fs0: — это и есть раздел ESP. Для того, что бы просмотреть содержимое каталогов ESP раздела (ls) выполните переход на ESP раздел — введите в строке приглашения fs0: — это очень похоже на dos команды типа а: с: (если кто еще помнит такое).

Разделитель в путях тоже в стиле DOS — обратный слеш (\).

EFI shell имеет довольно обширный набор команд, все их тут описывать смысла нет — если не достаточно встроенной подсказки, то есть краткие руководства в Internet. Наиболее полное писание UEFI Shell и его команд я нашел только в спецификации UEFI Shell 2.0 на сайте UEFI.org.

Загрузка ядра Linux непосредственно из UEFI

Если вы взгляните в файловом менеджере на ядро (/boot/vmlinuz*) то вы можете немало удивиться, заметив что тип будет указан как «DOS/Windows executable» — не удивляйтесь. Все последние ядра в Ubuntu собираются с опцией UEFISTUB (поддержка загрузки в режиме UEFI). А это добавляет заголовок аналогичный ДОСовскому .exe (именно так должны собираться все UEFI приложения). Т.е. само ядро можно загрузить как UEFI приложение. Для этого нужно разобраться с двумя основными вопросами:

1. Как правильно передать ядру параметры? Т.е. указать на корневую файловую систему, образ initrd, и указать опции загрузки ядра.
2. Как обеспечить UEFI доступ к самому ядру (и initrd)?

По первому пункту все достаточно просто: параметры, которые нужно передать ядру для загрузки можно подсмотреть в /boot/grub/grub.cfg, в команде загрузки linux (там стандартно передаются указание на корневой раздел и опции типа «ro», «quiet» и «splash»). Дополнительно ядру надо будет сообщить, где найти initrd (в ядрах версии 3.3 и выше это можно сделать через параметр intrd). В итоге, та команда, которую должен выполнить UEFI будет выглядеть примерно так:

В этом примере ядро и initrd лежат непосредственно в корне ESP раздела. Ядро переименовано в «vmlinuz.efi», а соответствующий ему образ рамдиска начальной инициализации ядра в «initrd». В команде указан UUID (моего корня, вам нужно прописать свой UUID) как путь к корневому разделу, но можно написать и что-то типа root=/dev/sda2 (UUID все же — лучше).

В первом варианте — для загрузки из UEFI нужно использовать подписанный вариант ядра (vmlinuz*.efi.signed).
Во втором варианте нужно организовать (это можно даже автоматизировать) подписывание каждого нового ядра, которое приходит с обновлениями системы.

Некоторые сложности может вызвать указание пути к initrd. Ядра выше 3.3 вообще не различают прямые и обратные слеши в параметре initrd, но нужно указать такой путь, что бы ядро смогло найти initrd при загрузки в окружение UEFI.

В целом, нам необходимо организовать доступ из UEFI и к ядру, и к initrd (напомню: UEFI имеет доступ только к ESP разделу и умеет работать только с файловой системой FAT32). Это может быть решено одним из трех вариантов:

Вариант 1: Загрузить ядро и intrd непосредственно из корневого раздела или раздела boot

Для этого нужно загрузить в UEFI драйвер для поддержки той файловой системы, в которую отформатирован ваш корень или /boot. (UEFI «из коробки» знает только FAT32, драйвера для чтения других FS можно найти например тут).

Вот какие команды надо выполнить в UEFI Shell для загрузки ядра прямо из корня, находящегося на разделе с EXT4 (boot не вынесен в отдельный раздел).
— загрузить драйвер поддержки ext2-3-4 (в нашем примере он был предварительно размещен на ESP разделе в каталоге EFI/drivers)

— смонтировать корневую FS (эта команда пытается все доступные устройства смапить всеми доступными драйверами)

— перейти (изменить текущий путь) в новую FS

— запустить ядро с параметрами

В этом примере я воспользовался тем, что в корне корневой FS автоматически создаются линки на самую свежую версию установленного ядра и его initrd. Перейдя (сменив текущий путь) в корневую ФС мне уже не нужно мудрить с указанием полного пути к ядру и initrd — они находятся в текущем каталоге (из которого и запускается ядро).

Все эти действия можно записать в скрипт (для скриптов UEFI Shell принято расширение .nsh), и запускать ОС вызвав его. К сожалению, непосредственно скрипт файл нельзя указать как исполняемый файл в пункте меню загрузки UEFI. Согласно спецификации UEFI Shell может исполнить скрипт, имя которого передано ему как параметр, но мне это сделать не удалось. UEFI Shell может автоматом исполнить (после паузы) скрипт startup.nsh, находящийся в корне ESP раздела (можно записать эту последовательность команд туда).

Но можно пойти другим путем. Спецификация UEFI поддерживает автоматическую загрузку драйверов при загрузке системы. А это собственно и есть то, что нам нужно для того, что бы получить доступ к файловой системе с ядром без скрипта. Однако и тут есть один подводный камень.

Дело в том, что просто загрузить драйвер — недостаточно, нужно еще вызвать процедуру ремаппинга устройств (т.е. выполнить ту самую команду map -r). При ремапинге каждый драйвер пытается «прицепиться» ко всем доступным устройствам, т.е. наш драйвер EXT2-4 сделает доступными все разделы на всех дисках с файловыми системами EXT2-4.

Добавить автоматическую загрузку драйвера можно командой

То же самое можно сделать командой bcfg из UEFI-Shell. Следующая команда добавит пункт загрузки Driver0000 (номер задает первый аргумент команды add), который будет загружать драйвер из файла EFI\drivers\ext2_x64.efi (с ESP раздела). Драйвер получит описание «EXT2-4 Driver»:

Все замечательно и этот драйвер, при каждом запуске системы, будет загружаться во время инициализации UEFI автоматически, но ремапинга не будет. Для того, чтобы после загрузки драйвера инициировать ремапинг нужно в опции загрузки драйвера указать специальный атрибут LOAD_OPTION_FORCE_RECONNECT, однако ни одной командой UEFI-Shell или опцией efibootmgr этот атрибут не установить (по крайней мере мне не удалось найти такой команды). Перелопатив спецификацию UEFI можно понять, что нужно то всего прописать значение 3 вместо 1 в первом 32-битном слове UEFI переменной отвечающей за загрузку драйвера (той самой Driver0000, что мы создали командой bcfg или efibootmgr). Сделать это изменение можно любым HEX редактором (из загруженной системы), запущенным с правами рута, в котором на редактирование открывается файл /sys/firmware/efi/efivars/Driver0000-8be4df61-93ca-11d2-aa0d-00e098032b8c (это маппинг в файловую систему sys переменной UEFI). В редакторе нужно 5-й байт от начала поменять с значения 01 на 03 и сохранить файл.

Хорошим тоном будет вернуть защиту после редактирования командой chattr +i

После нашей хакерской атаки на UEFI можно перегрузиться в UEFI-Shell и там прямо при запуске увидеть, что все EXT4 разделы уже отмаплены в FS<n> «диски», а значит на них можно сослаться при задании команды загрузки для опции загрузки ОС. В моем примере EXT4 раздел с корневой FS отмапился в FS2. А это позволяет задать в опции загрузки (используя команду bcfg из UEFI-Shell или efibootmgr из загруженной системы) команду такого вида:

Если вы все сделали правильно и не забыли подписать драйвер (если у вас включен SecureBoot), то поле перезагрузки система успешно должна загрузится прямо с вашего корневого раздела.

В принципе, несмотря на некоторую сложность этого метода в реализации, это САМЫЙ ПРАВИЛЬНЫЙ вариант загрузки ядра Linux из UEFI. Дополнительные удобства создают постоянно обновляемые ссылки на последнее и предыдущее ядра и их initrd в корне файловой системы Linux. На них можно однократно создать пункты загрузки UEFI и не нужно никаких обновлений после установки/удаления ядер и обновления initrd. Также однократно надо скопировать в EFS раздел драйвер для ФС корня и однократно настроить его загрузку.

Вариант 2: Скопировать ядро и intrd в ESP раздел

Преимущество в том, что не нужно мудрить с организацией поддержки другой FS. Однако, каждый раз при обновлении ядра или initrd их нужно вновь копировать в ESP раздел. Решить задачу автоматизации этого процесса можно одним из методов описанных в этой статье (англ.) или подобно тому как это реализовано в проекте UEFI Boot.

Вы можете выполнить команду запуска ядра из UEFI Shell, или записать ее в командный файл и запускать его из UEFI Shell, или, воспользовавшись утилитой efibootmgr, записать эту команду как пункт меню загрузки UEFI:

Эта команда добавит пункт загрузки LinuxKernel и сделает его первым в списке приоритета загрузки.

Вариант 3: Смонтировать ESP раздел как /boot

Преимущества этого решения в том, что новые ядра и initrd будут находится (устанавливаться и обновляться) прямо на ESP раздел (который станет одновременно boot разделом). Правда, неприятность в том, что название файла с ядром и initrd есть версия, и для каждого нового ядра нужно заново прописывать команду в пункт загрузки UEFI. Можно, конечно, переименовать в короткие имена (которые однократно будут записаны в пункты загрузки UEFI), однако переименование приводит нас к ситуации близкой к предыдущему случаю — initrd будет при обновлении снова получать номер версии и его каждый раз придется переименовывать. Воспользоваться автоматически создаваемыми ссылками в корневом разделе — не получится (они останутся в файловой сиcтеме корневого раздела, к которому нет доступа без доп. драйверов), а создать ссылки на FAT разделе — невозможно (этого FAT просто не умеет от рождения).

Команда для записи пункта загрузки UEFI через утилиту efibootmgr не отличается принципиально от той, что указана для способа с копированием ядра в ESP раздел:

Более детальная проработка этого варианта описана в отдельной статье UEFI Boot. Там реализовано автоматическое обновление пунктов загрузки UEFI при установке, обновлении и удалении ядер.

Устранение из процесса загрузки загрузчиков (оригинально это цепочка из двух: shim + GRUB) заметно (но не так что бы очень значительно) сокращает время загрузки ОС. Вот как это выглядит в цифрах на примере одного mini-pc (I5 5257U, 8Gb RAM, SSD): утилита systemd-analyze сообщает, что на стадию работы загрузчиков в случае цепочки UEFI-Shim-GRUB-Kernel требуется чуть меньше секунды — 967ms, а на прямую загрузку UEFI-Kernel — 153ms. При полной (холодной) загрузке системы за

14 секунд выигрыш составляет порядка 6%.

Полезные утилиты для UEFI

В стандартных репозиториях Ubuntu есть несколько полезных пакетов с утилитами для работы с настройками UEFI.

У всех этих утилит есть вполне толковые man-руководства и есть примеры использованию в Интернете, поэтому я не стану останавливаться на деталях использования этих утилит.

🙂 Патч Бармина живе всех живых

Ну и напоследок, последняя «веселая» история связанная с бородатым (по некоторым сведениям 1996 года рождения) патчем Бармина.

В конце января 2016 некий арчевод решил посмотреть — как работает этот известный патч. И он старательно вписал в команду даже специальный ключ, без которого этот патч уже не запускается… Ну… и получил кирпич из своего MCI нетбука — он даже после сброса не включился!

Как нетрудно догадаться корень беды — в кривой прошивке UEFI. Патч вытер вместе с корнем еще и переменные UEFI в NVRAM, которые монтируются в /sys/firmware/efi/efivars/, но принципиально это не могло быть проблемой, потому как стандартом UEFI предусматривается нарушение целостности данных в NVRAM: при обнаружении такой ситуации прошивка ОБЯЗАНА осуществить инициализацию NVRAM до состояния настроек по умолчанию/фабричных (Factory Default). Но вот в MCI решили забить на проверку целостности NVRAM, и незадачливый арчевод потащил свой нетбук кирпич в сервис.

После этой новости состоялся наезд на разработчиков SystemD (ну на них многие любят наезжать и ругаться, а те собственно сами довольно часто дают повод для вполне обоснованной и справедливой ругани в свой адрес): мол какого лешего, SystemD монтирует эти переменные с возможностью записи!? Давайте типа быстро переделайте на монтирование в режиме только-чтение. На что был дан резонный ответ — доступ на запись нужен утилитам, и разрешена запись только руту, который при желании премонтирует эти переменные в режиме записи. Так что, это не защитит от идиотов дураков «умников», которые экспериментируют с патчем Бармина.

Правда позже некоторые контрмеры все-таки были предприняты: теперь все UEFI переменные монтируются со специальным атрибутом, который запрещает запись и удаление этих файлов даже руту. Однако root в состоянии снять эти флаги (сhattr -i <имя файла>). Так что теперь для повторения судьбы арчевода с ноутбуком MCI нужно не только специальный ключ в команде rm -rf задавать, но еще и предварительно снять защиту с перемнных UEFI.

Самое же примечательное в этой ситуации ИМХО в том, что 20 лет назад отпущенная шутка, до сих пор стреляет, да еще с невиданной доселе мощью.