Target disk subsystem

In this section we are going to test the target computer’s performance to create a 1 GB file on local storage using the linux dd command. The dd command will create this 1GB file and time the creation process for us. Just be aware that this is a data distructive test. The contents of your local storage device will be erased during the test. Don’t perform this storage bandwidth test on a disk where you can not afford to lose the data.

The hardest step in the process is finding the local storage device name, removing all partitions on the disk, and then creating a new partition for our testing.

First lets find the name of your local storage disk. We will use the lsblk command to locate the linux device name. In the figure below you see the linux device name is sda for a sata attached disk, It has 2 partitions sda1 sda2

# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 238.5G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi └─sda2 8:2 0 238G 0 part / sr0 11:0 1 1024M 0 rom

Below is an example of an NVMe disk. In this case the device name is nume0n1 and the partition numbers are p1 p2 p3 p4.

# lsblk NAME MAT:MIN RM SIZE RO TYPE MOUNTPOINT nume0n1 259:0 0 4776 0 disk |-nume0n1p1 259:1 0 100M 0 part |-nume0n1p2 259:2 0 16M 0 part |-nume0n1p3 259:3 0 476.3G 0 part |-nume0n1p4 259:4 0 508M 0 part

For the rest of this section we will assume you have a NVMe drive so we will use that naming convention. So we know the NVMe device name is nume0n1. Lets use the fdisk utility to remove all of the existing partitions on the disk. Don’t forget I mentioned this is a data destructive test.

fdisk /dev/nume0n1

Use the d command to remove all of the existing partitions on the disk. Then use the w command to write the blank partition table to disk. You can confirm the partitions are gone with the p command. Now finally create a new partition using the n then p primary, 1 first partition and then pick the defaults for the remainder. Now use the w write command to write the partitions to disk and the q command to quit fdisk. Finally ensure the OS is in sync with the disk by keying in sync twice at the FOS Linux command prompt.

You can confirm your changes my once again using the lsblk command.

# lsblk NAME MAT:MIN RM SIZE RO TYPE MOUNTPOINT nume0n1 259:0 0 4776 0 disk |-nume0n1p1 259:1 0 477.6G 0 part

Now that we have our test partition we need to format it. Lets format this nvme first partition using this command.

mkfs -t ext4 /dev/nvme0n1p1

The output of this command should look similar to this

# mkfs -t ext4 /dev/nvme0n1p1 nke2fs 1.45.6 (20-Mar-2020) Discarding device blocks: done Creating filesysten with 124866880 4k blocks and 31219712 inodes Filesysten UUID: 5652bad-814c-4a2d-811a-fd5fb50a6dc4 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000 Allocating group tables: done Writing inode tables: done Creating journal (262144 blocks): done Writing superblocks and filesystem accounting information: done

Hang on we are almost done with the setup. The next step is to create a directory mount point and to connect the nvme partition to the directory mount point.

mkdir /ntfs mount -t ext4 /dev/nvme0n1p1 /ntfs

Issue the following command to confirm the partition is mounted.

df -h Filesystem Size Used Avail Use% Mounted on /dev/root 248M 97M 139M 42% / /dev/nvme0n1p1 477G 26G 452G 6% /ntfs

The line we are looking for is this one. It shows that the device /dev/nvme0n1p1 is connected to the /ntfs path.

/dev/nvme0n1p1 477G 26G 452G 6% /ntfs

Finally we’ve made it to the benchmarking point. Now we will use the dd command to create a 1GB file on the local disk.

dd if=/dev/zero of=/ntfs/test1.img bs=1G count=1 oflag=direct 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB, 1.0GiB) copied, 0.546232 s, 2.0 GB/s

In this case the dd command created the 1GB file in about a 1/2 second at a rate of 2.0 GB/s. This results is withing the expected range.

I can give you a few numbers off the top of my head that are reasonable results.
SATA HDD (spinning disk) 40-90MB/s
SATA SSD 350-520MB/s
NVMe 950-3500MB/s

If your results are within the above ranges for the selected storage device this part of the test was successful.

Preparing the FOG server with the prerequisites

sudo apt-get update sudo apt-get upgrade -y

Reboot the FOG server and then install the required packages

sudo apt-get install -y openssl efitools gnu-efi git build-essential help2man libssl-dev sudo perl -e'use CPAN; install "File::Slurp"'

Create the Secure Boot PKI infrastructure

Lets create the working directories

mkdir -p /opt/fog/secureboot/efikeys

Now lets create our bash file to create the PKI infrastructure

vi /opt/fog/secureboot/mkkeys.sh

Insert the following text into that bash script.

