Date   

Re: Keep .bbappend for older Yocto version

Jonas Vautherin
 

It does help, yes!
Thanks a lot!

On Thu, 18 Feb 2021, 12:24 , <Mikko.Rapeli@...> wrote:
Hi,

On Wed, Feb 17, 2021 at 12:02:26AM +0100, Jonas Vautherin wrote:
> Good evening,
>
> I am using Yocto Gatesgarth, and I was just updating a layer that was
> written for Dunfell. In the `conf/layer.conf`, I can simply add
> "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:
>
> ```
> LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
> ```
>
> However, this does not seem to work for a `.bbappend`. Let me use this
> particular layer as an example: it is a BSP that defines
> `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define
> `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I
> would like it to use the former, and when building with Gatesgarth, I would
> like it to use the latter.
>
> However, if I keep both `linux-yocto_4.19.bbappend`
> and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails
> with:
>
> ```
> ERROR: No recipes in default available for:
>   /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
> ```
>
> Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.
>
> Is there a way to keep both `*.bbappend` and have Yocto ignore the ones
> that do not correspond to its version? Or would that be bad practice anyway?

What I do in cases like this:

 * check and decide if BSP layer can be update to be fully compatible with new yocto
   version, by asking from maintainers of the BSP layer and HW vendors
   (usual answer is 'not this year, maybe next' or 'if you pay?', if you are lucky
    they will say 'just use the correct branch')

 * check if simple patches can update BSP layer to be compatible with new yocto
   version, if this involves Linux kernel, libdrm etc major version changes it
   might not work

Quite often, I keep using the BSP SW stack from old yocto release with only minimal
changes. For this to work, I make the minimal modifications needed to support building
with new yocto version like modify LAYERSERIES_COMPAT and adapt bbclasses, then copy
the needed old recipes from previous yocto version over the the BSP layer to be
maintained there by the BSP SW maintainers. What helps a lot, is that you have
reviewed what SW components you need to use from BSP SW meta layer and you have
BBMASK'ed away all recipes and bbappends which your product and its distro
configuration does not need.

Often BSP layers are full of examples, prototypes, or just plain weird changes
to high level SW components like gstreamer, systemd, openssl or openssh which your
product might not need (e.g. is prefectly fine with the poky version of the recipe).
These BSP side changes make yocto updates much more difficult and versioned dependencies
from BSP to poky are too complex and difficult to resolve easily. Thus look
for minimizing the impact of the BSP SW stack, keep it unchanged apart from minimal
bitbake and bbclass fixes, and update the rest.

For security and other updates, the BSP SW stack needs to be handled separately.

Hope this helps,

-Mikko


Re: #av1 #armv6 #raspberrypi #neon #av1 #armv6 #raspberrypi #neon

safouane maaloul
 



Le jeu. 18 févr. 2021 à 12:44, safouane maaloul <maaloulsafouane@...> a écrit :
This is my build configuration :
Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "raspberrypi0-wifi"
DISTRO               = "poky"
DISTRO_VERSION       = "3.1.5"
TUNE_FEATURES        = "arm armv6 vfp arm1176jzfs callconvention-hard"
TARGET_FPU           = "hard"
meta
meta-poky
meta-yocto-bsp       = "dunfell:7ea41de13774675828239b7738d3f5d70be8b1af"
meta-oe
meta-multimedia
meta-networking
meta-python          = "dunfell:5bba79488b7d393d2258d6e917f7bf7b0d7c4073"
meta-raspberrypi     = "dunfell:987993209716302eb8f314f69a2a3340555f94d8"
meta-gstreamer1.0    = "dunfell:b489b1ba084544d9c4c08f7c3b3d1c37ffa53c51"

Best regards,

Safouane

Le mer. 17 févr. 2021 à 13:24, Zoran Stojsavljevic <zoran.stojsavljevic@...> a écrit :
So, what is your MACHINE variable set to?

Maybe knowing that, somebody can help.

Zee


--
SAFOUANE MAALOUL


--
SAFOUANE MAALOUL


Re: #av1 #armv6 #raspberrypi #neon #av1 #armv6 #raspberrypi #neon

safouane maaloul
 



Le mer. 17 févr. 2021 à 13:18, safouane maaloul <maaloulsafouane@...> a écrit :
Yeah i know the problem is i am using armv6 (raspberry pi zero w) and there isn’t that option so i need a workaround ?

