jiazhang0 / meta-secure-core Goto Github PK

OpenEmbedded layer for the use cases on secure boot, integrity and encryption

License: MIT License

BitBake 45.95% PHP 0.21% C++ 21.81% Shell 23.44% BlitzBasic 2.67% Pascal 1.84% HTML 1.46% Clojure 2.46% NASL 0.17%

efi secure-boot security integrity tpm tpm2 signing-keys modsign encryption uefi

meta-secure-core's Introduction

NOTE: The development and maintenance work of this project is formally transferred to https://github.com/Wind-River/meta-secure-core. Don't use this depreciated project.

meta-secure-core

This layer provides the following common and platform-specific security features:

UEFI Secure Boot

For x86 platform, UEFI secure boot is the industry standard defined in the UEFI spec, allowing images loaded by UEFI BIOS to be verified with the trusted key. Whenever this feature is enabled, the bootloader and kernel will be signed automatically during the build, implying the signed binaries are contained by the resulting RPM and rootfs image.

MOK Secure Boot

For x86 platform, MOK secure boot is based on the UEFI secure boot, adding the shim loader to chainloader the second-stage bootloader. Meanwhile, the shim will also install a protocol which permits the second-stage bootloader to perform similar binary validation, e.g, for linux kernel.

User key store

By default, the signing key used by UEFI/MOK secure boot is the sample key for the purposes of development and demonstration. It is not recommended that this sample key be used for a production device and should be replaced by a secret key owned by the user.

TPM 1.x

This feature enables Trusted Platform Module 1.x support, including kernel option changes to enable tpm drivers, and picking up TPM 1.x packages.

TPM 2.0

This feature enables Trusted Platform Module 2.0 support, including kernel option changes to enable tpm drivers, and picking up TPM 2.0 packages.

Trusted Platform Module (TPM 2.0) is a microcontroller that stores keys, passwords, and digital certificates. A discrete TPM 2.0 offers the capabilities as part of the overall platform security requirements.

Encrypted storage

This feature gives 2 types of granularity for storage encryption. Data volume encryption allows the user to create encryption partition with a passphrase typed by the end user. Root filesystem encryption enables the data encryption on the entire rootfs except the boot partition.

Both types of storage encryption are based on device-mapper crypt target, which provides transparent encryption of block devices using the kernel crypto API. Additionally, the utility cryptsetup is used to conveniently setup disk encryption based on device-mapper crypt target.

IMA

The Linux IMA subsystem introduces hooks within the Linux kernel to support measuring the integrity of files that are loaded (including application code) before it is executed or mmap()ed to memory. The measured value (hash) is then registered in a log that can be consulted by administrators.

To support proven integrity of the files, the IMA subsystem can interact with the TPM chip within the system to protect the registered hashes from tampering by a rogue administrator or application. The IMA subsystem, as already supported by the Linux kernel, supports reporting on the hashes of files and commands ran by privileged accounts (and more if you create your own measurement policies).

In addition, IMA appraisal can even register the measured value as an extended attribute, and after subsequent measurement(s) validate this extended attribute against the measured value and refuse to load the file (or execute the application) if the hash does not match. In that case, the IMA subsystem allows files and applications to be loaded if the hashes match (and will save the updated hash if the file is modified) but refuse to load it if it doesn't. This provides some protection against offline tampering of the files.

MODSIGN

This feature provides the signature check for loading a kernel module. The signing key must be authenticated by a system trusted key already imported to the system trusted keyring.

If the kernel module is not signed, or signed by a signing key not matching up an imported system trusted key, kernel would refuse to load such a kernel module.

RPM signing

This feature provides the integrity verification for the RPM package.

Building the meta-secure-core layer

This layer should be added to the bblayers.conf file. To enable certain feature provided by this layer, add the feature to the local.conf file.

A reference implementation based on this layer is available.

meta-secure-core's People

Contributors

Stargazers

Watchers

meta-secure-core's Issues

Compilation error while enabling meta-secure-core

log.do_deploy.3658684.txt

HI,

Am getting the below error on enabling "Mmeta-secure-core.
Have attached run.do_deploy.3658684 also.

ERROR: grub-efi-2.04-r0 do_deploy: Execution of '/home/ankit_singh3/code/embeddedos_yocto_checkin_0/embeddedos_yocto/poky/build-secure-core/tmp/work/core2-64-poky-linux/grub-efi/2.04-r0/temp/run.do_deploy.3658684' failed with exit code 1:
install: '/home/ankit_singh3/code/embeddedos_yocto_checkin_0/embeddedos_yocto/poky/build-secure-core/tmp/work/core2-64-poky-linux/grub-efi/2.04-r0/deploy-grub-efi/grubx64.efi' and '/home/ankit_singh3/code/embeddedos_yocto_checkin_0/embeddedos_yocto/poky/build-secure-core/tmp/work/core2-64-poky-linux/grub-efi/2.04-r0/deploy-grub-efi/grubx64.efi' are the same file
WARNING: exit code 1 from a shell command.

ERROR: Logfile of failure stored in: /home/ankit_singh3/code/embeddedos_yocto_checkin_0/embeddedos_yocto/poky/build-secure-core/tmp/work/core2-64-poky-linux/grub-efi/2.04-r0/temp/log.do_deploy.3658684

secure-core-image failed to build hddimg. (mismatch in grub-efi output name)

I encountered this issue while building secure-core-image with .hddimg output.

