Re: [OE-core] Providing detailed CPE information for CVE matching capabilities

[Jasper Orschulko via lists.openembedded.org]

Hello again,

I have kept been pondering on this topic for quite some time and have
after quite some thought come to the conclusion that the mismatch in
the CPE Name Matching actually is due to a wrong interpretion of the
specification on the side of the dependencytrack maintainers and by
extension myself
(see https://github.com/DependencyTrack/dependency-track/issues/2988
for more details). So all-clear on that frontline. Sorry for the fuzz.

However, I still stand by the idea of providing more detailed CPE
information (e.g. target architecture) to avoid false positives, as
well as making openembedded-specific CVE reports possible.

Also, I believe it should be possible to gather the missing pieces of
information in an automated fashion by using a migration script for the
layers by leverage of the NIST CPE API. Using the cpeMatchString
parameter and the information we already have (product name and
version), we can attempt to guess the correct Part and Vendor
parameters:

// This might fail, if there is no CPE for current version (yet).
// However, might provide more accurate results.
if API(cpeMatchString="cpe:2.3:*:*:product_name:product_version:..."):
gather_facts_from_first_result
// If no matching CPE found:
// Reduce the product_name, which might result in less accurate results
else if API(cpeMatchString="cpe:2.3:*:*:product_name:*:..."):
gather_facts_from_first_result
// CVE unknown: Either name mismatch or no entry exists for this
product.
// Manual check required.
else:
CVE_*=unknown

This will reduce manual labor to feasibility checks, rather than
information gathering.

Leveraging the same mechanism, we could also attempt to guess the CPE_*
information when invoking the recipetool for the creation of new
recipes.

This would allow for a quick adoption and flatten out the path for
making these variables required by default, in turn improving reporting
and security for openembedded products.

Cheers, Jasper

On Fri, 2023-08-25 at 09:57 -1000, Steve Sakoman wrote:
> On Fri, Aug 25, 2023 at 9:18 AM Jasper Orschulko via
> lists.openembedded.org
>  wrote:
> > 
> > Hi Richard,
> > hi all,
> > 
> > I want to address a flaw in the current CPE generation
> > functionality in
> > openembedded, which renders the CPEs unusable in regards to the
> > minimal
> > requirements of the NIST CPE Name Matching Specification standard
> > (https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7696.pdf).
> > 
> > This makes working with the generated CPEs in thirdparty software
> > close
> > to impossible, as it would require the thirdparty software to
> > implement
> > matching logic beyond the requirements defined in the NIST
> > standard.
> > 
> > 
> > Status quo:
> > 
> > Currently, the CPE is generated from the optional CVE_PRODUCT
> > (optionally including the vendor) and CVE_VERSION variables. If
> > neither
> > are provided, CPE generation will fall back on the BPN and PV of
> > the
> > recipe.
> > 
> > As a result, the generated CPE will usually look as follows:
> > 
> > cpe:2.3:*:*:${BPN}:${PV}:*:*:*:*:*:*:*:*
> > 
> > Or, if the CVE_PRODUCT includes a vendor:
> > 
> > cpe:2.3:*:${vendor}:${product}:${PV}:*:*:*:*:*:*:*:*
> > 
> > 
> > 
> > The Issue (The TL;DR):
> > 
> > This will return zero¹ matches when doing CPE matching against CVE
> > CPEs
> > in accordance with the minimal requirements of the NIST Name
> > Matching
> > Specification. For reliable matches the components CPE should be as
> > precise as possible, i.e. not containing any "*" (ANY) values for
> > vital
> > attributes, such as: Part, Vendor, Product, Version, Target_HW.
> > 
> > 
> > 
> > The Issue (In detail):
> > 
> > To understand the issue in full detail, in depth knowledge of the
> > NIST
> > specification is required. However, I will try to provide a
> > comprehensive summary below:
> > 
> > CPE matching is done using a source CPE and target CPE. Due to
> > limitations (see Table 6-2, cases 4 & 11), using the CVE CPE as a
> > source and the component CPE as a target is the only sensible way
> > (otherwise a CVE CPE containing wildcards would lead to undefined
> > behavior).
> > 
> > Each attribute of the CVE CPE, will then be matched against the
> > component CPE, setting the relationship of each source attribute to
> > the
> > corresponding target attribute to either superset (⊃), equal (=),
> > subset (⊂) or disjoint (≠) (see Table 6-1, example: Table 6-3).
> > 
> > The NIST standard then defines 4 required CPE Name Comparison
> > Relations
> > (see Table 6-4), with two of them relevant for what we would
> > consider a
> > "match" between a CVE CPE and a component CPE:
> > 
> > If all attribute relations are EQUAL (=) -> Then CPE name relation
> > is
> > EQUAL (=) -> match
> > 
> > If all attribute relations are SUPERSET (⊃) or
> > EQUAL (=) -> Then CPE name relation is SUPERSET (⊃) -> match
> > 
> > Let's take a look at this, based on a real-world example:
> > 
> > CVE CPE: 

Re: [OE-core] [PATCH v3] rust: Upgrade 1.70.0 -> 1.71.0

[Randy MacLeod via lists.openembedded.org]

On 2023-08-25 11:30, Shinde, Yash wrote:


Hi Luca,

The current version of Rust Oe-selftest is based on Rust 1.70 and 
works well there. It is yet to be updated for Rust 1.71 (eventually 
1.72 which is latest). With every new Rust version there are newly 
test cases added from which some might fail leading to failure of Rust 
Oe-selftest.


The patch sent here is only for Rust version update and not for Rust 
Oe-selftest. The Rust Oe-selftest would be updated to recent versions 
after the Rust update is done.



We need to do both steps in on patch series.




The Rust Oe-selftest fails since it is still on Rust 1.70 and the Rust 
version is updated to 1.71 here. Parallelly will start to rebase Rust 
Oe-selftest on the latest versions.



Thanks.

Send the 1.70 -> 1.71 update along with the Rust Oe-selftest using 1.71 
as one series of commits.


../Randy


Regards,
Yash

*From: *Luca Ceresoli 
*Sent: *25 August 2023 18:50
*To: *Shinde, Yash via lists.openembedded.org 

*Cc: *Shinde, Yash ; 
openembedded-core@lists.openembedded.org; MacLeod, Randy 
; Kallapa, Umesh 
; Gowda, Naveen 
; Kokkonda, Sundeep 
; Moodalappa, Shivaprasad 


*Subject: *Re: [OE-core] [PATCH v3] rust: Upgrade 1.70.0 -> 1.71.0

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender 
and know the content is safe.


Hello Yash,

On Thu, 24 Aug 2023 07:30:18 -0700
"Shinde, Yash via lists.openembedded.org"
 wrote:

> Switch libstd-rs to use the dummy `sysroot` crate which represents the
> standard library crates. Target getrandom-open64.patch at 0.2.8 (merged
> for 0.2.9).
>
> Drop bootstrap_fail.patch as it is merged in upstream rust.
>
> Signed-off-by: Yash Shinde 

The rust.RustSelfTestSystemEmulated.test_rust test is failing on the
ABs with this patch applied:

https://autobuilder.yoctoproject.org/typhoon/#/builders/146/builds/408/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/154/builds/407/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/147/builds/407/steps/12/logs/stdio

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com



--
# Randy MacLeod
# Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186741): 
https://lists.openembedded.org/g/openembedded-core/message/186741
Mute This Topic: https://lists.openembedded.org/mt/100936266/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 07/13] cmake-example: workaround for pseudo breakeage

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 meta-selftest/recipes-test/cpp/cmake-example.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta-selftest/recipes-test/cpp/cmake-example.bb 
b/meta-selftest/recipes-test/cpp/cmake-example.bb
index 96d543180b4..fbf1f266721 100644
--- a/meta-selftest/recipes-test/cpp/cmake-example.bb
+++ b/meta-selftest/recipes-test/cpp/cmake-example.bb
@@ -15,3 +15,9 @@ SRC_URI += "\
 "
 
 FILES:${PN}-ptest += "${bindir}/test-cmake-example"
+
+# This is a workaround for packages with sources in-tree
+# Without this bitbake ... does not work after running the install script.
+# newenv['PSEUDO_IGNORE_PATHS'] = newenv['PSEUDO_IGNORE_PATHS'] + ""
+# path mismatch [3 links]: ino 37529096 db 
'/home/adrian/projects/oss/meta-yocto-upstream/projects/poky-oe-glibc-sd/tmp/work/cortexa57-poky-linux/cmake-example/1.0-r0/package/usr/src/debug/cmake-example/1.0-r0/oe-local-files/cmake-example-lib.cpp'
 req 
'/home/adrian/projects/oss/meta-yocto-upstream/projects/poky-oe-glibc-sd/workspace/sources/cmake-example/oe-local-files/cmake-example-lib.cpp'.
+PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186734): 
https://lists.openembedded.org/g/openembedded-core/message/186734
Mute This Topic: https://lists.openembedded.org/mt/100965620/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 13/13] docs: cover devtool ide

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 documentation/sdk-manual/extensible.rst | 97 -
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/documentation/sdk-manual/extensible.rst 
b/documentation/sdk-manual/extensible.rst
index 9e08e57a4e7..d05d4e36aa7 100644
--- a/documentation/sdk-manual/extensible.rst
+++ b/documentation/sdk-manual/extensible.rst
@@ -237,7 +237,7 @@ all the commands.
devtool
quick reference.
 
-Three ``devtool`` subcommands provide entry-points into
+Four ``devtool`` subcommands provide entry-points into
 development:
 
 -  *devtool add*: Assists in adding new software to be built.
@@ -245,6 +245,8 @@ development:
 -  *devtool modify*: Sets up an environment to enable you to modify
the source of an existing component.
 
+-  *devtool ide*: Generates a configuration for an IDE.
+
 -  *devtool upgrade*: Updates an existing recipe so that you can
build it for an updated set of source files.
 
@@ -632,6 +634,99 @@ command:
   proceed with your work. If you do use this command, realize that
   the source tree is preserved.
 
+Use ``devtool ide`` to generate an configuration for the IDE
+
+
+``devtool ide`` automatically configures the IDE for cross-compiling and 
remote debugging.
+The IDE is configured to call for example cmake directly. This has several 
advantages.
+First of all it is much faster than using e.g. ``devtool build``. But it also 
allows to
+use the very good integration of build tools like cmake or gdb with VSCode 
directly.
+
+Two different use cases are supported:
+
+- Generate the IDE configuration for a workspace created by ``devtool modify``.
+
+- Generate the IDE configuration for using a cross-toolchain as provided by
+  ``bitbake meta-ide-support build-sysroots``.
+
+Assuming the development environment is set up correctly and a workspace has 
been created
+for the recipe using ``devtool modify recipe``, the following command can 
create the
+configuration for VSCode in the recipe workspace:
+
+   $ devtool ide recipe core-image-minimal --target root@192.168.7.2
+
+What this command does exactly depends on the recipe or the build tool used by 
the recipe.
+Currently, only CMake and Meson are supported natively.
+
+For a recipe which inherits cmake it does:
+
+- Prepare the SDK by calling bitbake core-image-minimal, gdb-cross, 
qemu-native...
+
+- Generate a cmake-preset with configures cmake to use exactly the same 
environent and
+  the same cmake-cache configuration as used by ``bitbake recipe``. The 
cmake-preset referres
+  to the per-recipe-sysroot of the recipe.
+
+  Currently Configure, Build and Test presets are supported. Test presets 
execute the test
+  binaries with Qemu.
+
+- Generates a helper script to handle the do_install with pseudo
+
+- Generates some helper scripts to start the gdbserver on the target device
+
+- Generates the ``.vscode`` folder containing the following files:
+
+  - c_ccp_properties.json: configure the code navigation
+
+  - extensions.json: Recommend the extensions which are used.
+
+  - launch.json: Provide a configuration for remote debugging with gdb-cross 
and gdbserver.
+The debug-symbols are searched in the build-folder, the per-recipe-sysroot 
and the rootfs-dbg
+folder which is provided by the image.
+
+  - settings.json: confgure the indexer to ignore the build folders
+
+  - tasks.json: Provide some helpers for running
+
+- do_install and ``devtool deploy-target``
+
+- start the gdbserver via ssh
+
+For a recipe which inherits meson a similar configuration is generated.
+Because there is nothing like a meson-preset a wrapper script for meson is 
generated.
+
+For some special recipes and use cases a per-recipe-sysroot based SDK is not 
suitable.
+Therefore devtool ide also supports setting up the shared sysroots environment 
and generating
+a IDE configurations referring to the shared sysroots. Recipes leading to a 
shared sysroot
+are for example meta-ide-support or shared-sysroots. Also passing none as a 
recipe name leads
+to a shared sysroot SDK.
+
+   $ devtool ide none core-image-minimal
+
+In case of a shared sysroot SDK the configuration which gets generated for 
VSCode exposes the
+cross-tool-chain as a cmake-kit. If a cmake project is loaded into VSCode the 
cross-toolchain
+can be selected for compiling.
+
+The default IDE is VSCode. Some hints about using VSCode:
+
+- To work with cmake press ``Ctrl + Shift + p``, type cmake.
+  This will show some possible commands like selecting a cmake preset, 
compiling or running ctest.
+  A cmake kit might be activated by ``Ctrl + Shift + p``, type cmake quick 
start,
+  if not preset file is in the wokspace.
+
+- To work with meson press ``Ctrl + Shift + p``, type meson.
+  This will show some possible commands like compiling or executing the unit 
tests.
+
+- For the deployment to the target device, just press ``Ctrl + Shift + p``, 

[OE-core] [PATCH v3 12/13] oe-selftest devtool: ide tests

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 meta/lib/oeqa/selftest/cases/devtool.py | 133 
 1 file changed, 133 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/devtool.py 
b/meta/lib/oeqa/selftest/cases/devtool.py
index a2b77e528de..21644ef7bc2 100644
--- a/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/meta/lib/oeqa/selftest/cases/devtool.py
@@ -11,6 +11,7 @@ import tempfile
 import glob
 import fnmatch
 import unittest
+import json
 
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, create_temp_layer
@@ -2192,3 +2193,135 @@ class DevtoolUpgradeTests(DevtoolBase):
 
 #Step 4.5
 runCmd("grep %s %s" % (modconfopt, codeconfigfile))
+
+
+class DevtoolIdeTests(DevtoolBase):
+
+def __devtool_ide_recipe(self):
+tempdir = tempfile.mkdtemp(prefix='devtoolqa')
+self.track_for_cleanup(tempdir)
+self.track_for_cleanup(self.workspacedir)
+self.add_command_to_tearDown('bitbake -c clean %s' % self.recipe_name)
+self.add_command_to_tearDown('bitbake-layers remove-layer */workspace')
+
+conf_lines = [
+'IMAGE_FEATURES += "ssh-server-openssh debug-tweaks"',
+'IMAGE_CLASSES += "image-combined-dbg"',
+'IMAGE_GEN_DEBUGFS = "1"',
+'IMAGE_INSTALL += "gdbserver %s-ptest"' % self.recipe_name
+]
+self.write_config("\n".join(conf_lines))
+
+result = runCmd('devtool modify %s -x %s' % (self.recipe_name, 
tempdir))
+self.assertExists(os.path.join(tempdir, self.build_file),
+  'Extracted source could not be found')
+self.assertExists(os.path.join(self.workspacedir, 'conf',
+  'layer.conf'), 'Workspace directory not created')
+matches = glob.glob(os.path.join(self.workspacedir,
+'appends', self.recipe_name + '.bbappend'))
+self.assertTrue(matches, 'bbappend not created %s' % result.output)
+
+# Test devtool status
+result = runCmd('devtool status')
+self.assertIn(self.recipe_name, result.output)
+self.assertIn(tempdir, result.output)
+self._check_src_repo(tempdir)
+
+result = runCmd('devtool ide %s core-image-minimal -c --ide=code' % 
self.recipe_name)
+return tempdir
+
+def __devtool_ide_qemu(self):
+# Verify do_install works
+with open(os.path.join(self.tempdir, '.vscode', 'tasks.json')) as 
tasks_j:
+tasks_d = json.load(tasks_j)
+tasks = tasks_d["tasks"]
+task_install = next((task for task in tasks if task["label"] == 
"install && deploy-target %s"  % self.recipe_name), None)
+self.assertIsNot(task_install, None)
+install_deploy_cmd = task_install["command"]
+# execute only the bb_run_do_install script since the deploy would 
require e.g. Qemu running.
+install_cmd = install_deploy_cmd.replace("install_and_deploy", 
"bb_run_do_install")
+runCmd(install_cmd, cwd=self.tempdir)
+
+# Verify if re-building the SDK still works and the deploy and install 
script gets generated
+runCmd('devtool ide %s core-image-minimal -c --ide=code' % 
self.recipe_name)
+self.assertExists(install_deploy_cmd, 'install_and_deploy script not 
found')
+
+# Verify deployment to Qemu works
+with runqemu("core-image-minimal", runqemuparams = "nographic") as 
qemu:
+MAGIC_STRING_ORIG = "Magic: 123456789"
+MAGIC_STRING_NEW = "Magic: 987654321"
+
+# Verify the unmodified example prints the magic string
+status, output = qemu.run(self.example_exe)
+self.assertEqual(status, 0)
+self.assertIn(MAGIC_STRING_ORIG, output)
+
+# Verify the unmodified ptests work
+status, output = qemu.run("ptest-runner " + self.recipe_name)
+self.assertEqual(status, 0, msg=output)
+self.assertIn("PASS: cpp-example-lib", output)
+
+# Replace the Magic String in the code, compile and deploy to Qemu
+cpp_example_lib_hpp = os.path.join(self.tempdir, 
'cpp-example-lib.hpp')
+with open(cpp_example_lib_hpp, 'r') as file:
+cpp_code = file.read()
+cpp_code = cpp_code.replace(MAGIC_STRING_ORIG, 
MAGIC_STRING_NEW)
+with open(cpp_example_lib_hpp, 'w') as file:
+file.write(cpp_code)
+runCmd(install_deploy_cmd, cwd=self.tempdir)
+
+# Verify the modified example prints the modified magic string
+status, output = qemu.run(self.example_exe)
+self.assertEqual(status, 0)
+self.assertNotIn(MAGIC_STRING_ORIG, output)
+self.assertIn(MAGIC_STRING_NEW, output)
+
+# Verify the modified example ptests work
+status, output = qemu.run("ptest-runner " + self.recipe_name)
+

[OE-core] [PATCH v3 11/13] devtool: ide make deploy-target quicker

[Adrian Freihofer]

Instead of calling devtool deploy-target which starts a bitbake server
to get some variables the previous refactoring allows to generate a
simple script which does no longer depend on variables from bitbake.
This is much faster.
---
 scripts/lib/devtool/ide.py | 115 ++---
 1 file changed, 55 insertions(+), 60 deletions(-)

diff --git a/scripts/lib/devtool/ide.py b/scripts/lib/devtool/ide.py
index 7c7040232c4..9c724509d48 100755
--- a/scripts/lib/devtool/ide.py
+++ b/scripts/lib/devtool/ide.py
@@ -9,6 +9,7 @@
 
 import os
 import stat
+import sys
 import logging
 import json
 import re
@@ -360,15 +361,19 @@ class RecipeModified:
 self.bbappend = None
 # recipe variables from d.getVar
 self.b = None
+self.base_libdir = None
 self.bpn = None
 self.d = None
 self.fakerootcmd = None
 self.fakerootenv = None
+self.libdir = None
+self.max_process = None
 self.package_arch = None
 self.path = None
 self.recipe_sysroot = None
 self.recipe_sysroot_native = None
 self.staging_incdir = None
+self.strip_cmd = None
 self.target_arch = None
 self.workdir = None
 # replicate bitbake build environment
@@ -387,11 +392,6 @@ class RecipeModified:
 self.meson_cross_file = None
 # vscode
 self.dot_code_dir = None
-# TODO: remove calling devtool
-self.bb_env_passthrough_additions = None
-self.bbpath = None
-self.bitbakepath = None
-self.topdir = None
 
 def initialize(self, config, workspace, tinfoil):
 recipe_d = parse_recipe(
@@ -413,10 +413,14 @@ class RecipeModified:
 shutil.rmtree(self.temp_dir)
 
 self.b = recipe_d.getVar('B')
+self.base_libdir = recipe_d.getVar('base_libdir')
 self.bpn = recipe_d.getVar('BPN')
 self.d = recipe_d.getVar('D')
 self.fakerootcmd = recipe_d.getVar('FAKEROOTCMD')
 self.fakerootenv = recipe_d.getVar('FAKEROOTENV')
+self.libdir = recipe_d.getVar('libdir'),
+self.max_process = int(recipe_d.getVar(
+"BB_NUMBER_THREADS") or os.cpu_count() or 1)
 self.package_arch = recipe_d.getVar('PACKAGE_ARCH')
 self.path = recipe_d.getVar('PATH')
 self.recipe_sysroot = os.path.realpath(
@@ -425,15 +429,10 @@ class RecipeModified:
 recipe_d.getVar('RECIPE_SYSROOT_NATIVE'))
 self.staging_incdir = os.path.realpath(
 recipe_d.getVar('STAGING_INCDIR'))
+self.strip_cmd = recipe_d.getVar('STRIP')
 self.target_arch = recipe_d.getVar('TARGET_ARCH')
 self.workdir = os.path.realpath(recipe_d.getVar('WORKDIR'))
 
-self.bb_env_passthrough_additions = recipe_d.getVar(
-'BB_ENV_PASSTHROUGH_ADDITIONS')
-self.bbpath = recipe_d.getVar('BBPATH')
-self.bitbakepath = recipe_d.getVar('BITBAKEPATH')
-self.topdir = recipe_d.getVar('TOPDIR')
-
 self.__init_exported_variables(recipe_d)
 
 if bb.data.inherits_class('cmake', recipe_d):
@@ -971,6 +970,38 @@ class RecipeModified:
 cmd_lines.append(install_cmd)
 return self.write_script(cmd_lines, 'bb_run_do_install')
 
+def gen_deploy_target_script(self, args):
+"""Generate a quicker (works without tinfoil) variant of devtool 
target-deploy"""
+cmd_lines = ['#!/usr/bin/env python3']
+cmd_lines.append('import sys')
+cmd_lines.append('devtool_sys_path = %s' % str(sys.path))
+cmd_lines.append('devtool_sys_path.reverse()')
+cmd_lines.append('for p in devtool_sys_path:')
+cmd_lines.append('if p not in sys.path:')
+cmd_lines.append('sys.path.insert(0, p)')
+cmd_lines.append('from devtool.deploy import deploy_cached')
+args_filter = ['debug', 'dry_run', 'key', 'no_check_space', 
'no_host_check',
+   'no_preserve', 'port', 'recipename', 'show_status', 
'ssh_exec', 'strip', 'target']
+filtered_args_dict = {key: value for key, value in vars(
+args).items() if key in args_filter}
+cmd_lines.append('filtered_args_dict = %s' % str(filtered_args_dict))
+cmd_lines.append('class Dict2Class(object):')
+cmd_lines.append('def __init__(self, my_dict):')
+cmd_lines.append('for key in my_dict:')
+cmd_lines.append('setattr(self, key, my_dict[key])')
+cmd_lines.append('filtered_args = Dict2Class(filtered_args_dict)')
+cmd_lines.append('deploy_cached("%s", "%s", "%s", "%s", "%s", "%s", 
%d, "%s", "%s", filtered_args)' %
+ (self.d, self.workdir, self.path, self.strip_cmd,
+  self.libdir, self.base_libdir, self.max_process,
+  self.fakerootcmd, self.fakerootenv))
+return self.write_script(cmd_lines, 'deploy_target')
+
+def 

[OE-core] [PATCH v3 09/13] refactor: make strip_execs callable without d

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 meta/classes-global/staging.bbclass | 3 ++-
 meta/lib/oe/package.py  | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/classes-global/staging.bbclass 
b/meta/classes-global/staging.bbclass
index 3a300c32e7c..7f4075a5f6e 100644
--- a/meta/classes-global/staging.bbclass
+++ b/meta/classes-global/staging.bbclass
@@ -92,7 +92,8 @@ python sysroot_strip () {
 qa_already_stripped = 'already-stripped' in (d.getVar('INSANE_SKIP:' + pn) 
or "").split()
 strip_cmd = d.getVar("STRIP")
 
-oe.package.strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, d,
+max_process = oe.utils.multiprocess_launch_max_process(d)
+oe.package.strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
max_process,
qa_already_stripped=qa_already_stripped)
 }
 
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index ffca7559ba7..1dd20f85ebd 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -114,7 +114,7 @@ def is_static_lib(path):
 return start == magic
 return False
 