Best regards,

Safouane.Maaloul  

Le mer. 17 févr. 2021 à 13:13, Zoran Stojsavljevic <zoran.stojsavljevic@...> a écrit :
> ...compile  error "compiling simd-neon.h requires -mfpu=
> neon or equivalent"...

IIRC, this has to do with the platform chosen.

I know that for armv7 there are two types of machine:
MACHINE ?= "armv7" (FP library in SW)
MACHINE ?= "armv7hf" (hard FP = neon)

I guess you did set up the MACHINE variable with postfix fp, most probably.

My 2 cent worth answer,
Zee
_______


On Wed, Feb 17, 2021 at 11:00 AM safouane maaloul
<maaloulsafouane@...> wrote:
>
> Hello folks,
>
> I have an issue integrating av1  in yocto. I get the  compile  error "compiling simd-neon.h requires -mfpu=neon or equivalent". The problem is that i use armv6 (raspberrypi zero w) so i can't exactly do that. Anyone have a workaround this problem ?
>
> Best regards,
>
> Safouane.Maaloul
>
>
--
SAFOUANE MAALOUL


--
SAFOUANE MAALOUL


[meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.5.0

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 2dcde74..39cbc10 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -2,7 +2,7 @@ LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.4.0"
+PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc

inherit cmake
--
2.17.1


[meta-zephyr][PATCH 1/2] zephyr: upgrade 2.5.0-rc4 -> 2.5.0

Naveen Saini
 

Release notes:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v2.5.0

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
...r-kernel-src-2.5.0-rc4.inc => zephyr-kernel-src-2.5.0.inc} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename recipes-kernel/zephyr-kernel/{zephyr-kernel-src-2.5.0-rc4.inc => zephyr-kernel-src-2.5.0.inc} (82%)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc4.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
similarity index 82%
rename from recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc4.inc
rename to recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
index b8aa4dc..6350d86 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc4.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
@@ -1,5 +1,5 @@
SRCREV_FORMAT = "default_cmsis"
-SRCREV_default = "v2.5.0-rc4"
+SRCREV_default = "fe7c2efca800a0cf1bccf23aefe08b3c4beb88bf"
SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
SRCREV_nordic = "f3434da6446380fcdd426dbe2866af21d0d549b6"
SRCREV_stm32 = "cc8731dba4fd9c57d7fe8ea6149828b89c2bd635"
@@ -7,4 +7,4 @@ SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"

-PV = "2.5.0-rc4+git${SRCPV}"
+PV = "2.5.0+git${SRCPV}"
--
2.17.1


Re: QA notification for completed autobuilder build (yocto-3.2.2.rc1)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.2.2.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Monday, February 22.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf
Of Pokybuild User
Sent: Wednesday, 17 February, 2021 1:44 AM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.2.2.rc1)


A build flagged for QA (yocto-3.2.2.rc1) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2.2.rc1


Build hash information:

bitbake: 0a3bf681530bd63fc0036ca81ef868ab53fde56c
meta-arm: aa63e31b6edb5197764c21434219050ab51f0fbd
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: 1d866c58534eb1d317b7a674c6e6c57ab9594fb0
meta-kernel: f793168bd19af3d8c5a260dd35f387ed9a31794b
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: ebaaee50cb3ac75112827f935c48affaf622ce7f
poky: d5d6286a66f46f4523e35e0e3f20cd7396195fdc



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org



[PATCH yocto-autobuilder2] schedulers: add appropriate meta-arm branches to the release selector