#!/bin/bash # Copyright (c) 2015 by Roderick W. Smith # Updated 26-Nov-2021 by George1421 for the FOG Project # Licensed under the terms of the GPL v3 NAME=FOGProjectSB openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME PK/" -keyout efikeys/PK.key \ -out efikeys/PK.crt -days 3650 -nodes -sha256 openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME KEK/" -keyout efikeys/KEK.key \ -out efikeys/KEK.crt -days 3650 -nodes -sha256 openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME DB/" -keyout efikeys/DB.key \ -out efikeys/DB.crt -days 3650 -nodes -sha256 openssl x509 -in efikeys/PK.crt -out efikeys/PK.cer -outform DER openssl x509 -in efikeys/KEK.crt -out efikeys/KEK.cer -outform DER openssl x509 -in efikeys/DB.crt -out efikeys/DB.cer -outform DER GUID=`python3 -c 'import uuid; print(str(uuid.uuid1()))'` echo $GUID > efikeys/myGUID.txt cert-to-efi-sig-list -g $GUID efikeys/PK.crt efikeys/PK.esl cert-to-efi-sig-list -g $GUID efikeys/KEK.crt efikeys/KEK.esl cert-to-efi-sig-list -g $GUID efikeys/DB.crt efikeys/DB.esl rm -f efikeys/noPK.esl touch efikeys/noPK.esl sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k efikeys/PK.key -c efikeys/PK.crt PK efikeys/PK.esl efikeys/PK.auth sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k efikeys/PK.key -c efikeys/PK.crt PK efikeys/noPK.esl efikeys/noPK.auth sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k efikeys/PK.key -c efikeys/PK.crt KEK efikeys/KEK.esl efikeys/KEK.auth sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k efikeys/KEK.key -c efikeys/KEK.crt db efikeys/DB.esl efikeys/DB.auth chmod 0600 efikeys/*.key echo "" echo "" echo "For use with KeyTool, copy the *.auth and *.esl files to a FAT USB" echo "flash drive or to your EFI System Partition (ESP)." echo "For use with most UEFIs' built-in key managers, copy the *.cer files;" echo "but some UEFIs require the *.auth files." echo ""

Make the script we just created executable
Change into the secureboot directory and finally run the bash script.

chmod a+x /opt/fog/secureboot/mkkeys.sh cd /opt/fog/secureboot/ ./mkkeys.sh

I will tell you that when you run the mkkeys.sh you may get run time errors. You will need to research on your own what is missing and add that to your fog server using the apt-get package tool. I developed this process and a linux mint server and the duplicated it on a debian 10 fog server. I think I have all of the packages above that is needed. But YMMV.

Create the Secure Boot signed enrollment boot loader

Lets get the efitools package so we can built the enrollment bootloaders

git clone git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git

Change into the efitools directory and run make to build the templates.

cd /opt/fog/secureboot/efitools make

I will tell you that when you run the make commandyou may get run time errors. You will need to research on your own what is missing and add that to your fog server’s environment using the apt-get package tool. I developed this process and a linux mint server and the duplicated it on a debian 10 fog server. I think I have all of the packages above that is needed. But YMMV.

Now that we have the templates created we need to download the current secure boot key chains that are created by the hardware manufacture. My plan is to take the original certificate database, tack on the FOG certificates onto the end and then upload the combined certificates back to the target hardware. So for completeness I’ll show you how I downloaded the original certificates. To save you some time, I’ll include these files in a zip file a bit later in this post.

For this bit one of my dev fog servers runs on real hardware. I used these commands under debian to extract these generic certificates from the target computer’s bios. The computer I extracted them from was a Dell Precision 3620. So these certificates and certificate store is fairly new.

mkdir -p /opt/fog/secureboot/hwkeys cd /opt/fog/secureboot/ sudo efi-readvar -v PK -o /opt/fog/secureboot/hwkeys/hw_PK.esl sudo efi-readvar -v KEK -o /opt/fog/secureboot/hwkeys/hw_KEK.esl sudo efi-readvar -v db -o /opt/fog/secureboot/hwkeys/hw_db.esl sudo efi-readvar -v dbx -o /opt/fog/secureboot/hwkeys/hw_dbx.esl sudo chmod 666 /opt/fog/secureboot/hwkeys/*

The following certificates (not really the correct word to use, but for my sanity I’ll call them certificates) are the only ones we are interested in (hw_KEK.esl, hw_db.esl, hw_dbx.esl). As I said above, you don’t need to do the above part because I’ll provide these generic certificates. note: 15-Dec-23 the hw_dbx.esl file might not be created if the dbx database is empty. If this is the case you should ignore the commands that use that file. Thank you @jfernandz for the updated inforamtion

Now lets bring everything together

cp /opt/fog/secureboot/efikeys/* /opt/fog/secureboot/efitools/ cp /opt/fog/secureboot/hwkeys/* /opt/fog/secureboot/efitools/ cd /opt/fog/secureboot/efitools mv DB.esl DB-fog.esl mv KEK.esl KEK-fog.esl mv dbx.esl dbx-fog.esl

At this point we are going to take the hardware certificates we downloaded from the uefi firmware and tag the FOG certificates onto the end.

cat hw_db.esl DB-fog.esl > DB.esl cat hw_KEK.esl KEK-fog.esl > KEK.esl cat hw_dbx.esl > dbx.esl

Lets rebuild the signed boot loaders with the updated certificates

rm LockDown*efi LockDown.so LockDown.o make cp LockDown-signed.efi EnrollKeys.efi

/opt/fog/secureboot/efitools/EnrollKeys.efi is the boot loader we will use to auto insert the updated security keys into the uefi firmware. So lets copy that file to the /tftpboot

cp /opt/fog/secureboot/efitools/EnrollKeys.efi /tftpboot

The other two key files from this process that we will need is the FOG certificate private and public keys.

/opt/fog/secureboot/efikeys/DB.crt
/opt/fog/secureboot/efikeys/DB.key

In the next post we will go through and sign all of the boot files needed to secure boot into FOG.

Sample download with certificates
Here are the microsoft certificates that I downloaded from my Dell Desktop computer running debian. If you want this file you will need to download it and change the extension to .zip from .txt to be able to extract the contents. These keys are not unique, serialized, or unique. Every computer that is secure boot capable have these default keys installed.

ms_hwcerts.zip.txt