On Wed, Jan 26, 2022 at 1:17 PM Paul Eggleton
<bluelightning@bluelightning.org> wrote:

On Wednesday, 26 January 2022 14:39:39 NZDT Paul Eggleton wrote:

Hi folks

I've been looking into a couple of compiler flags for hardening that I think
we might want to consider enabling by default in security-flags.inc:


1) -fstack-clash-protection

This option was introduced to gcc 8.x and provides protection against the
stack clash vulnerability:

https://securingsoftware.blogspot.com/2017/12/stack-clash-vulnerability.html

It has been enabled in some Linux distributions already (e.g. Ubuntu,
Fedora).

That is good testimony, it will be good to know how this option
impacts performance
and does it work across architectures and libc's supported in OE.

Another quirk of this - with dunfell, the buildepoxy SDK test fails on Ubuntu
18.04 with -fstack-clash-protection because the version of meson in dunfell
uses the same LDFLAGS value for both host and target, and host gcc doesn't
support that option. Not sure what to do other than just filtering out the
option from LDFLAGS in the test.

Cheers
Paul

On Wednesday, 26 January 2022 14:39:39 NZDT Paul Eggleton wrote:

Hi folks

I've been looking into a couple of compiler flags for hardening that I think
we might want to consider enabling by default in security-flags.inc:


1) -fstack-clash-protection

This option was introduced to gcc 8.x and provides protection against the
stack clash vulnerability:

https://securingsoftware.blogspot.com/2017/12/stack-clash-vulnerability.html

It has been enabled in some Linux distributions already (e.g. Ubuntu,
Fedora).

Another quirk of this - with dunfell, the buildepoxy SDK test fails on Ubuntu
18.04 with -fstack-clash-protection because the version of meson in dunfell
uses the same LDFLAGS value for both host and target, and host gcc doesn't
support that option. Not sure what to do other than just filtering out the
option from LDFLAGS in the test.

Cheers
Paul

On 1/26/22 10:10 AM, Khem Raj wrote:

On Wed, Jan 26, 2022 at 9:21 AM Rudolf J Streif
<rudolf.streif@ibeeto.com> wrote:

I got a question about the linux-firmware-bcm4373 package. The link

/lib/firmware/brcm/brcmfmac4373-sdio.clm_blob ->
../cypress/cyfmac4373-sdio.clm_blob

is packaged into linux-firmware and not into linux-firmware-bcm4373.

It's essentially not included in

FILES:${PN}-bcm4373 =
"${nonarch_base_libdir}/firmware/brcm/brcmfmac4373-sdio.bin \
${nonarch_base_libdir}/firmware/brcm/brcmfmac4373.bin \
${nonarch_base_libdir}/firmware/cypress/cyfmac4373-sdio.bin \
"

which means it is automatically packaged as a "leftover" into
linux-firmware.

Is there a reason for that or is it simply an oversight?

seems an oversight.

Thanks, Khem. I sent a patch to OE.

Thanks,
Rudi

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

On Wed, Jan 26, 2022 at 9:21 AM Rudolf J Streif
<rudolf.streif@ibeeto.com> wrote:

I got a question about the linux-firmware-bcm4373 package. The link

/lib/firmware/brcm/brcmfmac4373-sdio.clm_blob ->
../cypress/cyfmac4373-sdio.clm_blob

is packaged into linux-firmware and not into linux-firmware-bcm4373.

It's essentially not included in

FILES:${PN}-bcm4373 =
"${nonarch_base_libdir}/firmware/brcm/brcmfmac4373-sdio.bin \
${nonarch_base_libdir}/firmware/brcm/brcmfmac4373.bin \
${nonarch_base_libdir}/firmware/cypress/cyfmac4373-sdio.bin \
"

which means it is automatically packaged as a "leftover" into
linux-firmware.

Is there a reason for that or is it simply an oversight?

seems an oversight.

Thanks,
Rudi

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

Hi all

I'd like to install my python3 application in a custom folder with all local packages and data.


The source code folder has this tree


./myapp/__main__.py

