linuxboot / heads Goto Github PK

The Linux kernel bootloader should not have USB enabled; loading the modules should require measurement and adjustment of the PCRs (to invalidate the disk encryption keys).

There is no reason it has to be an executable; we have all the utility pieces to do it as a script.

dm-verity can be used to sign the root filesystem image with the user's key (stored in the ROM).

What happens if the ME firmware is zeroed out? Does coreboot still start up ok?

At compile time it links to our build of libqrencode, but initrd is installed with the one from the system. This is similar to issue #23

The coreboot code should enable VT-d early in the boot process to avoid rogue hardware attacks prior to measuring bootlbock, etc.

Related to issue #7, the initrd is built with some command line tools from the host system. these should be built as submodules.

This will allow the LUKS headers to be included in the PCRs, as well as record the TPM stored keys into a LUKS key slot.

Downside: it requires an additional several MB of libraries. Can a simpler one be built?

The Heads kernel needs aes-xts-plain64 cipher built in (or as a loadable module) to be able to read the Qubes lvm volumes.

It should be possible to update the firmware (other than the locked boot block) without a hardware programmer. Perhaps reserve the 4 MB upper flash chip for the bootblock, coreboot and the Linux recovery image, and use the lower 8 MB chip for the normal boot image?

The default coreboot ROM layout mixes up romstage and ramstage pieces. They should be separated, especially so that the key ones can be locked with the SPI flash BP bits (once issue #12 is resolved)

Hardware supports it, but coreboot does not generate it. x230 does; can we copy its code?

The Coreboot crossgcc target is not verified and does not check certs. In util/crossgcc/buildgcc:

download_showing_percentage() {
        url=$1
        printf " ..${red}  0%%"
        wget --no-check-certificate $url 2>&1 | while read line; do
                printf "${red}"
                echo $line | grep -o "[0-9]\+%" | awk '{printf("\b\b\b\b%4s", $1)}'
                printf "${NC}"
        done
}

There should be some shell scripts in the Heads ROM initrd to make it easier.

Hey,

in order to get the maximum sealing against the platform it would be useful to have a well documented and feature complete trusted boot in coreboot. I started to refactor the tpm stack and implement the missing features. Take a look at https://review.coreboot.org/#/q/status:open+tpm

Hey,

Maybe we want to implement them as well. Or extend the current implementation of coreboot itself. I know only PR is secure but I guess it would be good to have them in a security section with the BP feature.

Spec says 256 bytes should be sealable.

The disk keys can be split via secret sharing. Need to write a program to split/combine secrets.

The bootblock should measure itself and the next stages.

A two factor device like the yubikey could be added to the auth process for booting / decrypting.

The sealed totp secret should be made inaccessible after unsealtotp.sh has been run to prevent other processes from possibly reading out the secret.

This makes the builds harder to reproduce and the initrd larger than necessary. uclibc would be a better choice.

The disk key should be a combination of the user password and the TPM secret, currently it is just the user password.

The QR codes don't fit on the 80x25 screen that coreboot's native VGA initializes. Can it use half height characters instead?

xen.gz has timestamps from gzip, xen has non-reproducible data in the header and various compile time defines.

Hey,

for an UI improvement I would recommend something like http://invisible-island.net/dialog/ . Which is really easy to configure and has an advanced feature set.

The /start-xen script in the initrd should check the PGP signatures on the files before passing them to kexec

Can't make the start script executable.

It seems to change between boots.

The underlying libtpm and qrencode libraries must be made reproducible.

Something in the new per-board Makefile is causing coreboot to rebuild everything. This doesn't happen when make -C "/build/heads/build/coreboot-git" obj=./x230 DOTCONFIG=../../config/coreboot-x230.config -j 8 is run by hand, so it might be an environment variable.

The binaries from submodules are correctly installed, but libraries are not. This prevents a clean build of the ROM image from being bootable.

Something in the mbedtls adapter layer is not correctly setting up the auth. tpmtotp fails.

It is harder to reproduce builds since they are built with the system's gcc, rather than a specific version. Coreboot builds its own gcc, can we use that instead?

The mbedtls build hsa the random number generator stubbed out. Need to replace it with a proper one.

The top level Makefile doesn't know that all of the tpmtotp executables (for TPM operations) are generated with the same command, so it runs make -C build/tpmtotp-git many, many times.

Should use the .INTERMEDIATE: trick to let it know that they will be generated together.

Once the bootblock is more stabilized, the BP3-0 bits should be set to avoid overwriting it and prevent the root of trust from being subverted by a software attack on the flash chip.

Rom flashed

Rom was flashed following those instructions and built with that patch

Hey,

do we want to integrate the payload into coreboot so that it can be built out of the box ?

Do we need the storage root public key for anything? The mbedtls RSA wrapper would need to be improved to use it correctly.

A make on a clean cloned copy of heads produces the following errors under ubuntu 16.04:
sudo apt-get install m4 bison flex zlib1g-dev git build-essential
git clone https://github.com/osresearch/heads.git

1- initrd/bin directory is not created:
make
[...]
cmp --quiet "initrd/bin/kexec" "/media/user/7725fbc2-4b2d-4ade-9f1d-337ad8203dc3/Qubes/heads/build/kexec-tools-2.0.12/build/sbin/kexec" || cp -a "/media/user/7725fbc2-4b2d-4ade-9f1d-337ad8203dc3/Qubes/heads/build/kexec-tools-2.0.12/build/sbin/kexec" "initrd/bin/kexec"
cp: cannot create regular file 'initrd/bin/kexec': No such file or directory
Makefile:121: recipe for target 'initrd/bin/kexec' failed
make: *** [initrd/bin/kexec] Error 1

fix:
mkdir -p initrd/bin/

2- initrd/lib/x86_64-linux-gnu directory is not created:
make
[...]
cmp --quiet "initrd/lib/x86_64-linux-gnu/libtpm.so" "/media/user/7725fbc2-4b2d-4ade-9f1d-337ad8203dc3/Qubes/heads/build/tpmtotp-git/libtpm/libtpm.so" || cp -a "/media/user/7725fbc2-4b2d-4ade-9f1d-337ad8203dc3/Qubes/heads/build/tpmtotp-git/libtpm/libtpm.so" "initrd/lib/x86_64-linux-gnu/libtpm.so"
cp: cannot create regular file 'initrd/lib/x86_64-linux-gnu/libtpm.so': No such file or directory
Makefile:124: recipe for target 'initrd/lib/x86_64-linux-gnu/libtpm.so' failed
make: *** [initrd/lib/x86_64-linux-gnu/libtpm.so] Error 1

fix:
mkdir -p initrd/lib/x86_64-linux-gnu/

Once at the length in the CBFS and again at 256 KB.

There is no way to clear/take ownership without them.

FSP is available from https://downloadmirror.intel.com/26196/eng/SKL_Gold_FSP.tgz

The various pieces are not reproducible in their builds.

The TPM can unseal the disk keys, but it is currently not supported in Xen. Heads could pass it in as an command line option or other mechanism.

The makefile target for coreboot config only supports the x230; it should support building the qemu target or the (soon to be create) chell chromebook target without having to copy files around.

This makes it hard to have a canned start-xen script.