-def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, d, 
qa_already_stripped=False):
+def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, max_process, 
qa_already_stripped=False):
 """
 Strip executable code (like executables, shared libraries) _in_place_
 - Based on sysroot_strip in staging.bbclass
@@ -122,6 +122,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 :param strip_cmd: Strip command (usually ${STRIP})
 :param libdir: ${libdir} - strip .so files in this directory
 :param base_libdir: ${base_libdir} - strip .so files in this directory
+:param max_process: number of stripping processes started in parallel
 :param qa_already_stripped: Set to True if already-stripped' in 
${INSANE_SKIP}
 This is for proper logging and messages only.
 """
@@ -164,7 +165,6 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 # ...but is it ELF, and is it already stripped?
 checkelf.append(file)
 inodecache[file] = s.st_ino
-max_process = int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
 results = oe.utils.multiprocess_launch_mp(is_elf, checkelf, max_process)
 for (file, elf_file) in results:
 #elf_file = is_elf(file)
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186736): 
https://lists.openembedded.org/g/openembedded-core/message/186736
Mute This Topic: https://lists.openembedded.org/mt/100965622/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 10/13] devtool: refactor deploy-target

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 scripts/lib/devtool/__init__.py |   5 +-
 scripts/lib/devtool/deploy.py   | 230 +---
 2 files changed, 124 insertions(+), 111 deletions(-)

diff --git a/scripts/lib/devtool/__init__.py b/scripts/lib/devtool/__init__.py
index 702db669de3..7d64547616e 100644
--- a/scripts/lib/devtool/__init__.py
+++ b/scripts/lib/devtool/__init__.py
@@ -78,12 +78,15 @@ def exec_fakeroot(d, cmd, **kwargs):
 """Run a command under fakeroot (pseudo, in fact) so that it picks up the 
appropriate file permissions"""
 # Grab the command and check it actually exists
 fakerootcmd = d.getVar('FAKEROOTCMD')
+fakerootenv = d.getVar('FAKEROOTENV')
+exec_fakeroot_no_d(fakerootcmd, fakerootenv, cmd, kwargs)
+
+def exec_fakeroot_no_d(fakerootcmd, fakerootenv, cmd, **kwargs):
 if not os.path.exists(fakerootcmd):
 logger.error('pseudo executable %s could not be found - have you run a 
build yet? pseudo-native should install this and if you have run any build then 
that should have been built')
 return 2
 # Set up the appropriate environment
 newenv = dict(os.environ)
-fakerootenv = d.getVar('FAKEROOTENV')
 for varvalue in fakerootenv.split():
 if '=' in varvalue:
 splitval = varvalue.split('=', 1)
diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
index e14a5874177..ea7e2cb1ae8 100644
--- a/scripts/lib/devtool/deploy.py
+++ b/scripts/lib/devtool/deploy.py
@@ -16,7 +16,7 @@ import bb.utils
 import argparse_oe
 import oe.types
 
-from devtool import exec_fakeroot, setup_tinfoil, check_workspace_recipe, 
DevtoolError
+from devtool import exec_fakeroot_no_d, setup_tinfoil, check_workspace_recipe, 
DevtoolError
 
 logger = logging.getLogger('devtool')
 
@@ -133,16 +133,11 @@ def _prepare_remote_script(deploy, verbose=False, 
dryrun=False, undeployall=Fals
 
 return '\n'.join(lines)
 
-
-
-def deploy(args, config, basepath, workspace):
-"""Entry point for the devtool 'deploy' subcommand"""
+def deploy_cached(srcdir, workdir, path, strip_cmd, libdir, base_libdir, 
max_process, fakerootcmd, fakerootenv, args):
 import math
 import oe.recipeutils
 import oe.package
 
-check_workspace_recipe(workspace, args.recipename, checksrc=False)
-
 try:
 host, destdir = args.target.split(':')
 except ValueError:
@@ -152,116 +147,131 @@ def deploy(args, config, basepath, workspace):
 if not destdir.endswith('/'):
 destdir += '/'
 
+recipe_outdir = srcdir
+if not os.path.exists(recipe_outdir) or not os.listdir(recipe_outdir):
+raise DevtoolError('No files to deploy - have you built the %s '
+'recipe? If so, the install step has not installed '
+'any files.' % args.recipename)
+
+if args.strip and not args.dry_run:
+# Fakeroot copy to new destination
+srcdir = recipe_outdir
+recipe_outdir = os.path.join(workdir, 'devtool-deploy-target-stripped')
+if os.path.isdir(recipe_outdir):
+exec_fakeroot_no_d(fakerootcmd, fakerootenv, "rm -rf %s" % 
recipe_outdir, shell=True)
+exec_fakeroot_no_d(fakerootcmd, fakerootenv, "cp -af %s %s" % 
(os.path.join(srcdir, '.'), recipe_outdir), shell=True)
+os.environ['PATH'] = ':'.join([os.environ['PATH'], path or ''])
+oe.package.strip_execs(args.recipename, recipe_outdir, strip_cmd, 
libdir, base_libdir, max_process)
+
+filelist = []
+inodes = set({})
+ftotalsize = 0
+for root, _, files in os.walk(recipe_outdir):
+for fn in files:
+fstat = os.lstat(os.path.join(root, fn))
+# Get the size in kiB (since we'll be comparing it to the output 
of du -k)
+# MUST use lstat() here not stat() or getfilesize() since we don't 
want to
+# dereference symlinks
+if fstat.st_ino in inodes:
+fsize = 0
+else:
+fsize = int(math.ceil(float(fstat.st_size)/1024))
+inodes.add(fstat.st_ino)
+ftotalsize += fsize
+# The path as it would appear on the target
+fpath = os.path.join(destdir, os.path.relpath(root, 
recipe_outdir), fn)
+filelist.append((fpath, fsize))
+
+if args.dry_run:
+print('Files to be deployed for %s on target %s:' % (args.recipename, 
args.target))
+for item, _ in filelist:
+print('  %s' % item)
+return 0
+
+extraoptions = ''
+if args.no_host_check:
+extraoptions += '-o UserKnownHostsFile=/dev/null -o 
StrictHostKeyChecking=no'
+if not args.show_status:
+extraoptions += ' -q'
+
+scp_sshexec = ''
+ssh_sshexec = 'ssh'
+if args.ssh_exec:
+scp_sshexec = "-S %s" % args.ssh_exec
+ssh_sshexec = args.ssh_exec
+scp_port = ''
+ssh_port = ''
+if args.port:
+scp_port = "-P %s" % args.port
+ssh_port = 

[OE-core] [PATCH v3 08/13] refactor: make multiprocess_launch callable without d

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 meta/lib/oe/package.py |  5 +++--
 meta/lib/oe/utils.py   | 12 +---
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 9d70925b9b7..ffca7559ba7 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -164,7 +164,8 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 # ...but is it ELF, and is it already stripped?
 checkelf.append(file)
 inodecache[file] = s.st_ino
-results = oe.utils.multiprocess_launch(is_elf, checkelf, d)
+max_process = int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
+results = oe.utils.multiprocess_launch_mp(is_elf, checkelf, max_process)
 for (file, elf_file) in results:
 #elf_file = is_elf(file)
 if elf_file & 1:
@@ -192,7 +193,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 elf_file = int(elffiles[file])
 sfiles.append((file, elf_file, strip_cmd))
 
-oe.utils.multiprocess_launch(runstrip, sfiles, d)
+oe.utils.multiprocess_launch_mp(runstrip, sfiles, max_process)
 
 
 def file_translate(file):
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 69ca8987f3d..430e874d90a 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -264,10 +264,17 @@ def execute_pre_post_process(d, cmds):
 bb.note("Executing %s ..." % cmd)
 bb.build.exec_func(cmd, d)
 
-# For each item in items, call the function 'target' with item as the first 
+def multiprocess_launch_max_process(d):
+return int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
+
+def multiprocess_launch(target, items, d, extraargs=None):
+max_process = multiprocess_launch_max_process(d)
+return multiprocess_launch_mp(target, items, max_process, extraargs)
+
+# For each item in items, call the function 'target' with item as the first
 # argument, extraargs as the other arguments and handle any exceptions in the
 # parent thread
-def multiprocess_launch(target, items, d, extraargs=None):
+def multiprocess_launch_mp(target, items, max_process, extraargs=None):
 
 class ProcessLaunch(multiprocessing.Process):
 def __init__(self, *args, **kwargs):
@@ -302,7 +309,6 @@ def multiprocess_launch(target, items, d, extraargs=None):
 self.update()
 return self._result
 
-max_process = int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
 launched = []
 errors = []
 results = []
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186735): 
https://lists.openembedded.org/g/openembedded-core/message/186735
Mute This Topic: https://lists.openembedded.org/mt/100965621/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 06/13] tests: add a C++ example recipe

[Adrian Freihofer]

This simple C++ project supports compilation with cmake and with meson.
It's supposed to be used with oe-selftest for the devtool ide plugin.

Signed-off-by: Adrian Freihofer 
---
 meta-selftest/recipes-test/cpp/.gitignore |  1 +
 .../recipes-test/cpp/cmake-example.bb | 17 ++
 .../recipes-test/cpp/cmake-example/run-ptest  | 10 
 .../recipes-test/cpp/cpp-example.inc  | 24 
 .../recipes-test/cpp/files/CMakeLists.txt | 60 +++
 .../cpp/files/cpp-example-lib.cpp | 17 ++
 .../cpp/files/cpp-example-lib.hpp | 16 +
 .../recipes-test/cpp/files/cpp-example.cpp| 16 +
 .../recipes-test/cpp/files/meson.build| 34 +++
 .../cpp/files/test-cpp-example.cpp| 19 ++
 .../recipes-test/cpp/meson-example.bb | 17 ++
 .../recipes-test/cpp/meson-example/run-ptest  | 10 
 12 files changed, 241 insertions(+)
 create mode 100644 meta-selftest/recipes-test/cpp/.gitignore
 create mode 100644 meta-selftest/recipes-test/cpp/cmake-example.bb
 create mode 100644 meta-selftest/recipes-test/cpp/cmake-example/run-ptest
 create mode 100644 meta-selftest/recipes-test/cpp/cpp-example.inc
 create mode 100644 meta-selftest/recipes-test/cpp/files/CMakeLists.txt
 create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example-lib.cpp
 create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example-lib.hpp
 create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example.cpp
 create mode 100644 meta-selftest/recipes-test/cpp/files/meson.build
 create mode 100644 meta-selftest/recipes-test/cpp/files/test-cpp-example.cpp
 create mode 100644 meta-selftest/recipes-test/cpp/meson-example.bb
 create mode 100644 meta-selftest/recipes-test/cpp/meson-example/run-ptest

diff --git a/meta-selftest/recipes-test/cpp/.gitignore 
b/meta-selftest/recipes-test/cpp/.gitignore
new file mode 100644
index 000..30d388a12b7
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/.gitignore
@@ -0,0 +1 @@
+build*
\ No newline at end of file
diff --git a/meta-selftest/recipes-test/cpp/cmake-example.bb 
b/meta-selftest/recipes-test/cpp/cmake-example.bb
new file mode 100644
index 000..96d543180b4
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/cmake-example.bb
@@ -0,0 +1,17 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+SUMMARY = "A C++ example compiled with cmake."
+
+inherit cmake
+
+require cpp-example.inc
+
+SRC_URI += "\
+file://CMakeLists.txt \
+"
+
+FILES:${PN}-ptest += "${bindir}/test-cmake-example"
diff --git a/meta-selftest/recipes-test/cpp/cmake-example/run-ptest 
b/meta-selftest/recipes-test/cpp/cmake-example/run-ptest
new file mode 100644
index 000..94b620a1984
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/cmake-example/run-ptest
@@ -0,0 +1,10 @@
+#!/bin/sh
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+test-cmake-example
+
+# Note: run-ptests exits with exit value from test-cmake-example
diff --git a/meta-selftest/recipes-test/cpp/cpp-example.inc 
b/meta-selftest/recipes-test/cpp/cpp-example.inc
new file mode 100644
index 000..39c61cf4ceb
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/cpp-example.inc
@@ -0,0 +1,24 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+inherit ptest
+
+DEPENDS += "json-c"
+
+PV = "1.0"
+
+S = "${WORKDIR}"
+
+SRC_URI = "\
+file://cpp-example.cpp \
+file://cpp-example-lib.hpp \
+file://cpp-example-lib.cpp \
+file://test-cpp-example.cpp \
+file://run-ptest \
+"
diff --git a/meta-selftest/recipes-test/cpp/files/CMakeLists.txt 
b/meta-selftest/recipes-test/cpp/files/CMakeLists.txt
new file mode 100644
index 000..839aa59b5e3
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/files/CMakeLists.txt
@@ -0,0 +1,60 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+cmake_minimum_required(VERSION 3.22)
+
+project(cmake-example
+  VERSION 1.0.0
+  LANGUAGES CXX
+)
+
+option(BUILD_SHARED_LIBS "Build using shared libraries" ON)
+
+set(CMAKE_CXX_STANDARD 17)
+set(CMAKE_CXX_STANDARD_REQUIRED On)
+set(CMAKE_CXX_EXTENSIONS Off)
+
+include(GNUInstallDirs)
+
+# Find json-c
+# find_package(PkgConfig REQUIRED)
+# pkg_check_modules(JSONC REQUIRED json-c)
+find_package(json-c)
+
+# A simple library linking json-c library found by pkgconfig
+add_library(cmake-example-lib cpp-example-lib.cpp cpp-example-lib.hpp)
+set_target_properties(cmake-example-lib PROPERTIES 
+VERSION ${PROJECT_VERSION}
+SOVERSION ${PROJECT_VERSION_MAJOR}
+)
+target_link_libraries(cmake-example-lib PRIVATE json-c::json-c)
+# target_link_libraries(cmake-example-lib ${JSONC_LIBRARIES})
+# target_include_directories(cmake-example-lib PUBLIC ${JSONC_INCLUDE_DIRS})
+# target_compile_options(cmake-example-lib PUBLIC 

[OE-core] [PATCH v3 05/13] devtool: new ide plugin

[Adrian Freihofer]

The new devtool ide plugin configures an IDE to work with the eSDK.

With this initial implementation VSCode is the default IDE.
The plugin works for recipes inheriting the cmake or the meson bbclass.
Support for more programming languages and build tools may be added in
the future.

Using the plugin in recipe modes:
$ devtool modify a-recipe
$ devtool ide a-recipe a-image
$ code "$BUILDDIR/workspace/sources/a-recipe"
Work in VSCode, after installing the proposed plugins

Using the plugin without a recipe
$ devtool ide none a-image
vscode where/the/sources/are
Use the cross tool-chain which is provided as a cmake-kit.

The goal of this implementation is to create a configuration for VSCode
(or other IDEs) that allows to work on the code of a recipe completely
independent from bitbake. bitbake is only called if the configuration or
the whole SDK has to be regenerated. But bitbake should not need to be
called while working in the IDE. This has two major advantages over
calling devtool build from the IDE:
- The IDE provides plugins for integration with cmake, for example.
  These features are usable, which would not be the case if bitbake or
  devtool are called from within the IDE.
- It is much faster.

Signed-off-by: Adrian Freihofer 
---
 scripts/lib/devtool/ide.py | 1190 
 1 file changed, 1190 insertions(+)
 create mode 100755 scripts/lib/devtool/ide.py

