f0b4bfd65d
Fix the below yocto compliance issue:
INFO: test_signatures (common.CommonCheckLayer)
INFO: ... FAIL
Stdout:
Loading cache...done.
Loaded 1645 entries from dependency cache.
INFO: Traceback (most recent call last):
File "/build/layers/oe-core/scripts/lib/checklayer/cases/common.py", line 81, in test_signatures
self.fail('Adding layer %s changed signatures.\n%s' % (self.tc.layer['name'], msg))
AssertionError: Adding layer meta-tpm2 changed signatures.
107 signatures changed, initial differences (first hash before, second after):
linux-yocto:do_fetch: c57d21fe3def6c9959bbfd487420c6845d4c720d7e72aa5cf1e11af324ba5d45 -> 3b1f37d37a491287fa36bc0f1e3d65d6ff2af899d173f684600a8fbff643b695
bitbake-diffsigs --task linux-yocto do_fetch --signature c57d21fe3def6c9959bbfd487420c6845d4c720d7e72aa5cf1e11af324ba5d45 3b1f37d37a491287fa36bc0f1e3d65d6ff2af899d173f684600a8fbff643b695
NOTE: Starting bitbake server...
basehash changed from 847e3bff305906a9ad386dc76de2fc2dfdaf7bc2b7dfb15bb2cd17dd9ba1f8bd to a522d659617359c730eac2f149a171ddd030959af67d1d3c3606cc9adba7db08
Variable SRC_URI value changed:
@@ -1 +1,2 @@
-git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}
+git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA} ${@bb.utils.contains('DISTRO_FEATURES', 'tpm2', 'file://tpm2.scc file://tpm2.cfg', '', d)}
+DISTRO_FEATURES{tpm2} = Unset
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
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.