Ross Burton
 

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
schedulers.py | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/schedulers.py b/schedulers.py
index dbf72c9..8479290 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -175,6 +175,7 @@ def parent_scheduler(target):
'branch': 'master',
'branch_poky': 'master',
'branch_bitbake': 'master',
+ 'branch_meta-arm': 'master',
'branch_meta-gplv2': 'master',
'branch_meta-intel': 'master',
'branch_meta-mingw': 'master',
@@ -184,6 +185,7 @@ def parent_scheduler(target):
'branch': 'master',
'branch_poky': 'master-next',
'branch_bitbake': 'master-next',
+ 'branch_meta-arm': 'master',
'branch_meta-gplv2': 'master',
'branch_meta-intel': 'master',
'branch_meta-mingw': 'master',
@@ -194,6 +196,7 @@ def parent_scheduler(target):
'branch_poky': 'ross/mut',
'repo_poky': 'git://git.yoctoproject.org/poky-contrib',
'branch_bitbake': 'master',
+ 'branch_meta-arm': 'master',
'branch_meta-gplv2': 'master',
'branch_meta-intel': 'master',
'branch_meta-mingw': 'master',
@@ -203,6 +206,7 @@ def parent_scheduler(target):
'branch': 'gatesgarth',
'branch_poky': 'gatesgarth',
'branch_bitbake': '1.48',
+ 'branch_meta-arm': 'gatesgarth',
'branch_meta-gplv2': 'gatesgarth',
'branch_meta-intel': 'gatesgarth',
'branch_meta-mingw': 'gatesgarth',
@@ -212,6 +216,7 @@ def parent_scheduler(target):
'branch': 'dunfell',
'branch_poky': 'dunfell',
'branch_bitbake': '1.46',
+ 'branch_meta-arm': 'dunfell',
'branch_meta-gplv2': 'dunfell',
'branch_meta-intel': 'dunfell',
'branch_meta-mingw': 'dunfell',
--=20
2.25.1


[PATCH yocto-autobuilder-helper] config: build and test SDKs when using package_deb

Ross Burton
 

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
config.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index ea2d86b..3286e57 100644
--- a/config.json
+++ b/config.json
@@ -580,8 +580,8 @@
"pkgman-deb-non-deb" : {
"MACHINE" : "qemux86",
"PACKAGE_CLASSES" : "package_deb",
- "BBTARGETS" : "core-image-sato core-image-sato-dev core-imag=
e-sato-sdk core-image-minimal core-image-minimal-dev",
- "SANITYTARGETS" : "core-image-minimal:do_testimage core-imag=
e-sato:do_testimage core-image-sato-sdk:do_testimage"
+ "BBTARGETS" : "core-image-sato core-image-sato-dev core-imag=
e-sato-sdk core-image-minimal core-image-minimal-dev core-image-sato:do_p=
opulate_sdk",
+ "SANITYTARGETS" : "core-image-minimal:do_testimage core-imag=
e-sato:do_testimage core-image-sato-sdk:do_testimage core-image-sato:do_t=
estsdk"
},
"pkgman-non-rpm" : {
"MACHINE" : "qemux86",
--=20
2.25.1


changing root password in readonly rootfs

Marek Belisko
 

Hi,

does anybody know if there is a way to have possibility to change root
pwd when readonly rootfs is used? I've added shadow package + overlay
/ect/shadow + /etc/passwd but chpasswd complains and changis is not
possible.

Thanks and BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


Re: Regarding Mender integration

U RAVI KUMAR <uppadaravi2511@...>
 

HI robert,

    Thank you very much for your response.

Regards,
RAVI_UPPADA


On Wed, Feb 17, 2021 at 2:21 PM Robert Berger@... <robert.berger.yocto.user@...> wrote:
Hi,

Please see my comments in-line.

On 16/02/2021 19:48, U RAVI KUMAR wrote:
>     I have some issues while integrating the mender on the yocto
>     project.I have included meta-mener-core,meta-mender-raspberrypi
>     layers.And iam getting the following error:
>
>     ERROR: u-boot-1_2020.07-r0 do_patch: Command Error: 'quilt --quiltrc
>     /home/ravi_uppada/work/vm/sato/poky/build/tmp/work/raspberrypi4_64-poky-linux/u-boot/1_2020.07-r0/recipe-sysroot-native/etc/quiltrc
>     push' exited with 0  Output:
>     Applying patch 0001-configs-rpi-enable-mender-requirements.patch
>     patching file configs/rpi_0_w_defconfig
>     Hunk #1 FAILED at 19.

...

This looks like the patch you/mender try/tries to apply does not work
with your u-boot version.[0]

[0]
https://github.com/mendersoftware/meta-mender/tree/master/meta-mender-core/recipes-bsp/u-boot

Which Yocto version do you use?

Which Mender version do you use?

You could look into creating your own Mender integration[1] instead of
the mender class.

[1]
https://docs.mender.io/system-updates-yocto-project/board-integration/bootloader-support/u-boot/manual-u-boot-integration

I think the right place to ask Mender specific questions is here[2].

[2] https://hub.mender.io/

Regards,

Robert



Re: [meta-security] [PATCH 0/5] Some fixes for IMA/EVM

Dmitry Baryshkov
 

I suppose, patch 3 can be split into logical chunks.
Other patches are:

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

ср, 17 февр. 2021 г. в 17:09, Ming Liu <liu.ming50@gmail.com>:


From: Ming Liu <liu.ming50@gmail.com>

Ming Liu (5):
ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
initramfs-framework-ima: fix a wrong path
meta: refactor IMA/EVM sign rootfs
initramfs-framework-ima: let ima_enabled return 0
ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic

meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../initrdscripts/initramfs-framework-ima/ima | 3 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 +++++++++
.../ima-evm-utils/ima-evm-utils_git.bb | 1 +
6 files changed, 38 insertions(+), 21 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb

--
2.29.0



--
With best wishes
Dmitry


[meta-security] [PATCH 5/5] ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

Or else wic will fail without "--no-fstab-update" option.

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
meta-integrity/classes/ima-evm-rootfs.bbclass | 3 +++
1 file changed, 3 insertions(+)

diff --git a/meta-integrity/classes/ima-evm-rootfs.bbclass b/meta-integrity/classes/ima-evm-rootfs.bbclass
index 4359af0..0acd6e7 100644
--- a/meta-integrity/classes/ima-evm-rootfs.bbclass
+++ b/meta-integrity/classes/ima-evm-rootfs.bbclass
@@ -28,6 +28,9 @@ IMA_EVM_ROOTFS_HASHED ?= ". -depth 0 -false"
# the iversion flags (needed by IMA when allowing writing).
IMA_EVM_ROOTFS_IVERSION ?= ""

+# Avoid re-generating fstab when ima is enabled.
+WIC_CREATE_EXTRA_ARGS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'ima', ' --no-fstab-update', '', d)}"
+
ima_evm_sign_rootfs () {
cd ${IMAGE_ROOTFS}

--
2.29.0


[meta-security] [PATCH 4/5] initramfs-framework-ima: let ima_enabled return 0

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

Otherwise, ima script would not run as intended.

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
.../recipes-core/initrdscripts/initramfs-framework-ima/ima | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
index 16ed53f..cff26a3 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
@@ -6,6 +6,7 @@ ima_enabled() {
if [ "$bootparam_no_ima" = "true" ]; then
return 1
fi
+ return 0
}

ima_run() {
--
2.29.0


[meta-security] [PATCH 3/5] meta: refactor IMA/EVM sign rootfs

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

The current logic in ima-evm-rootfs.bbclass does not guarantee
ima_evm_sign_rootfs is the last function in IMAGE_PREPROCESS_COMMAND
by appending to it, for instance, if there are other "_append" being
used as it's the case in openembedded-core/meta/classes/image.bbclass:

| IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;' \
| if bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) \
| and not bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True,
| False, d) else ''} reproducible_final_image_task; "