diff --git a/scripts/lib/devtool/ide.py b/scripts/lib/devtool/ide.py
new file mode 100755
index 000..7c7040232c4
--- /dev/null
+++ b/scripts/lib/devtool/ide.py
@@ -0,0 +1,1190 @@
+#! /usr/bin/env python3
+#
+# Copyright (C) 2023 Siemens AG
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+"""Devtool ide plugin"""
+
+import os
+import stat
+import logging
+import json
+import re
+import shutil
+from argparse import RawTextHelpFormatter
+from enum import IntEnum, auto
+
+import bb
+from devtool import exec_build_env_command, setup_tinfoil, 
check_workspace_recipe, DevtoolError, parse_recipe
+from devtool.standard import get_real_srctree
+
+SHARED_SYSROOT_RECIPES = ['none', 'meta-ide-support', 'build-sysroots']
+SUPPORTED_IDES = ['code', 'none']
+
+logger = logging.getLogger('devtool')
+
+
+class TargetDevice:
+"""SSH remote login parameters"""
+
+def __init__(self, args):
+self.extraoptions = ''
+if args.no_host_check:
+self.extraoptions += '-o UserKnownHostsFile=/dev/null -o 
StrictHostKeyChecking=no'
+self.ssh_sshexec = 'ssh'
+if args.ssh_exec:
+self.ssh_sshexec = args.ssh_exec
+self.ssh_port = ''
+if args.port:
+self.ssh_port = "-p %s" % args.port
+if args.key:
+self.extraoptions += ' -i %s' % args.key
+
+self.target = args.target
+target_sp = args.target.split('@')
+if len(target_sp) == 1:
+self.login = ""
+self.host = target_sp[0]
+elif len(target_sp) == 2:
+self.login = target_sp[0]
+self.host = target_sp[1]
+else:
+logger.error("Invalid target argument: %s" % args.target)
+
+
+class RecipeNative:
+def __init__(self, name, target_arch=None):
+self.name = name
+self.target_arch = target_arch
+self.bootstrap_tasks = [self.name + ':do_addto_recipe_sysroot']
+self.staging_bindir_native = None
+self.target_sys = None
+self.__native_bin = None
+
+def initialize(self, config, workspace, tinfoil):
+recipe_d = parse_recipe(
+config, tinfoil, self.name, appends=True, filter_workspace=False)
+if not recipe_d:
+raise DevtoolError("Parsing %s recipe failed" % self.name)
+self.staging_bindir_native = os.path.realpath(
+recipe_d.getVar('STAGING_BINDIR_NATIVE'))
+self.target_sys = recipe_d.getVar('TARGET_SYS')
+
+@property
+def native_bin(self):
+if not self.__native_bin:
+raise DevtoolError("native binary name is not defined.")
+return self.__native_bin
+
+
+class RecipeGdbCross(RecipeNative):
+def __init__(self, args, target_arch, target_device, gdbserver_multi=True):
+super().__init__('gdb-cross-' + target_arch, target_arch)
+self.target_device = target_device
+self.gdb = None
+self.gdbserver_port_next = int(args.gdbserver_port_start)
+self.gdbserver_multi = gdbserver_multi
+self.config_db = {}
+
+def initialize(self, config, workspace, tinfoil):
+super().initialize(config, workspace, tinfoil)
+gdb_bin = self.target_sys + '-gdb'
+gdb_path = os.path.join(
+self.staging_bindir_native, self.target_sys, gdb_bin)
+self.gdb = gdb_path
+
+@property
+def host(self):
+return self.target_device.host
+
+def __gdbserver_start_cmd(self, binary, port):
+if self.gdbserver_multi:
+gdbserver_cmd = "/usr/bin/gdbserver --multi :%s" % (

[OE-core] [PATCH v3 03/13] cmake.bbclass: cleanup spaces and tabs

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 meta/classes-recipe/cmake.bbclass | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/cmake.bbclass 
b/meta/classes-recipe/cmake.bbclass
index 7c40df4cdbf..c63b0a80b18 100644
--- a/meta/classes-recipe/cmake.bbclass
+++ b/meta/classes-recipe/cmake.bbclass
@@ -90,12 +90,14 @@ def map_host_arch_to_uname_arch(host_arch):
 return "ppc64"
 return host_arch
 
+
 cmake_do_generate_toolchain_file() {
if [ "${BUILD_SYS}" = "${HOST_SYS}" ]; then
cmake_crosscompiling="set( CMAKE_CROSSCOMPILING FALSE )"
-   else
-   cmake_sysroot="set( CMAKE_SYSROOT \"${RECIPE_SYSROOT}\" )"
+   else
+   cmake_sysroot="set( CMAKE_SYSROOT \"${RECIPE_SYSROOT}\" )"
fi
+
cat > ${WORKDIR}/toolchain.cmake <
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186731): 
https://lists.openembedded.org/g/openembedded-core/message/186731
Mute This Topic: https://lists.openembedded.org/mt/100965617/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 04/13] cmake.bbclass: support qemu

[Adrian Freihofer]

Define the CMAKE_CROSSCOMPILING_EMULATOR variable similar to what the
meson bbclass does. This allows for example to execute cross compilied
unit tests on the build machine.

CMAKE_CROSSCOMPILING_EMULATOR is a semi colon separated list of
paramters which could directly handle the -L and the -E parameters.
Creating a wrapper script is not absolutely mandatory. But anyway lets
do it similar to what the meson.bbclass does and also disable pseudo.

Signed-off-by: Adrian Freihofer 
---
 meta/classes-recipe/cmake.bbclass | 21 +
 1 file changed, 21 insertions(+)

diff --git a/meta/classes-recipe/cmake.bbclass 
b/meta/classes-recipe/cmake.bbclass
index c63b0a80b18..944b0d8fefd 100644
--- a/meta/classes-recipe/cmake.bbclass
+++ b/meta/classes-recipe/cmake.bbclass
@@ -4,6 +4,13 @@
 # SPDX-License-Identifier: MIT
 #
 
+inherit qemu
+
+EXEWRAPPER_ENABLED:class-native = "False"
+EXEWRAPPER_ENABLED:class-nativesdk = "False"
+EXEWRAPPER_ENABLED ?= "${@bb.utils.contains('MACHINE_FEATURES', 
'qemu-usermode', 'True', 'False', d)}"
+DEPENDS:append = "${@' qemu-native' if d.getVar('EXEWRAPPER_ENABLED') == 
'True' else ''}"
+
 # Path to the CMake file to process.
 OECMAKE_SOURCEPATH ??= "${S}"
 
@@ -156,6 +163,20 @@ EOF
 
 addtask generate_toolchain_file after do_patch before do_configure
 
+cmake_do_generate_toolchain_file:append:class-target() {
+if [ "${EXEWRAPPER_ENABLED}" = "True" ]; then
+# Write out a qemu wrapper that will be used as exe_wrapper so that 
camake
+# can run target helper binaries through that. This also allows to 
execute ctest.
+qemu_binary="${@qemu_wrapper_cmdline(d, '${STAGING_DIR_HOST}', 
['${STAGING_DIR_HOST}/${libdir}','${STAGING_DIR_HOST}/${base_libdir}'])}"
+echo "#!/bin/sh" > "${WORKDIR}/cmake-qemuwrapper"
+echo "$qemu_binary \"\$@\"" >> "${WORKDIR}/cmake-qemuwrapper"
+chmod +x "${WORKDIR}/cmake-qemuwrapper"
+echo "set( CMAKE_CROSSCOMPILING_EMULATOR 
${WORKDIR}/cmake-qemuwrapper)" \
+  >> ${WORKDIR}/toolchain.cmake
+fi
+}
+
+
 CONFIGURE_FILES = "CMakeLists.txt"
 
 do_configure[cleandirs] = "${@d.getVar('B') if d.getVar('S') != d.getVar('B') 
else ''}"
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186730): 
https://lists.openembedded.org/g/openembedded-core/message/186730
Mute This Topic: https://lists.openembedded.org/mt/100965616/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 00/13] devtool ide plugin

[Adrian Freihofer]

Changes in comparison to v2:
- Fix the oe-selftests to run on a mchine without vscode installed


According to 
https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/
one of the proposed areas for development of the Yocto project is "VSCode IDE 
Integration - New developer tooling".
One aspect of this larger topic is helping application developers configure the 
IDE to work on a recipe's source code using Yocto's eSDK. This patchset 
provides a new devtool plugin (devtool ide) that does this fully automatically 
for recipes inheriting the cmake or the meson bbclass. Support for more 
programming languages and build tools may be added in the future.

Let's start with a brief introduction of how it looks like from a user's 
perspective.

Reference setup
---

$ . oe-init-build-env

Add the following layers to bblayers.conf file:
- meta
- meta-poky
- meta-yocto-bsp
- meta-selftest
  
Add the following to the local.conf

IMAGE_CLASSES += "image-combined-dbg"
IMAGE_GEN_DEBUGFS = "1"
IMAGE_FEATURES += "ssh-server-dropbear debug-tweaks"
IMAGE_INSTALL:append = "\
cmake-example-ptest \
meson-example-ptest \
gdbserver \
"

Working on a recipe
---

Note for those who "hate cmake with passion": Replace cmake by meson in the 
following commands.

1. Add the recipe which should be modified to the workspace

   $ devtool modify cmake-example

2. Build the eSDK. This provides all the host tools as well as an image which 
can be used on the target device.
   Since everything is built with one bitbake command also all the debug 
symbols are expected to be consistent.

   $ devtool ide cmake-example core-image-minimal

3. Install the image on the target device or simply use Qemu

   $ runqemu

4. Start VSCode

   $ code "$BUILDDIR/workspace/sources/cmake-example"

5. Work in VSCode, after installing the proposed plugins

   Ctrl + Shift + p, cmake Select Configure Preset
   Ctrl + Shift + p, cmake Build

6. Execute the unit tests on the host works with Qemu even for cross compiled 
test executables.

   Ctrl + Shift + p, cmake Test

7. Remote debugging with GDB

   Ctrl + Shift + p, Run Task --> install && deploy-target cmake-example
   F5 (Debug configuration might be selected before)

8. Work on the recipes and call bitbake again to get the SDK updated.
   Building the application by calling cmake (from the IDE) or by calling 
bitbake or by calling devtool build is expected to produce the exact same 
results. To make that possible, the devtool ide plugin is designed to configure 
the IDE to call cmake with the exact same configuration as used by bitbake when 
building the recipe. Unlike the eSDK, the goal here is clearly that there is no 
longer a separation between the SDK and the application development process. 
Regardless of which tool is called, the same source files are edited and the 
same o-files are generated and re-used.

Working with a SDK without a recipe
---

If devtool ide is called for a recipe named none or meta-ide-support the eSDK 
with its generic environment file gets generated.
In case of using VSCode and cmake in addition to the well known environment 
file a cmake-kit
https://vector-of-bool.github.io/docs/vscode-cmake-tools/kits.html is added to 
the User-Local Kits.
This allows to work with cmake calling the cross-toolchain out of VSCode or a 
shell with the environment file sourced.

Design
--

The goal of this implementation is to create a configuration for VSCode (or 
other IDEs) that allows to work on the code of a recipe completely independent 
from bitbake. bitbake is only called if the configuration or the whole SDK has 
to be regenerated. But bitbake should not need to be called while working in 
the IDE. This has two major advantages over calling devtool build from the IDE:
- The IDE provides plugins for integration with cmake, for example. These 
features are usable, which would not be the case if bitbake or devtool are 
called from within the IDE.
- It is much faster.

Supporting other IDEs
-

Focus is currently VSCode. But a paramter "--ide=none" is already supported.
With this paramter passed, no VSCode specific config files are generated.
Instead, simple scripts are generated, which should be suitable for integration 
with other IDEs.

Testing
---

Reasonable but not yet complete test coverage is provided by:

$ oe-selftest -r devtool.DevtoolIdeTests

What's next?


- There is still a lot of room for improvement. But nonetheless, it provides a 
first implementation that could be integrated into the core, I think. 
Unfortunately there was no feedback on my RFC at 
https://lists.openembedded.org/g/openembedded-core/message/183819 so far.
- Support for more build-tools and programming languages as well as more IDEs 
should be possible. To prove the extendability 2 of both are already supported.

Adrian Freihofer (13):
  vscode: add minimal 

[OE-core] [PATCH v3 01/13] vscode: add minimal configuration

[Adrian Freihofer]

It is essential to configure VSCode indexer plugins to ignore the build
folder of bitbake. Otherwise, the indexer plugins run with 100% CPU load
until an OOM exception occurs. In practice, this makes VSCode more or
less unusable for working with Yocto until a file like the one added by
this commit is deployed before VSCode starts. From the user's point of
view, it is not obvious why the system runs at 100% CPU load and
eventually crashes.

It is even more misleading that VSCode starts the indexers immediately,
but does not stop or reconfigure them when the ignore list is updated.
In practice, this means that every time the ignore list is changed,
VSCode immediately starts indexing the build folder until the OOM
exception stops it. Depending on the system's OOM handler, the entire
build machine may crash.
Particularly annoying is the Python plugin that ignores the general
ignore list and requires an extra ignore section.

Signed-off-by: Adrian Freihofer 
---
 .gitignore|  2 ++
 .vscode/settings.json | 29 +
 2 files changed, 31 insertions(+)
 create mode 100644 .vscode/settings.json

diff --git a/.gitignore b/.gitignore
index 8f48d452dab..f6ce090b5fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,3 +36,5 @@ _toaster_clones/
 downloads/
 sstate-cache/
 toaster.sqlite
+.vscode/
+vscode-bitbake-build/
diff --git a/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 000..4c941d47444
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,29 @@
+{
+"files.watcherExclude": {
+"**/.git/**": true,
+"**/cache/**": true,
+"**/tmp*/**": true,
+"**/downloads/**": true,
+"**/sstate-cache/**": true,
+"**/vscode-bitbake-build/**": true,
+"**/workspace/sources/**": true
+},
+"files.exclude": {
+"**/.git/**": true,
+"**/cache/**": true,
+"**/tmp*/**": true,
+"**/downloads/**": true,
+"**/sstate-cache/**": true,
+"**/vscode-bitbake-build/**": true,
+"**/workspace/sources/**": true
+},
+"python.analysis.exclude": [
+"**/.git/**",
+"**/cache/**",
+"**/tmp*/**",
+"**/downloads/**",
+"**/sstate-cache/**",
+"**/vscode-bitbake-build/**",
+"**/workspace/sources/**"
+]
+}
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186728): 
https://lists.openembedded.org/g/openembedded-core/message/186728
Mute This Topic: https://lists.openembedded.org/mt/100965614/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3 02/13] cmake.bbclass: refactor cmake args

[Adrian Freihofer]

Make the details of the cmake configure arguments available to
d.getVar(). This allows to share them with devtool via tinfoil.

Signed-off-by: Adrian Freihofer 
---
 meta/classes-recipe/cmake.bbclass | 43 +--
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/meta/classes-recipe/cmake.bbclass 
b/meta/classes-recipe/cmake.bbclass
index 0dda104a695..7c40df4cdbf 100644
--- a/meta/classes-recipe/cmake.bbclass
+++ b/meta/classes-recipe/cmake.bbclass
@@ -158,6 +158,29 @@ CONFIGURE_FILES = "CMakeLists.txt"
 
 do_configure[cleandirs] = "${@d.getVar('B') if d.getVar('S') != d.getVar('B') 
else ''}"
 
+OECMAKE_ARGS = "\
+-DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
+-DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
+
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir'),
 d.  getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
+-DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
d.getVar('prefix') + '/')} \
+-DPYTHON_EXECUTABLE:PATH=${PYTHON} \
+-DPython_EXECUTABLE:PATH=${PYTHON} \
+-DPython3_EXECUTABLE:PATH=${PYTHON} \
+-DLIB_SUFFIX=${@d.getVar('baselib').replace('lib', '')} \
+-DCMAKE_INSTALL_SO_NO_EXE=0 \
+-DCMAKE_TOOLCHAIN_FILE:FILEPATH=${WORKDIR}/toolchain.cmake \
+-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
+-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON \
+-DFETCHCONTENT_FULLY_DISCONNECTED=ON \
+-DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=ON \
+"
+
 cmake_do_configure() {
if [ "${OECMAKE_BUILDPATH}" ]; then
bbnote "cmake.bbclass no longer uses OECMAKE_BUILDPATH.  The 
default behaviour is now out-of-tree builds with B=WORKDIR/build."
@@ -178,25 +201,7 @@ cmake_do_configure() {
  ${OECMAKE_GENERATOR_ARGS} \
  $oecmake_sitefile \
  ${OECMAKE_SOURCEPATH} \
- -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
- -DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir'), 
d.getVar('prefix') + '/')} \
- -DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir'), 
d.getVar('prefix') + '/')} \
- 
-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir'), 
d.getVar('prefix') + '/')} \
- -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
- 
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir'),
 d.  getVar('prefix') + '/')} \
- -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
- -DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir'), 
d.getVar('prefix') + '/')} \
- 
-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'), 
d.getVar('prefix') + '/')} \
- 
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
d.getVar('prefix') + '/')} \
- -DPYTHON_EXECUTABLE:PATH=${PYTHON} \
- -DPython_EXECUTABLE:PATH=${PYTHON} \
- -DPython3_EXECUTABLE:PATH=${PYTHON} \
- -DLIB_SUFFIX=${@d.getVar('baselib').replace('lib', '')} \
- -DCMAKE_INSTALL_SO_NO_EXE=0 \
- -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
- -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
- -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON \
- -DFETCHCONTENT_FULLY_DISCONNECTED=ON \
+ ${OECMAKE_ARGS} \
  ${EXTRA_OECMAKE} \
  -Wno-dev
 }
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186729): 
https://lists.openembedded.org/g/openembedded-core/message/186729
Mute This Topic: https://lists.openembedded.org/mt/100965615/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Providing detailed CPE information for CVE matching capabilities

[Jasper Orschulko via lists.openembedded.org]

Hi Steve,

I don't think it makes much of a difference at this point. When looking
at the recipes in openembedded core (master), only a handful of recipes
provide the CVE vendor:

➜  meta git:(master) pwd
/home/jasper/git/openembedded-core/meta   
➜  meta git:(master) grep -rP 'CVE_PRODUCT\s*=\s*"\w+:\w+'
recipes-support/curl/curl_8.2.1.bb:CVE_PRODUCT = "haxx:curl
haxx:libcurl curl:curl curl:libcurl libcurl:libcurl
daniel_stenberg:curl"
recipes-support/boost/boost.inc:CVE_PRODUCT = "boost:boost"
recipes-extended/ed/ed_1.19.bb:CVE_PRODUCT = "gnu:ed"
recipes-extended/tar/tar_1.35.bb:CVE_PRODUCT = "gnu:tar"
recipes-devtools/flex/flex_2.6.4.bb:CVE_PRODUCT = "flex_project:flex"
recipes-devtools/subversion/subversion_1.14.2.bb:CVE_PRODUCT =
"apache:subversion"
recipes-connectivity/openssl/openssl_3.1.2.bb:CVE_PRODUCT =
"openssl:openssl"

Without the patch these few recipes will indeed match _some_ CVEs.

Everything other recipe is missing a vendor attribute and will
therefore not match according to the NIST specification regardless of
the provided "a" or "*".

But yes, for what it's worth it probably does not make sense to
backport the patch at the moment, since it will just replace one
erroneous behaviour with another. I only realized this after submitting
the patch, as in my use-case (integration with dependencytrack) there
were indeed more "matches" (1 CVE on Kernel vs. 300+), but after closer
inspection it turned out that was only due to an optional fuzzy
matching feature in dependencytrack and not because the results
actually improved. Sorry for the trouble.

Cheers, Jasper