NOTE: Trying to install /home/xxx/dev/dcfast_ipc_image/image/poky/build/tmp/deploy/images/genericx86-64/bzImage as /home/xxx/dev/dcfast_ipc_image/image/poky/build/tmp/work/genericx86_64-poky-linux/secure-core-image/1.0-r0/secure-core-image-1.0/hddimg/bzImage
install: cannot stat '/home/xxx/dev/dcfast_ipc_image/image/poky/build/tmp/deploy/images/genericx86-64/grub-efi-bootx64.efi': No such file or directory

What I have noticed is that

in deploy dir, grub-efi-grubx64.efi exists instead of grub-efi-bootx64.efi

there is a difference between the naming of grubimage found in grub-efi-efi-secure-boot.inc and grub-efi_%.bb(currently using 2.06 version)

# meta-secure-core/meta-efi-secure-boot/recipes-bsp/grub/grub-efi-efi-secure-boot.inc
74:        grubimage = "grubx64.efi"
76:        grubimage = "grubia32.efi"
80:    d.setVar("GRUB_IMAGE", grubimage)

# conf/image-uefi.conf
21:EFI_BOOT_IMAGE ?= "boot${EFI_ARCH}.efi"

# poky/meta/recipes-bsp/grub/grub-efi_2.06.bb
20:    prefix = "" if d.getVar('EFI_PROVIDER') == "grub-efi" else "grub-efi-"
35:    grubimage = prefix + d.getVar("EFI_BOOT_IMAGE")
37:    d.setVar("GRUB_IMAGE", grubimage)

meta-secure-core causes the grubimage to end up with grub-efi-grubx64.efi instead of the grub-efi-bootx64.efi that is expected by grub-efi_2.06.bb

For building, I followed the instruction written in meta-secure-core/meta/README with a few tweaks.

poky: honister
meta-openembedded: honister
meta-securecore: master:5fcb2f0e67fa3f3607f65e317330cc8e045f1106

Am I missing some configuration in the local.conf ? or is this a bug ?

local.conf

MACHINE ?= "qemux86-64"
DISTRO ?= "poky"
SDKMACHINE ?= "x86_64"
TARGET_ARCH ?= "x86_64"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"
CONF_VERSION = "2"
IMAGE_FSTYPES += " hddimg"
ROOT_HOME ??= "/home/root"
MACHINE_forcevariable= "genericx86-64"
INITRAMFS_IMAGE = "secure-core-image-initramfs"
DISTRO_FEATURES_NATIVE:append = " systemd ima tpm2 efi-secure-boot luks"
DISTRO_FEATURES:append = " systemd ima tpm2 efi-secure-boot luks modsign"
MACHINE_FEATURES_NATIVE:append = " efi"
MACHINE_FEATURES:append = " efi"
PACKAGE_CLASSES = "package_rpm"
SECURE_CORE_IMAGE_EXTRA_INSTALL ?= "\
    packagegroup-efi-secure-boot \
    packagegroup-tpm2 \
    packagegroup-ima \
    packagegroup-luks \
"
DEBUG_FLAGS:forcevariable = ""
IMAGE_INSTALL:append = " kernel-image-bzimage"

build script

cd /path/to/poky
source oe-init-build-env
bitbake-layers add-layer \
  $SCRIPTPATH/meta-openembedded/meta-oe \
  $SCRIPTPATH/meta-openembedded/meta-perl \
  $SCRIPTPATH/meta-secure-core/meta \
  $SCRIPTPATH/meta-secure-core/meta-signing-key \
  $SCRIPTPATH/meta-secure-core/meta-efi-secure-boot \
  $SCRIPTPATH/meta-secure-core/meta-tpm2 \
  $SCRIPTPATH/meta-secure-core/meta-integrity \
  $SCRIPTPATH/meta-secure-core/meta-encrypted-storage
bitbake secure-core-image

SYSTEM_TRUSTED and SECONDARY_TRUSTED are incorrectly parsed

Despite having, neither ima or modsign as DISTRO_FEATURES, I received the following error:

| NOTE: system_trusted_key.key is unavailable
| DEBUG: Python function check_deploy_keys finished
| ERROR: Function failed: ERROR: Unable to find user key for SYSTEM_TRUSTED ...

Everything looked OK in meta-signing-key/classes/user-key-store.bbclass.

However, after some debugging it turned out SYSTEM_TRUSTED and SECONDARY_TRUSTED were always being set to "1" - regardless of the status of ima or modsign.

I believe this is a parsing error, as when I changed the if statements to have an explicit check; i.e. if d.getVar("IMA", True) == "1" or d.getVar("MODSIGN", True) == "1". I got the correct result.

I have submitted a pull request, with a fix for this.

#60

Out-Of-Tree module fails to probe: "Required key not available"

Hello!

I'm have an out-of-tree kernel module that I'm including in my image. I'm following the out-of-tree modules guide that's included in the Yocto kernel development manual to include it properly in my build.

I get the following error when trying to probe this module:

modprobe: ERROR: could not insert 'my-custom-module': Required key not available

I have the modsign and ima distro features enabled and I'm including linux-yocto-integrity.inc in my kernel recipe. I would expect this error for a module that I did not build with the rest of my image, but this module was built as a recipe along with my kernel, so I was hoping this module would also be signed.

Would it be possible to append the module.bbclass class that's provided by OpenEmbedded Core to include a module signing task? If not, would the correct approach be to create a new signed-module.bbclass that inherits from module.bbclass that includes the signing step?

I was trying to hack on this idea last night but I'm unfamiliar with how to sign kernel modules. Thanks for your help!

Grub embeded config does not always reflet the variable GRUB_SIGN_VERIFY_STRICT

The grub embeded configuration can lead to a cache contamination. Here is how we can reproduce this:

Run a first build with GRUB_SIGN_VERIFY_STRICT=1, this lead a perfectly valid grub image which will fail to load if the .cfg.sig is not found.
Run a second build, but change GRUB_SIGN_VERIFY_STRICT=0. This will produce an image which will still fail if the .cfg.sig is not found. More over, your SSTATE will contains the broken image since the hash is computed with the GRUB_SIGN_VERIFY_STRICT=0, but the resulting binary will try to load the signature file.

Failed to sign RPM packages: rpmsign: --signfiles: unknown option

Reproduce steps:
$ git clone git://git.yoctoproject.org/poky
$ git clone git://git.openembedded.org/meta-openembedded
$ git clone https://github.com/jiazhang0/meta-secure-core
$ cd poky; . ./oe-init-build-env ../build
$ echo 'DISTRO_FEATURES_append += "ima"' >> conf/local.conf

Add those layers to conf/bblayers.conf:
/ala-lpggp51/wfan/yocto/meta-secure-core/meta-efi-secure-boot
/ala-lpggp51/wfan/yocto/meta-secure-core/meta-encrypted-storage
/ala-lpggp51/wfan/yocto/meta-secure-core/meta-integrity
/ala-lpggp51/wfan/yocto/meta-secure-core/meta-signing-key
/ala-lpggp51/wfan/yocto/meta-secure-core/meta-tpm
/ala-lpggp51/wfan/yocto/meta-secure-core/meta-tpm2
/ala-lpggp51/wfan/yocto/meta-openembedded/meta-oe
/ala-lpggp51/wfan/yocto/meta-openembedded/meta-perl \

$ bitbake linux-yocto

ERROR: shadow-securetty-4.2.1-r3 do_package_write_rpm: Function failed: Failed to sign RPM packages: rpmsign: --signfiles: unknown option
ERROR: update-rc.d-0.7-r5 do_package_write_rpm: Function failed: Failed to sign RPM packages: rpmsign: --signfiles: unknown option

Hosting at yoctoproject.org?

Thank you for the work on this layer. Do you have a plan to move it to a hosting place where it will look less like a personal project, like yoctoproject.org ? I' asking because every person I know looking at the layer for the first time is wondering if it is a legitimate, serious project, if it is the reference repository and not just a personal fork of someone.

Have you heard such concerns before? Is there any plan of migration?

Use grub-efi without SELoader

When UEFI_SELOADER=0 is set, it is not possible to use the the wks plugin bootimg-efi to install grub. The layer change the grub image from grub-efi-bootx64.efi to grubx64.efi. This is probably valid if SELoader is used, but I think the layer should leave the the grub image name to its default if SELoader is not used.

shim fails to build with qemux86

I got the build error even build it with:

setarch linux32 ${MAKE} ${EXTRA_OEMAKE} ARCH=ia32

Looks the shim can't be built with i586-poky-linux-gcc. Any suggestion to fix it? Or just update the COMPATIBLE_HOST to support x86-64 only?