and ima-evm-rootfs should be in IMAGE_CLASSES instead of in INHERIT
since that would impact all recipes but not only image recipes.

To fix the above issues, we introduce a ima_evm_sign_handler setting
IMA/EVM rootfs signing requirements/dependencies in event
bb.event.RecipePreFinalise, it checks 'ima' distro feature to decide if
IMA/EVM rootfs signing logic should be applied or not.

We also need split public keys to ima-evm-keys recipe, so it could be
added both in initramfs and rootfs, so initramfs recipe does not have to
inherit ima-evm-rootfs

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 30 ++++++++-----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 ++++++++++
4 files changed, 32 insertions(+), 20 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb

diff --git a/meta-integrity/README.md b/meta-integrity/README.md
index 4607948..5048fba 100644
--- a/meta-integrity/README.md
+++ b/meta-integrity/README.md
@@ -73,8 +73,10 @@ Adding the layer only enables IMA (see below regarding EVM) during
compilation of the Linux kernel. To also activate it when building
the image, enable image signing in the local.conf like this:

- INHERIT += "ima-evm-rootfs"
+ IMAGE_CLASSES += "ima-evm-rootfs"
IMA_EVM_KEY_DIR = "${INTEGRITY_BASE}/data/debug-keys"
+ IMA_EVM_PRIVKEY = "${IMA_EVM_KEY_DIR}/privkey_ima.pem"
+ IMA_EVM_X509 = "${IMA_EVM_KEY_DIR}/x509_ima.der"