./package/__init__.py

./package/pkg.py


I manage the application by myapp_1.0.bb recipe.

I'd like the myapp_1.0.ipk package contains


/home/apps/myapp/__main__.py

/home/apps/package/__init__.py

/home/apps/package/pkg.py


I try setup.py and  inherit setuptools3 in my myapp_git.bb but 'packages' is installed under python system folder.


There is a way to customize the path of python package installation?


MZ

I got a question about the linux-firmware-bcm4373 package. The link

/lib/firmware/brcm/brcmfmac4373-sdio.clm_blob -> ../cypress/cyfmac4373-sdio.clm_blob

is packaged into linux-firmware and not into linux-firmware-bcm4373.

It's essentially not included in

FILES:${PN}-bcm4373 = "${nonarch_base_libdir}/firmware/brcm/brcmfmac4373-sdio.bin \
  ${nonarch_base_libdir}/firmware/brcm/brcmfmac4373.bin \
  ${nonarch_base_libdir}/firmware/cypress/cyfmac4373-sdio.bin \
"

which means it is automatically packaged as a "leftover" into linux-firmware.

Is there a reason for that or is it simply an oversight?

Thanks,
Rudi

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

Hi,

On Tue, Jan 25, 2022 at 04:30:40PM +0000, Ross Burton wrote:

On Mon, 24 Jan 2022 at 16:18, Jon Mason <jdmason@kudzu.us> wrote:

CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE

This is the only one that sticks out to me. I think it needs another
_, SKIP_RECIPE and IGNORE_CVE.

Please don't include CVE twice in the variable name, that's was annoying and just
got used to the CVE_CHECK_WHITELIST one. CVE_CHECK_IGNORE would do.

Cheers,

-Mikko

Other than that, +1.

Will we have a bit of logic to detect the obsolete names being set and
emit warnings/errors?

Ross

Hi Michael,

On January 25, 2022 5:45:46 PM GMT+01:00, Michael Opdenacker <michael.opdenacker@bootlin.com> wrote:

A wrong path was given given the working directory.

Also revert the changes with "git reset --hard" to
have a clean state before further branch switches.