On Fri, 2023-08-25 at 09:57 -1000, Steve Sakoman wrote:
> On Fri, Aug 25, 2023 at 9:18 AM Jasper Orschulko via
> lists.openembedded.org
>  wrote:
> > 
> > Hi Richard,
> > hi all,
> > 
> > I want to address a flaw in the current CPE generation
> > functionality in
> > openembedded, which renders the CPEs unusable in regards to the
> > minimal
> > requirements of the NIST CPE Name Matching Specification standard
> > (https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7696.pdf).
> > 
> > This makes working with the generated CPEs in thirdparty software
> > close
> > to impossible, as it would require the thirdparty software to
> > implement
> > matching logic beyond the requirements defined in the NIST
> > standard.
> > 
> > 
> > Status quo:
> > 
> > Currently, the CPE is generated from the optional CVE_PRODUCT
> > (optionally including the vendor) and CVE_VERSION variables. If
> > neither
> > are provided, CPE generation will fall back on the BPN and PV of
> > the
> > recipe.
> > 
> > As a result, the generated CPE will usually look as follows:
> > 
> > cpe:2.3:*:*:${BPN}:${PV}:*:*:*:*:*:*:*:*
> > 
> > Or, if the CVE_PRODUCT includes a vendor:
> > 
> > cpe:2.3:*:${vendor}:${product}:${PV}:*:*:*:*:*:*:*:*
> > 
> > 
> > 
> > The Issue (The TL;DR):
> > 
> > This will return zero¹ matches when doing CPE matching against CVE
> > CPEs
> > in accordance with the minimal requirements of the NIST Name
> > Matching
> > Specification. For reliable matches the components CPE should be as
> > precise as possible, i.e. not containing any "*" (ANY) values for
> > vital
> > attributes, such as: Part, Vendor, Product, Version, Target_HW.
> > 
> > 
> > 
> > The Issue (In detail):
> > 
> > To understand the issue in full detail, in depth knowledge of the
> > NIST
> > specification is required. However, I will try to provide a
> > comprehensive summary below:
> > 
> > CPE matching is done using a source CPE and target CPE. Due to
> > limitations (see Table 6-2, cases 4 & 11), using the CVE CPE as a
> > source and the component CPE as a target is the only sensible way
> > (otherwise a CVE CPE containing wildcards would lead to undefined
> > behavior).
> > 
> > Each attribute of the CVE CPE, will then be matched against the
> > component CPE, setting the relationship of each source attribute to
> > the
> > corresponding target attribute to either superset (⊃), equal (=),
> > subset (⊂) or disjoint (≠) (see Table 6-1, example: Table 6-3).
> > 
> > The NIST standard then defines 4 required CPE Name Comparison
> > Relations
> > (see Table 6-4), with two of them relevant for what we would
> > consider a
> > "match" between a CVE CPE and a component CPE:
> > 
> > If all attribute relations are EQUAL (=) -> Then CPE name relation
> > is
> > EQUAL (=) -> match
> > 
> > If all attribute relations are SUPERSET (⊃) or
> > EQUAL (=) -> Then CPE name relation is SUPERSET (⊃) -> match
> > 
> > Let's take a look at this, based on a real-world example:
> > 
> > CVE CPE: cpe:2.3:o:linux:linux_kernel:5.15.37:*:*:*:*:*:x86:*:*
> > Component CPE: cpe:2.3:*:*:linux_kernel:5.15.37:*:*:*:*:*:*:*:*
> > 
> > In this example the CVE CPE has the attributes "Part" ("o"),
> > "Vendor"
> > ("linux") and "Target_HW" defined, while the Component CPE sets
> > these
> > attributes to "ANY", thus the CVE CPE attributes are subsets of the
> > component CPEs (see 

Re: [OE-core] Providing detailed CPE information for CVE matching capabilities

[Steve Sakoman]

On Fri, Aug 25, 2023 at 9:18 AM Jasper Orschulko via
lists.openembedded.org
 wrote:
>
> Hi Richard,
> hi all,
>
> I want to address a flaw in the current CPE generation functionality in
> openembedded, which renders the CPEs unusable in regards to the minimal
> requirements of the NIST CPE Name Matching Specification standard
> (https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7696.pdf).
>
> This makes working with the generated CPEs in thirdparty software close
> to impossible, as it would require the thirdparty software to implement
> matching logic beyond the requirements defined in the NIST standard.
>
>
> Status quo:
>
> Currently, the CPE is generated from the optional CVE_PRODUCT
> (optionally including the vendor) and CVE_VERSION variables. If neither
> are provided, CPE generation will fall back on the BPN and PV of the
> recipe.
>
> As a result, the generated CPE will usually look as follows:
>
> cpe:2.3:*:*:${BPN}:${PV}:*:*:*:*:*:*:*:*
>
> Or, if the CVE_PRODUCT includes a vendor:
>
> cpe:2.3:*:${vendor}:${product}:${PV}:*:*:*:*:*:*:*:*
>
>
>
> The Issue (The TL;DR):
>
> This will return zero¹ matches when doing CPE matching against CVE CPEs
> in accordance with the minimal requirements of the NIST Name Matching
> Specification. For reliable matches the components CPE should be as
> precise as possible, i.e. not containing any "*" (ANY) values for vital
> attributes, such as: Part, Vendor, Product, Version, Target_HW.
>
>
>
> The Issue (In detail):
>
> To understand the issue in full detail, in depth knowledge of the NIST
> specification is required. However, I will try to provide a
> comprehensive summary below:
>
> CPE matching is done using a source CPE and target CPE. Due to
> limitations (see Table 6-2, cases 4 & 11), using the CVE CPE as a
> source and the component CPE as a target is the only sensible way
> (otherwise a CVE CPE containing wildcards would lead to undefined
> behavior).
>
> Each attribute of the CVE CPE, will then be matched against the
> component CPE, setting the relationship of each source attribute to the
> corresponding target attribute to either superset (⊃), equal (=),
> subset (⊂) or disjoint (≠) (see Table 6-1, example: Table 6-3).
>
> The NIST standard then defines 4 required CPE Name Comparison Relations
> (see Table 6-4), with two of them relevant for what we would consider a
> "match" between a CVE CPE and a component CPE:
>
> If all attribute relations are EQUAL (=) -> Then CPE name relation is
> EQUAL (=) -> match
>
> If all attribute relations are SUPERSET (⊃) or
> EQUAL (=) -> Then CPE name relation is SUPERSET (⊃) -> match
>
> Let's take a look at this, based on a real-world example:
>
> CVE CPE: cpe:2.3:o:linux:linux_kernel:5.15.37:*:*:*:*:*:x86:*:*
> Component CPE: cpe:2.3:*:*:linux_kernel:5.15.37:*:*:*:*:*:*:*:*
>
> In this example the CVE CPE has the attributes "Part" ("o"), "Vendor"
> ("linux") and "Target_HW" defined, while the Component CPE sets these
> attributes to "ANY", thus the CVE CPE attributes are subsets of the
> component CPEs (see Table 6-2, case 13), making the entire CVE CPE a
> subset of the component CPE, thus causing a false-negative.
>
>
>
> Proposed solution:
>
> Openembedded should, in accordance with the CPE Naming Specification
> (https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf), provide
> complete and accurate CPE information (at least: Part, Vendor, Product,
> Version, Target_HW) for recipes in order to avoid false-negatives
> during CVE CPE comparison and ensure compatibility with other tools.
>
> A component CPE could then look like this (something I came up with in
> 5 minutes, enjoy with a grain of salt):
>
> cpe:2.3:o:linux:linux_kernel:5.15.37::*:open
> embedded:::en_US (is there a bitbake
> variable for this?):*
>
> Setting attributes such as SW_Edition = "openembbeded" and Target_SW =
> "" also has the positive side-effect of allowing
> for the registration of openembedded-specific CVEs, e.g.
> vulnerabilities in patches within recipes.
>
> Of course, this is easier said than done, as some of the required
> information, especially "Part" and "Vendor" is missing from existing
> recipes.
>
> I therefore, suggest the following approach:
>
> Step 1 (non-intrusive):
>
> Introduce a new, optional variable CVE_PART, which is set to "a"
> (application) by default but may be overridden in a recipe (e.g. for
> linux_kernel)
>
> For consistency: Introduce the new, optional variable CVE_VENDOR as a
> replacement for the CVE_PRODUCT "double role" (for backwards
> compatibility, we can evaluate CVE_VENDOR first, then check for a
> vendor within CVE_PRODUCT).
>
> Adding already existing information from the build (e.g. Target_HW) to
> the CPE.
>
> Start filling in CVE_VENDOR for core recipes (openembedded-core).
>
> Optional: Step 2 (enforcement):
>
> Once a certain threshold of recipes with complete information is
> reached, we might want to consider enforcing explicit CVE_* variable
> declaration by default, with an 

[OE-core] Providing detailed CPE information for CVE matching capabilities

[Jasper Orschulko via lists.openembedded.org]

Hi Richard,
hi all,

I want to address a flaw in the current CPE generation functionality in
openembedded, which renders the CPEs unusable in regards to the minimal
requirements of the NIST CPE Name Matching Specification standard
(https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7696.pdf).

This makes working with the generated CPEs in thirdparty software close
to impossible, as it would require the thirdparty software to implement
matching logic beyond the requirements defined in the NIST standard.


Status quo:

Currently, the CPE is generated from the optional CVE_PRODUCT
(optionally including the vendor) and CVE_VERSION variables. If neither
are provided, CPE generation will fall back on the BPN and PV of the
recipe.

As a result, the generated CPE will usually look as follows:

cpe:2.3:*:*:${BPN}:${PV}:*:*:*:*:*:*:*:*

Or, if the CVE_PRODUCT includes a vendor:

cpe:2.3:*:${vendor}:${product}:${PV}:*:*:*:*:*:*:*:*



The Issue (The TL;DR):

This will return zero¹ matches when doing CPE matching against CVE CPEs
in accordance with the minimal requirements of the NIST Name Matching
Specification. For reliable matches the components CPE should be as
precise as possible, i.e. not containing any "*" (ANY) values for vital
attributes, such as: Part, Vendor, Product, Version, Target_HW.



The Issue (In detail):

To understand the issue in full detail, in depth knowledge of the NIST
specification is required. However, I will try to provide a
comprehensive summary below:

CPE matching is done using a source CPE and target CPE. Due to
limitations (see Table 6-2, cases 4 & 11), using the CVE CPE as a
source and the component CPE as a target is the only sensible way
(otherwise a CVE CPE containing wildcards would lead to undefined
behavior).

Each attribute of the CVE CPE, will then be matched against the
component CPE, setting the relationship of each source attribute to the
corresponding target attribute to either superset (⊃), equal (=),
subset (⊂) or disjoint (≠) (see Table 6-1, example: Table 6-3).

The NIST standard then defines 4 required CPE Name Comparison Relations
(see Table 6-4), with two of them relevant for what we would consider a
"match" between a CVE CPE and a component CPE:

If all attribute relations are EQUAL (=) -> Then CPE name relation is
EQUAL (=) -> match

If all attribute relations are SUPERSET (⊃) or
EQUAL (=) -> Then CPE name relation is SUPERSET (⊃) -> match

Let's take a look at this, based on a real-world example:

CVE CPE: cpe:2.3:o:linux:linux_kernel:5.15.37:*:*:*:*:*:x86:*:*
Component CPE: cpe:2.3:*:*:linux_kernel:5.15.37:*:*:*:*:*:*:*:*

In this example the CVE CPE has the attributes "Part" ("o"), "Vendor"
("linux") and "Target_HW" defined, while the Component CPE sets these
attributes to "ANY", thus the CVE CPE attributes are subsets of the
component CPEs (see Table 6-2, case 13), making the entire CVE CPE a
subset of the component CPE, thus causing a false-negative.



Proposed solution:

Openembedded should, in accordance with the CPE Naming Specification
(https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf), provide
complete and accurate CPE information (at least: Part, Vendor, Product,
Version, Target_HW) for recipes in order to avoid false-negatives
during CVE CPE comparison and ensure compatibility with other tools.

A component CPE could then look like this (something I came up with in
5 minutes, enjoy with a grain of salt):

cpe:2.3:o:linux:linux_kernel:5.15.37::*:open
embedded:::en_US (is there a bitbake
variable for this?):*

Setting attributes such as SW_Edition = "openembbeded" and Target_SW =
"" also has the positive side-effect of allowing
for the registration of openembedded-specific CVEs, e.g.
vulnerabilities in patches within recipes.

Of course, this is easier said than done, as some of the required
information, especially "Part" and "Vendor" is missing from existing
recipes.

I therefore, suggest the following approach:

Step 1 (non-intrusive): 

Introduce a new, optional variable CVE_PART, which is set to "a"
(application) by default but may be overridden in a recipe (e.g. for
linux_kernel)

For consistency: Introduce the new, optional variable CVE_VENDOR as a
replacement for the CVE_PRODUCT "double role" (for backwards
compatibility, we can evaluate CVE_VENDOR first, then check for a
vendor within CVE_PRODUCT).

Adding already existing information from the build (e.g. Target_HW) to
the CPE.

Start filling in CVE_VENDOR for core recipes (openembedded-core).

Optional: Step 2 (enforcement):

Once a certain threshold of recipes with complete information is
reached, we might want to consider enforcing explicit CVE_* variable
declaration by default, with an option for disabling this behavior
(e.g. introducing a variable CVE_UNKNOWN), similar to the LICENSE
variable bahavior.


I hope I was able to give some insights on why I believe that
improvements to the openembedded CPE generation process, as well as to
information provided by the recipes (even 

Re: [OE-core] [PATCH] python3: Add packagegroup-core-buildessential rdep to ptests

[Khem Raj]

On 8/25/23 12:54 AM, Richard Purdie wrote:

On Fri, 2023-08-25 at 00:09 -0700, Khem Raj wrote:

cppext test needs full toolchain as it tries to build an extention with
C, using packagegroup-core-buildessential ensures that a function
toolchain bits are pulled into ptest image, as an aside it also
abstracts hardcoding compiler to be gcc

Signed-off-by: Khem Raj 
---
  meta/recipes-devtools/python/python3_3.11.4.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3_3.11.4.bb 
b/meta/recipes-devtools/python/python3_3.11.4.bb
index 8fd1382caa4..e31c4a81ef6 100644
--- a/meta/recipes-devtools/python/python3_3.11.4.bb
+++ b/meta/recipes-devtools/python/python3_3.11.4.bb
@@ -424,7 +424,7 @@ FILES:${PN}-man = "${datadir}/man"
  # See https://bugs.python.org/issue18748 and 
https://bugs.python.org/issue37395
  RDEPENDS:libpython3:append:libc-glibc = " libgcc"
  RDEPENDS:${PN}-ctypes:append:libc-glibc = " ${MLPREFIX}ldconfig"
-RDEPENDS:${PN}-ptest = "${PN}-modules ${PN}-tests ${PN}-dev ${PN}-cgitb 
${PN}-zipapp unzip bzip2 libgcc tzdata coreutils sed gcc g++ binutils"
+RDEPENDS:${PN}-ptest = "${PN}-modules ${PN}-tests ${PN}-dev ${PN}-cgitb 
${PN}-zipapp unzip bzip2 libgcc tzdata coreutils sed 
packagegroup-core-buildessential"
  RDEPENDS:${PN}-ptest:append:libc-glibc = " locale-base-fr-fr locale-base-en-us 
locale-base-tr-tr locale-base-de-de"
  RDEPENDS:${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 
'${MLPREFIX}tk ${MLPREFIX}tk-lib', '', d)}"
  RDEPENDS:${PN}-idle += "${@bb.utils.contains('PACKAGECONFIG', 'tk', '${PN}-tkinter 
${MLPREFIX}tcl', '', d)}"


That also increases the dependencies needed to complete a build of
target python and I'm not sure this is a great idea. Compiler
dependencies in ptests are a real problem in this regard but this patch
makes the situation a lot worse :(



We can drop it, I have added the needed bits into meta-clang
I think hardcoding dependencies for toolchain components could be made 
better.


for poky ptests is in default distro features so I can see your concern


Cheers,

Richard


OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186723): 
https://lists.openembedded.org/g/openembedded-core/message/186723
Mute This Topic: https://lists.openembedded.org/mt/100951409/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] base.bbclass: Do not fail during parsing if ${SRCREV} does not exist

[Peter Kjellerstedt]

After commit a8e7b0f932 (base/package: Move source revision information
from PV to PKGV) was integrated, having a recipe with a SRCREV that
currently cannot be fetched would lead to an exception during parsing.
Catch that exception and instead raise bb.parse.SkipRecipe. That way
the parsing continues as it should. Instead you now get a meaningful
error if you try build a recipe with a SRCREV that cannot be fetched,
e.g.:

  ERROR: Nothing PROVIDES 'psplash'
  psplash was skipped: Fetcher failure: Unable to resolve 'unknown-ref'
  in upstream git repository in git ls-remote output for
  git.yoctoproject.org/psplash

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes-global/base.bbclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
index 7c774d250f..fb55a6eee9 100644
--- a/meta/classes-global/base.bbclass
+++ b/meta/classes-global/base.bbclass
@@ -131,7 +131,13 @@ def setup_hosttools_dir(dest, toolsvar, d, fatal=True):
 python fetcher_hashes_dummyfunc() {
 return
 }
-fetcher_hashes_dummyfunc[vardepvalue] = "${@bb.fetch.get_hashvalue(d)}"
+fetcher_hashes_dummyfunc[vardepvalue] = "${@validate_hashvalue(d)}"
+
+def validate_hashvalue(d):
+try:
+bb.fetch.get_hashvalue(d)
+except bb.fetch2.FetchError as e:
+raise bb.parse.SkipRecipe(e)
 
 addtask fetch
 do_fetch[dirs] = "${DL_DIR}"

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186722): 
https://lists.openembedded.org/g/openembedded-core/message/186722
Mute This Topic: https://lists.openembedded.org/mt/100960059/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH][dunfell 3/3] linux/cve-exclusion: remove obsolete manual entries

[Ross Burton]

From: Ross Burton 

The generated file covers all but two of these CVEs (which will be fixed
when [1] and [2] are resolved) so remove the redundant entries.

[1] https://github.com/nluedtke/linux_kernel_cves/issues/344
[2] https://github.com/nluedtke/linux_kernel_cves/issues/345

Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/linux/cve-exclusion.inc | 1827 ---
 1 file changed, 1827 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc 
b/meta/recipes-kernel/linux/cve-exclusion.inc
index a18e603bc93..efc8b094755 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -1,1840 +1,13 @@
 # Kernel CVE exclusion file
 
-# https://nvd.nist.gov/vuln/detail/CVE-2014-8171
-# Patched in kernel since v3.12 4942642080ea82d99ab5b653abb9a12b7ba31f4a
-CVE_CHECK_WHITELIST += "CVE-2014-8171"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2017-1000255
-# Patched in kernel since v4.14 265e60a170d0a0ecfc2d20490134ed2c48dd45ab
-CVE_CHECK_WHITELIST += "CVE-2017-1000255"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2018-5873
-# Patched in kernel since v4.11 073c516ff73557a8f7315066856c04b50383ac34
-CVE_CHECK_WHITELIST += "CVE-2018-5873"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2018-10840
-# Patched in kernel since v4.18 8a2b307c21d4b290e3cbe33f768f194286d07c23
-CVE_CHECK_WHITELIST += "CVE-2018-10840"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2018-10876
-# Patched in kernel since v4.18 8844618d8aa7a9973e7b527d038a2a589665002c
-CVE_CHECK_WHITELIST += "CVE-2018-10876"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2018-10882
-# Patched in kernel since v4.18 c37e9e013469521d9adb932d17a1795c139b36db
-CVE_CHECK_WHITELIST += "CVE-2018-10882"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2018-10902
-# Patched in kernel since v4.18 39675f7a7c7e7702f7d5341f1e0d01db746543a0
-CVE_CHECK_WHITELIST += "CVE-2018-10902"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2018-14625
-# Patched in kernel since v4.20 834e772c8db0c6a275d75315d90aba4ebbb1e249
-CVE_CHECK_WHITELIST += "CVE-2018-14625"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2018-16880
-# Patched in kernel since v5.0 b46a0bf78ad7b150ef5910da83859f7f5a514ffd
-CVE_CHECK_WHITELIST += "CVE-2018-16880"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2018-16884
-# Patched in kernel since v5.0 d4b09acf924b84bae77cad090a9d108e70b43643
-CVE_CHECK_WHITELIST += "CVE-2018-16884"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2019-3819
-# Patched in kernel since v5.0 13054abbaa4f1fd4e6f3b4b63439ec033b4c8035
-CVE_CHECK_WHITELIST += "CVE-2019-3819"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2019-20810
-# Patched in kernel since v5.6 9453264ef58638ce8976121ac44c07a3ef375983
-# Backported in version v5.4.48 6e688a315acf9c2b9b6e8c3e3b7a0c2720f72cba
-CVE_CHECK_WHITELIST += "CVE-2019-20810"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2020-1749
-# Patched in kernel since v5.5 6c8991f41546c3c472503dff1ea9daaddf9331c2
-# Backported in version v5.4.5 48d58ae9e87aaa11814364ddb52b3461f9abac57
-CVE_CHECK_WHITELIST += "CVE-2020-1749"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2020-8428
-# Patched in kernel since v5.5 d0cb50185ae942b03c4327be322055d622dc79f6
-# Backported in version v5.4.16 454759886d0b463213fad0f1c733469e2c501ab9
-CVE_CHECK_WHITELIST += "CVE-2020-8428"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2020-8647
-# Patched in kernel since v5.6 513dc792d6060d5ef572e43852683097a8420f56
-# Backported in version v5.4.25 5d230547476eea90b57ed9fda4bfe5307779abbb
-CVE_CHECK_WHITELIST += "CVE-2020-8647"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2020-8649
-# Patched in kernel since v5.6 513dc792d6060d5ef572e43852683097a8420f56
-# Backported in version v5.4.25 5d230547476eea90b57ed9fda4bfe5307779abbb
-CVE_CHECK_WHITELIST += "CVE-2020-8649"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2020-8992
-# Patched in kernel since v5.6 af133ade9a40794a37104ecbcc2827c0ea373a3c
-# Backported in version v5.4.21 94f0fe04da78adc214b51523499031664f9db408
-CVE_CHECK_WHITELIST += "CVE-2020-8992"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2020-9383
-# Patched in kernel since v5.6 2e90ca68b0d2f5548804f22f0dd61145516171e3
-# Backported in version v5.4.23 1eb78bc92c847f9e1c01a01b2773fc2fe7b134cf
-CVE_CHECK_WHITELIST += "CVE-2020-9383"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2020-10690
-# Patched in kernel since v5.5 a33121e5487b424339636b25c35d3a180eaa5f5e
-# Backported in version v5.4.8 bfa2e0cd3dfda64fde43c3dca3aeba298d2fe7ad
-CVE_CHECK_WHITELIST += "CVE-2020-10690"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2020-10711
-# Patched in kernel since v5.7 eead1c2ea2509fd754c6da893a94f0e69e83ebe4
-# Backported in version v5.4.42 debcbc56fdfc2847804d3d00d43f68f3074c5987
-CVE_CHECK_WHITELIST += "CVE-2020-10711"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2020-10732
-# Patched in kernel since v5.7 1d605416fb7175e1adf094251466caa52093b413
-# Backported in version v5.4.44 a02c130efbbce91af1e9dd99a5a381dd43494e15
-CVE_CHECK_WHITELIST += "CVE-2020-10732"
-
-# 

[OE-core] [PATCH][dunfell 1/3] linux-yocto: add script to generate kernel CVE_CHECK_WHITELIST entries

[Ross Burton]

From: Ross Burton 

Instead of manually looking up new CVEs and determining what point
releases the fixes are incorporated into, add a script to generate the
CVE_CHECK_WHITELIST data automatically.

First, note that this is very much an interim solution until the
cve-check class fetches data from www.linuxkernelcves.com directly.

The script should be passed the path to a local clone of the
linuxkernelcves repository[1] and the kernel version number. It will
then write to standard output the CVE_STATUS entries for every known
kernel CVE.

The script should be periodically reran as CVEs are backported and
kernels upgraded frequently.

[1] https://github.com/nluedtke/linux_kernel_cves

Note: for the Dunfell backport this is not a cherry-pick of the commit
in master as the variable names are different. This incorporates the
following commits:

linux/generate-cve-exclusions: add version check warning
linux/generate-cve-exclusions.py: fix comparison
linux-yocto: add script to generate kernel CVE_STATUS entries

Signed-off-by: Ross Burton 
---
 .../linux/generate-cve-exclusions.py  | 101 ++
 1 file changed, 101 insertions(+)
 create mode 100755 meta/recipes-kernel/linux/generate-cve-exclusions.py