This uses the default keys provided in the "data" directory of the layer.
Because everyone has access to these private keys, such an image
diff --git a/meta-integrity/classes/ima-evm-rootfs.bbclass b/meta-integrity/classes/ima-evm-rootfs.bbclass
index d6ade3b..4359af0 100644
--- a/meta-integrity/classes/ima-evm-rootfs.bbclass
+++ b/meta-integrity/classes/ima-evm-rootfs.bbclass
@@ -37,15 +37,6 @@ ima_evm_sign_rootfs () {
# reasons (including a change of the signing keys) without also
# re-running do_rootfs.

- # Copy file(s) which must be on the device. Note that
- # evmctl uses x509_evm.der also for "ima_verify", which is probably
- # a bug (should default to x509_ima.der). Does not matter for us
- # because we use the same key for both.
- install -d ./${sysconfdir}/keys
- rm -f ./${sysconfdir}/keys/x509_evm.der
- install "${IMA_EVM_X509}" ./${sysconfdir}/keys/x509_evm.der
- ln -sf x509_evm.der ./${sysconfdir}/keys/x509_ima.der
-
# Fix /etc/fstab: it must include the "i_version" mount option for
# those file systems where writing files is allowed, otherwise
# these changes will not get detected at runtime.
@@ -80,13 +71,16 @@ ima_evm_sign_rootfs () {
}

# Signing must run as late as possible in the do_rootfs task.
-# IMAGE_PREPROCESS_COMMAND runs after ROOTFS_POSTPROCESS_COMMAND, so
-# append (not prepend!) to IMAGE_PREPROCESS_COMMAND, and do it with
-# _append instead of += because _append gets evaluated later. In
-# particular, we must run after prelink_image in
-# IMAGE_PREPROCESS_COMMAND, because prelinking changes executables.
-
-IMAGE_PREPROCESS_COMMAND_append = " ima_evm_sign_rootfs ; "
+# To guarantee that, we append it to IMAGE_PREPROCESS_COMMAND in
+# RecipePreFinalise event handler, this ensures it's the last
+# function in IMAGE_PREPROCESS_COMMAND.
+python ima_evm_sign_handler () {
+ if not e.data or 'ima' not in e.data.getVar('DISTRO_FEATURES').split():
+ return

-# evmctl must have been installed first.
-do_rootfs[depends] += "ima-evm-utils-native:do_populate_sysroot"
+ e.data.appendVar('IMAGE_PREPROCESS_COMMAND', ' ima_evm_sign_rootfs; ')
+ e.data.appendVar('IMAGE_INSTALL', ' ima-evm-keys')
+ e.data.appendVarFlag('do_rootfs', 'depends', ' ima-evm-utils-native:do_populate_sysroot')
+}
+addhandler ima_evm_sign_handler
+ima_evm_sign_handler[eventmask] = "bb.event.RecipePreFinalise"
diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb
index dacdc8b..77f6f7c 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb
@@ -27,5 +27,5 @@ do_install () {

FILES_${PN} = "/init.d ${sysconfdir}"

-RDEPENDS_${PN} = "keyutils ${IMA_POLICY}"
+RDEPENDS_${PN} = "keyutils ima-evm-keys ${IMA_POLICY}"
RDEPENDS_${PN} += "initramfs-framework-base"
diff --git a/meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb b/meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb
new file mode 100644
index 0000000..62685bb
--- /dev/null
+++ b/meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb
@@ -0,0 +1,16 @@
+SUMMARY = "IMA/EMV public keys"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+inherit features_check
+REQUIRED_DISTRO_FEATURES = "ima"
+
+ALLOW_EMPTY_${PN} = "1"
+
+do_install () {
+ if [ -e "${IMA_EVM_X509}" ]; then
+ install -d ${D}/${sysconfdir}/keys
+ install "${IMA_EVM_X509}" ${D}${sysconfdir}/keys/x509_evm.der
+ lnr ${D}${sysconfdir}/keys/x509_evm.der ${D}${sysconfdir}/keys/x509_ima.der
+ fi
+}
--
2.29.0


[meta-security] [PATCH 2/5] initramfs-framework-ima: fix a wrong path

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

/etc/ima-policy > /etc/ima/ima-policy.

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
.../recipes-core/initrdscripts/initramfs-framework-ima/ima | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
index 8616f99..16ed53f 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
@@ -46,7 +46,7 @@ ima_run() {
# ("[Linux-ima-user] IMA policy loading via cat") and we get better error reporting when
# checking the write of each line. To minimize the risk of policy loading going wrong we
# also remove comments and blank lines ourselves.
- if ! (set -e; while read i; do if echo "$i" | grep -q -e '^#' -e '^ *$'; then debug "Skipping IMA policy: $i"; else debug "Writing IMA policy: $i"; if echo $i; then sleep ${bootparam_ima_delay:-0}; else fatal "Invalid line in IMA policy: $i"; exit 1; fi; fi; done) </etc/ima-policy >/sys/kernel/security/ima/policy; then
+ if ! (set -e; while read i; do if echo "$i" | grep -q -e '^#' -e '^ *$'; then debug "Skipping IMA policy: $i"; else debug "Writing IMA policy: $i"; if echo $i; then sleep ${bootparam_ima_delay:-0}; else fatal "Invalid line in IMA policy: $i"; exit 1; fi; fi; done) </etc/ima/ima-policy >/sys/kernel/security/ima/policy; then
fatal "Could not load IMA policy."
fi
}
--
2.29.0


[meta-security] [PATCH 1/5] ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

'ima' does not have to be in native DISTRO_FEATURES, unset it to avoid
sanity check, this fixes a following error:

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
.../recipes-security/ima-evm-utils/ima-evm-utils_git.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb
index 7f649c2..bd85583 100644
--- a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb
+++ b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb
@@ -26,6 +26,7 @@ S = "${WORKDIR}/git"
inherit pkgconfig autotools features_check

REQUIRED_DISTRO_FEATURES = "ima"
+REQUIRED_DISTRO_FEATURES_class-native = ""

EXTRA_OECONF_append_class-target = " --with-kernel-headers=${STAGING_KERNEL_BUILDDIR}"

--
2.29.0


[meta-security] [PATCH 0/5] Some fixes for IMA/EVM

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

Ming Liu (5):
ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
initramfs-framework-ima: fix a wrong path
meta: refactor IMA/EVM sign rootfs
initramfs-framework-ima: let ima_enabled return 0
ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic

meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../initrdscripts/initramfs-framework-ima/ima | 3 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 +++++++++
.../ima-evm-utils/ima-evm-utils_git.bb | 1 +
6 files changed, 38 insertions(+), 21 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb

--
2.29.0


Re: Timing a recipe

Richard Purdie
 

On Tue, 2021-02-16 at 11:43 -0800, rustyhowell@gmail.com wrote:
"time bitbake recipe" is perfect for manual things. But I wanted to
also measure the recipe times when building the entire image.  I
ended up creating  a bbappend with new pre/post tasks for the main
tasks (fetch, unpack, configure, compile, install, package).   The
pre task drops a timestamp file and the post task reads the file,
calculates the elapsed time and logs it to a file.  It's a bit clunky
but it gives the information I want.  Thanks for the help.
As others have said, please look at the buildstats class and the data
it saves into TMPDIR/buildstats. It should do what you want and we have
tools like pybootchart which can show it visually.

Cheers,

Richard


Re: #av1 #armv6 #raspberrypi #neon #av1 #armv6 #raspberrypi #neon

Zoran
 

So, what is your MACHINE variable set to?

Maybe knowing that, somebody can help.

Zee


Re: Timing a recipe

Ross Burton
 

As said, buildstats is *exactly* what you want. There's a forked
pybootchart in oe-core that can visualise the data too.

Ross

On Mon, 15 Feb 2021 at 20:08, <rustyhowell@gmail.com> wrote:

Is there a way to automatically record build time of a recipe without modifying the recipe itself? I have a recipe that is a monster, it has many git URIs and produces many packages that are coupled. It should be broken up but company deadlines have kept us from taking the time to do this. I was talking to my boss about this. He said we really needs some concrete data about how much this monster recipe is costing us before green-lighting the massive effort to split up the recipe. I agree with him, so I would like to know how much time is spent repeatedly building this recipe. I figure I could do this by adding do_fetch_prepend() and writing the time to a file, and then do_install_append() and writing the time to the file. So after a week or so, I would have many start/end data points to discuss.

However, I did not want to modify the recipe itself. I was hoping to augment the recipe via local.conf. Another bbappend in a new layer would work I guess, but I was hoping there was something simpler. Thanks in advance.



1521 - 1540 of 53871