One change at a time please ☺️

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
scripts/run-docs-build | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 5d6d24a..c93b3e6 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -43,11 +43,12 @@ cp -r ./_build/final/* $outputdir/bitbake/next
# see the latest releases.
for branch in 1.46 1.48 1.50 1.52; do
git checkout $branch
- git checkout master doc/releases.rst
+ git checkout master releases.rst
make clean
make publish
mkdir $outputdir/bitbake/$branch
cp -r ./_build/final/* $outputdir/bitbake/$branch
+ git reset --hard

This should be done right after the git checkout. It's better to ensure what you build is clean that try to ensure the next oneto build has a clean env. Especially since checkouts can dirty the git repo I think (I've had this issue multiple times when switching between kernel branches far enough from one another).

Also git reset --hard is not enough. I use git clean -ffdx instead usually. Didn't have a problem with this one for a while now.

done

# only sync bitbake folder for now. We need bitbake to be published first
@@ -79,11 +80,12 @@ cp -r ./_build/final/* $outputdir/next
for branch in dunfell gatesgarth hardknott honister; do
cd $ypdocs
git checkout $branch
- git checkout master documentation/releases.rst
+ git checkout master releases.rst
make clean
make publish
mkdir $outputdir/$branch
cp -r ./_build/final/* $outputdir/$branch
+ git reset --hard

Ditto.

done

# Yocto Project releases/tags
@@ -101,12 +103,13 @@ for tag in $(git tag --list 'yocto-*'); do
if [ "$tag" = "yocto-3.3" ] || [ "$tag" = "yocto-3.4" ]; then
git am "${scriptdir}/${tag}/0001-conf-update-for-release.patch"
fi
- git checkout master documentation/releases.rst
+ git checkout master releases.rst
make clean
make publish
version=$(echo $tag | cut -c7-)
mkdir $outputdir/$version
cp -r ./_build/final/* $outputdir/$version
+ git reset --hard

Ditto.

Cheers,
Quentin

fi
done

Hello All,

Advice on working with Yocto and Raspberry Pi CM4 Lite would be helpful.

I recently got my hands on with CM4 and now I want to build Yocto image with u-boot as bootloader. I have few doubts before I start the build.

1. Which machine to use in local.conf file? In the meta-raspberrypi there is no specific machine for CM4 https://github.com/agherzan/meta-raspberrypi/tree/master/conf/machine. Will the "raspberrypi4-64" and "raspberrypi4" also work for CM4? As per my understanding the Raspberry Pi 4 and CM4 are mostly the same except for the device tree and drivers. Which device tree will work with RPi CM4? Do I need to generate them separately for CM4?
2. Since I have CM4 lite, there is no on board eMMC. I am using custom IO board and it has SD card slot. I can boot from SD card instead. Do I need to set anything specific for CM4 to work in my image recipe or local.conf? Is it same as booting RPi 4 from uSD card?

My intention is to use RPi CM4 for software updates using RAUC.

Can anyone please let me about these? This would help me to get started.

Thanks in advance.

Please let me know if any details are missing.

I am trying to fetch a private gitlab repo within Yocto image recipe using SSH protocol. In my image recipe I have passed SRC_URI as:

SRC_URI = " \
        gitsm://git@...:2224/blah/blah/blah/blah;protocol=ssh;branch=master \
"

But this results in the error:

ERROR: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export PATH="/root /build-swu-v2/tmp/sysroots-uninative/x86_64-linux/usr/bin:/root/sources/poky/scripts: /root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/awsclient/1.4- r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi:/root/build-swu-v2/tmp /work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/awsclient/1.4-r0/recipe-sysroot/usr/bin /crossscripts:/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi /awsclient/1.4-r0/recipe-sysroot-native/usr/sbin:/root/build-swu-v2/tmp/work/cortexa7t2hf- neon-vfpv4-poky-linux-gnueabi/awsclient/1.4-r0/recipe-sysroot-native/usr/bin:/root/build- swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/awsclient/1.4-r0/recipe-sysroot- native/sbin:/root/build-swu-v2/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi /awsclient/1.4-r0/recipe-sysroot-native/bin:/root/sources/poky/bitbake/bin:/root/build-swu- v2/tmp/hosttools"; export HOME="/root"; LANG=C git -c core.fsyncobjectfiles=0 clone --bare  --mirror "ssh://git@...:2224/iot/products/iot-device-suite_client/aws- iot-client" /root/downloads//git2/git@...:2224/blah/blah/blah/blah --progress failed with exit code 128, no output
ERROR: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.',  'gitsm://git@...:2224/blah/blah/blah/blah;protocol=ssh;branch=master')
DEBUG: Python function base_do_fetch finished

But I am able to clone the repo using git clone.

SSH key is already added to the Gitlab. There is no config file in my ~/.ssh. Do I need to create a config file? What should be the content of the config file?

Can anyone please let me know how to resolve this?

Thanks in advance.

Hi all,

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

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

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

ETA for completion next Monday, Jan 31.

Thanks,
Jay

On Tuesday, 25 January 2022 21:26:33 NZDT Paul Barker wrote:

The layer index may need some modification to handle different layers
having different names for the in-development branch. We could implement
the layer index changes first to support other layers which rename their
master branch.

I'm going to bite the bullet with meta-linux-mainline and rename the
master branch to "dev" this week to see what happens.

The layer index does already support this, it's just not exposed (at the time
I introduced it - some time ago - I thought it might encourage people to
deviate from the release branch names, but in hindsight that was probably not
worth worrying about.) So at the moment an admin can set an alternative branch
name. It would not be hard to expose it through the UI for layer maintainers
though.

Cheers,
Paul

Hi folks

I've been looking into a couple of compiler flags for hardening that I think we
might want to consider enabling by default in security-flags.inc:


1) -fstack-clash-protection

This option was introduced to gcc 8.x and provides protection against the
stack clash vulnerability:

https://securingsoftware.blogspot.com/2017/12/stack-clash-vulnerability.html

It has been enabled in some Linux distributions already (e.g. Ubuntu, Fedora).


2) -z noexecstack (or alternative mitigations)

gcc will enable an executable stack under a few different circumstances - see
here for details

https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart

I've written a check that we could add to insane.bbclass that warns/errors on
binaries with an executable stack. Does this seem reasonable to have?
The other possibility is we add -Wl,-z,noexecstack to LDFLAGS and then see
what breaks, but unfortunately issues are likely only going to show up when
the program crashes at runtime, and also it will stop the aforementioned check
from working.


Any opinions?

Thanks
Paul

Once a week has proven a bit too hectic: it's better to have
more time to test, submit, review and integrate the updates
before AUH runs again.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
schedulers.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/schedulers.py b/schedulers.py
index a5d740e..32e3efe 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -417,9 +417,9 @@ schedulers.append(sched.Nightly(name='nightly-buildperf-ubuntu1604', branch='mas
schedulers.append(sched.Nightly(name='nightly-buildperf-centos7', branch='master', properties=parent_default_props('buildperf-centos7'),
builderNames=['buildperf-centos7'], hour=[3,9,15,21], minute=0))

-# Run the AUH every Sunday
+# Run the AUH twice a month on 1st and 15th
schedulers.append(sched.Nightly(name='nightly-auh', branch='master', properties=parent_default_props('auh'),
- builderNames=['auh'], dayOfWeek=6, hour=5, minute=0))
+ builderNames=['auh'], dayOfMonth=[1, 15], hour=5, minute=0))

# If any of our sphinx docs branches change, trigger a build
schedulers.append(sched.AnyBranchScheduler(name="yocto-docs-changed",
--
2.34.1

On 2022-01-24 11:17, Jon Mason wrote:

From the beginning, OpenEmbedded and The Yocto Project have always

strived to be as inclusive as possible to all races, sexes,
orientations, religions, nationalities, and any other thing which
might divide people. As continuation of this striving, there are
suggested changes below that are being proposed to make the projects
more inclusive and show the community as the professional, friendly,
and welcoming group that it is. There are words in use by the
projects directly or one of its derivative layers that could be
offensive to some. For more information on which words we selected
and why, please consult
https://inclusivenaming.org/word-lists/overview/
In the process of changing these, we are using this opportunity to
make the terms more obvious and useful, as well as removing cruft and
other unused code. This is the pure definition of a win-win solution.
With this in mind, a group of people have tried to identify issues and
come up with a plan to address these. We’ve divided the tasks into 3
areas: bitbake variables, oe-core variables, and everything else.

Jon,

I've looked over all the changes and agree with Ross on his one suggestion
and that the rest of the changes are fine.


The new terms are equally or in some cases more clear so hopefully that will
result in less confusion and a better experience for everyone at the one-time
cost of a hopefully not too bumpy transition.

Thanks!

../Randy

Bitbake Variables
Taking issues in turn, for bitbake:
For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
become "HALT, NO_NEW_TASKS and "WARN".
BB_ENV_WHITELIST -> BB_ENV_PASSTHROUGH
BB_ENV_EXTRAWHITE -> BB_ENV_PASSTHROUGH_ADDITIONS
BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS
BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
BB_STAMP_WHITELIST and BB_STAMP_POLICY -> delete the code (already merged)
basewhitelist and taskwhitelist as used in sigdata/siginfo will need
to be renamed and older file usage of the variables renamed at import
for backwards compatibility. The variables in bitbake along with usage
of abort will be renamed as appropriate.
For most variables, errors will be shown to the user if the old
variable names are set. Mostly this can be done in event hooks but
some like the BB_ENV changes will need special handling.
These changes hopefully improve consistency (e.g. a consistent BB_
prefix and BASHHASH as terminology used elsewhere) and also improve
the description of the variables to be more understandable to users.
OE-Core Variables
For OE-Core, the proposals are:
For blacklist.bbclass, the proposal is to add the functionality to the
anonymous Python in base.bbclass instead. PNBLACKLIST[xxx] would
become SKIP_RECIPE[xxx]. INHERIT_BLACKLIST would simply be dropped.
SSTATE_DUPWHITELIST -> SSTATE_ALLOW_OVERLAP_FILES
CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
SYSROOT_DIRS_BLACKLIST -> SYSROOT_DIRS_IGNORE
LICENSE_FLAGS_WHITELIST -> LICENSE_FLAGS_ACCEPTED
UNKNOWN_CONFIGURE_WHITELIST -> UNKNOWN_CONFIGURE_OPT_IGNORE
SDK_LOCAL_CONF_BLACKLIST -> ESDK_LOCALCONF_REMOVE
SDK_LOCAL_CONF_WHITELIST -> ESDK_LOCALCONF_ALLOW
SDK_INHERIT_BLACKLIST -> ESDK_CLASS_INHERIT_DISABLE
TUNEABI_WHITELIST - already removed as obsolete
For the ICECC_USER_XXX and ICECC_SYSTEM_XXX, we think these can likely
be merged into single variables:
ICECC_USER_CLASS_BL -> ICECC_CLASS_DISABLE
ICECC_SYSTEM_CLASS_BL -> ICECC_CLASS_DISABLE
ICECC_USER_PACKAGE_WL -> ICECC_RECIPE_ENABLE
ICECC_USER_PACKAGE_BL -> ICECC_RECIPE_DISABLE
ICECC_SYSTEM_PACKAGE_BL -> ICECC_RECIPE_DISABLE
For license handling, we’d use the opportunity to clean up the
WHITELIST_(ANY LICENSE) syntax and replace it with a
INCOMPATIBLE_LICENSE_ALLOWED_RECIPES, which would be a list of recipes
which are of a blocked the INCOMPATIBLE_LICENSE list.
Everything else
The migration plan includes writing a script to assist with the
migration. In many cases it can likely make the translation. In cases
where that isn’t possible, it will aim to list the areas the user
needs to fix references.
A warning mechanism will be added to bitbake to detect usage of old
variable names (post parsing), except for BB_ENV issues which will
likely need special handling. A (limited) conversion script will be
created to help with the migration. For those instances where a 1-1
mapping is not achievable, a list of the occurrences and what it
should be changed to will occur.
Patch files in OE to be renamed:
11_tcpd_blacklist.patch -> 11_tcpd_blocklist.patch
mount.blacklist -> mount.disallow
0001-lxdm.conf.in-blacklist-root-for-release-images.patch ->
0001-lxdm.conf.in-deny-root-for-release-images.patch
022-RH-Remove-the-property-blacklist-exception-builtin.patch ->
022-RH-Remove-the-default-property-exception-builtin.patch
0001-Cargo.toml-do-not-abort-on-panic.patch ->
0001-Cargo.toml-do-not-exit-on-panic.patch
0004-Cargo.toml-do-not-abort-on-panic.patch ->
0004-Cargo.toml-do-not-exit-on-panic.patch
Also, there are a few others outside of OE that should probably be patched too.
Branch Names
The “master” branches on the relevant OpenEmbedded and Yocto Project
git trees will be changed to an alternative name at some point in the
future. The current preferred name is “devel”. There is no time
table for this currently, and there is no obligation or requirement to
change the branch name for any downstream project which is beyond the
project’s remit.
Similarly, there is no need to change any recipes that are using a
“master” branch as part of the SRC_URI. Those are outside the scope
of YP/OE and this effort.
Note
These changes are only to bitbake and OE-Core. There is no
requirement to change any other layers but we’d note consistency is
encouraged and helpful to users.
Helping
If you would like to help, please put your name by the items in
question on the inclusive language wiki page.
https://wiki.yoctoproject.org/wiki/Inclusive_language
Thanks
Special thanks to Richard Purdie, Michael Opdenacker. Marta
Rybczynska, Scott Murray, Jan-Simon Moeller, Saul Wold, and Armin
Kuster for providing their time, technical details, text, and feedback
on this task.

--
# Randy MacLeod
# Wind River Linux