diff --git a/meta/recipes-kernel/linux/generate-cve-exclusions.py 
b/meta/recipes-kernel/linux/generate-cve-exclusions.py
new file mode 100755
index 000..12ae3b0b1d0
--- /dev/null
+++ b/meta/recipes-kernel/linux/generate-cve-exclusions.py
@@ -0,0 +1,101 @@
+#! /usr/bin/env python3
+
+# Generate granular CVE status metadata for a specific version of the kernel
+# using data from linuxkernelcves.com.
+#
+# SPDX-License-Identifier: GPL-2.0-only
+
+import argparse
+import datetime
+import json
+import pathlib
+import re
+
+from packaging.version import Version
+
+
+def parse_version(s):
+"""
+Parse the version string and either return a packaging.version.Version, or
+None if the string was unset or "unk".
+"""
+if s and s != "unk":
+# packaging.version.Version doesn't approve of versions like 
v5.12-rc1-dontuse
+s = s.replace("-dontuse", "")
+return Version(s)
+return None
+
+
+def main(argp=None):
+parser = argparse.ArgumentParser()
+parser.add_argument("datadir", type=pathlib.Path, help="Path to a clone of 
https://github.com/nluedtke/linux_kernel_cves;)
+parser.add_argument("version", type=Version, help="Kernel version number 
to generate data for, such as 6.1.38")
+
+args = parser.parse_args(argp)
+datadir = args.datadir
+version = args.version
+base_version = f"{version.major}.{version.minor}"
+
+with open(datadir / "data" / "kernel_cves.json", "r") as f:
+cve_data = json.load(f)
+
+with open(datadir / "data" / "stream_fixes.json", "r") as f:
+stream_data = json.load(f)
+
+print(f"""
+# Auto-generated CVE metadata, DO NOT EDIT BY HAND.
+# Generated at {datetime.datetime.now()} for version {version}
+
+python check_kernel_cve_status_version() {{
+this_version = "{version}"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
+""")
+
+for cve, data in cve_data.items():
+if "affected_versions" not in data:
+print(f"# Skipping {cve}, no affected_versions")
+print()
+continue
+
+affected = data["affected_versions"]
+first_affected, last_affected = re.search(r"(.+) to (.+)", 
affected).groups()
+first_affected = parse_version(first_affected)
+last_affected = parse_version(last_affected)
+
+handled = False
+if not last_affected:
+print(f"# {cve} has no known resolution")
+elif first_affected and version < first_affected:
+print(f"# fixed-version: only affects {first_affected} onwards")
+handled = True
+elif last_affected < version:
+print(f"# fixed-version: Fixed after version {last_affected}")
+handled = True
+else:
+if cve in stream_data:
+backport_data = stream_data[cve]
+if base_version in backport_data:
+backport_ver = 
Version(backport_data[base_version]["fixed_version"])
+if backport_ver <= version:
+print(f"# cpe-stable-backport: Backported in 
{backport_ver}")
+handled = True
+else:
+# TODO print a note that the kernel needs bumping
+print(f"# {cve} needs backporting (fixed from 
{backport_ver})")
+else:
+print(f"# {cve} needs backporting (fixed from 
{last_affected})")
+else:
+print(f"# {cve} needs backporting (fixed from 

[OE-core] [PATCH][kirkstone 3/3] linux/cve-exclusion: remove obsolete manual entries

[Ross Burton]

From: Ross Burton 

The generated file covers all but one of these CVEs (which will be fixed
when [1] is resolved) so remove the redundant entries.

[1] https://github.com/nluedtke/linux_kernel_cves/issues/344

Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/linux/cve-exclusion.inc | 869 
 1 file changed, 869 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc 
b/meta/recipes-kernel/linux/cve-exclusion.inc
index 45b7a3dffeb..c34928e1002 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -1,875 +1,6 @@
-# Kernel CVE exclusion file
-
-# https://nvd.nist.gov/vuln/detail/CVE-2021-3759
-# Patched in kernel since v5.15 18319498fdd4cdf8c1c2c48cd432863b1f915d6f
-# Backported in version v5.4.224 bad83d55134e647a739ebef2082541963f2cbc92
-# Backported in version v5.10.154 836686e1a01d7e2fda6a5a18252243ff30a6e196
-CVE_CHECK_IGNORE += "CVE-2021-3759"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2021-4135
-# Patched in kernel since v5.16 481221775d53d6215a6e5e9ce1cce6d2b4ab9a46
-# Backported in version v5.4.168 699e794c12a3cd79045ff135bc87a53b97024e43
-# Backported in version v5.10.88 1a34fb9e2bf3029f7c0882069d67ff69cbd645d8
-# Backported in version v5.15.11 27358aa81a7d60e6bd36f0bb1db65cd084c2cad0
-CVE_CHECK_IGNORE += "CVE-2021-4135"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2021-4155
-# Patched in kernel since v5.16 983d8e60f50806f90534cc5373d0ce867e5aaf79
-# Backported in version v5.4.171 102af6edfd3a372db6e229177762a91f552e5f5e
-# Backported in version v5.10.91 16d8568378f9ee2d1e69216d39961aa72710209f
-# Backported in version v5.15.14 b0e72ba9e520b95346e68800afff0db65e766ca8
-CVE_CHECK_IGNORE += "CVE-2021-4155"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-0168
-# Patched in kernel since v5.18 b92e358757b91c2827af112cae9af513f26a3f34
-# Backported in version v5.10.110 9963ccea6087268e1275b992dca5d0dd4b938765
-# Backported in version v5.15.33 f143f8334fb9eb2f6c7c15b9da1472d9c965fd84
-CVE_CHECK_IGNORE += "CVE-2022-0168"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-0171
-# Patched in kernel since v5.18 683412ccf61294d727ead4a73d97397396e69a6b
-# Backported in version v5.10.146 a60babeb60ff276963d4756c7fd2e7bf242bb777
-# Backported in version v5.15.70 39b0235284c7aa33a64e07b825add7a2c108094a
-CVE_CHECK_IGNORE += "CVE-2022-0171"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1016
-# Patched in kernel since v5.18 4c905f6740a365464e91467aa50916555b28213d
-# Backported in version v5.4.188 06f0ff82c70241a766a811ae1acf07d6e2734dcb
-# Backported in version v5.10.109 2c74374c2e88c7b7992bf808d9f9391f7452f9d9
-# Backported in version v5.15.32 fafb904156fbb8f1dd34970cd5223e00b47c33be
-CVE_CHECK_IGNORE += "CVE-2022-1016"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1184
-# Patched in kernel since v6.1 61a1d87a324ad5e3ed27c6699dfc93218fcf3201
-# Backported in version v5.10.150 483831ad0440f62c10d1707c97ce824bd82d98ae
-# Backported in version v5.15.75 dd366295d1eca557e7a9000407ec3952f691d27b
-# Backported in version v5.19.17 edb71f055684f9023fd97e2f85c6f31380d163c1
-CVE_CHECK_IGNORE += "CVE-2022-1184"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1198
-# Patched in kernel since v5.17 efe4186e6a1b54bf38b9e05450d43b0da1fd7739
-# Backported in version v5.4.189 28c8fd84bea13cbf238d7b19d392de2fcc31331c
-# Backported in version v5.10.110 f67a1400788f550d201c71aeaf56706afe57f0da
-# Backported in version v5.15.33 3eb18f8a1d02a9462a0e4903efc674ca3d0406d1
-CVE_CHECK_IGNORE += "CVE-2022-1198"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1199
-# Patched in kernel since v5.17 71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac
-# Backported in version v5.4.185 0a64aea5fe023cf1e4973676b11f49038b1f045b
-# Backported in version v5.10.106 e2201ef32f933944ee02e59205adb566bafcdf91
-# Backported in version v5.15.29 46ad629e58ce3a88c924ff3c5a7e9129b0df5659
-CVE_CHECK_IGNORE += "CVE-2022-1199"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1462
-# Patched in kernel since v5.19 a501ab75e7624d133a5a3c7ec010687c8b961d23
-# Backported in version v5.4.208 f7785092cb7f022f59ebdaa181651f7c877df132
-# Backported in version v5.10.134 08afa87f58d83dfe040572ed591b47e8cb9e225c
-# Backported in version v5.15.58 b2d1e4cd558cffec6bfe318f5d74e6cffc374d29
-CVE_CHECK_IGNORE += "CVE-2022-1462"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1734
-# Patched in kernel since v5.18 d270453a0d9ec10bb8a802a142fb1b3601a83098
-# Backported in version v5.4.193 33d3e76fc7a7037f402246c824d750542e2eb37f
-# Backported in version v5.10.115 1961c5a688edb53fe3bc25cbda57f47adf12563c
-# Backported in version v5.15.39 b8f2b836e7d0a553b886654e8b3925a85862d2eb
-CVE_CHECK_IGNORE += "CVE-2022-1734"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1852
-# Patched in kernel since v5.19 fee060cd52d69c114b62d1a2948ea9648b5131f9
-# Backported in version v5.10.120 3d8fc6e28f321d753ab727e3c3e740daf36a8fa3
-# Backported in version v5.15.45 531d1070d864c78283b7597449e60ddc53319d88
-CVE_CHECK_IGNORE += 

[OE-core] [PATCH][kirkstone 1/3] linux-yocto: add script to generate kernel CVE_CHECK_IGNORE entries

[Ross Burton]

From: Ross Burton 

Instead of manually looking up new CVEs and determining what point
releases the fixes are incorporated into, add a script to generate the
CVE_CHECK_IGNORE data automatically.

First, note that this is very much an interim solution until the
cve-check class fetches data from www.linuxkernelcves.com directly.

The script should be passed the path to a local clone of the
linuxkernelcves repository[1] and the kernel version number. It will
then write to standard output the CVE_STATUS entries for every known
kernel CVE.

The script should be periodically reran as CVEs are backported and
kernels upgraded frequently.

[1] https://github.com/nluedtke/linux_kernel_cves

Note: for the backport this is not a cherry-pick of the commit in master
as the variable names are different. This incorporates the following
commits:

linux/generate-cve-exclusions: add version check warning
linux/generate-cve-exclusions.py: fix comparison
linux-yocto: add script to generate kernel CVE_STATUS entries

Signed-off-by: Ross Burton 
---
 .../linux/generate-cve-exclusions.py  | 101 ++
 1 file changed, 101 insertions(+)
 create mode 100755 meta/recipes-kernel/linux/generate-cve-exclusions.py

diff --git a/meta/recipes-kernel/linux/generate-cve-exclusions.py 
b/meta/recipes-kernel/linux/generate-cve-exclusions.py
new file mode 100755
index 000..b9b87f245d6
--- /dev/null
+++ b/meta/recipes-kernel/linux/generate-cve-exclusions.py
@@ -0,0 +1,101 @@
+#! /usr/bin/env python3
+
+# Generate granular CVE status metadata for a specific version of the kernel
+# using data from linuxkernelcves.com.
+#
+# SPDX-License-Identifier: GPL-2.0-only
+
+import argparse
+import datetime
+import json
+import pathlib
+import re
+
+from packaging.version import Version
+
+
+def parse_version(s):
+"""
+Parse the version string and either return a packaging.version.Version, or
+None if the string was unset or "unk".
+"""
+if s and s != "unk":
+# packaging.version.Version doesn't approve of versions like 
v5.12-rc1-dontuse
+s = s.replace("-dontuse", "")
+return Version(s)
+return None
+
+
+def main(argp=None):
+parser = argparse.ArgumentParser()
+parser.add_argument("datadir", type=pathlib.Path, help="Path to a clone of 
https://github.com/nluedtke/linux_kernel_cves;)
+parser.add_argument("version", type=Version, help="Kernel version number 
to generate data for, such as 6.1.38")
+
+args = parser.parse_args(argp)
+datadir = args.datadir
+version = args.version
+base_version = f"{version.major}.{version.minor}"
+
+with open(datadir / "data" / "kernel_cves.json", "r") as f:
+cve_data = json.load(f)
+
+with open(datadir / "data" / "stream_fixes.json", "r") as f:
+stream_data = json.load(f)
+
+print(f"""
+# Auto-generated CVE metadata, DO NOT EDIT BY HAND.
+# Generated at {datetime.datetime.now()} for version {version}
+
+python check_kernel_cve_status_version() {{
+this_version = "{version}"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
+""")
+
+for cve, data in cve_data.items():
+if "affected_versions" not in data:
+print(f"# Skipping {cve}, no affected_versions")
+print()
+continue
+
+affected = data["affected_versions"]
+first_affected, last_affected = re.search(r"(.+) to (.+)", 
affected).groups()
+first_affected = parse_version(first_affected)
+last_affected = parse_version(last_affected)
+
+handled = False
+if not last_affected:
+print(f"# {cve} has no known resolution")
+elif first_affected and version < first_affected:
+print(f"# fixed-version: only affects {first_affected} onwards")
+handled = True
+elif last_affected < version:
+print(f"# fixed-version: Fixed after version {last_affected}")
+handled = True
+else:
+if cve in stream_data:
+backport_data = stream_data[cve]
+if base_version in backport_data:
+backport_ver = 
Version(backport_data[base_version]["fixed_version"])
+if backport_ver <= version:
+print(f"# cpe-stable-backport: Backported in 
{backport_ver}")
+handled = True
+else:
+# TODO print a note that the kernel needs bumping
+print(f"# {cve} needs backporting (fixed from 
{backport_ver})")
+else:
+print(f"# {cve} needs backporting (fixed from 
{last_affected})")
+else:
+print(f"# {cve} needs backporting (fixed from 

[OE-core] [PATCH][mickledore 1/2] linux-yocto: add script to generate kernel CVE_CHECK_IGNORE entries

[Ross Burton]

From: Ross Burton 

Instead of manually looking up new CVEs and determining what point
releases the fixes are incorporated into, add a script to generate the
CVE_CHECK_IGNORE data automatically.

First, note that this is very much an interim solution until the
cve-check class fetches data from www.linuxkernelcves.com directly.

The script should be passed the path to a local clone of the
linuxkernelcves repository[1] and the kernel version number. It will
then write to standard output the CVE_STATUS entries for every known
kernel CVE.

The script should be periodically reran as CVEs are backported and
kernels upgraded frequently.

[1] https://github.com/nluedtke/linux_kernel_cves

Note: for the backport this is not a cherry-pick of the commit in master
as the variable names are different. This incorporates the following
commits:

linux/generate-cve-exclusions: add version check warning
linux/generate-cve-exclusions.py: fix comparison
linux-yocto: add script to generate kernel CVE_STATUS entries

Signed-off-by: Ross Burton 
---
 .../linux/generate-cve-exclusions.py  | 101 ++
 1 file changed, 101 insertions(+)
 create mode 100755 meta/recipes-kernel/linux/generate-cve-exclusions.py

diff --git a/meta/recipes-kernel/linux/generate-cve-exclusions.py 
b/meta/recipes-kernel/linux/generate-cve-exclusions.py
new file mode 100755
index 000..b9b87f245d6
--- /dev/null
+++ b/meta/recipes-kernel/linux/generate-cve-exclusions.py
@@ -0,0 +1,101 @@
+#! /usr/bin/env python3
+
+# Generate granular CVE status metadata for a specific version of the kernel
+# using data from linuxkernelcves.com.
+#
+# SPDX-License-Identifier: GPL-2.0-only
+
+import argparse
+import datetime
+import json
+import pathlib
+import re
+
+from packaging.version import Version
+
+
+def parse_version(s):
+"""
+Parse the version string and either return a packaging.version.Version, or
+None if the string was unset or "unk".
+"""
+if s and s != "unk":
+# packaging.version.Version doesn't approve of versions like 
v5.12-rc1-dontuse
+s = s.replace("-dontuse", "")
+return Version(s)
+return None
+
+
+def main(argp=None):
+parser = argparse.ArgumentParser()
+parser.add_argument("datadir", type=pathlib.Path, help="Path to a clone of 
https://github.com/nluedtke/linux_kernel_cves;)
+parser.add_argument("version", type=Version, help="Kernel version number 
to generate data for, such as 6.1.38")
+
+args = parser.parse_args(argp)
+datadir = args.datadir
+version = args.version
+base_version = f"{version.major}.{version.minor}"
+
+with open(datadir / "data" / "kernel_cves.json", "r") as f:
+cve_data = json.load(f)
+
+with open(datadir / "data" / "stream_fixes.json", "r") as f:
+stream_data = json.load(f)
+
+print(f"""
+# Auto-generated CVE metadata, DO NOT EDIT BY HAND.
+# Generated at {datetime.datetime.now()} for version {version}
+
+python check_kernel_cve_status_version() {{
+this_version = "{version}"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
+""")
+
+for cve, data in cve_data.items():
+if "affected_versions" not in data:
+print(f"# Skipping {cve}, no affected_versions")
+print()
+continue
+
+affected = data["affected_versions"]
+first_affected, last_affected = re.search(r"(.+) to (.+)", 
affected).groups()
+first_affected = parse_version(first_affected)
+last_affected = parse_version(last_affected)
+
+handled = False
+if not last_affected:
+print(f"# {cve} has no known resolution")
+elif first_affected and version < first_affected:
+print(f"# fixed-version: only affects {first_affected} onwards")
+handled = True
+elif last_affected < version:
+print(f"# fixed-version: Fixed after version {last_affected}")
+handled = True
+else:
+if cve in stream_data:
+backport_data = stream_data[cve]
+if base_version in backport_data:
+backport_ver = 
Version(backport_data[base_version]["fixed_version"])
+if backport_ver <= version:
+print(f"# cpe-stable-backport: Backported in 
{backport_ver}")
+handled = True
+else:
+# TODO print a note that the kernel needs bumping
+print(f"# {cve} needs backporting (fixed from 
{backport_ver})")
+else:
+print(f"# {cve} needs backporting (fixed from 
{last_affected})")
+else:
+print(f"# {cve} needs backporting (fixed from 

[OE-core] [PATCH v2 2/2] linux-yocto: update CVE exclusions files

[Ross Burton]

From: Ross Burton 

No changes to the data, but the version checks are added.

Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/linux/cve-exclusion_6.1.inc | 11 ++-
 meta/recipes-kernel/linux/cve-exclusion_6.4.inc | 11 ++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion_6.1.inc 
b/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
index 499785f6d2d..ce3a534cf34 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
@@ -1,5 +1,14 @@
+
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2023-08-21 12:41:13.991251 for version 6.1.43
+# Generated at 2023-08-25 12:42:35.329668 for version 6.1.46"
+
+python check_kernel_cve_status_version() {
+this_version = "6.1.46"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
 
 CVE_STATUS[CVE-2003-1604] = "fixed-version: Fixed after version 2.6.12rc2"
 
diff --git a/meta/recipes-kernel/linux/cve-exclusion_6.4.inc 
b/meta/recipes-kernel/linux/cve-exclusion_6.4.inc
index b9210724bf0..63f0760b2d3 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_6.4.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_6.4.inc
@@ -1,5 +1,14 @@
+
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2023-08-21 12:41:33.545124 for version 6.4.9
+# Generated at 2023-08-25 12:42:28.369507 for version 6.4.11"
+
+python check_kernel_cve_status_version() {
+this_version = "6.4.11"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
 
 CVE_STATUS[CVE-2003-1604] = "fixed-version: Fixed after version 2.6.12rc2"
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186713): 
https://lists.openembedded.org/g/openembedded-core/message/186713
Mute This Topic: https://lists.openembedded.org/mt/100958509/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 1/2] linux/generate-cve-exclusions: add version check warning

[Ross Burton]

From: Ross Burton 

Embed the version that this file was generated for in the include, and
compare it to the version that is being checked.

This should act as a reminder to update the file when the kernel is
upgraded.

Signed-off-by: Ross Burton 
---
 .../linux/generate-cve-exclusions.py  | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/generate-cve-exclusions.py 
b/meta/recipes-kernel/linux/generate-cve-exclusions.py
index 34f9ee731dc..3bc1c7096ff 100755
--- a/meta/recipes-kernel/linux/generate-cve-exclusions.py
+++ b/meta/recipes-kernel/linux/generate-cve-exclusions.py
@@ -42,9 +42,18 @@ def main(argp=None):
 with open(datadir / "data" / "stream_fixes.json", "r") as f:
 stream_data = json.load(f)
 
-print("# Auto-generated CVE metadata, DO NOT EDIT BY HAND.")
-print(f"# Generated at {datetime.datetime.now()} for version {version}")
-print()
+print(f"""
+# Auto-generated CVE metadata, DO NOT EDIT BY HAND.
+# Generated at {datetime.datetime.now()} for version {version}
+
+python check_kernel_cve_status_version() {{
+this_version = "{version}"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
+""")
 
 for cve, data in cve_data.items():
 if "affected_versions" not in data:
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186712): 
https://lists.openembedded.org/g/openembedded-core/message/186712
Mute This Topic: https://lists.openembedded.org/mt/100958508/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v3] rust: Upgrade 1.70.0 -> 1.71.0

[Shinde, Yash via lists.openembedded.org]

Hi Luca,

The current version of Rust Oe-selftest is based on Rust 1.70 and works well 
there. It is yet to be updated for Rust 1.71 (eventually 1.72 which is latest). 
With every new Rust version there are newly test cases added from which some 
might fail leading to failure of Rust Oe-selftest.

The patch sent here is only for Rust version update and not for Rust 
Oe-selftest. The Rust Oe-selftest would be updated to recent versions after the 
Rust update is done.

The Rust Oe-selftest fails since it is still on Rust 1.70 and the Rust version 
is updated to 1.71 here. Parallelly will start to rebase Rust Oe-selftest on 
the latest versions.

Regards,
Yash

From: Luca Ceresoli
Sent: 25 August 2023 18:50
To: Shinde, Yash via 
lists.openembedded.org
Cc: Shinde, Yash; 
openembedded-core@lists.openembedded.org;
 MacLeod, Randy; Kallapa, 
Umesh; Gowda, 
Naveen; Kokkonda, 
Sundeep; Moodalappa, 
Shivaprasad
Subject: Re: [OE-core] [PATCH v3] rust: Upgrade 1.70.0 -> 1.71.0

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

Hello Yash,

On Thu, 24 Aug 2023 07:30:18 -0700
"Shinde, Yash via lists.openembedded.org"
 wrote:

> Switch libstd-rs to use the dummy `sysroot` crate which represents the
> standard library crates. Target getrandom-open64.patch at 0.2.8 (merged
> for 0.2.9).
>
> Drop bootstrap_fail.patch as it is merged in upstream rust.
>
> Signed-off-by: Yash Shinde 

The rust.RustSelfTestSystemEmulated.test_rust test is failing on the
ABs with this patch applied:

https://autobuilder.yoctoproject.org/typhoon/#/builders/146/builds/408/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/154/builds/407/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/147/builds/407/steps/12/logs/stdio

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186711): 
https://lists.openembedded.org/g/openembedded-core/message/186711
Mute This Topic: https://lists.openembedded.org/mt/100936266/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 3/3] libx11-compose-data: add CVE_PRODUCT

[Ross Burton]

On 24 Aug 2023, at 14:41, Emil Kronborg Andersen via lists.openembedded.org 
 wrote:
> 
> Signed-off-by: Emil Kronborg Andersen 
> ---
> meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb 
> b/meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb
> index 2131f46213..5d5762456c 100644
> --- a/meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb
> +++ b/meta/recipes-graphics/xorg-lib/libx11-compose-data_1.8.4.bb
> @@ -33,3 +33,5 @@ do_install() {
> PACKAGES = "${PN}"
> 
> FILES:${PN} = "${datadir}/X11/locale ${libdir}/X11/locale"
> +
> +CVE_PRODUCT += "x.org:libx11”

This is _just_ the compose data, is it feasible for this to have a CVE?

Ross


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186710): 
https://lists.openembedded.org/g/openembedded-core/message/186710
Mute This Topic: https://lists.openembedded.org/mt/100935314/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] linux-firmware: add firmware files for NXP BT chipsets

[Tom Hochstein]

Please hold off on this. The -common design is not working correctly and is 
causing those firmware packages to be registered as a runtime dependency of the 
main package.

Tom

-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Tom Hochstein via 
lists.openembedded.org
Sent: Thursday, August 24, 2023 3:04 PM
To: openembedded-core@lists.openembedded.org; otavio.salva...@ossystems.com.br
Cc: Tom Hochstein 
Subject: [OE-core] [PATCH] linux-firmware: add firmware files for NXP BT 
chipsets

These BT only firmware files are submitted for NXP chips.

88w8997-bt:
uartuart8997_bt_v4.bin version: 16.92.21.p81
helper_uart_300.bin version: 16.92.21.p81

88w8987-bt:
uartuart8987_bt.bin version: 16.92.21.p76.5

88w9098-bt:
uartuart9098_bt_v1.bin version: 17.92.1.p136.24

iw416-bt:
uartiw416_bt_v0.bin version: 16.92.21.p81

iw611-bt / iw612-bt:
uartspi_n61x_v1.bin.se version: 18.99.1.p154.40

These firmware files are downloaded over UART interface. The
helper_uart_300.bin needs to be downloaded before
uartuart8997_bt_v4.bin for 88w8997 chip to set download baudrate
to 300.

The above commit message is copied from the source commit message:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/nxp?id=1f82dd25c3ea59b6bed80ee685d860f0c5f19875

Signed-off-by: Tom Hochstein 
---
 .../linux-firmware/linux-firmware_20230625.bb | 50 +++
 1 file changed, 50 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
index 6765226b9d..45556d419e 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
@@ -40,6 +40,7 @@ LICENSE = "\
 & Firmware-myri10ge_firmware \
 & Firmware-netronome \
 & Firmware-nvidia \
+& Firmware-nxp \
 & Firmware-OLPC \
 & Firmware-ath9k-htc \
 & Firmware-phanfw \
@@ -105,6 +106,7 @@ LIC_FILES_CHKSUM = 
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
 
file://LICENCE.Netronome;md5=4add08f2577086d7996503cddf5f \
 file://LICENCE.nvidia;md5=4428a922ed3ba2ceec95f076a488ce07 
\
 file://LICENCE.NXP;md5=58bb8ba632cd729b9ba6183bc6aed36f \
+file://LICENSE.nxp;md5=cca321ca1524d6a1e4fed87486cd82dc \
 file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd \
 
file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 \
 file://LICENCE.phanfw;md5=954dcec0e051f9409812b561ea743bfa 
\
@@ -174,6 +176,7 @@ NO_GENERIC_LICENSE[Firmware-moxa] = "LICENCE.moxa"
 NO_GENERIC_LICENSE[Firmware-myri10ge_firmware] = "LICENCE.myri10ge_firmware"
 NO_GENERIC_LICENSE[Firmware-netronome] = "LICENCE.Netronome"
 NO_GENERIC_LICENSE[Firmware-nvidia] = "LICENCE.nvidia"
+NO_GENERIC_LICENSE[Firmware-nxp] = "LICENSE.nxp"
 NO_GENERIC_LICENSE[Firmware-OLPC] = "LICENCE.OLPC"
 NO_GENERIC_LICENSE[Firmware-ath9k-htc] = "LICENCE.open-ath9k-htc-firmware"
 NO_GENERIC_LICENSE[Firmware-phanfw] = "LICENCE.phanfw"
@@ -309,6 +312,16 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-nvidia-license \
  ${PN}-nvidia-tegra-k1 ${PN}-nvidia-tegra \
  ${PN}-nvidia-gpu \
+ ${PN}-nxp-license \
+ ${PN}-nxp8987-sdio \
+ ${PN}-nxp8997-common \
+ ${PN}-nxp8997-pcie \
+ ${PN}-nxp8997-sdio \
+ ${PN}-nxp9098-common \
+ ${PN}-nxp9098-pcie \
+ ${PN}-nxp9098-sdio \
+ ${PN}-nxpiw416-sdio \
+ ${PN}-nxpiw612-sdio \
  ${PN}-netronome-license ${PN}-netronome \
  ${PN}-qat ${PN}-qat-license \
  ${PN}-qcom-license ${PN}-qcom-yamato-license \
@@ -543,6 +556,42 @@ FILES:${PN}-netronome = " \

 RDEPENDS:${PN}-netronome += "${PN}-netronome-license"

+# For NXP
+LICENSE:${PN}-nxp8987-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-common = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-pcie = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-common = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-pcie = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxpiw416-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxpiw612-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp-license = "Firmware-nxp"
+
+FILES:${PN}-nxp8987-sdio = "${nonarch_base_libdir}/firmware/nxp/*8987*"
+FILES:${PN}-nxp8997-common = " \
+${nonarch_base_libdir}/firmware/nxp/uartuart8997_bt_v4.bin \
+${nonarch_base_libdir}/firmware/nxp/helper_uart_300.bin \
+"
+ALLOW_EMPTY:${PN}-nxp8997-pcie = "1"
+ALLOW_EMPTY:${PN}-nxp8997-sdio = "1"
+FILES:${PN}-nxp9098-common = 
"${nonarch_base_libdir}/firmware/nxp/uartuart9098_bt_v1.bin"
+ALLOW_EMPTY:${PN}-nxp9098-pcie = "1"
+ALLOW_EMPTY:${PN}-nxp9098-sdio = "1"
+FILES:${PN}-nxpiw416-sdio = 

[OE-core] [PATCH 2/2] linux-yocto: update CVE exclusions files

[Ross Burton]

From: Ross Burton 

No changes to the data, but the version checks are added.

Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/linux/cve-exclusion_6.1.inc | 11 ++-
 meta/recipes-kernel/linux/cve-exclusion_6.4.inc | 11 ++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion_6.1.inc 
b/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
index 499785f6d2d..ce3a534cf34 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
@@ -1,5 +1,14 @@
+
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2023-08-21 12:41:13.991251 for version 6.1.43
+# Generated at 2023-08-25 12:42:35.329668 for version 6.1.46"
+
+python check_kernel_cve_status_version() {
+this_version = "6.1.46"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
 
 CVE_STATUS[CVE-2003-1604] = "fixed-version: Fixed after version 2.6.12rc2"
 
diff --git a/meta/recipes-kernel/linux/cve-exclusion_6.4.inc 
b/meta/recipes-kernel/linux/cve-exclusion_6.4.inc
index b9210724bf0..63f0760b2d3 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_6.4.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_6.4.inc
@@ -1,5 +1,14 @@
+
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2023-08-21 12:41:33.545124 for version 6.4.9
+# Generated at 2023-08-25 12:42:28.369507 for version 6.4.11"
+
+python check_kernel_cve_status_version() {
+this_version = "6.4.11"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
 
 CVE_STATUS[CVE-2003-1604] = "fixed-version: Fixed after version 2.6.12rc2"
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186708): 
https://lists.openembedded.org/g/openembedded-core/message/186708
Mute This Topic: https://lists.openembedded.org/mt/100956520/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] linux/generate-cve-exclusions: add version check warning

[Ross Burton]

From: Ross Burton 

Embed the version that this file was generated for in the include, and
compare it to the version that is being checked.

This should act as a reminder to update the file when the kernel is
upgraded.

Signed-off-by: Ross Burton 
---
 .../linux/generate-cve-exclusions.py  | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/generate-cve-exclusions.py 
b/meta/recipes-kernel/linux/generate-cve-exclusions.py
index 34f9ee731dc..f73afebb7e0 100755
--- a/meta/recipes-kernel/linux/generate-cve-exclusions.py
+++ b/meta/recipes-kernel/linux/generate-cve-exclusions.py
@@ -42,9 +42,18 @@ def main(argp=None):
 with open(datadir / "data" / "stream_fixes.json", "r") as f:
 stream_data = json.load(f)
 
-print("# Auto-generated CVE metadata, DO NOT EDIT BY HAND.")
-print(f"# Generated at {datetime.datetime.now()} for version {version}")
-print()
+print(f"""
+# Auto-generated CVE metadata, DO NOT EDIT BY HAND.
+# Generated at {datetime.datetime.now()} for version {version}"
+
+python check_kernel_cve_status_version() {{
+this_version = "{version}"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
+""")
 
 for cve, data in cve_data.items():
 if "affected_versions" not in data:
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186707): 
https://lists.openembedded.org/g/openembedded-core/message/186707
Mute This Topic: https://lists.openembedded.org/mt/100956517/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v3] rust: Upgrade 1.70.0 -> 1.71.0

[Luca Ceresoli via lists.openembedded.org]

Hello Yash,

On Thu, 24 Aug 2023 07:30:18 -0700
"Shinde, Yash via lists.openembedded.org"
 wrote:

> Switch libstd-rs to use the dummy `sysroot` crate which represents the
> standard library crates. Target getrandom-open64.patch at 0.2.8 (merged
> for 0.2.9).
> 
> Drop bootstrap_fail.patch as it is merged in upstream rust.
> 
> Signed-off-by: Yash Shinde 

The rust.RustSelfTestSystemEmulated.test_rust test is failing on the
ABs with this patch applied:

https://autobuilder.yoctoproject.org/typhoon/#/builders/146/builds/408/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/154/builds/407/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/147/builds/407/steps/12/logs/stdio

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186706): 
https://lists.openembedded.org/g/openembedded-core/message/186706
Mute This Topic: https://lists.openembedded.org/mt/100936266/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][kirkstone][PATCH 1/1] python3-git: upgrade 3.1.27 -> 3.1.32

[Narpat Mali via lists.openembedded.org]

From: Narpat Mali 

The delta between 3.1.27 & 3.1.32 contains the CVE-2022-24439 &
CVE-2023-40267 fixes and other bugfixes.

Changelog:
https://github.com/gitpython-developers/GitPython/releases/tag/3.1.32
https://gitpython.readthedocs.io/en/stable/changes.html#id5

- Bump cygwin/cygwin-install-action from 3 to 4 by @dependabot in #1572
- Fix up the commit trailers functionality by @itsluketwist in #1576
- Name top-level exceptions as private variables by @Hawk777 in #1590
- fix pypi long description by @eUgEntOptIc44 in #1603
- Don't rely on del by @r-darwish in #1606
- Block insecure non-multi options in clone/clone_from by @Beuc in #1609
- Fix Sphinx rendering errors by @stephan-cr in #1524
- tests: Use command -v instead of third-party which program by @mgorny in #1525
- fix/add allow_unsafe_* params in docstrings + fix typo by @obfusk in #1530
- use tempfile.TemporaryDirectory & fix clone_from_unsafe_protocol tests by 
@obfusk in #1531
- Fix some resource leaks by open file handles by @marlamb in #1532
- fix files list on file rename by @teknoraver in #1537
- Declare support for Python 3.11 by @hugovk in #1541
- Fix ignored by @Lightborne in #1545
- Fix timezone parsing functions for non-hour timezones by @jcowgill in #1547
- Enable user to override default diff -M arg by @mellowed100 in #1551
- Remove optional from two member variables by @Sineaggi in #1550
- Fix RecursionError when iterating streams by @eric-wieser in #1554
- Fix get_values() so it correctly loads section names by @Codym48 in #1555
- Add datetime.datetime type to commit_date and author_date by 
@SergeantMenacingGarlic in #1501
- Bump cygwin/cygwin-install-action from 2 to 3 by @dependabot in #1514
- Fix command injection by @stsewd in #1518
- Document PushInfoList by @skinitimski in #1522
- Fix type hint on create_tag by @drewcassidy in #1523
- Block insecure options and protocols by default by @stsewd in #1521
- Make the git.__version__ re-appear.

Signed-off-by: Narpat Mali 
---
 ...-git-CVE-2022-24439-fix-from-PR-1518.patch |  97 
 ...-git-CVE-2022-24439-fix-from-PR-1521.patch | 488 --
 ...n3-git_3.1.27.bb => python3-git_3.1.32.bb} |   6 +-
 3 files changed, 1 insertion(+), 590 deletions(-)
 delete mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
 delete mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1521.patch
 rename meta/recipes-devtools/python/{python3-git_3.1.27.bb => 
python3-git_3.1.32.bb} (80%)

diff --git 
a/meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
 
b/meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
deleted file mode 100644
index 16192b22c7..00
--- 
a/meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
+++ /dev/null
@@ -1,97 +0,0 @@
-From 6ebe9231cd34dacd32a964859bc509aaa1e3f5fd Mon Sep 17 00:00:00 2001
-From: Narpat Mali 
-Date: Fri, 6 Jan 2023 14:13:10 +
-Subject: [PATCH] python3-git: CVE-2022-24439 fix from PR 1518
-
-Fix command injection
-Add `--` in some commands that receive user input
-and if interpreted as options could lead to remote
-code execution (RCE).
-
-There may be more commands that could benefit from `--`
-so the input is never interpreted as an option,
-but most of those aren't dangerous.
-
-Fixed commands:
-
-- push
-- pull
-- fetch
-- clone/clone_from and friends
-- archive (not sure if this one can be exploited, but it doesn't hurt
-  adding `--` :))
-
-For anyone using GitPython and exposing any of the GitPython methods to users,
-make sure to always validate the input (like if starts with `--`).
-And for anyone allowing users to pass arbitrary options, be aware
-that some options may lead fo RCE, like `--exc`, `--upload-pack`,
-`--receive-pack`, `--config` (#1516).
-
-Ref #1517
-
-CVE: CVE-2022-24439
-
-Upstream-Status: Backport 
[https://github.com/gitpython-developers/GitPython/pull/1518]
-
-Signed-off-by: Narpat Mali 

- git/remote.py| 6 +++---
- git/repo/base.py | 4 ++--
- 2 files changed, 5 insertions(+), 5 deletions(-)
-
-diff --git a/git/remote.py b/git/remote.py
-index 56f3c5b..59681bc 100644
 a/git/remote.py
-+++ b/git/remote.py
-@@ -881,7 +881,7 @@ class Remote(LazyMixin, IterableObj):
- else:
- args = [refspec]
- 
--proc = self.repo.git.fetch(self, *args, as_process=True, 
with_stdout=False,
-+proc = self.repo.git.fetch("--", self, *args, as_process=True, 
with_stdout=False,
-universal_newlines=True, v=verbose, 
**kwargs)
- res = self._get_fetch_info_from_stderr(proc, progress,
-
kill_after_timeout=kill_after_timeout)
-@@ -905,7 +905,7 @@ class Remote(LazyMixin, IterableObj):
- # No argument refspec, then ensure the repo's config has a fetch 

[OE-core] [PATCH 1/2] lib/oe/recipeutils.py: accommodate SRCPV being optional and deprecated in version check regex

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/recipeutils.py | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index 6996e426ec0..3336db8ab06 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -945,10 +945,9 @@ def replace_dir_vars(path, d):
 path = path.replace(dirpath, '${%s}' % dirvars[dirpath])
 return path
 
-def get_recipe_pv_without_srcpv(pv, uri_type):
+def get_recipe_pv_with_pfx_sfx(pv, uri_type):
 """
-Get PV without SRCPV common in SCM's for now only
-support git.
+Get PV separating prefix and suffix components.
 
 Returns tuple with pv, prefix and suffix.
 """
@@ -956,7 +955,7 @@ def get_recipe_pv_without_srcpv(pv, uri_type):
 sfx = ''
 
 if uri_type == 'git':
-git_regex = 
re.compile(r"(?Pv?)(?P.*?)(?P\+[^\+]*(git)?r?(AUTOINC\+))(?P.*)")
+git_regex = 
re.compile(r"(?Pv?)(?P.*?)(?P\+[^\+]*(git)?r?(AUTOINC\+)?)(?P.*)")
 m = git_regex.match(pv)
 
 if m:
@@ -1008,7 +1007,7 @@ def get_recipe_upstream_version(rd):
 src_uri = src_uris.split()[0]
 uri_type, _, _, _, _, _ =  decodeurl(src_uri)
 
-(pv, pfx, sfx) = get_recipe_pv_without_srcpv(rd.getVar('PV'), uri_type)
+(pv, pfx, sfx) = get_recipe_pv_with_pfx_sfx(rd.getVar('PV'), uri_type)
 ru['current_version'] = pv
 
 manual_upstream_version = rd.getVar("RECIPE_UPSTREAM_VERSION")
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186703): 
https://lists.openembedded.org/g/openembedded-core/message/186703
Mute This Topic: https://lists.openembedded.org/mt/100953124/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] python3-sphinx: correct version check

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/python/python3-sphinx_7.1.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python3-sphinx_7.1.1.bb 
b/meta/recipes-devtools/python/python3-sphinx_7.1.1.bb
index fa616cd5044..92d60126922 100644
--- a/meta/recipes-devtools/python/python3-sphinx_7.1.1.bb
+++ b/meta/recipes-devtools/python/python3-sphinx_7.1.1.bb
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=5eb6ac1b115a1ed24a12d9f15b633993"
 SRC_URI[sha256sum] = 
"59b8e391f0768a96cd233e8300fe7f0a8dc2f64f83dc2a54336a9a84f428ff4e"
 
 inherit python_flit_core pypi
+UPSTREAM_CHECK_REGEX = "/Sphinx/(?P(\d+[\.\-_]*)+)/"
 
 do_install:append () {
# The cache format of "{None, 'en', 'ja'}" doesn't seem to be 
consistent (dict ordering?)
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186704): 
https://lists.openembedded.org/g/openembedded-core/message/186704
Mute This Topic: https://lists.openembedded.org/mt/100953125/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [meta-oe][PATCH 0/3] add missing CVE_PRODUCT

[Emil Kronborg Andersen via lists.openembedded.org]

Hi Luca,

Sorry about that. I sent them to the meta-oe mailing list now.

Best regards,
Emil

From: Luca Ceresoli 
Sent: Friday, August 25, 2023 10:24
To: Emil Kronborg Andersen via lists.openembedded.org 

Cc: Emil Kronborg Andersen ; 
openembedded-core@lists.openembedded.org 

Subject: Re: [OE-core] [meta-oe][PATCH 0/3] add missing CVE_PRODUCT

Hello Emil,

On Thu, 24 Aug 2023 16:07:44 +0200
"Emil Kronborg Andersen via lists.openembedded.org"
 wrote:

> Some recipes does not have 'CVE_PRODUCT' set, and will thus pass a check
> against the NIST database with 0 CVEs, even though there could be
> several.
>
> Emil Kronborg Andersen (3):
>   libopus: add CVE_PRODUCT
>   lcms: add CVE_PRODUCT
>   snappy: add CVE_PRODUCT
>
>  meta-oe/recipes-extended/snappy/snappy_1.1.9.bb   | 2 ++
>  meta-oe/recipes-multimedia/libopus/libopus_1.4.bb | 2 ++
>  meta-oe/recipes-support/lcms/lcms_2.15.bb | 2 ++

These patches should be sent to the meta-oe mailing list.

Best regards,
Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186702): 
https://lists.openembedded.org/g/openembedded-core/message/186702
Mute This Topic: https://lists.openembedded.org/mt/100935810/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][kirkstone][PATCH 1/1] nghttp2: fix CVE-2023-35945

[Urade, Yogita via lists.openembedded.org]

From: Yogita Urade 

Envoy is a cloud-native high-performance edge/middle/service
proxy. Envoy’s HTTP/2 codec may leak a header map and
bookkeeping structures upon receiving `RST_STREAM` immediately
followed by the `GOAWAY` frames from an upstream server. In
nghttp2, cleanup of pending requests due to receipt of the
`GOAWAY` frame skips de-allocation of the bookkeeping structure
and pending compressed header. The error return [code path] is
taken if connection is already marked for not sending more
requests due to `GOAWAY` frame. The clean-up code is right after
the return statement, causing memory leak. Denial of service
through memory exhaustion. This vulnerability was patched in
versions(s) 1.26.3, 1.25.8, 1.24.9, 1.23.11.

References:
https://nvd.nist.gov/vuln/detail/CVE-2023-35945
https://github.com/envoyproxy/envoy/security/advisories/GHSA-jfxv-29pc-x22r

Signed-off-by: Yogita Urade 
---
 .../nghttp2/nghttp2/CVE-2023-35945.patch  | 151 ++
 .../recipes-support/nghttp2/nghttp2_1.47.0.bb |   1 +
 2 files changed, 152 insertions(+)
 create mode 100644 meta/recipes-support/nghttp2/nghttp2/CVE-2023-35945.patch

diff --git a/meta/recipes-support/nghttp2/nghttp2/CVE-2023-35945.patch 
b/meta/recipes-support/nghttp2/nghttp2/CVE-2023-35945.patch
new file mode 100644
index 00..e03915fda8
--- /dev/null
+++ b/meta/recipes-support/nghttp2/nghttp2/CVE-2023-35945.patch
@@ -0,0 +1,151 @@
+From ce385d3f55a4b76da976b3bdf71fe2deddf315ba Mon Sep 17 00:00:00 2001
+From: Tatsuhiro Tsujikawa 
+Date: Thu, 24 Aug 2023 09:34:26 +
+Subject: [PATCH] Fix memory leak
+
+This commit fixes memory leak that happens when PUSH_PROMISE or
+HEADERS frame cannot be sent, and nghttp2_on_stream_close_callback
+fails with a fatal error.  For example, if GOAWAY frame has been
+received, a HEADERS frame that opens new stream cannot be sent.
+
+This issue has already been made public via CVE-2023-35945 [1] issued
+by envoyproxy/envoy project.  During embargo period, the patch to fix
+this bug was accidentally submitted to nghttp2/nghttp2 repository [2].
+And they decided to disclose CVE early.  I was notified just 1.5 hours
+before disclosure.  I had no time to respond.
+
+PoC described in [1] is quite simple, but I think it is not enough to
+trigger this bug.  While it is true that receiving GOAWAY prevents a
+client from opening new stream, and nghttp2 enters error handling
+branch, in order to cause the memory leak,
+nghttp2_session_close_stream function must return a fatal error.
+nghttp2 defines 2 fatal error codes:
+
+- NGHTTP2_ERR_NOMEM
+- NGHTTP2_ERR_CALLBACK_FAILURE
+
+NGHTTP2_ERR_NOMEM, as its name suggests, indicates out of memory.  It
+is unlikely that a process gets short of memory with this simple PoC
+scenario unless application does something memory heavy processing.
+
+NGHTTP2_ERR_CALLBACK_FAILURE is returned from application defined
+callback function (nghttp2_on_stream_close_callback, in this case),
+which indicates something fatal happened inside a callback, and a
+connection must be closed immediately without any further action.  As
+nghttp2_on_stream_close_error_callback documentation says, any error
+code other than 0 or NGHTTP2_ERR_CALLBACK_FAILURE is treated as fatal
+error code.  More specifically, it is treated as if
+NGHTTP2_ERR_CALLBACK_FAILURE is returned.  I guess that envoy returns
+NGHTTP2_ERR_CALLBACK_FAILURE or other error code which is translated
+into NGHTTP2_ERR_CALLBACK_FAILURE.
+
+[1] https://github.com/envoyproxy/envoy/security/advisories/GHSA-jfxv-29pc-x22r
+[2] https://github.com/nghttp2/nghttp2/pull/1929
+
+CVE: CVE-2023-35945
+
+Upstream-Status: Backport 
[https://github.com/nghttp2/nghttp2/commit/ce385d3f55a4b76da976b3bdf71fe2deddf315ba]
+
+Signed-off-by: Yogita Urade 
+---
+ lib/nghttp2_session.c| 10 +-
+ tests/nghttp2_session_test.c | 34 ++
+ 2 files changed, 39 insertions(+), 5 deletions(-)
+
+diff --git a/lib/nghttp2_session.c b/lib/nghttp2_session.c
+index 380a47c..2d9285f 100644
+--- a/lib/nghttp2_session.c
 b/lib/nghttp2_session.c
+@@ -2940,6 +2940,7 @@ static ssize_t 
nghttp2_session_mem_send_internal(nghttp2_session *session,
+   if (rv < 0) {
+ int32_t opened_stream_id = 0;
+ uint32_t error_code = NGHTTP2_INTERNAL_ERROR;
++int rv2 = 0;
+
+ DEBUGF("send: frame preparation failed with %s\n",
+nghttp2_strerror(rv));
+@@ -2982,19 +2983,18 @@ static ssize_t 
nghttp2_session_mem_send_internal(nghttp2_session *session,
+ }
+ if (opened_stream_id) {
+   /* careful not to override rv */
+-  int rv2;
+   rv2 = nghttp2_session_close_stream(session, opened_stream_id,
+  error_code);
+-
+-  if (nghttp2_is_fatal(rv2)) {
+-return rv2;
+-  }
+ }
+
+ nghttp2_outbound_item_free(item, mem);
+ nghttp2_mem_free(mem, item);
+ 

Re: [OE-core] [meta-oe][PATCH 0/3] add missing CVE_PRODUCT

[Luca Ceresoli via lists.openembedded.org]

Hello Emil,

On Thu, 24 Aug 2023 16:07:44 +0200
"Emil Kronborg Andersen via lists.openembedded.org"
 wrote:

> Some recipes does not have 'CVE_PRODUCT' set, and will thus pass a check
> against the NIST database with 0 CVEs, even though there could be
> several.
> 
> Emil Kronborg Andersen (3):
>   libopus: add CVE_PRODUCT
>   lcms: add CVE_PRODUCT
>   snappy: add CVE_PRODUCT
> 
>  meta-oe/recipes-extended/snappy/snappy_1.1.9.bb   | 2 ++
>  meta-oe/recipes-multimedia/libopus/libopus_1.4.bb | 2 ++
>  meta-oe/recipes-support/lcms/lcms_2.15.bb | 2 ++

These patches should be sent to the meta-oe mailing list.

Best regards,
Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186700): 
https://lists.openembedded.org/g/openembedded-core/message/186700
Mute This Topic: https://lists.openembedded.org/mt/100935810/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][kirkstone][PATCH] Qemu: Resolve undefined reference issue in CVE-2023-2861

[Siddharth via lists.openembedded.org]

The commit 
[https://github.com/openembedded/openembedded-core/commit/9bd4ddeb4b5efc65b0514d50d6991211271924c1]
 backports fix for CVE-2023-2861 for version 6.2.0.
The 'qemu_fstat' in `do_create_others' is not defined which leads to the 
undefined symbol error on certain architectures.

Also, the commit message says "(Mjt: drop adding qemu_fstat wrapper for 7.2 
where wrappers aren't used)". So either the wrapper has to be dropped or it has 
to be defined.

Hence, backported the main patch rather than the cherry picked one.

Signed-off-by: Siddharth Doshi 
---
 .../qemu/qemu/CVE-2023-2861.patch | 66 +++
 1 file changed, 37 insertions(+), 29 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch
index 48f51f5d03..a86413fbad 100644
--- a/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch
@@ -1,14 +1,16 @@
-From 10fad73a2bf1c76c8aa9d6322755e5f877d83ce5 Mon Sep 17 00:00:00 2001
+From f6b0de53fb87ddefed348a39284c8e2f28dc4eda Mon Sep 17 00:00:00 2001
 From: Christian Schoenebeck 
-Date: Wed Jun 7 18:29:33 2023 +0200
-Subject: [PATCH] 9pfs: prevent opening special files (CVE-2023-2861) The 9p
- protocol does not specifically define how server shall behave when client
- tries to open a special file, however from security POV it does make sense
- for 9p server to prohibit opening any special file on host side in general. A
- sane Linux 9p client for instance would never attempt to open a special file
- on host side, it would always handle those exclusively on its guest side. A
- malicious client however could potentially escape from the exported 9p tree
- by creating and opening a device file on host side.
+Date: Wed, 7 Jun 2023 18:29:33 +0200
+Subject: [PATCH] 9pfs: prevent opening special files (CVE-2023-2861)
+
+The 9p protocol does not specifically define how server shall behave when
+client tries to open a special file, however from security POV it does
+make sense for 9p server to prohibit opening any special file on host side
+in general. A sane Linux 9p client for instance would never attempt to
+open a special file on host side, it would always handle those exclusively
+on its guest side. A malicious client however could potentially escape
+from the exported 9p tree by creating and opening a device file on host
+side.
 
 With QEMU this could only be exploited in the following unsafe setups:
 
@@ -32,19 +34,16 @@ Signed-off-by: Christian Schoenebeck 

 Reviewed-by: Greg Kurz 
 Reviewed-by: Michael Tokarev 
 Message-Id: 
-(cherry picked from commit f6b0de5)
-Signed-off-by: Michael Tokarev 
-(Mjt: drop adding qemu_fstat wrapper for 7.2 where wrappers aren't used)
-
-Upstream-Status: Backport 
[https://github.com/qemu/qemu/commit/10fad73a2bf1c76c8aa9d6322755e5f877d83ce5]
 
+Upstream-Status: Backport from 
[https://github.com/qemu/qemu/commit/10fad73a2bf1c76c8aa9d6322755e5f877d83ce5]
 CVE: CVE-2023-2861
 
 Signed-off-by: Archana Polampalli 
+Signed-off-by: Siddharth Doshi 
 ---
- fsdev/virtfs-proxy-helper.c | 27 --
- hw/9pfs/9p-util.h   | 38 +
- 2 files changed, 63 insertions(+), 2 deletions(-)
+ fsdev/virtfs-proxy-helper.c | 27 +++--
+ hw/9pfs/9p-util.h   | 40 +
+ 2 files changed, 65 insertions(+), 2 deletions(-)
 
 diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
 index 15c0e79b0..f9e4669a5 100644
@@ -56,12 +55,12 @@ index 15c0e79b0..f9e4669a5 100644
  #include "hw/9pfs/9p-proxy.h"
 +#include "hw/9pfs/9p-util.h"
  #include "fsdev/9p-iov-marshal.h"
-
+ 
  #define PROGNAME "virtfs-proxy-helper"
 @@ -338,6 +339,28 @@ static void resetugid(int suid, int sgid)
  }
  }
-
+ 
 +/*
 + * Open regular file or directory. Attempts to open any special file are
 + * rejected.
@@ -106,22 +105,30 @@ index 15c0e79b0..f9e4669a5 100644
  ret = -errno;
  }
 diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
-index 546f46dc7..54e270ac6 100644
+index 546f46dc7..23000e917 100644
 --- a/hw/9pfs/9p-util.h
 +++ b/hw/9pfs/9p-util.h
-@@ -13,6 +13,8 @@
+@@ -13,12 +13,16 @@
  #ifndef QEMU_9P_UTIL_H
  #define QEMU_9P_UTIL_H
-
+ 
 +#include "qemu/error-report.h"
 +
  #ifdef O_PATH
  #define O_PATH_9P_UTIL O_PATH
  #else
-@@ -26,6 +28,38 @@ static inline void close_preserve_errno(int fd)
+ #define O_PATH_9P_UTIL 0
+ #endif
+ 
++#define qemu_fstat  fstat
++
+ static inline void close_preserve_errno(int fd)
+ {
+ int serrno = errno;
+@@ -26,6 +30,38 @@ static inline void close_preserve_errno(int fd)
  errno = serrno;
  }
-
+ 
 +/**
 + * close_if_special_file() - Close @fd if neither regular file nor directory.
 + *
@@ -157,10 +164,10 @@ index 546f46dc7..54e270ac6 100644
  static inline int openat_dir(int dirfd, const char *name)
  {
  return openat(dirfd, name,
-@@ -56,6 +90,10 @@ again:
+@@ -56,6 

Re: [OE-core] [PATCH] python3: Add packagegroup-core-buildessential rdep to ptests

[Richard Purdie]

On Fri, 2023-08-25 at 00:09 -0700, Khem Raj wrote:
> cppext test needs full toolchain as it tries to build an extention with
> C, using packagegroup-core-buildessential ensures that a function
> toolchain bits are pulled into ptest image, as an aside it also
> abstracts hardcoding compiler to be gcc
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-devtools/python/python3_3.11.4.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/python/python3_3.11.4.bb 
> b/meta/recipes-devtools/python/python3_3.11.4.bb
> index 8fd1382caa4..e31c4a81ef6 100644
> --- a/meta/recipes-devtools/python/python3_3.11.4.bb
> +++ b/meta/recipes-devtools/python/python3_3.11.4.bb
> @@ -424,7 +424,7 @@ FILES:${PN}-man = "${datadir}/man"
>  # See https://bugs.python.org/issue18748 and 
> https://bugs.python.org/issue37395
>  RDEPENDS:libpython3:append:libc-glibc = " libgcc"
>  RDEPENDS:${PN}-ctypes:append:libc-glibc = " ${MLPREFIX}ldconfig"
> -RDEPENDS:${PN}-ptest = "${PN}-modules ${PN}-tests ${PN}-dev ${PN}-cgitb 
> ${PN}-zipapp unzip bzip2 libgcc tzdata coreutils sed gcc g++ binutils"
> +RDEPENDS:${PN}-ptest = "${PN}-modules ${PN}-tests ${PN}-dev ${PN}-cgitb 
> ${PN}-zipapp unzip bzip2 libgcc tzdata coreutils sed 
> packagegroup-core-buildessential"
>  RDEPENDS:${PN}-ptest:append:libc-glibc = " locale-base-fr-fr 
> locale-base-en-us locale-base-tr-tr locale-base-de-de"
>  RDEPENDS:${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 
> '${MLPREFIX}tk ${MLPREFIX}tk-lib', '', d)}"
>  RDEPENDS:${PN}-idle += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 
> '${PN}-tkinter ${MLPREFIX}tcl', '', d)}"

That also increases the dependencies needed to complete a build of
target python and I'm not sure this is a great idea. Compiler
dependencies in ptests are a real problem in this regard but this patch
makes the situation a lot worse :(

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186698): 
https://lists.openembedded.org/g/openembedded-core/message/186698
Mute This Topic: https://lists.openembedded.org/mt/100951409/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][mickledore][PATCH 1/1] ffmpeg: add CVE_CHECK_IGNORE for CVE-2023-39018

[Narpat Mali via lists.openembedded.org]

From: Narpat Mali 

CVE-2023-39018 belongs to ffmpeg-cli-wrapper (Java wrapper around the FFmpeg 
CLI)
and not ffmpeg itself. As per CVE description, it is mentioned as FFmpeg 0.7.0 
which
is the version for ffmpeg-cli-wrapper and ffmpeg don't have 0.7.0 version at 
all.

Debian & Bugzilla trackers have already marked as NOT-FOR-US/RESOLVED-INVALID.
As it won't be affecting the ffmpeg package so, we can ignore the CVE-2023-39018
in ffmpeg recipe.

References:
https://github.com/bramp/ffmpeg-cli-wrapper
https://github.com/FFmpeg/FFmpeg
https://security-tracker.debian.org/tracker/CVE-2023-39018
https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-39018

Upstream master patch:
https://git.openembedded.org/openembedded-core/commit/?id=c21ed498b423c13463a4ae0bb475883cc7901847

Signed-off-by: Narpat Mali 
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
index cccd9f65ab..aa5a8681cf 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
@@ -30,6 +30,12 @@ SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
 
 SRC_URI[sha256sum] = 
"619e706d662c8420859832ddc259cd4d4096a48a2ce1eefd052db9e440eef3dc"
 
+# CVE-2023-39018 issue belongs to ffmpeg-cli-wrapper (Java wrapper around the 
FFmpeg CLI)
+# and not ffmepg itself.
+# https://security-tracker.debian.org/tracker/CVE-2023-39018
+# https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-39018
+CVE_CHECK_IGNORE += "CVE-2023-39018"
+
 # Build fails when thumb is enabled: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
 ARM_INSTRUCTION_SET:armv4 = "arm"
 ARM_INSTRUCTION_SET:armv5 = "arm"
-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186697): 
https://lists.openembedded.org/g/openembedded-core/message/186697
Mute This Topic: https://lists.openembedded.org/mt/100951729/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][kirkstone][PATCH 1/1] go: Fix CVE-2023-29409

[Soumya via lists.openembedded.org]

From: Soumya Sambu 

Extremely large RSA keys in certificate chains can cause a
client/server to expend significant CPU time verifying
signatures. With fix, the size of RSA keys transmitted
during handshakes is restricted to <= 8192 bits. Based on
a survey of publicly trusted RSA keys, there are currently
only three certificates in circulation with keys larger than
this, and all three appear to be test certificates that are
not actively deployed. It is possible there are larger keys
in use in private PKIs, but we target the web PKI, so causing
breakage here in the interests of increasing the default
safety of users of crypto/tls seems reasonable.

References:
https://nvd.nist.gov/vuln/detail/CVE-2023-29409

Signed-off-by: Soumya Sambu 
---
 meta/recipes-devtools/go/go-1.17.13.inc   |   1 +
 .../go/go-1.19/CVE-2023-29409.patch   | 175 ++
 2 files changed, 176 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.19/CVE-2023-29409.patch

diff --git a/meta/recipes-devtools/go/go-1.17.13.inc 
b/meta/recipes-devtools/go/go-1.17.13.inc
index e0f02f3e28..91dd886cd0 100644
--- a/meta/recipes-devtools/go/go-1.17.13.inc
+++ b/meta/recipes-devtools/go/go-1.17.13.inc
@@ -42,6 +42,7 @@ SRC_URI += "\
 file://CVE-2023-24536_3.patch \
 file://CVE-2023-24531_1.patch \
 file://CVE-2023-24531_2.patch \
+file://CVE-2023-29409.patch \
 "
 SRC_URI[main.sha256sum] = 
"a1a48b23afb206f95e7bbaa9b898d965f90826f6f1d1fc0c1d784ada0cd300fd"
 
diff --git a/meta/recipes-devtools/go/go-1.19/CVE-2023-29409.patch 
b/meta/recipes-devtools/go/go-1.19/CVE-2023-29409.patch
new file mode 100644
index 00..38451f7555
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.19/CVE-2023-29409.patch
@@ -0,0 +1,175 @@
+From 2300f7ef07718f6be4d8aa8486c7de99836e233f Mon Sep 17 00:00:00 2001
+From: Roland Shoemaker 
+Date: Wed, 23 Aug 2023 12:03:43 +
+Subject: [PATCH] crypto/tls: restrict RSA keys in certificates to <= 8192 bits
+
+Extremely large RSA keys in certificate chains can cause a client/server
+to expend significant CPU time verifying signatures. Limit this by
+restricting the size of RSA keys transmitted during handshakes to <=
+8192 bits.
+
+Based on a survey of publicly trusted RSA keys, there are currently only
+three certificates in circulation with keys larger than this, and all
+three appear to be test certificates that are not actively deployed. It
+is possible there are larger keys in use in private PKIs, but we target
+the web PKI, so causing breakage here in the interests of increasing the
+default safety of users of crypto/tls seems reasonable.
+
+Thanks to Mateusz Poliwczak for reporting this issue.
+
+Updates #61460
+Fixes #61579
+Fixes CVE-2023-29409
+
+Change-Id: Ie35038515a649199a36a12fc2c5df3af855dca6c
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1912161
+Reviewed-by: Damien Neil 
+Reviewed-by: Tatiana Bradley 
+Run-TryBot: Roland Shoemaker 
+(cherry picked from commit d865c715d92887361e4bd5596e19e513f27781b7)
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1965487
+Reviewed-on: https://go-review.googlesource.com/c/go/+/514915
+Run-TryBot: David Chase 
+Reviewed-by: Matthew Dempsky 
+TryBot-Bypass: David Chase 
+
+CVE: CVE-2023-29409
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/2300f7ef07718f6be4d8aa8486c7de99836e233f]
+
+Signed-off-by: Soumya Sambu 
+---
+ src/crypto/tls/handshake_client.go  |  8 +++
+ src/crypto/tls/handshake_client_test.go | 78 +
+ src/crypto/tls/handshake_server.go  |  4 ++
+ 3 files changed, 90 insertions(+)
+
+diff --git a/src/crypto/tls/handshake_client.go 
b/src/crypto/tls/handshake_client.go
+index 85622f1..828d2cb 100644
+--- a/src/crypto/tls/handshake_client.go
 b/src/crypto/tls/handshake_client.go
+@@ -852,6 +852,10 @@ func (hs *clientHandshakeState) sendFinished(out []byte) 
error {
+   return nil
+ }
+
++// maxRSAKeySize is the maximum RSA key size in bits that we are willing
++// to verify the signatures of during a TLS handshake.
++const maxRSAKeySize = 8192
++
+ // verifyServerCertificate parses and verifies the provided chain, setting
+ // c.verifiedChains and c.peerCertificates or sending the appropriate alert.
+ func (c *Conn) verifyServerCertificate(certificates [][]byte) error {
+@@ -862,6 +866,10 @@ func (c *Conn) verifyServerCertificate(certificates 
[][]byte) error {
+   c.sendAlert(alertBadCertificate)
+   return errors.New("tls: failed to parse certificate 
from server: " + err.Error())
+   }
++  if cert.PublicKeyAlgorithm == x509.RSA && 
cert.PublicKey.(*rsa.PublicKey).N.BitLen() > maxRSAKeySize {
++  c.sendAlert(alertBadCertificate)
++  return fmt.Errorf("tls: server sent certificate 
containing RSA key larger than %d bits", maxRSAKeySize)
++  }
+   certs[i] = cert
+   }
+

Re: [OE-Core][PATCH] oeqa/utils/gitarchive: replace warning with info when reading local tags

[Alexis Lothoré via lists . openembedded . org]

Hi Richard,

On 8/25/23 08:41, Richard Purdie wrote:
> On Thu, 2023-08-24 at 11:18 +0200, Alexis Lothoré via
> lists.openembedded.org wrote:
>> From: Alexis Lothoré 
>>
>> Whenever a script needs to list tags, if it falls back to the third method
>> (reading local tags only), it emits a warning. While this warning is useful
>> for future diagnostic if some tagging issues re-appear, it makes buildperf
>> autobuilds status as "Passed with warnings", which is not desirable
>>
>> Signed-off-by: Alexis Lothoré 
>> ---
>> See [1]: buildperf build has completed without any major issue, but is
>> still flaggued as "Passed with warnings" because of the log.warning in
>> gitarchive
>>
>> [1] https://autobuilder.yoctoproject.org/typhoon/#/builders/133/builds/2135
>> ---
>>  meta/lib/oeqa/utils/gitarchive.py | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/lib/oeqa/utils/gitarchive.py 
>> b/meta/lib/oeqa/utils/gitarchive.py
>> index ac36ecb3a9ca..64448f47d94e 100644
>> --- a/meta/lib/oeqa/utils/gitarchive.py
>> +++ b/meta/lib/oeqa/utils/gitarchive.py
>> @@ -128,7 +128,7 @@ def get_tags(repo, log, pattern=None, url=None):
>>  tags_refs = repo.run_cmd(cmd)
>>  tags = ["".join(d.split()[1].split('/', 2)[2:]) for d in 
>> tags_refs.splitlines()]
>>  else:
>> -log.warning("Read local tags only, some remote tags may be 
>> missed")
>> +log.info("Read local tags only, some remote tags may be missed")
>>  cmd = ["tag"]
>>  if pattern:
>>  cmd += ["-l", pattern]
> 
> Thanks for getting to the bottom of this! I merged them directly so we
> could see the effect on the buildperf worker and you looked at the
> results before I managed to report back which was helpful! :

Thanks for the quick merges ! And sorry for the mess of the last days builds

buildperf worker seems indeed to behave correctly again ([1]), but I only took a
look at the build general status since I am not so familiar with those, please
do not hesitate to ping me if I am missing any more specific issue which could
remain regarding the tagging patches.

[1] https://autobuilder.yoctoproject.org/typhoon/#/builders/133/builds/2138
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186695): 
https://lists.openembedded.org/g/openembedded-core/message/186695
Mute This Topic: https://lists.openembedded.org/mt/100932169/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Dilemma on changes - merge or not to merge (e.g. 6.4)

[Mikko Rapeli]

Hi,

On Fri, Aug 25, 2023 at 07:34:25AM +0100, Richard Purdie wrote:
> On Fri, 2023-08-25 at 09:27 +0300, Mikko Rapeli wrote:
> > Hi,
> > 
> > On Thu, Aug 24, 2023 at 09:18:03PM +0100, Richard Purdie wrote:
> > > On Thu, 2023-08-24 at 15:04 +0100, Richard Purdie via
> > > lists.openembedded.org wrote:
> > > > On Wed, 2023-08-23 at 22:16 +0100, Richard Purdie via
> > > > lists.openembedded.org wrote:
> > > > > On Tue, 2023-08-22 at 23:01 +0100, Richard Purdie via
> > > > > lists.openembedded.org wrote:
> > > > > > so the commands are stopping mid flow for unknown reasons or the ssh
> > > > > > connection fails. I can't tell if this coincides with an rcu stall 
> > > > > > or
> > > > > > not. Both logs do have rcu stalls in.
> > > > > > 
> > > > > > After these failures the system does continue to otherwise work
> > > > > > normally and subsequent tests pass.
> > > > > > 
> > > > > > I wonder if the slow emulation might be causing the networking to
> > > > > > glitch and break the ssh connection.
> > > > > > 
> > > > > > I'm at a bit of a loss on where from here. 
> > > > > 
> > > > > I thought I'd update the thread with new information.
> > > > > 
> > > > > I went back to the start with this and looked again and what is going
> > > > > on. Interestingly, I found one of the autobuilder workers would
> > > > > consistently fail the qemuppc-alt configuration for core-image-sato-
> > > > > sdk. I paused the worker and experimented.
> > > > > 
> > > > > I saw two different failures (included below). One shows systemd-udevd
> > > > > timing out on it's watchdog after 3 minutes and resetting, including
> > > > > taking out an ssh session running the cpio configure command. There 
> > > > > was
> > > > > no RCU stall reported.
> > > > > 
> > > > > The second failure shows systemd-logind as well as systemd-udevd with
> > > > > the 3 minute time out, the kernel complaining about missed IRQs, an 
> > > > > RCU
> > > > > stall and lots of breakage following including cut ssh commands.
> > > > > 
> > > > > I could not get the cpio build test to complete.
> > > > > 
> > > > > Interestingly, I came back to the same image/worker later this evening
> > > > > and now it all works fine. The difference is earlier there was a world
> > > > > build running on the worker, which continued to wind down even after I
> > > > > paused the worker. By the evening, that background load was no longer
> > > > > present and the ppc image works in isolation. This tells us the issue
> > > > > is system load dependent and only occurs on loaded systems.
> > > > > 
> > > > > I suspect I need to replicate the load and retry locally, see if I can
> > > > > reliably reproduce the hang. The watchdog won't be present on sysvinit
> > > > > systems which also show the issues but I'd guess there is still some
> > > > > other starvation/timeout occurring.
> > > > 
> > > > I've now seen the failure on the autobuilder:
> > > > 
> > > > * with linux-yocto 6.1.38
> > > > * with linux-yocto 6.1.46
> > > > * with qemu 8.0.4
> > > > * with qemu 8.0.3
> > > > * with qemu 8.0.0
> > > > 
> > > > I was a little suspicious of:
> > > > 
> > > > "hw/ppc: Fix clock update drift"
> > > > https://gitlab.com/qemu-project/qemu/-/commit/73d6ac24c81f1aeae554d469616c9181511e6523
> > > > 
> > > > but we've tested with and without that.
> > > > 
> > > > qemu has just released 8.1.0 so perhaps we should try that next.
> > > 
> > > qemu 8.1.0 brings with it a new set of problems but I've reproduced the
> > > hang with 8.1.0 so it does not solve that.
> > > 
> > > I'm really struggling to understand which change brought in these
> > > issues for qemuppc.
> > 
> > Are these issues visible on mickledore branch? Maybe mickledore with kernel 
> > 6.1 stable update or
> > qemu 7.2 update to 8.y.x could be tested too. At least then kernel or qemu 
> > could be blamed
> > for the issues.
> 
> Not that I know of.
> 
> I have now also reproduced the failure with glibc 2.37 instead of 2.38
> including the fortify sources change and the 6.1.34 kernel so there is
> something else causing this.
> 
> I've wondered if we need to try going back to qemu 7.2. It may also be
> worth ruling out binutils.

Yes, I'd have no objection to qemu downgrade if that helps with stability
and release deadline. I really trust you don't do this lightly and I would
much prefer you do this instead of burning out when hunting fixes for the 
various
issues. In product environments I've done this a lot: changes get reverted if
they cause too much instability and fixes don't come within some limited time
from the developers who are responsible for those changes.

> It shouldn't be systemd as the sysvinit images show the issue too.

FWIW, poky master branch with 6.4 kernel is working well on our arm64 boards
and CI results are stable, same with qemu-arm64 on 7.2 and 8.0.x versions.

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186694): 

[OE-core] [PATCH] python3: Add packagegroup-core-buildessential rdep to ptests

[Khem Raj]

cppext test needs full toolchain as it tries to build an extention with
C, using packagegroup-core-buildessential ensures that a function
toolchain bits are pulled into ptest image, as an aside it also
abstracts hardcoding compiler to be gcc

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/python/python3_3.11.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3_3.11.4.bb 
b/meta/recipes-devtools/python/python3_3.11.4.bb
index 8fd1382caa4..e31c4a81ef6 100644
--- a/meta/recipes-devtools/python/python3_3.11.4.bb
+++ b/meta/recipes-devtools/python/python3_3.11.4.bb
@@ -424,7 +424,7 @@ FILES:${PN}-man = "${datadir}/man"
 # See https://bugs.python.org/issue18748 and https://bugs.python.org/issue37395
 RDEPENDS:libpython3:append:libc-glibc = " libgcc"
 RDEPENDS:${PN}-ctypes:append:libc-glibc = " ${MLPREFIX}ldconfig"
-RDEPENDS:${PN}-ptest = "${PN}-modules ${PN}-tests ${PN}-dev ${PN}-cgitb 
${PN}-zipapp unzip bzip2 libgcc tzdata coreutils sed gcc g++ binutils"
+RDEPENDS:${PN}-ptest = "${PN}-modules ${PN}-tests ${PN}-dev ${PN}-cgitb 
${PN}-zipapp unzip bzip2 libgcc tzdata coreutils sed 
packagegroup-core-buildessential"
 RDEPENDS:${PN}-ptest:append:libc-glibc = " locale-base-fr-fr locale-base-en-us 
locale-base-tr-tr locale-base-de-de"
 RDEPENDS:${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 
'${MLPREFIX}tk ${MLPREFIX}tk-lib', '', d)}"
 RDEPENDS:${PN}-idle += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 
'${PN}-tkinter ${MLPREFIX}tcl', '', d)}"
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186693): 
https://lists.openembedded.org/g/openembedded-core/message/186693
Mute This Topic: https://lists.openembedded.org/mt/100951409/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-Core][PATCH] oeqa/utils/gitarchive: replace warning with info when reading local tags

[Richard Purdie]

On Thu, 2023-08-24 at 11:18 +0200, Alexis Lothoré via
lists.openembedded.org wrote:
> From: Alexis Lothoré 
> 
> Whenever a script needs to list tags, if it falls back to the third method
> (reading local tags only), it emits a warning. While this warning is useful
> for future diagnostic if some tagging issues re-appear, it makes buildperf
> autobuilds status as "Passed with warnings", which is not desirable
> 
> Signed-off-by: Alexis Lothoré 
> ---
> See [1]: buildperf build has completed without any major issue, but is
> still flaggued as "Passed with warnings" because of the log.warning in
> gitarchive
> 
> [1] https://autobuilder.yoctoproject.org/typhoon/#/builders/133/builds/2135
> ---
>  meta/lib/oeqa/utils/gitarchive.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/lib/oeqa/utils/gitarchive.py 
> b/meta/lib/oeqa/utils/gitarchive.py
> index ac36ecb3a9ca..64448f47d94e 100644
> --- a/meta/lib/oeqa/utils/gitarchive.py
> +++ b/meta/lib/oeqa/utils/gitarchive.py
> @@ -128,7 +128,7 @@ def get_tags(repo, log, pattern=None, url=None):
>  tags_refs = repo.run_cmd(cmd)
>  tags = ["".join(d.split()[1].split('/', 2)[2:]) for d in 
> tags_refs.splitlines()]
>  else:
> -log.warning("Read local tags only, some remote tags may be 
> missed")
> +log.info("Read local tags only, some remote tags may be missed")
>  cmd = ["tag"]
>  if pattern:
>  cmd += ["-l", pattern]

Thanks for getting to the bottom of this! I merged them directly so we
could see the effect on the buildperf worker and you looked at the
results before I managed to report back which was helpful! :)

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186692): 
https://lists.openembedded.org/g/openembedded-core/message/186692
Mute This Topic: https://lists.openembedded.org/mt/100932169/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Dilemma on changes - merge or not to merge (e.g. 6.4)

[Richard Purdie]

On Fri, 2023-08-25 at 09:27 +0300, Mikko Rapeli wrote:
> Hi,
> 
> On Thu, Aug 24, 2023 at 09:18:03PM +0100, Richard Purdie wrote:
> > On Thu, 2023-08-24 at 15:04 +0100, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Wed, 2023-08-23 at 22:16 +0100, Richard Purdie via
> > > lists.openembedded.org wrote:
> > > > On Tue, 2023-08-22 at 23:01 +0100, Richard Purdie via
> > > > lists.openembedded.org wrote:
> > > > > so the commands are stopping mid flow for unknown reasons or the ssh
> > > > > connection fails. I can't tell if this coincides with an rcu stall or
> > > > > not. Both logs do have rcu stalls in.
> > > > > 
> > > > > After these failures the system does continue to otherwise work
> > > > > normally and subsequent tests pass.
> > > > > 
> > > > > I wonder if the slow emulation might be causing the networking to
> > > > > glitch and break the ssh connection.
> > > > > 
> > > > > I'm at a bit of a loss on where from here. 
> > > > 
> > > > I thought I'd update the thread with new information.
> > > > 
> > > > I went back to the start with this and looked again and what is going
> > > > on. Interestingly, I found one of the autobuilder workers would
> > > > consistently fail the qemuppc-alt configuration for core-image-sato-
> > > > sdk. I paused the worker and experimented.
> > > > 
> > > > I saw two different failures (included below). One shows systemd-udevd
> > > > timing out on it's watchdog after 3 minutes and resetting, including
> > > > taking out an ssh session running the cpio configure command. There was
> > > > no RCU stall reported.
> > > > 
> > > > The second failure shows systemd-logind as well as systemd-udevd with
> > > > the 3 minute time out, the kernel complaining about missed IRQs, an RCU
> > > > stall and lots of breakage following including cut ssh commands.
> > > > 
> > > > I could not get the cpio build test to complete.
> > > > 
> > > > Interestingly, I came back to the same image/worker later this evening
> > > > and now it all works fine. The difference is earlier there was a world
> > > > build running on the worker, which continued to wind down even after I
> > > > paused the worker. By the evening, that background load was no longer
> > > > present and the ppc image works in isolation. This tells us the issue
> > > > is system load dependent and only occurs on loaded systems.
> > > > 
> > > > I suspect I need to replicate the load and retry locally, see if I can
> > > > reliably reproduce the hang. The watchdog won't be present on sysvinit
> > > > systems which also show the issues but I'd guess there is still some
> > > > other starvation/timeout occurring.
> > > 
> > > I've now seen the failure on the autobuilder:
> > > 
> > > * with linux-yocto 6.1.38
> > > * with linux-yocto 6.1.46
> > > * with qemu 8.0.4
> > > * with qemu 8.0.3
> > > * with qemu 8.0.0
> > > 
> > > I was a little suspicious of:
> > > 
> > > "hw/ppc: Fix clock update drift"
> > > https://gitlab.com/qemu-project/qemu/-/commit/73d6ac24c81f1aeae554d469616c9181511e6523
> > > 
> > > but we've tested with and without that.
> > > 
> > > qemu has just released 8.1.0 so perhaps we should try that next.
> > 
> > qemu 8.1.0 brings with it a new set of problems but I've reproduced the
> > hang with 8.1.0 so it does not solve that.
> > 
> > I'm really struggling to understand which change brought in these
> > issues for qemuppc.
> 
> Are these issues visible on mickledore branch? Maybe mickledore with kernel 
> 6.1 stable update or
> qemu 7.2 update to 8.y.x could be tested too. At least then kernel or qemu 
> could be blamed
> for the issues.

Not that I know of.

I have now also reproduced the failure with glibc 2.37 instead of 2.38
including the fortify sources change and the 6.1.34 kernel so there is
something else causing this.

I've wondered if we need to try going back to qemu 7.2. It may also be
worth ruling out binutils.

It shouldn't be systemd as the sysvinit images show the issue too.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186691): 
https://lists.openembedded.org/g/openembedded-core/message/186691
Mute This Topic: https://lists.openembedded.org/mt/100733646/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Dilemma on changes - merge or not to merge (e.g. 6.4)

[Mikko Rapeli]

Hi,

On Thu, Aug 24, 2023 at 09:18:03PM +0100, Richard Purdie wrote:
> On Thu, 2023-08-24 at 15:04 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > On Wed, 2023-08-23 at 22:16 +0100, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Tue, 2023-08-22 at 23:01 +0100, Richard Purdie via
> > > lists.openembedded.org wrote:
> > > > so the commands are stopping mid flow for unknown reasons or the ssh
> > > > connection fails. I can't tell if this coincides with an rcu stall or
> > > > not. Both logs do have rcu stalls in.
> > > > 
> > > > After these failures the system does continue to otherwise work
> > > > normally and subsequent tests pass.
> > > > 
> > > > I wonder if the slow emulation might be causing the networking to
> > > > glitch and break the ssh connection.
> > > > 
> > > > I'm at a bit of a loss on where from here. 
> > > 
> > > I thought I'd update the thread with new information.
> > > 
> > > I went back to the start with this and looked again and what is going
> > > on. Interestingly, I found one of the autobuilder workers would
> > > consistently fail the qemuppc-alt configuration for core-image-sato-
> > > sdk. I paused the worker and experimented.
> > > 
> > > I saw two different failures (included below). One shows systemd-udevd
> > > timing out on it's watchdog after 3 minutes and resetting, including
> > > taking out an ssh session running the cpio configure command. There was
> > > no RCU stall reported.
> > > 
> > > The second failure shows systemd-logind as well as systemd-udevd with
> > > the 3 minute time out, the kernel complaining about missed IRQs, an RCU
> > > stall and lots of breakage following including cut ssh commands.
> > > 
> > > I could not get the cpio build test to complete.
> > > 
> > > Interestingly, I came back to the same image/worker later this evening
> > > and now it all works fine. The difference is earlier there was a world
> > > build running on the worker, which continued to wind down even after I
> > > paused the worker. By the evening, that background load was no longer
> > > present and the ppc image works in isolation. This tells us the issue
> > > is system load dependent and only occurs on loaded systems.
> > > 
> > > I suspect I need to replicate the load and retry locally, see if I can
> > > reliably reproduce the hang. The watchdog won't be present on sysvinit
> > > systems which also show the issues but I'd guess there is still some
> > > other starvation/timeout occurring.
> > 
> > I've now seen the failure on the autobuilder:
> > 
> > * with linux-yocto 6.1.38
> > * with linux-yocto 6.1.46
> > * with qemu 8.0.4
> > * with qemu 8.0.3
> > * with qemu 8.0.0
> > 
> > I was a little suspicious of:
> > 
> > "hw/ppc: Fix clock update drift"
> > https://gitlab.com/qemu-project/qemu/-/commit/73d6ac24c81f1aeae554d469616c9181511e6523
> > 
> > but we've tested with and without that.
> > 
> > qemu has just released 8.1.0 so perhaps we should try that next.
> 
> qemu 8.1.0 brings with it a new set of problems but I've reproduced the
> hang with 8.1.0 so it does not solve that.
> 
> I'm really struggling to understand which change brought in these
> issues for qemuppc.

Are these issues visible on mickledore branch? Maybe mickledore with kernel 6.1 
stable update or
qemu 7.2 update to 8.y.x could be tested too. At least then kernel or qemu 
could be blamed
for the issues.

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186690): 
https://lists.openembedded.org/g/openembedded-core/message/186690
Mute This Topic: https://lists.openembedded.org/mt/100733646/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-