bootutils: Utilities to create bootable disks, remaster ISO images, make multiboot disk images
Goals – who needs this?
Use case 1: Multiboot disk image
Use case 2: Remastering ISO
Use case 3: Create boot disk on separate disk
Use case 4: Fix grub-install errors
Linux-only. No effort spent on supporting other OS
Tag: Linux
Secure Boot BOF at DebConf17
Helen Koike of Collabora has proposed a BOF on UEFI Secure Boot at DebConf17, this August:
DebConf17 – BoF proposal to discuss secure boot
I want to send a BoF proposal to DebConf17 so we can meet there and discuss about secure boot. I would like to know if you are interested in attending and also which topics you suggest for discussion. I would appreciate if you could put your name and suggestions in this form in case you are interested https://goo.gl/forms/lHoEibY1H6FmSHSJ2 , or just reply to this email thread.
For full message, see the debian-efi mailing list archives.
https://lists.debian.org/debian-efi/2017/05/threads.html
https://debconf17.debconf.org/
Linux kernel EGP_PGT_DUMP build option
Sai Praneeth Prakhya of Intel submitted V2 of an Intel UEFI diagnostic patch for the Linux kernel, the new version adds x86 support.
[PATCH V2] x86/efi: Add EFI_PGT_DUMP support for x86_32, kexec
EFI_PGT_DUMP, as the name suggests dumps efi page tables to dmesg during kernel boot. This feature is very useful while debugging page faults/null pointer dereferences to efi related addresses. Presently, this feature is limited only to x86_64, so let’s extend it to other efi configurations like kexec kernel, efi=old_map and to x86_32 as well. This doesn’t effect normal boot path because this config option should be used only for debug purposes.
Changes since v1:
1. Call efi_dump_pagetable() only once from efi_enter_virtual_mode() – as suggested by Boris
For more info, see the patch on the linux-(kernel,efi) lists.
Kees on Linux kernel 4.11 security
Here’s a quick summary of some of the interesting security things in this week’s v4.11 release of the Linux kernel:[…]
Debian Live images now include UEFI support
Steve McIntyre gave an update on Debian official images to the debian-(cd, devel-announce,live,cloud) mailing lists. There’s a UEFI update on Debian Live images:
Live images – now including UEFI support
After a hiatus, weekly builds of live images for testing are now happening again. These cover amd64 and i386, and there is a separate image for each of the common desktop environments. Thanks to great work by Neil Williams, Iain Learmonth and Ana Custura on new tools (vmdebootstrap and live-wraper), these also include support for UEFI booting as a new feature. Please help test the images and give feedback:
http://get.debian.org/cdimage/weekly-live-builds/
See Steve’s message to the above-listed lists for the full post.
https://lists.debian.org/msgid-search/20170428012707.GJ28360@einval.com
Debian 9 defers UEFI Secure Boot support
From the latest “Bits from the Release Team” message, it appears that Debian 9 will probably defer Secure Boot support to later.
Secure Boot
At a recent team meeting, we decided that support for Secure Boot in the forthcoming Debian 9 “stretch” would no longer be a blocker to release. The likely, although not certain outcome is that stretch will not have Secure Boot support. We appreciate that this will be a disappointment to many users and developers. However, we need to balance that with the limited time available for the volunteer teams working on this feature, and the risk of bugs being introduced through rushed development. It’s possible that Secure Boot support could be introduced at some point in stretch’s lifetime.
Full message:
https://lists.debian.org/debian-devel-announce/2017/04/msg00013.html
https://wiki.debian.org/SecureBoot
https://wiki.debian.org/UEFI
Rescatux adds new UEFI rescue options
Adrian announced Rescatux 0.41b, with new UEFI rescue options:
(*) Change UEFI Boot order
(*) Create UEFI Boot Entry
(*) Fake Microsoft Windows UEFI.
(*) Hide Microsoft Windows UEFI
(*) Reinstall Microsoft Windows UEFI boot entries
Adrian has a thread on the debian-efi list, asking for feedback on these features. Excerpt of announcement below, see the full announcement on the debian-efi list.
Rescatux 0.41b1 released with UEFI rescue options
* Rescatux introduction
Rescatux is a GNU/Linux rescue cd (and eventually also Windows) but it is not like other rescue disks. Rescatux comes with Rescapp. Rescapp is a nice wizard that will guide you through your rescue tasks.[…]
* Rescatux 0.41b1 released
Last week I released Rescatux 0.41b1 with a bunch of new UEFI rescue options. I just wanted to share with you some technical details about those options so that I can get some feedback from you.[…]
http://wiki.rescatux.org/wiki/Main_Page
ALT Linux Rescue also has the option to boot either into their Linux or into their provided UEFI Shell. I wish more Linux distirbutions provided features like this.
Microsoft seeks U-Boot Linux firmware Engineer
Senior Software Engineer, Linux Firmware – CSI / Azure – Cloud Server Infrastructure
The Cloud Server Infrastructure Firmware Development (CSI-FW) team is responsible for server hardware definition, design and development of Server and Rack Infrastructure engineering for Microsoft’s online services. […] This role will be for a highly-motivated Firmware Engineer with a solid background in embedded system design using embedded Linux. […] Required Qualifications:
[…]
* Extensive knowledge of u-boot customization, Linux kernel internals and adding new hardware drivers
[…]
https://careers.microsoft.com/jobdetails.aspx?jid=282596
Docker: LinuxKit (and Cilium)
IBM updates Linux IMA to improve boot security
Thiago Jung Bauermann of IBM has submitted a 6-part patch to the Linux-IMA-devel/Linux-Kernel lists, with some improvements to Linux IMA for OpenPOWER secure/trusted boot. Including comments from parts 1 and 6 of the patch, see the full patch for full details.
Appended signatures support for IMA appraisal
On the OpenPOWER platform, secure boot and trusted boot are being implemented using IMA for taking measurements and verifying signatures. Since the kernel image on Power servers is an ELF binary, kernels are signed using the scripts/sign-file tool and thus use the same signature format as signed kernel modules. This patch series adds support in IMA for verifying those signatures. It adds flexibility to OpenPOWER secure boot, because it can boot kernels with the signature appended to them as well as kernels where the signature is stored in the IMA extended attribute. The first four patches are cleanups and improvements that can be taken independently from the others (and from each other as well). The last two are the ones actually focused on this feature. […] This patch introduces the appended_imasig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA signature appended to it. Here is how it can be used in a rule:
appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig
appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig|imasig
In the second form, IMA will accept either an appended signature or a signature stored in the extended attribute. In that case, it will first check whether there is an appended signature, and if not it will read it from the extended attribute. The format of the appended signature is the same used for signed kernel modules. This means that the file can be signed with the scripts/sign-file tool, with a command line such as this:
$ sign-file sha256 privkey_ima.pem x509_ima.der vmlinux
This code only works for files that are hashed from a memory buffer, not for files that are read from disk at the time of hash calculation. In other words, only hooks that use kernel_read_file can support appended signatures. The change in CONFIG_INTEGRITY_SIGNATURE to select CONFIG_KEYS instead of depending on it is to avoid a dependency recursion in CONFIG_IMA_APPRAISE_APPENDED_SIG, because CONFIG_MODULE_SIG_FORMAT selects CONFIG_KEYS and Kconfig complains that CONFIG_INTEGRITY_SIGNATURE depends on it.
https://lists.sourceforge.net/lists/listinfo/linux-ima-devel
Background for Kernel Lockdown patch
Re: https://firmwaresecurity.com/2017/04/05/linux-kernel-lockdown-2/
Here’s more background on the Kernel Lockdown patch, from email by David Howells of Red Hat:
The idea is to properly implement UEFI Secure Boot mode such that we can kexec another operating system (Linux, Windows, etc.) and pass on the Secure Boot flag with a guarantee that we haven’t been compromised. This assumes the following:
(1) Someone wanting to compromise your machine can’t get physical access to the running hardware. I think pretty much all bets are off if someone gets their hands on your computer.
(2) Whatever boots our kernel is not itself compromised. If it is, there’s pretty much nothing we can do about it.
(3) Whatever boots our kernel can prove that our kernel is what it says it is.
Now, (2) has to start with security right from the system booting, and likely involves the firmware being checked by the hardware. The firmware then has to validate anything it runs, and the things it runs have to validate anything they run, etc. up to our kernel being booted.
With regard to (3), take the example of booting Fedora Linux on a UEFI PC in secure boot mode: the UEFI BIOS boots the Fedora SHIM, which boots Grub, which boots the kernel. The SHIM is signed by the UEFI signing authority and is checked against the UEFI key database; Grub and the kernel are signed by a key built into the SHIM.
[Note that in secure boot mode, Grub loads the kernel image asks the SHIM to verify it; further, the SHIM will catch anyone trying to boot without verification and halt the machine.]
[Note that we do verification with cryptographic signatures, but compiled-in hash whitelists would also work.]
In order to maintain the security guarantee, the kernel then needs to prevent unauthorised modification of code and data in the running kernel (module loading is permissible) and also it needs to protect any private keys or other security data it may hold within the image. We try to do this by the following means:
(1) Refuse to use any key or hash that UEFI has in its blacklist.
(2) Refuse to load any module that isn’t signed/hashed.
(3) Refuse to load any firmware that isn’t signed/hashed.
(4) Refuse to kexec any image that isn’t signed/hashed.
(5) Refuse to dump a kernel image for software suspend/hibernation if it’s not encrypted. Further, if it is encrypted, the key must be protected.
(6) Refuse to load a dumped kernel image that isn’t encrypted with a protected key.
(7) Refuse to allow userspace direct access to kernel memory (no /dev/mem, /dev/kmem, /proc/kcore).
(8) Refuse to allow userspace direct, unsupervised access to hardware (no iopl, /dev/ioports, MSRs, etc.). It might be feasible to open PCI BARs through dedicated device files for certain functions though (eg. X servers), but unconstrained DMA must be disallowed.
(9) Refuse to let userspace configure a driver to use a piece of hardware to muck around with system RAM, possibly by mismatching driver and device.
See the posting on the linux-kernel/efi list for full message.
Hopper available for Linux
Linux Kernel: exclude EFI from KASLR VA space randomization
Greg Kroah-Hartman of the Linux Foundation submitted version 4.10 of a 81-part(!) patch to the Linux kernel by Baoquan He of Red Hat.
[PATCH 4.10 65/81] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization
4.10-stable review patch. If anyone has any objections, please let me know.
commit a46f60d76004965e5669dbf3fc21ef3bc3632eb4 upstream.
Currently KASLR is enabled on three regions: the direct mapping of physical memory, vamlloc and vmemmap. However the EFI region is also mistakenly included for VA space randomization because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END. (This breaks kexec and possibly other things that rely on stable addresses.) The EFI region is reserved for EFI runtime services virtual mapping which should not be included in KASLR ranges. In Documentation/x86/x86_64/mm.txt, we can see:
ffffffef00000000 – fffffffeffffffff (=64 GB) EFI region mapping space
EFI uses the space from -4G to -64G thus EFI_VA_START > EFI_VA_END, Here EFI_VA_START = -4G, and EFI_VA_END = -64G. Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.
More info: see the linux-efi/linux-kernel list.
Linux Kernel lockdown
David Howells of Red Hat has posted a 24-part patch to the Linux-(Kernel,EFI) lists, which hardens Linux from some firmware attacks.
These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include:
(*) No unsigned modules and no modules for which can’t validate the signature.
(*) No use of ioperm(), iopl() and no writing to /dev/port.
(*) No writing to /dev/mem or /dev/kmem.
(*) No hibernation.
(*) Restrict PCI BAR access.
(*) Restrict MSR access.
(*) No kexec_load().
(*) Certain ACPI restrictions.
(*) Restrict debugfs interface to ASUS WMI.
The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn’t insecure. The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system.[…]
See the full patch for more info:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown
http://vger.kernel.org/majordomo-info.html
Encrypted Arch UEFI Installation guide
Arch Linux users might want to read this document.
An efficent method to achieve a properly encrypted, UEFI-booting, Arch Linux system. Multi-OS, and VirtualBox, UEFI booting are also supported. OBJECTIVE: Install Arch Linux with encrypted root and swap filesystems and boot from UEFI. Note: This method supports both dedicated Arch installs and those who wish to install Arch on a multi-OS-UEFI booting system. VirtualBox Installers Note: This installation method can also be used to install Arch Linux as an UEFI-booting Guest system in VirtualBox. You must have UEFI-booting enabled in VBox’s Guest System Settings prior to installation.[…]
https://github.com/HardenedArray/Encrypted-Arch-UEFI-Installation
USB Canary
“USB Canary: A Linux tool that uses pyudev to monitor devices while your computer is locked. In the case it detects someone plugging in or unplugging devices it can be configured to send you an SMS or alert you via Slack of the potential security breach.”
Matthew announces Shim review process
LUV announces v2.1-rc2 release
Ricardo Neri of Intel posted a LONG announcement about LUV V2.1-rc2, most of which included here. There are a LOT of new features in this LUV release!
This is to announce the release of LUV v2.1-rc2. It has been a while since the last time of our last release. This is not the ideal release cadence are working to make changes. We will now release more frequently. We aim to release a new version every 4-5 weeks with the content we accumulate over that period of time. Given the large number of new features and changes in this release, it made sense to release it as rc2 of v2.1 to allow for issues to arise and stabilize towards the next release cycle.
This release include the client side of our telemetrics solution. This solution is based on the implementation done for Clear Linux[1]; abiding Intel privacy policies[2]. Please note that telemetrics is an opt-in feature and is disabled by default and only works for systems within Intel networks. We will work now on the server side of the solution.
In this release we have migrated from systemV to systemd, which is inline with most Linux distributions. Also, our telemetrics client needed it to function. Megha Dey did all the heavy lifting to migrate to systemd; which was not an easy task (kudos to her!). She worked on stabilizing network and revamping our splash screen, which now uses plymouth.
Sai Praneeth Prakhya extended our existing implementation to detect illegal access to UEFI Boot Services memory regions after boot. His extension now allows to detect such access to also conventional memory. Likewise, it now detects these acceses at runtime and long after UEFI SetVirtualAddressMap. This has been quite useful recently to detect bugs related to UEFI capsules in certain firmware implementations.
Gayatri Kammela worked on providing tools to make the netboot images more useful. She completed a reference implementation of an HTTP server to collect test results in a test farm. The documentation of this implementation can be found here[2]; we don’t provide collection services. Of course, the client-side implementation of this solution is part of this release. Along with this solution, she wrote a script to customize a netboot binary (an EFI application) to work with her reference implementation[4].
Naresh Bhat updated the kernel configuration for aarch64. He also worked on providing a more clean, unified and structured kernel command line for all the supported CPU architectures. He also enabled support of netboot images for aarch64.
Fathi Boudra kindly reworked the kernel configuration fragments to avoid unnecessary duplications.
Matt Hart added a new luv.poweroff option.
Configuration of LUV has been simplified by moving all the parameters that the user might configure a LUV.cfg file found in the boot partition of the disk image. No more meddling with the grub.cfg configuration file.
We now provide images built for both GPT and MBR partition schemes.
Updated test suites: We include FWTS V17.03.00, CHIPSEC v1.2.5 plus all the changes available as of this week towards the release of v.1.2.6, which should be coming soon. BITS was bumped to v2079. We use Linux v4.10. This release is based on the Morty version of the Yocto Project.
meta-oe and updates to the build process: Our build process changed a bit. We now include certain components from the meta-oe layer[5]. Such layer has been added to our repository, but it still need to be added locally to the build/conf/bblayers.conf file when building.
Binary images for x86: A announcement to download binary images for x86 will be sent this week.
See rest of announcement for list of Known Issues, and Fixed Issues.
[1] https://clearlinux.org/features/telemetry
[2] http://www.intel.com/content/www/us/en/privacy/intel-privacy.html
[3] https://github.com/01org/luv-yocto/wiki/Send–LUV-test-results-to-an-HTTP-server
[4] https://github.com/01org/luv-yocto/wiki/Using-LUV-Script-modify_luv_netboot_efi.py
[5] https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/
Full announcement:
https://lists.01.org/mailman/listinfo/luv
Linux storage stack infographics
Hyper-V UEFI bootloader complexities
[…]Forcing GRUB installation to EFI removable media path does basically the same thing as when Ubuntu installer asks you if you want to force UEFI installation: it installs to the removable media path in the ESP (EFI System Partition). This is fine for environment where no other operating system is present. However if there is another operating system present on the device which depends on this fallback location “removable media path” it will make this system temporary unbootable (you can manually configure GRUB later to boot it if necessary though). Windows installer for example *also* installs to the removable media path in the ESP. All OS installers installing things to this removable media path will conflict with any other such installers and that’s why in Debian (and Ubuntu) installers don’t do this by default. You explicitly have to select UEFI mode during the normal installation (what I did).[…]
Firmware Security 
You must be logged in to post a comment.