Will, CI should fail without patch 4, e.g. Probably, it's an all-or-nothing series from that perspective, and it only makes sense to break it up for readability reasons. OK. Looking at more details

Is that https://nvd.nist.gov/vuln/detail/cve-2021-4034, and does that relate to "This vulnerability has been modified and is currently undergoing reanalysis."? Or is it something else? Jan --

Hi! There's a security problem in pkexec vs. kernel interaction. Impact is local root. If you want to get root on someone else's system, it should be easy right now. It is fixed in 5.18, 5.10.120,

cip-gitlab/ci/iwamatsu/linux-5.10.y-cip-rc build: 188 builds: 3 failed, 185 passed, 4 errors, 10 warnings (v5.10.118-cip8-218-g9c4d612b27204) Full Build Summary:

cip-gitlab/ci/iwamatsu/linux-4.19.y-cip-rc baseline: 112 runs, 19 regressions (v4.19.245-cip74-32-g2d021d7a9e637) Regressions Summary ------------------- platform | arch | lab

cip-gitlab/ci/iwamatsu/linux-4.19.y-cip-rc baseline-nfs: 39 runs, 3 regressions (v4.19.245-cip74-32-g2d021d7a9e637) Regressions Summary ------------------- platform | arch | lab |

cip-gitlab/ci/iwamatsu/linux-4.19.y-cip-rc baseline-cip-nfs: 10 runs, 2 regressions (v4.19.245-cip74-32-g2d021d7a9e637) Regressions Summary ------------------- platform | arch | lab

cip-gitlab/ci/iwamatsu/linux-4.19.y-cip-rc build: 170 builds: 6 failed, 164 passed, 2 errors, 30 warnings (v4.19.245-cip74-32-g2d021d7a9e637) Full Build Summary:

I tried to make the patches bisection-safe. The build should work but the verity and swupdate functionality is not available after patch 1. patch 1 and 3 are the main changes. I will re-oder the

Hmm, patch 4 is likely needed to ensure that CI is still passing with its deployment jobs. Jan -- Siemens AG, Technology Competence Center Embedded Linux

Thanks for this update. I'll have a look and also try to apply it to meta-iot2050 as test case. One question: Is the series bisection-safe, or are the patches 3 and 4 needed to build again. Patch 2

From: Quirin Gylstorff <quirin.gylstorff@...> This update introduces the new IMAGE_CMD_*. Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...> --- classes/wic-targz-img.bbclass

From: Quirin Gylstorff <quirin.gylstorff@...> The identifier img was delete from the image name. Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...> ---

From: Quirin Gylstorff <quirin.gylstorff@...> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...> --- start-qemu.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4

From: Quirin Gylstorff <quirin.gylstorff@...> This series adapt isar-cip-core to the IMAGE_CMD_* introduced in ISAR commit [1]. See also ISAR API changelog[2]. This new feature remove the

From: Quirin Gylstorff <quirin.gylstorff@...> The image types wic-swu-img and secure-wic-swu-img were removed. Rename `squashfs-img` to squashfs according new naming scheme. To use squashfs

Hi! Below is document about kernel security I have mentioned on the irc. But looking at it some more, TSC might have been looking at easier "turn this CONFIG on and this off" kind of hardening. I'll

Hi! Thanks for the report. Unfortunately, mainline seems to be different here. Looking at the code, is min < 0 in your case? Best regards, Pavel -- DENX Software Engineering GmbH,

Hi! First, thanks for reaching us over email. Yup, those issues seem to be real. We'd preffer not to take fixes that are not upstream, and this is not too severe bug. (Should the skb be freed in the

From: Jan Kiszka <jan.kiszka@...> Same story as for abrootfs-hook, same solution pattern, just different implementation of find_root_via_image_uuid. Signed-off-by: Jan Kiszka