Date   

[hardknott][PATCH] sssd: fix CVE-2021-3621

kai
 

From: Kai Kang <kai.kang@...>

Backport patch to fix CVE-2021-3621.

CVE: CVE-2021-3621

Signed-off-by: Kai Kang <kai.kang@...>
---
.../sssd/files/CVE-2021-3621.patch | 291 ++++++++++++++++++
recipes-security/sssd/sssd_1.16.5.bb | 1 +
2 files changed, 292 insertions(+)
create mode 100644 recipes-security/sssd/files/CVE-2021-3621.patch

diff --git a/recipes-security/sssd/files/CVE-2021-3621.patch b/recipes-security/sssd/files/CVE-2021-3621.patch
new file mode 100644
index 0000000..3d2c707
--- /dev/null
+++ b/recipes-security/sssd/files/CVE-2021-3621.patch
@@ -0,0 +1,291 @@
+Backport patch to fix CVE-2021-3621.
+
+Upstream-Status: Backport [https://github.com/SSSD/sssd/commit/b4b3267]
+CVE: CVE-2021-3621
+
+Signed-off-by: Kai Kang <kai.kang@...>
+
+From b4b32677a886bc26d60ce0171505aa3ab0c82c8a Mon Sep 17 00:00:00 2001
+From: Alexey Tikhonov <atikhono@...>
+Date: Fri, 30 Jul 2021 19:05:31 +0200
+Subject: [PATCH] TOOLS: replace system() with execvp() to avoid execution of
+ user supplied command
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+:relnote: A flaw was found in SSSD, where the sssctl command was
+vulnerable to shell command injection via the logs-fetch and
+cache-expire subcommands. This flaw allows an attacker to trick
+the root user into running a specially crafted sssctl command,
+such as via sudo, to gain root access. The highest threat from this
+vulnerability is to confidentiality, integrity, as well as system
+availability.
+This patch fixes a flaw by replacing system() with execvp().
+
+:fixes: CVE-2021-3621
+
+Reviewed-by: Pavel Březina <pbrezina@...>
+---
+ src/tools/sssctl/sssctl.c | 40 +++++++++++++++++-------
+ src/tools/sssctl/sssctl.h | 2 +-
+ src/tools/sssctl/sssctl_data.c | 57 +++++++++++-----------------------
+ src/tools/sssctl/sssctl_logs.c | 31 ++++++++++++++----
+ 4 files changed, 73 insertions(+), 57 deletions(-)
+
+diff --git a/src/tools/sssctl/sssctl.c b/src/tools/sssctl/sssctl.c
+index afaa84bc0..403c89c35 100644
+--- a/src/tools/sssctl/sssctl.c
++++ b/src/tools/sssctl/sssctl.c
+@@ -97,22 +97,37 @@ sssctl_prompt(const char *message,
+ return SSSCTL_PROMPT_ERROR;
+ }
+
+-errno_t sssctl_run_command(const char *command)
++errno_t sssctl_run_command(const char *const argv[])
+ {
+ int ret;
++ int wstatus;
+
+- DEBUG(SSSDBG_TRACE_FUNC, "Running %s\n", command);
++ DEBUG(SSSDBG_TRACE_FUNC, "Running '%s'\n", argv[0]);
+
+- ret = system(command);
++ ret = fork();
+ if (ret == -1) {
+- DEBUG(SSSDBG_CRIT_FAILURE, "Unable to execute %s\n", command);
+ fprintf(stderr, _("Error while executing external command\n"));
+ return EFAULT;
+- } else if (WEXITSTATUS(ret) != 0) {
+- DEBUG(SSSDBG_CRIT_FAILURE, "Command %s failed with [%d]\n",
+- command, WEXITSTATUS(ret));
++ }
++
++ if (ret == 0) {
++ /* cast is safe - see
++ https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
++ "The statement about argv[] and envp[] being constants ... "
++ */
++ execvp(argv[0], discard_const_p(char * const, argv));
+ fprintf(stderr, _("Error while executing external command\n"));
+- return EIO;
++ _exit(1);
++ } else {
++ if (waitpid(ret, &wstatus, 0) == -1) {
++ fprintf(stderr,
++ _("Error while executing external command '%s'\n"), argv[0]);
++ return EFAULT;
++ } else if (WEXITSTATUS(wstatus) != 0) {
++ fprintf(stderr,
++ _("Command '%s' failed with [%d]\n"), argv[0], WEXITSTATUS(wstatus));
++ return EIO;
++ }
+ }
+
+ return EOK;
+@@ -132,11 +147,14 @@ static errno_t sssctl_manage_service(enum sssctl_svc_action action)
+ #elif defined(HAVE_SERVICE)
+ switch (action) {
+ case SSSCTL_SVC_START:
+- return sssctl_run_command(SERVICE_PATH" sssd start");
++ return sssctl_run_command(
++ (const char *[]){SERVICE_PATH, "sssd", "start", NULL});
+ case SSSCTL_SVC_STOP:
+- return sssctl_run_command(SERVICE_PATH" sssd stop");
++ return sssctl_run_command(
++ (const char *[]){SERVICE_PATH, "sssd", "stop", NULL});
+ case SSSCTL_SVC_RESTART:
+- return sssctl_run_command(SERVICE_PATH" sssd restart");
++ return sssctl_run_command(
++ (const char *[]){SERVICE_PATH, "sssd", "restart", NULL});
+ }
+ #endif
+
+diff --git a/src/tools/sssctl/sssctl.h b/src/tools/sssctl/sssctl.h
+index 70fc19eff..71f798b2a 100644
+--- a/src/tools/sssctl/sssctl.h
++++ b/src/tools/sssctl/sssctl.h
+@@ -42,7 +42,7 @@ enum sssctl_prompt_result
+ sssctl_prompt(const char *message,
+ enum sssctl_prompt_result defval);
+
+-errno_t sssctl_run_command(const char *command);
++errno_t sssctl_run_command(const char *const argv[]); /* argv[0] - command */
+ bool sssctl_start_sssd(bool force);
+ bool sssctl_stop_sssd(bool force);
+ bool sssctl_restart_sssd(bool force);
+diff --git a/src/tools/sssctl/sssctl_data.c b/src/tools/sssctl/sssctl_data.c
+index cc46cafbf..8a042664c 100644
+--- a/src/tools/sssctl/sssctl_data.c
++++ b/src/tools/sssctl/sssctl_data.c
+@@ -105,15 +105,15 @@ static errno_t sssctl_backup(bool force)
+ }
+ }
+
+- ret = sssctl_run_command("sss_override user-export "
+- SSS_BACKUP_USER_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "user-export",
++ SSS_BACKUP_USER_OVERRIDES, NULL});
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to export user overrides\n"));
+ return ret;
+ }
+
+- ret = sssctl_run_command("sss_override group-export "
+- SSS_BACKUP_GROUP_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "group-export",
++ SSS_BACKUP_GROUP_OVERRIDES, NULL});
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to export group overrides\n"));
+ return ret;
+@@ -158,8 +158,8 @@ static errno_t sssctl_restore(bool force_start, bool force_restart)
+ }
+
+ if (sssctl_backup_file_exists(SSS_BACKUP_USER_OVERRIDES)) {
+- ret = sssctl_run_command("sss_override user-import "
+- SSS_BACKUP_USER_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "user-import",
++ SSS_BACKUP_USER_OVERRIDES, NULL});
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to import user overrides\n"));
+ return ret;
+@@ -167,8 +167,8 @@ static errno_t sssctl_restore(bool force_start, bool force_restart)
+ }
+
+ if (sssctl_backup_file_exists(SSS_BACKUP_USER_OVERRIDES)) {
+- ret = sssctl_run_command("sss_override group-import "
+- SSS_BACKUP_GROUP_OVERRIDES);
++ ret = sssctl_run_command((const char *[]){"sss_override", "group-import",
++ SSS_BACKUP_GROUP_OVERRIDES, NULL});
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to import group overrides\n"));
+ return ret;
+@@ -296,40 +296,19 @@ errno_t sssctl_cache_expire(struct sss_cmdline *cmdline,
+ void *pvt)
+ {
+ errno_t ret;
+- char *cmd_args = NULL;
+- const char *cachecmd = SSS_CACHE;
+- char *cmd = NULL;
+- int i;
+-
+- if (cmdline->argc == 0) {
+- ret = sssctl_run_command(cachecmd);
+- goto done;
+- }
+
+- cmd_args = talloc_strdup(tool_ctx, "");
+- if (cmd_args == NULL) {
+- ret = ENOMEM;
+- goto done;
++ const char **args = talloc_array_size(tool_ctx,
++ sizeof(char *),
++ cmdline->argc + 2);
++ if (!args) {
++ return ENOMEM;
+ }
++ memcpy(&args[1], cmdline->argv, sizeof(char *) * cmdline->argc);
++ args[0] = SSS_CACHE;
++ args[cmdline->argc + 1] = NULL;
+
+- for (i = 0; i < cmdline->argc; i++) {
+- cmd_args = talloc_strdup_append(cmd_args, cmdline->argv[i]);
+- if (i != cmdline->argc - 1) {
+- cmd_args = talloc_strdup_append(cmd_args, " ");
+- }
+- }
+-
+- cmd = talloc_asprintf(tool_ctx, "%s %s", cachecmd, cmd_args);
+- if (cmd == NULL) {
+- ret = ENOMEM;
+- goto done;
+- }
+-
+- ret = sssctl_run_command(cmd);
+-
+-done:
+- talloc_free(cmd_args);
+- talloc_free(cmd);
++ ret = sssctl_run_command(args);
+
++ talloc_free(args);
+ return ret;
+ }
+diff --git a/src/tools/sssctl/sssctl_logs.c b/src/tools/sssctl/sssctl_logs.c
+index aca988c05..c85cc7a4b 100644
+--- a/src/tools/sssctl/sssctl_logs.c
++++ b/src/tools/sssctl/sssctl_logs.c
+@@ -32,6 +32,7 @@
+ #include <popt.h>
+ #include <stdio.h>
+ #include <signal.h>
++#include <glob.h>
+
+ #include "util/util.h"
+ #include "tools/common/sss_process.h"
+@@ -231,6 +232,7 @@ errno_t sssctl_logs_remove(struct sss_cmdline *cmdline,
+ {
+ struct sssctl_logs_opts opts = {0};
+ errno_t ret;
++ glob_t globbuf;
+
+ /* Parse command line. */
+ struct poptOption options[] = {
+@@ -254,8 +256,19 @@ errno_t sssctl_logs_remove(struct sss_cmdline *cmdline,
+
+ sss_signal(SIGHUP);
+ } else {
++ globbuf.gl_offs = 4;
++ ret = glob(LOG_PATH"/*.log", GLOB_ERR|GLOB_DOOFFS, NULL, &globbuf);
++ if (ret != 0) {
++ DEBUG(SSSDBG_CRIT_FAILURE, "Unable to expand log files list\n");
++ return ret;
++ }
++ globbuf.gl_pathv[0] = discard_const_p(char, "truncate");
++ globbuf.gl_pathv[2] = discard_const_p(char, "--size");
++ globbuf.gl_pathv[3] = discard_const_p(char, "0");
++
+ printf(_("Truncating log files...\n"));
+- ret = sssctl_run_command("truncate --size 0 " LOG_FILES);
++ ret = sssctl_run_command((const char * const*)globbuf.gl_pathv);
++ globfree(&globbuf);
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to truncate log files\n"));
+ return ret;
+@@ -270,8 +283,8 @@ errno_t sssctl_logs_fetch(struct sss_cmdline *cmdline,
+ void *pvt)
+ {
+ const char *file;
+- const char *cmd;
+ errno_t ret;
++ glob_t globbuf;
+
+ /* Parse command line. */
+ ret = sss_tool_popt_ex(cmdline, NULL, SSS_TOOL_OPT_OPTIONAL, NULL, NULL,
+@@ -281,13 +294,19 @@ errno_t sssctl_logs_fetch(struct sss_cmdline *cmdline,
+ return ret;
+ }
+
+- cmd = talloc_asprintf(tool_ctx, "tar -czf %s %s", file, LOG_FILES);
+- if (cmd == NULL) {
+- fprintf(stderr, _("Out of memory!"));
++ globbuf.gl_offs = 3;
++ ret = glob(LOG_PATH"/*.log", GLOB_ERR|GLOB_DOOFFS, NULL, &globbuf);
++ if (ret != 0) {
++ DEBUG(SSSDBG_CRIT_FAILURE, "Unable to expand log files list\n");
++ return ret;
+ }
++ globbuf.gl_pathv[0] = discard_const_p(char, "tar");
++ globbuf.gl_pathv[1] = discard_const_p(char, "-czf");
++ globbuf.gl_pathv[2] = discard_const_p(char, file);
+
+ printf(_("Archiving log files into %s...\n"), file);
+- ret = sssctl_run_command(cmd);
++ ret = sssctl_run_command((const char * const*)globbuf.gl_pathv);
++ globfree(&globbuf);
+ if (ret != EOK) {
+ fprintf(stderr, _("Unable to archive log files\n"));
+ return ret;
+--
+2.33.0
+
diff --git a/recipes-security/sssd/sssd_1.16.5.bb b/recipes-security/sssd/sssd_1.16.5.bb
index 9784ec7..02d0837 100644
--- a/recipes-security/sssd/sssd_1.16.5.bb
+++ b/recipes-security/sssd/sssd_1.16.5.bb
@@ -22,6 +22,7 @@ SRC_URI = "https://releases.pagure.org/SSSD/${BPN}/${BP}.tar.gz \
file://0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch \
file://0001-nss-Collision-with-external-nss-symbol.patch \
file://0002-Provide-missing-defines-which-otherwise-are-availabl.patch \
+ file://CVE-2021-3621.patch \
"

SRC_URI[sha256sum] = "2e1a7bf036b583f686d35164f2d79bdf4857b98f51fe8b0d17aa0fa756e4d0c0"
--
2.17.1


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.3.3.rc2)

Teoh, Jay Shen
 

Hello all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.3.3.rc2 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 Wednesday, 15 September.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Friday, 10 September, 2021 4:00 AM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.3.3.rc2)

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


https://autobuilder.yocto.io/pub/releases/yocto-3.3.3.rc2


Build hash information:

bitbake: c7b506d11df78cfc4610db6578745eaa6220b13a
meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a
meta-arm: ba82ea920a3a43244a0a72bd74817e2f00f4a1af
meta-aws: 171aa2cf4d12ff4877e9104b6ec46be54128e3d8
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 5c4a6b02f650a99a5ec55561443fcf880a863d19
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
meta-openembedded: 7bd7e1da9034e72ca4262dba55f70b2b23499aae
oecore: 567dd35d893c5d8969d41f263a24da8fbae3fc2f
poky: 0a2ca9d60f3851515a79d5aa9ddd8b4069b5a206



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







[meta-security][dunfell][PATCH] linux-%_5.%.bbappend: drop recipe

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
(cherry picked from commit 833ae34c8f3222358f65e8ee3fdbac565485694e)
---
recipes-kernel/linux/linux-%_5.%.bbappend | 4 ----
1 file changed, 4 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-%_5.%.bbappend

diff --git a/recipes-kernel/linux/linux-%_5.%.bbappend b/recipes-kernel/linux/linux-%_5.%.bbappend
deleted file mode 100644
index 6bc40cd..0000000
--- a/recipes-kernel/linux/linux-%_5.%.bbappend
+++ /dev/null
@@ -1,4 +0,0 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "yama", " features/yama/yama.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}"
--
2.25.1


[ANNOUNCEMENT]Milestone 3 for Yocto Project 3.4 (yocto-3.4_M3) now available

Vineela
 

Hello,

 

We are pleased to announce the third milestone release for Yocto Project 3.4 (yocto-3.4_M3) is now available for download.

 

Download:

 

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.4_M3

 

bitbake: 0a11696e0898c3c5108e6d7c5ad28da50e00ea66

meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a

meta-arm: 46e8fc6a67efbcc357cf507b903a3e3e133c78f7

meta-aws: 32ae20566a39454ab0ba4c80c23a32ed7c14dcaf

meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400

meta-intel: cb1bf2bdc1b20f76fde8b291a12b361a4bc2511e

meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8

meta-openembedded: 1511e25cea69b98bf2778984d7a649dad5597878

oecore: ffb886497390d4de2631bda671f2f631bc0bc7be

poky: f2728d3ec8c0589e02e9a3ce7cf8aca902cae0a3

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.4_M3/testreport.txt

 

Thank you.

 

Vineela Tummalapalli,

Yocto Project Build and Release

vineela.tummalapalli@...

 


QA notification for completed autobuilder build (yocto-3.3.3.rc2)

Richard Purdie
 

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


https://autobuilder.yocto.io/pub/releases/yocto-3.3.3.rc2


Build hash information:

bitbake: c7b506d11df78cfc4610db6578745eaa6220b13a
meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a
meta-arm: ba82ea920a3a43244a0a72bd74817e2f00f4a1af
meta-aws: 171aa2cf4d12ff4877e9104b6ec46be54128e3d8
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 5c4a6b02f650a99a5ec55561443fcf880a863d19
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
meta-openembedded: 7bd7e1da9034e72ca4262dba55f70b2b23499aae
oecore: 567dd35d893c5d8969d41f263a24da8fbae3fc2f
poky: 0a2ca9d60f3851515a79d5aa9ddd8b4069b5a206



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


Re: regd pTest #systemd #yocto

Khem Raj
 

On 9/9/21 3:59 AM, rpaluri@... wrote:
Hi,
1. I'm aware that yocto picks up packages from respective open source
community. For e.g. dbus package is picked from freedesktop.org etc.
In this regard, what kind of tests does yocto runs to ensure that
the package that is getting picked-up is stable enough?
there is system integration testing that happens on autobuilders which you can check reports for

2. Is it Yocto, that writes pTest's to ensure that the package that is
getting picked up is stable enough?
ptests are generic and one can add more to a package but usually you will see that its trying to run the unit tests of the given package in a cross environment.

3. I could find pTest report for e.g. on Dunfell @
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.1/testreport.txt
<http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.1/testreport.txt> (Refer
"qemuarm64 PTest Result Summary" or "qemux86-64 PTest Result
Summary" section for details). The test report only details the
number of pTest's that passed, failed or skipped for respective
package. Is there any report that *details* the pTest's, which
failed, passed or skipped?
the detailed run logs would be available when you run it, I am not sure if we preserve those in release notes.

Additionally, I'm looking for pTest's for systemd, udev and glibc packages.
Below are my observations on these packages w.r.t pTests.
1. pTest for systemd package has been removed with
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/systemd?h=dunfell&id=40db00818e3b1cce8aa85ee30f3081ae9a5f8e66
<http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/systemd?h=dunfell&id=40db00818e3b1cce8aa85ee30f3081ae9a5f8e66> commit.
2. Similarly pTest for udev has been removed with
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core?h=dunfell&id=3e5e540513665105b963262c2eaf33f197a0a36c
<http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core?h=dunfell&id=3e5e540513665105b963262c2eaf33f197a0a36c>.
yes someone needs to step up and get ptests working with meson on these packages, they are temporarily removed there.

3. I don't find ptest's for glibc package either.
there is glibc-testsuite package which provides glibc testing.

As there aren't any pTests for these three packages, are there any other existing tests that can be run to validate these packages?
Thanks,
Ravi


Re: Enable graphic in core-image-minimal for raspberrypi #yocto

Khem Raj
 

minimal image is not ideal target as it is console only image
perhaps use core-image-weston (wayland) or core-image-x11/core-image-sato ( X11 ) as starting point.

On 9/9/21 3:28 AM, yasminebenghozzi6@... wrote:
Hello,
I cant find how to add maybe graphic conf for the yocto image I already have for the raspberrypi,
Any help?


Re: extra-cmake-modules #yocto

Khem Raj
 

On 9/8/21 11:18 PM, sateesh m wrote:
Hi All,
I am trying to build an extra-cmake-modules package. Using bitbake command "bitbake extra-cmake-modules" compiled succuss. But using bitbake core-image-plasma-mobile throwing error. So I want to disable native build on the x86 platform is it possible? or else can anybody know how to fix this issue suggest me any corrections required.
find if docs can be disabled during build, and perhaps that will get you moving forward

ERROR: extra-cmake-modules-native-5.79.0-r0 do_compile: Execution of '/home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/temp/run.do_compile.20787' failed with exit code 1:
[1/2] cd /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs && /usr/local/bin/sphinx-build -c /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs -d /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs/doctrees -b html /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/git/docs /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs/html
> build-html.log
FAILED: docs/doc_format_html
cd /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs && /usr/local/bin/sphinx-build -c /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs -d /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs/doctrees -b html /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/git/docs /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs/html
> build-html.log
Extension error:
Could not import extension ecm (exception: cannot import name 'htmlescape')
ninja: build stopped: subcommand failed.
WARNING: exit code 1 from a shell command.
ERROR: Logfile of failure stored in: /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/temp/log.do_compile.20787
--
Regards,
Sateesh


Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: Sept 9, 2021

Randy MacLeod
 

YP AB Intermittent failures meeting
===================================
Sept 9, 2021, 9 AM ET
https://windriver.zoom.us/j/3696693975

Attendees: Kiran, Richard, Trevor, Randy!


Summary:
========

Ptest results continue to improve but there's still room
for even more improvement.

The make/ninja load average limit is in but it's not clear
if it's effective yet and it breaks dunfell. Trevor investigating
(Aug 26!, Sept 9). Trevor is going to get back to this!


If anyone wants to help, we could use more eyes on the logs,
particularly the summary logs and understanding iostat #
when the dd test times out.



Plans for the week:
===================

Richard: QA results for M3, etc.
Alex: SWAT plans. September email, training. libevent monotonic fix!
Sakib: hook more responsive load average in to latency test. (v3)
Trevor: patch to set PARALLEL_MAKE : -l 50
-> dunfell, gatesgarth, hardknott (Aug 5 - it's a priority)
Investigate dunfell which failed with this change.
- data on WR AB load average.
Saul: SBOM
Randy: Vacation
Kiran: probably work on one of the ptest failures.


Nothing much new below here. Keeping the list since it's still to-do.

../Randy

Meeting Notes:
==============

1. job server

- ninja could be patched with make's more responsive algorithm
next or is this good enough?

Aug 26:
Randy made some graphs that show that the -l NUM results
in the number of compile jobs oscillates *wildly* between 0 and 200
on a 192 core builder compiling chromium. What I did was:
$ bitbake -c cleansstate chromium-x11
$ bitbake -c configure chromium-x11
$ bitbake -c compile chromium-x11
and while that compile was running:
$ while [ ! -f /tmp/compiling-chromium-is-done ]; do \
cat /proc/loadavg >> procs-load.log ; sleep 0.5 ;
done
Results so far:
https://postimg.cc/gallery/3hjfYfG/f8f46c97
Next step is either:
a. collect data as above for an image build and see if the sub-optimal
ninja behaviour makes a difference
and/or
b. patch ninja with make's more responsive load avg
algorithm:
https://git.savannah.gnu.org/cgit/make.git/commit/?id=d8728efc8


- Richard suggested that we extract make's code for measuring the load
average to a separate binary and run it in the periodic io latency
test. Also can we translate it to python?
- Trevor is working on this and had some problems so next week.
(Aug 19 - Trevor is back from vaction so maybe next week.)

- Trevor to see if the load average change really did reduce load
on WR build systems. (Aug 19)

2. AB status

Trevor is learning about buildbot and working on a scheduling bug
(CentOS worker?)

bitbake layer setup tool should allow multiple backends:
eg: kas, a y-a-helper.

ptest cases are improving, we may be close to done!
Let's wait a week to see how things go.
(July29, Aug 5, Aug 19, we're not done...)

- lttng-tools ptest is failing. RP is working on it with upstream.
The timeout (done on Aug 5) increase hasn't helped.


3. Sakib's improvements to the logging are merged.

Sakib generated a summary of all high latency 'top' logs from
~July 23->July 29 by just running his summary script on the
merged raw top logs.

More analysis required....


Still relevant parts of
Previous Meeting Notes:
=======================


4. bitbake server timeout ( no change july 29, Aug 19)

"Timeout while waiting for a reply from the bitbake server (60s)"

5. io stalls (no update: July 29)

Richard said that it would make sense to write an ftrace utility
/ script to monitor io latency and we could install it with sudo
Ch^W mentioned ftrace on IRC.
Sakib and Randy will work on that but not for a week or two
or longer! (Aug 19).

Randy collected iostat data on 3 build server:
https://postimg.cc/gallery/8cN6LYB
We agreed that having -ty-2 be ~ 100 utilization for many hours
in a row is not acceptable and that a threshold of ~ 10 minutes
at 100% utilization may be a reasonable limt. I need to figure out
if I can get data on the fraction of IO done per IO clas since
we do use ionice to do clean-up and other activities.


../Randy


Re: Minutes: Yocto Project Weekly Triage Meeting 9/9/2021

Stephen Jolley
 

Done with AR

 

Stephen

 

From: Trevor Gamblin <trevor.gamblin@...>
Sent: Thursday, September 9, 2021 8:06 AM
To: Yocto-mailing-list <yocto@...>
Cc: Richard Purdie <richard.purdie@...>; trevor.gamblin@...; MacLeod, Randy <Randy.MacLeod@...>; steve@...; timothy.t.orling@...; sjolley.yp.pm@...; alexandre.belloni@...; Ross Burton <ross@...>; Wold, Saul <saul.wold@...>; Bruce Ashfield <bruce.ashfield@...>; kiran.surendran@...
Subject: Minutes: Yocto Project Weekly Triage Meeting 9/9/2021

 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Alex, Bruce, Diane, Kiran, Randy, Richard, Ross, Saul, Stephen, Steve, Tim, Trevor

ARs:

- Randy to move AB defects to M4 after call

- Tim to file a bug about improving ptest runner timeout warnings

- Stephen to handle 3.4 M3 unassigned bugs (move to M4 or 3.5 M1 if enhancements)

- Trevor to ask Alex Kanavin if he could help on 14518

- General reminder to review Old Milestone bugs and move as necessary

 

Notes:

 

- (carried over) Steve encountered build failures such as the one in https://errors.yoctoproject.org/Errors/Details/593109/ when attempting to run dunfell builds with the PARALLEL_MAKE load averaging added. WR is testing/investigating on internal Autobuilder instance - Trevor is still planning on looking into this!

Medium+ 3.4 Unassigned Enhancements/Bugs: 77 (No change)

Medium+ 3.99 Unassigned Enhancements/Bugs: 38 (No change)

 

AB-INT Bugs: 49 (Last week 48)


Minutes: Yocto Project Weekly Triage Meeting 9/9/2021

Trevor Gamblin
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Alex, Bruce, Diane, Kiran, Randy, Richard, Ross, Saul, Stephen, Steve, Tim, Trevor

ARs:

- Randy to move AB defects to M4 after call

- Tim to file a bug about improving ptest runner timeout warnings

- Stephen to handle 3.4 M3 unassigned bugs (move to M4 or 3.5 M1 if enhancements)

- Trevor to ask Alex Kanavin if he could help on 14518

- General reminder to review Old Milestone bugs and move as necessary

Notes:

- (carried over) Steve encountered build failures such as the one in https://errors.yoctoproject.org/Errors/Details/593109/ when attempting to run dunfell builds with the PARALLEL_MAKE load averaging added. WR is testing/investigating on internal Autobuilder instance - Trevor is still planning on looking into this!

Medium+ 3.4 Unassigned Enhancements/Bugs: 77 (No change)

Medium+ 3.99 Unassigned Enhancements/Bugs: 38 (No change)

AB-INT Bugs: 49 (Last week 48)


yocto library build needs ldconfig to start working

Ashutosh Naik
 

I have a rather simple bitbake package which adds a shared library foo.so to the system in /usr/lib/. However, on first boot, I am always forced to do an explicit "ldconfig" for the library to be detected by the applications. Subsequent reboots do not need an ldconfig.

Can I avoid this ldconfig step ? As all other libraries work fine without it.

Here is my .bb file :

DESCRIPTION = "FOO library"
DEPENDS = "bar"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=00006733ca3231dd8b07dde266d4d4e4"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

SRC_URI = "file://foo-1.0.tar.gz"
S = "${WORKDIR}/foo-1.0"

inherit autotools pkgconfig

BBCLASSEXTEND = "native nativesdk"
EXTRA_OEMAKE = '-C ${S} FOO_BITBAKE=yes'
FILES_${PN} += "/usr/lib/*.so"

do_compile() {
    oe_runmake
}

do_install() 
    oe_runmake DESTDIR=${D} install
}

Thanks for your help!
Ash


[yocto-autobuilder2][PATCH] add prioritizeBuilders

Trevor Gamblin
 

This prioritizeBuilders function sorts builders by the length of their
associated worker lists, so that builders that can only be assigned to a
small number of workers are assigned to those workers before other
builds that don't have specific needs when resources are limited. An
example might be when a slot is available on an Ubuntu-based worker, and
"oe-selftest-ubuntu" and "genericx86-64" build requests exist in the
queue. Since oe-selftest-ubuntu requires an Ubuntu-based worker and
genericx86-64 does not, genericx86-64 will be assigned a higher value
(lower priority) so that oe-selftest-ubuntu is assigned to that worker
first.

Signed-off-by: Trevor Gamblin <trevor.gamblin@...>
---
builders.py | 13 +++++++++++++
master.cfg | 6 ++++++
2 files changed, 19 insertions(+)

diff --git a/builders.py b/builders.py
index 53c5f0e..94fb561 100644
--- a/builders.py
+++ b/builders.py
@@ -135,6 +135,19 @@ for builder in config.subbuilders:
workernames=workers, nextWorker=nextWorker, nextBuild=nextBuild,
factory=f, env=extra_env))

+# prioritize assigning builders to available workers based on the length
+# of the worker lists they are associated with. Builders that have fewer
+# valid worker options should always be assigned first
+def prioritizeBuilders(buildmaster, builders):
+ # re-use the builder_to_workers list
+ builder_to_workers = config.builder_to_workers
+
+ # sort builders by the length of their worker lists. Since not all
+ # builders are explicitly listed in builder_to_workers, make sure to
+ # default to the len() of the "default" value
+ builders.sort(key=lambda b: len(builder_to_workers.get(b.name)) if b.name in builder_to_workers.keys() else len(builder_to_workers.get("default")))
+ return builders
+
def create_parent_builder_factory(buildername, waitname):
factory = util.BuildFactory()
# NOTE: Assumes that yocto-autobuilder repo has been cloned to home
diff --git a/master.cfg b/master.cfg
index a7c151f..4f7d74e 100644
--- a/master.cfg
+++ b/master.cfg
@@ -88,6 +88,12 @@ c['www'] = www.www
# These items are specific to an individual AB deployment
c['workers'] = workers.workers

+# This enables our prioritizeBuilders function from builders.py.
+# Builders such as buildperf-centos7, buildperf-ubuntu1604,
+# oe-selftest-*, and reproducible-* will be assigned (if possible)
+# before other builders since their possible worker lists are smaller
+c['prioritizeBuilders'] = builders.prioritizeBuilders
+
c['title'] = "Yocto Autobuilder"
c['titleURL'] = "https://autobuilder.yoctoproject.org/main/"
# visible location for internal web server
--
2.31.1


regd pTest #systemd #yocto

rpaluri@...
 

Hi,
  1. I'm aware that yocto picks up packages from respective open source community. For e.g. dbus package is picked from freedesktop.org etc. In this regard, what kind of tests does yocto runs to ensure that the package that is getting picked-up is stable enough?
  2. Is it Yocto, that writes pTest's to ensure that the package that is getting picked up is stable enough?
  3. I could find pTest report for e.g. on Dunfell @ http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.1/testreport.txt (Refer "qemuarm64 PTest Result Summary" or "qemux86-64 PTest Result Summary" section for details). The test report only details the number of pTest's that passed, failed or skipped for respective package. Is there any report that details the pTest's, which failed, passed or skipped?
Additionally, I'm looking for pTest's for systemd, udev and glibc packages.
Below are my observations on these packages w.r.t pTests.
  1. pTest for systemd package has been removed with http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/systemd?h=dunfell&id=40db00818e3b1cce8aa85ee30f3081ae9a5f8e66 commit. 
  2. Similarly pTest for udev has been removed with http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core?h=dunfell&id=3e5e540513665105b963262c2eaf33f197a0a36c.
  3. I don't find ptest's for glibc package either.
As there aren't any pTests for these three packages, are there any other existing tests that can be run to validate these packages?

Thanks,
Ravi


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.4_M3.rc1)

Teoh, Jay Shen
 

Hi All,

This is the full report for yocto-3.4_M3.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issue found.


Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Saturday, 4 September, 2021 9:27 PM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.4_M3.rc1)

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


https://autobuilder.yocto.io/pub/releases/yocto-3.4_M3.rc1


Build hash information:

bitbake: 0a11696e0898c3c5108e6d7c5ad28da50e00ea66
meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a
meta-arm: 46e8fc6a67efbcc357cf507b903a3e3e133c78f7
meta-aws: 32ae20566a39454ab0ba4c80c23a32ed7c14dcaf
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: cb1bf2bdc1b20f76fde8b291a12b361a4bc2511e
meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
meta-openembedded: 1511e25cea69b98bf2778984d7a649dad5597878
oecore: ffb886497390d4de2631bda671f2f631bc0bc7be
poky: f2728d3ec8c0589e02e9a3ce7cf8aca902cae0a3



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






Enable graphic in core-image-minimal for raspberrypi #yocto

yasminebenghozzi6@...
 

Hello, 
I cant find how to add maybe graphic conf for the yocto image I already have for the raspberrypi, 
Any help? 


extra-cmake-modules #yocto

sateesh m
 

Hi All,

I am trying to build an extra-cmake-modules package. Using bitbake command "bitbake extra-cmake-modules" compiled succuss. But using bitbake core-image-plasma-mobile throwing error. So I want to disable native build on the x86 platform is it possible? or else can anybody know how to fix this issue suggest me any corrections required.


ERROR: extra-cmake-modules-native-5.79.0-r0 do_compile: Execution of '/home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/temp/run.do_compile.20787' failed with exit code 1:
[1/2] cd /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs && /usr/local/bin/sphinx-build -c /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs -d /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs/doctrees -b html /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/git/docs /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs/html > build-html.log
FAILED: docs/doc_format_html 
cd /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs && /usr/local/bin/sphinx-build -c /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs -d /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs/doctrees -b html /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/git/docs /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/build/docs/html > build-html.log
 
Extension error:
Could not import extension ecm (exception: cannot import name 'htmlescape')
ninja: build stopped: subcommand failed.
WARNING: exit code 1 from a shell command.
 
ERROR: Logfile of failure stored in: /home/sateesh/KDE/sources/fu540-build/tmp-glibc/work/x86_64-linux/extra-cmake-modules-native/5.79.0-r0/temp/log.do_compile.20787
 
--
Regards,
Sateesh


Re: [meta-security][PATCH 1/2] image-with-hardened-binaries: add class

Maximilian Blenk
 

Hi,

I'm really not used to this e-mail process :-D
forwording my original answer to the mailing list...

BR Max

On 06.09.21 10:18, Maximilian Blenk wrote:

Hi Robert, Hi Armin,

sorry for the late reply.

Regarding  Armins question:
If the config file you've used (e.g. th eon ein the selftest) enables all the tests, then it should be fine indeed. I'm not completely sure what the core-mage-minimal includes though. It if it contains systemd the build should be failing if the rpath check is enabled (you would have to whitelist the binaries in the config file)
Currently there is no test for failing. Should i add one?

Sure i can remove the ".py", i just want to avoid confusion of "checksec.sh" and "checksec.py" (which are completely different tools)

Regarding Roberts question:
In case the tooling finds a violation it fails the build and outputs an error message containing the buildsystem paths to the binaries and the actual check it is failing. The message also contains some reasoning on why the used feature shouldn't be used. The bitbake class basically take the output you pasted (there is a json mode) and checks it against the whitelist (and some other unreasonable things, such as usage of relro in statically linked applications)


Br Max

On 21.08.21 18:59, Robert Berger wrote:
Hi,

On 21/08/2021 18:35, Armin Kuster wrote:

Regarding the selftest, is there test for failure?

I ran this against core-image-minimal and nothing was printed out. Does
that mean its fine?

You may want to remove the ".py" from
python3-checksec.py-native_0.6.1.bb, its not needed.

If you run checksec manually against some binary e.g. ls.coreutils it outputs something like this:

https://pastebin.com/JkeN1h3k

Not sure what this should output.


-armin




Re: Inactive service of hello world #yocto

Nicolas Jeker
 

On Tue, 2021-09-07 at 10:43 -0700, Rudolf J Streif wrote:
What does your 'Hello World' service do? Just print 'Hello World' to
the console and then exit?

If so that would be the reason why it is inactive. Systemd starts it
and then it exits. Typically, services keep running (except for some
special cases) once they are started. That's what makes them a service.
To stop them 'systemctl stop <service>' is used. By default systemctl
sends SIGTERM to tell the service to clean up and terminate itself.
To piggyback on that, it is possible to set Type=oneshot[1] for the
service so that systemd considers the service to be up after it exited.
I find it useful for init or migration scripts that another service can
then depend upon.

[1]:
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=


:rjs


On Tue, Sep 7, 2021, 10:20 <yasminebenghozzi6@...> wrote:
Hi everyone, 

I wanted to run the helloworld service, but it keeps telling that its
inactive , I really cant find why, I changed the service many times
but no solution.
I m sorry I ant copy paste from putty




Re: Building Yocto on AWS container getting ERROR: The postinstall intercept hook 'update_icon_cache' failed, #yocto

mail2uvijay@...
 

For the error,  i have tried installed below package in aws container
libgdk-pixbuf2.0-0 in container,
and added DEPENDS += "qemuwrapper-cross" in bb file.

Will try the option building "core-image-minimal" or "core-image-sato"

Regards,
Vijay

2741 - 2760 of 57399