oky-linux/shim/12+gitAUTOINC+5202f80c32-r0/vendor_cert.cer" -c -o security_policy.o security_policy.c
| /tmp/ccvE99ZV.s: Assembler messages:
| /tmp/ccvE99ZV.s:268: Error: bad register name %rsp)' | /tmp/ccvE99ZV.s:269: Error: bad register name %rdi'
| /tmp/ccvE99ZV.s:270: Error: bad register name %rsi' | /tmp/ccvE99ZV.s:271: Error: bad register name %r10'
| /tmp/ccvE99ZV.s:272: Error: bad register name %rsp' | /tmp/ccvE99ZV.s:273: Error: bad register name %rax'
| /tmp/ccvE99ZV.s:274: Error: bad register name %r10' | /tmp/ccvE99ZV.s:275: Error: bad register name %rsp'
| /tmp/ccvE99ZV.s:276: Error: bad register name %rax' | /tmp/ccvE99ZV.s:277: Error: bad register name %r10'
| /tmp/ccvE99ZV.s:278: Error: bad register name %r11' | /tmp/ccvE99ZV.s:279: Error: bad register name %r11'
| /tmp/ccvE99ZV.s:280: Error: bad register name %r11' | /tmp/ccvE99ZV.s:282: Error: bad register name %rdi'
| /tmp/ccvE99ZV.s:283: Error: bad register name %rcx' | /tmp/ccvE99ZV.s:284: Error: bad register name %rdx'
| /tmp/ccvE99ZV.s:285: Error: bad register name %r8' | /tmp/ccvE99ZV.s:286: Error: bad register name %r9'
| /tmp/ccvE99ZV.s:287: Error: bad register name %r10' | /tmp/ccvE99ZV.s:288: Error: invalid instruction suffix for call'
| /tmp/ccvE99ZV.s:289: Error: bad register name %rsp)' | /tmp/ccvE99ZV.s:290: Error: bad register name %r11'
| /tmp/ccvE99ZV.s:291: Error: bad register name %rsi' | /tmp/ccvE99ZV.s:292: Error: bad register name %rdi'
| /tmp/ccvE99ZV.s:297: Error: bad register name %rdi' | /tmp/ccvE99ZV.s:298: Error: bad register name %rsi'
| /tmp/ccvE99ZV.s:299: Error: bad register name %rsp' | /tmp/ccvE99ZV.s:300: Error: bad register name %rax'
| /tmp/ccvE99ZV.s:301: Error: bad register name %r10' | /tmp/ccvE99ZV.s:302: Error: bad register name %rsp'
| /tmp/ccvE99ZV.s:303: Error: bad register name %rax' | /tmp/ccvE99ZV.s:304: Error: bad register name %r10'
| /tmp/ccvE99ZV.s:305: Error: bad register name %r11' | /tmp/ccvE99ZV.s:306: Error: bad register name %r11'
| /tmp/ccvE99ZV.s:307: Error: bad register name %r11' | /tmp/ccvE99ZV.s:309: Error: bad register name %rcx'
| /tmp/ccvE99ZV.s:310: Error: bad register name %rdx' | /tmp/ccvE99ZV.s:311: Error: bad register name %r8'
| /tmp/ccvE99ZV.s:312: Error: invalid instruction suffix for call' | /tmp/ccvE99ZV.s:313: Error: bad register name %rsp)'
| /tmp/ccvE99ZV.s:314: Error: bad register name %r11' | /tmp/ccvE99ZV.s:315: Error: bad register name %rsi'
| /tmp/ccvE99ZV.s:316: Error: bad register name `%rdi'
| make[1]: *** [security_policy.o] Error 1

Fail to build sbsigntool

The commit fa5550d introduced a do_configure error:
| configure: error: cannot find the gnu-efi crt path

Packaging warnings with tpm2-tools on Yocto Thud

meta-tpm2/recipes-tpm/tpm2-tools/tpm2-tools.inc needs to inherit bash-completion.

Bitbake produces the following warnings otherwise:
WARNING: tpm2-tools-git.AUTOINC+e3a2fcf720-r0 do_package: QA Issue: tpm2-tools: Files/directories were installed but not shipped in any package:
/usr/share
/usr/share/bash-completion
/usr/share/bash-completion/completions
/usr/share/bash-completion/completions/tpm2_policyauthorize
/usr/share/bash-completion/completions/tpm2_makecredential
/usr/share/bash-completion/completions/tpm2_policysecret
...

building tpm2-tss, tpm2-tools, tpm2-abrmd on x86 platform.

Hi all,

I need to build the intel sample application using Yocto for x86 environment, which is having dependency on tpm2-tss, tpm2-tools, tpm2-abrmd.
I have added the .bb files into present build (my own project build) but is having issues with run time dependencies.
Can anybody help me to resolve the dependencies.

ERROR: ParseError at /home/builduser/Linux_am335x/trunk/build/meta-crestron/recipes-external/tpm2-tss/tpm2-tss_2.4.6.bb:51: unparsed line: 'FILES:libtss2-tcti-device = "${libdir}/libtss2-tcti-device.so.*"'

I work on 16.04.1-Ubuntu, I have tried installing the libraries using :

sudo apt-get install libtss2-utils
sudo apt-get install libtss2-dev
And found the libraries present at /usr/lib/x86_64-linux-gnu

Thanks in advance.

signed kernel and initramfs on different partition than grub

I like to place the signed kernel and initramfs files on different partition, but it seems that GRUB can not verify the signed files from there.
I tried to set root env variable. kernel is found, but this error occurs:

The file \bzImage loaded with the exit code 0xE
error: failed to verify kernel (hd0,gpt7)/bzImage
error: you need to load the kernel first

Create gatesgarth branch

It's time to create gatesgarth branch.

Is there any reason that packagegroup-tpm doesn't include the tpm-quote-tools package?

Failed to build grub-efi 2.04

The grub-efi has been upgraded to 2.04 in oe-core. After I updated the grub-efi bbapend in meta-efi-secure-boot and refreshed the patches, the grub-efi still failed to build:

../../grub-2.04/grub-core/loader/i386/linux.c: In function 'grub_verify_linux':
../../grub-2.04/grub-core/loader/i386/linux.c:651:10: error: too few arguments to function 'grub_file_open'
file = grub_file_open (path);
^
In file included from ../../grub-2.04/include/grub/err.h:23:0,
from ../../grub-2.04/include/grub/file.h:23,
from ../../grub-2.04/include/grub/loader.h:23,
from ../../grub-2.04/grub-core/loader/i386/linux.c:19:
../../grub-2.04/include/grub/file.h:209:25: note: declared here
grub_file_t EXPORT_FUNC(grub_file_open) (const char *name, enum grub_file_type type);
^

The grub_file_open function has been updated with 2 arguments now.

meta-encrypted-storage use case 2 luks-setup.sh issues

Hi Jiazhang0,

I am working through using meta-encrypted-storage following section use case 2: luks-setup.sh and have encountered some issues. I am using branch Sumo but this doesn't seem to have changed much since then afaik.

In luks-setup.sh, the parameters for tpm2_takeownership don't work for me. --LockPasswd i believe is --lock-passwd. If you do set a lock password tpm2_dictionarylockout fails. I think this is because setting a password requires the clearing and the settings of the password to be two commands. This worked for me:

Replacing
[ -n "$OPT_LOCKOUT_AUTH" ] && cmd="${cmd} --lockPasswd $OPT_LOCKOUT_AUTH"
With
[ -n "$OPT_LOCKOUT_AUTH" ] && cmd="${cmd} && tpm2_takeownership --lock-passwd $OPT_LOCKOUT_AUTH"

If a partition exists the script fails to wait for the user to acknowledge the overwrite of the existing partition and errors with Unable to create the LUKS partition on $luks_dev. This worked for me:

Replacing
! cryptsetup --type luks --cipher aes-xts-plain --hash sha256
--use-random --key-file "$passphrase" luksFormat "$luks_dev" &&
print_error "Unable to create the LUKS partition on $luks_dev" &&
return 1

With
cmd="cryptsetup --type luks --cipher aes-xts-plain --hash sha256
--use-random --key-file '$passphrase' luksFormat '$luks_dev'"
eval "$cmd"
if [ $? -ne 0 ]; then
print_error "Unable to create the LUKS partition on $luks_dev"
return 1
fi

Once the LUKS partition is created, the next step in the guide Retrieve the passphrase errors out as below:

root@hwr-01:~# cryptfs-tpm2 -q unseal passphrase -P sha256 -o /tmp/passphrase
Wed Mar 27 01:27:59 UTC 2019: [INFO] Use tabrmd as the default tcti interface
Wed Mar 27 01:27:59 UTC 2019: [ERROR] Unable to find out the tabrmd tcti library
Wed Mar 27 01:27:59 UTC 2019: [ERROR] Unable to get the TPM PCR banks (0x80005)Wed Mar 27 01:27:59 UTC 2019: [ERROR] Unsupported PCR bank algorithm

Just wondering your thoughts on if I am missing something obvious or how to proceed with 3.

Kind Regards,
Ham.

Query reg. poky dunfell branch and meta-secure-core combination

In 'poky dunfell and meta-secure-core' combination seen multiple files/classes missing observation, and the same missing files(few) present in gatesgarth branch. So, would like to know thoughts on 'dunfell and meta-secure-core' combination.. does this supported? If not which LTS branch is supported? Please let me know.

tpm2-abrmd can't find option file

I'm not sure why the locations of the release vs git versions of the abrmd configuration files was re-organized (/etc/default/tpm2-abrmd) but bitbake can't find it anymore:

Build Configuration:
BB_VERSION           = "1.39.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "opensuse-42.3"
TARGET_SYS           = "arm-oe-linux-gnueabi"
MACHINE              = "raspberrypi3"
DISTRO               = "nodistro"
DISTRO_VERSION       = "nodistro.0"
TUNE_FEATURES        = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard cortexa7"
TARGET_FPU           = "hard"
meta-raspberrypi     = "master:b2da4618b0ac2ad7dbc26387cad4c03796f8a06e"
meta                 = "master:85981cbbf0ce48a6d82bc39248afa9540ca858d8"
meta-oe              
meta-python          
meta-perl            
meta-networking      = "master:52904e753532d095b14972fa03a25e7e24696159"
meta                 
meta-efi-secure-boot 
meta-encrypted-storage 
meta-ids             
meta-integrity       
meta-signing-key     
meta-tpm             
meta-tpm2            = "master:33ec1d1f82cc783fc9640d4105795d85f52213f9"
workspace            = "<unknown>:<unknown>"

Initialising tasks: 100% |##################################################################################################################| Time: 0:00:19
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: tpm2-abrmd-git.AUTOINC+c90cd599bb-r0 do_fetch: Failed to fetch URL file://tpm2-abrmd.default, attempting MIRRORS if available
ERROR: tpm2-abrmd-git.AUTOINC+c90cd599bb-r0 do_fetch: Fetcher failure: Unable to find file file://tpm2-abrmd.default anywhere. The paths that were searched were:
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd-git.AUTOINC+c90cd599bb/nodistro
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd/nodistro
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/files/nodistro
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd-git.AUTOINC+c90cd599bb/raspberrypi3
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd/raspberrypi3
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/files/raspberrypi3
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd-git.AUTOINC+c90cd599bb/armv7ve
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd/armv7ve
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/files/armv7ve
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd-git.AUTOINC+c90cd599bb/rpi
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd/rpi
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/files/rpi
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd-git.AUTOINC+c90cd599bb/arm
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd/arm
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/files/arm
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd-git.AUTOINC+c90cd599bb/
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/tpm2-abrmd/
    /opt/oe/configs/z/secure/rpi3-tpm2-secure-core/layers/meta-secure-core/meta-tpm2/recipes-tpm/tpm2-abrmd/files/
    /opt/Downloads
ERROR: tpm2-abrmd-git.AUTOINC+c90cd599bb-r0 do_fetch: Fetcher failure for URL: 'file://tpm2-abrmd.default'. Unable to fetch URL from any source.

Can we revert 0bb383b, or should I create a patch so it works again?

fails patch of grub 2.02 with current tips of warrior branch

ERROR: grub-efi-native-2.02-r0 do_patch: Command Error: 'quilt --quiltrc /srv/workspace/repo/poky-linux/build/tmp/work/x86_64-linux/grub-efi-native/2.02-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch mok2verify-support-to-verify-non-PE-file-with-PKCS-7.patch
patching file grub-core/Makefile.core.def
Hunk #1 succeeded at 1754 (offset -116 lines).
patching file grub-core/commands/boot.c
patching file grub-core/gfxmenu/gui_label.c
patching file grub-core/lib/efi/mok2verify.c
patching file grub-core/loader/i386/linux.c
Hunk #1 FAILED at 36.
Hunk #2 succeeded at 673 (offset 38 lines).
Hunk #3 FAILED at 706.
Hunk #4 succeeded at 1181 (offset 18 lines).
2 out of 4 hunks FAILED -- rejects in file grub-core/loader/i386/linux.c
patching file grub-core/loader/linux.c
patching file grub-core/normal/main.c
patching file grub-core/normal/menu.c
Hunk #2 succeeded at 775 (offset -1 lines).
patching file grub-core/normal/menu_text.c
patching file include/grub/efi/mok2verify.h
Patch mok2verify-support-to-verify-non-PE-file-with-PKCS-7.patch does not apply (enforce with -f)
ERROR: grub-efi-native-2.02-r0 do_patch:
ERROR: grub-efi-native-2.02-r0 do_patch: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: /srv/workspace/repo/poky-linux/build/tmp/work/x86_64-linux/grub-efi-native/2.02-r0/temp/log.do_patch.6005
ERROR: Task (virtual:native:/srv/workspace/repo/poky-linux/build/../layers/poky/meta/recipes-bsp/grub/grub-efi_2.02.bb:do_patch) failed with exit code '1'

poky is sync to tip of warrior branch at commit 01b8a8b54bc569e5ef3f5e6fc6abcee365ab25d9
meta-secure-core is sync to tip of master at commit 1275424

Setting GRUB_SIGN_VERIFY fail at deploy

When setting the variable GRUB_SIGN_VERIFY=0 the deploy task fail since it try to deploy the signature file. How ever, those files are not generated since the variable GRUB_SIGN_VERIFY is set to 0.

ima key is encrypted

x509_ima.key file is encrypted. Could you please either update it to contain raw key or provide a password.

efitools with digicert

Has anyone used efitools together with DigiCert ?

I am using the sing-efi-sig-list tool that is built by the efitools recipe and the certificates come from digicert.

I have setup some digicert environments and the OPENSSL_CONF variable.
For testing purposes, the openssl configuration file among other things contain this line
dynamic_path = /usr/lib/engines-1.1/libpkcs11.so
and this is the command that is called sign-efi-sig-list -t "<some_time>" -e pkcs11 -c "/path/to/cert.pub" -k "private_key_url" PK PK.esl PK.auth

the sign-efi-sig-list is available in the recipe-sysroot-native. however when I used this tool from the recipe-sysroot-native I received this error
.../poky/build/tmp/work/x86_64-linux/openssl-native/1.1.1l-r0/recipe-sysroot-native/usr/lib/engines-1.1/pkcs11.so: cannot open shared object file: No such file or directory

how I can solve this, since libp11 depends on openssl...

I found it a bit strange that even after overriding the openssl_conf variable, the tool still targets "openssl-native/1.1.1l-r0/recipe-sysroot-native/usr/lib/engines-1.1/pkcs11.so"

I have also tried signing the ESL using the host sign-efi-sig-list and it worked...

Secureboot fails to boot with error "Verification requested but nobody cares"

Hi All,
I have been trying to enable secure boot for yocto dunfell branch with meta-secure-core's gatesgarth branch.

I am able to build and boot successfully in non secureboot mode but when secureboot is enabled below error occurs while grub is loaded and boot entry selected
error: "Verification requested but nobody cares: /bzImage"

I googled for solution but geeks have seen this issue in grub-2.06 but I am having grub-2.04 version , though i tried using 'check signatures = enforce' in grun environment it is not working so I am stuck with this issue.

Please help me to resolve the isue.

Thanks and Regards
Pavan

util-linux package name extension causes build error

The package name extension to util-linux-switch_root.static causes a build error in my environment (based on poky pyro). As far as I know, the '_' character is used as separator in yocto, therefore it should not be used in a package name.
In the attached patch, I replaed the '_' with a '-', which fixed the build error. I'm not sure, if the '-' is the best choise, so maybe another replacement is also possible (allowed characters: [a-z0-9.+-]).

0001-util-linux-Fix-package-name-extension.patch.txt

tpm2_tss stack is missing TSS FAPI library

HI All,

I have made use of the recipe tpm2-tss_2.4.6.bb for integrating TPM2-TSS stack. On building I am not getting any files or library for FAPI library. Is the recipe lacking support for FAPI

Reg. build issue 'secure-core-image-initramfs-1.0-r0 do_rootfs: Could not invoke dnf. Command..'

Hi All,

Am facing secure-core-image build issue with mention error, any thoughts would be appreciated, thanks in advance!
Let me know if any further details required on same.

Best Regards,
Loki

// Logs:

WARNING: linux-yocto-5.4.219+gitAUTOINC+7e9781b04d_35826e154e-r0 do_kernel_configcheck: [kernel config]: This BSP sets config options that are not offered anywhere within this kernel:

CONFIG_IMA_TEMPLATE

ERROR: secure-core-image-initramfs-1.0-r0 do_rootfs: Could not invoke dnf. Command '/home/dell/build4/dunfell_poky/poky/build/tmp/work/qemux86_64-poky-linux/secure-core-image-initramfs/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /home/dell/build4/dunfell_poky/poky/build/tmp/work/qemux86_64-poky-linux/secure-core-image-initramfs/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/home/dell/build4/dunfell_poky/poky/build/tmp/work/qemux86_64-poky-linux/secure-core-image-initramfs/1.0-r0/rootfs/etc/yum.repos.d --installroot=/home/dell/build4/dunfell_poky/poky/build/tmp/work/qemux86_64-poky-linux/secure-core-image-initramfs/1.0-r0/rootfs --setopt=logdir=/home/dell/build4/dunfell_poky/poky/build/tmp/work/qemux86_64-poky-linux/secure-core-image-initramfs/1.0-r0/temp --repofrompath=oe-repo,/home/dell/build4/dunfell_poky/poky/build/tmp/work/qemux86_64-poky-linux/secure-core-image-initramfs/1.0-r0/oe-rootfs-repo -x busybox-syslog --setopt=gpgcheck=True install base-passwd busybox initrdscripts-secure-core packagegroup-ima-initramfs packagegroup-luks-initramfs packagegroup-tpm2-initramfs run-postinsts' returned 1:
DNF version: 4.2.2
cachedir: /home/dell/build4/dunfell_poky/poky/build/tmp/work/qemux86_64-poky-linux/secure-core-image-initramfs/1.0-r0/rootfs/var/cache/dnf
Added oe-repo repo from /home/dell/build4/dunfell_poky/poky/build/tmp/work/qemux86_64-poky-linux/secure-core-image-initramfs/1.0-r0/oe-rootfs-repo
repo: using cache for: oe-repo
not found other for:
not found modules for:
not found deltainfo for:
not found updateinfo for:
oe-repo: using metadata from Thu 08 Dec 2022 10:47:39 PM UTC.
No module defaults found
Excludes in dnf.conf: busybox-syslog
No match for argument: base-passwd
No match for argument: busybox
No match for argument: initrdscripts-secure-core
No match for argument: packagegroup-ima-initramfs
No match for argument: packagegroup-luks-initramfs
No match for argument: packagegroup-tpm2-initramfs
No match for argument: run-postinsts
Error: Unable to find a match

ERROR: Logfile of failure stored in: /home/dell/build4/dunfell_poky/poky/build/tmp/work/qemux86_64-poky-linux/secure-core-image-initramfs/1.0-r0/temp/log.do_rootfs.939896
ERROR: Task (/home/dell/build4/dunfell_poky/poky/meta-secure-core/meta/recipes-core/images/secure-core-image-initramfs.bb:do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4703 tasks of which 4436 didn't need to be rerun and 1 failed.
..

add LAYERSERIES_COMPAT for dunfell

Hi,
been using meta-secure-core with yocto dunfell and it's not compatible by layer.conf
LAYERSERIES_COMPAT_XXX = "thud warrior zeus dunfell"
please add.
thx, by the way meta-secure-core is very cool!

fails patch of grub 2.04 with dunfell branch

poky dunfell branch breaks patch application of
meta-efi-secure-boot/recipes-bsp/grub/grub-efi/0001-grub-verify-Add-strict_security-variable.patch
starting with poky commit c55481b8066a32afefdd4404b7ce5a7e8ebbb7cd which has a number of CVE patches.
poky tag 'dunfell-23.0.13' appears to build, but poky tag 'dunfell-23.0.14' does not.

Make fails: missing resourcemgr.service

I have a clean build pulled just this week from the Sumo branch. The target is aarch62 for the raspberryPI 3 64 bit user space target. This is a systemd target not sysvinit. The build completed successfully after which I added the packagegroup-security-tpm2 package. Now I am getting the following build failure. I checked the package group and see the resourcemgr is part of the build. Don't know where to go with this... Thanks.

NOTE: Executing RunQueue Tasks
ERROR: tpm2.0-tss-1.3.0-r0 do_patch: Function failed: fix_systemd_unit (log file is located at /home/rpi/tmp/work/aarch64-poky-linux/tpm2.0-tss/1.3.0-r0/temp/log.do_patch.10164)
ERROR: Logfile of failure stored in: /home/rpi/tmp/work/aarch64-poky-linux/tpm2.0-tss/1.3.0-r0/temp/log.do_patch.10164
Log data follows:
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are ['/home/MCA_RDP_SRV/poky-pi/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot']
| NOTE: Installed into sysroot: []
| NOTE: Skipping as already exists in sysroot: ['quilt-native']
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing python function do_patch
| DEBUG: Executing python function patch_do_patch
| DEBUG: Searching for ax_pthread.m4 in paths:
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss-1.3.0/poky
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss/poky
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/files/poky
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss-1.3.0/aarch64
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss/aarch64
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/files/aarch64
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss-1.3.0/raspberrypi3-64
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss/raspberrypi3-64
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/files/raspberrypi3-64
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss-1.3.0/raspberrypi3
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss/raspberrypi3
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/files/raspberrypi3
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss-1.3.0/rpi
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss/rpi
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/files/rpi
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss-1.3.0/aarch64
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss/aarch64
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/files/aarch64
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss-1.3.0/
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss/
| /home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/files/
| DEBUG: Python function patch_do_patch finished
| DEBUG: Python function do_patch finished
| DEBUG: SITE files ['endian-little', 'bit-64', 'arm-common', 'arm-64', 'common-linux', 'common-glibc', 'aarch64-linux', 'common']
| DEBUG: Executing shell function fix_systemd_unit
| sed: can't read /home/rpi/tmp/work/aarch64-poky-linux/tpm2.0-tss/1.3.0-r0/git/contrib/resourcemgr.service: No such file or directory
| WARNING: exit code 2 from a shell command.
| ERROR: Function failed: fix_systemd_unit (log file is located at /home/rpi/tmp/work/aarch64-poky-linux/tpm2.0-tss/1.3.0-r0/temp/log.do_patch.10164)
ERROR: Task (/home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss_1.3.0.bb:do_patch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2935 tasks of which 2934 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/home/MCA_RDP_SRV/poky-pi/meta-security/meta-tpm/recipes-tpm/tpm2.0-tss/tpm2.0-tss_1.3.0.bb:do_patch

Comment from tpm2-tss team.....

@AndreasFuchsSIT
Member
AndreasFuchsSIT commented 10 minutes ago
Hi...
First, tpm2-tss v1.3.0 is quite old by now. I highly recommend going for the 2.1 release now.

Second, the build scripts you're using there are attempting to get to the resource manager which was split out and reimplemented into a second (independent) project.

So these are errors in the bitbake recepies of the distro you're attempting to build. Has nothing to do with this project here, sorry.

Try to get in touch with the author of the bitbake and also kindly ask them to move up to version 2.1 of tpm2-tss...

Thanks...

Is it possible to use this layer on devices with u-boot?

Is it possible to use this layer on devices with u-boot?
If yes, which features are compatible?

shim_git.bb & efitools.inc Compile Failing

Patch file://0001-console.c-Fix-compilation-against-latest-usr-include.patch not being applied correctly resulting in the below error.

| console.c:363:5: error: 'EFI_WARN_UNKNOWN_GLYPH' undeclared here (not in a function); did you mean 'EFI_WARN_UNKOWN_GLYPH'?
|   {  EFI_WARN_UNKNOWN_GLYPH,     L"Warning Unknown Glyph"},
|      ^~~~~~~~~~~~~~~~~~~~~~
|      EFI_WARN_UNKOWN_GLYPH
| <builtin>: recipe for target 'console.o' failed
| make[1]: *** [console.o] Error 1
| make[1]: Leaving directory '/home/kwalsh/workspace/images/hawkeye_secure/build/tmp/work/corei7-64-poky-linux/shim/12+gitAUTOINC+5202f80c32-r0/git/lib'
| Makefile:223: recipe for target 'lib/lib.a' failed
| make: *** [lib/lib.a] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/kwalsh/workspace/images/hawkeye_secure/build/tmp/work/corei7-64-poky-linux/shim/12+gitAUTOINC+5202f80c32-r0/temp/log.do_compile.24762)
ERROR: Task (/home/kwalsh/workspace/images/hawkeye_secure/sources/meta-secure-core/meta-efi-secure-boot/recipes-bsp/shim/shim_git.bb:do_compile) failed with exit code '1'

However the following works file://0001-console.c-Fix-compilation-against-latest-usr-include.patch;apply=0 when used in shim_git.bb and efitools.inc. Also 100% sure what apply=0 syntax means, maybe don't apply this patch? If so, not sure this workaround is valid.

Note on build, attempting to build a warrior build using the gatesgarth branch from this repository.

Build not working with ARM

Hi there,
I have been trying to add meta-secure-core to a current project but it does not seem to be compatible with ARM.

ERROR: Nothing RPROVIDES 'grub-efi' (but /build/layers/poky/meta/recipes-core/packagegroups/packagegroup-core-boot.bb RDEPENDS on or otherwise requires it)
grub-efi was skipped: grub-efi is incompatible with target arm

Is there any way I would be able to get this working with ARM?

Kirkstone support

Right now the master branch just supports honister. We're trying to update our system to kirkstone for LTS reasons. The bits of meta-secure-core we need (meta-tpm2, meta-efi-secure-boot, meta-encrypted-storage, meta-signing-key) seem to work fine. Can kirkstone be added to the LAYERSERIES_COMPAT variables?

Cross compiling fails when libtss_esys.a is used to build application using ESAPI library

HI All,

I have used the tpm2-tss recipe to build the stack. The stack gets build properly and creates respective library. I wanted to use ESAPI library to create an application. So I used libtss2_esys.a to build the application but the build failed as the lib has some undefined symbols which are related to openssl. So how to define those symbols in the TCG stack and regenerate proper library.
My application is build using cmake and my distro is ST openstlinux.

Below is the error I am getting during build.

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: VERBOSE=1 cmake --build /home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/build --target all --
| [1/2] /home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot-native/usr/bin/arm-ostl-linux-gnueabi/arm-ostl-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0=/usr/src/debug/tpm-test/1.0-r0 -fdebug-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0=/usr/src/debug/tpm-test/1.0-r0 -fdebug-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot= -fdebug-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot-native= -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot -MD -MT CMakeFiles/tpm-test.dir/tpm2_fapi.o -MF CMakeFiles/tpm-test.dir/tpm2_fapi.o.d -o CMakeFiles/tpm-test.dir/tpm2_fapi.o -c ../tpm2_fapi.c
| [2/2] : && /home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot-native/usr/bin/arm-ostl-linux-gnueabi/arm-ostl-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0=/usr/src/debug/tpm-test/1.0-r0 -fdebug-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0=/usr/src/debug/tpm-test/1.0-r0 -fdebug-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot= -fdebug-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot-native= -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic CMakeFiles/tpm-test.dir/tpm2_fapi.o -o tpm-test -Wl,-Bstatic -ltss2-esys -ltss2-rc -Wl,-Bdynamic -ldl && :
| FAILED: tpm-test
| : && /home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot-native/usr/bin/arm-ostl-linux-gnueabi/arm-ostl-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0=/usr/src/debug/tpm-test/1.0-r0 -fdebug-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0=/usr/src/debug/tpm-test/1.0-r0 -fdebug-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot= -fdebug-prefix-map=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot-native= -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic CMakeFiles/tpm-test.dir/tpm2_fapi.o -o tpm-test -Wl,-Bstatic -ltss2-esys -ltss2-rc -Wl,-Bdynamic -ldl && :
| /home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot-native/usr/bin/arm-ostl-linux-gnueabi/../../libexec/arm-ostl-linux-gnueabi/gcc/arm-ostl-linux-gnueabi/9.3.0/ld: /home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot/usr/lib/libtss2-esys.a(libtss2_esys_la-esys_context.o): in function Esys_Initialize': | /usr/src/debug/tpm2-tss/3.2.0-r0/build/../tpm2-tss-3.2.0/src/tss2-esys/esys_context.c:61: undefined reference to Tss2_Sys_GetContextSize'
| /home/eaton/workspace/edge-linux-yocto/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/tpm-test/1.0-r0/recipe-sysroot-native/usr/bin/arm-ostl-linux-gnueabi/../../libexec/arm-ostl-linux-gnueabi/gcc/arm-ostl-linux-gnueabi/9.3.0/ld: /usr/src/debug/tpm2-tss/3.2.0-r0/build/../tpm2-tss-3.2.0/src/tss2-esys/esys_context.c:73: undefined reference to `Tss2_Sys_Initialize'

Secureboot - which certificate and from where it is used

As per the readme - "Whenever this feature is enabled, the bootloader and kernel will be signed automatically during the build, implying the signed binaries are contained by the resulting RPM and rootfs image."
But which certificate and from where it is used ? As i have to copy them to DB of the system.