[OE-core][master][PATCH] tiff: Remove unused patch from tiff
Remove 0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
file from tiff as it was removed while upgrading tiff from
4.4.0 -> 4.5.0
Signed-off-by: Nikhil R
---
...-of-TIFFTAG_INKNAMES-and-related-TIF.patch | 267 --
1 file changed, 267 deletions(-)
delete mode 100644
meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
diff --git
a/meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
b/meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
deleted file mode 100644
index 17b37be041..00
---
a/meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
+++ /dev/null
@@ -1,267 +0,0 @@
-From f00484b9519df933723deb38fff943dc291a793d Mon Sep 17 00:00:00 2001
-From: Su_Laus
-Date: Tue, 30 Aug 2022 16:56:48 +0200
-Subject: [PATCH] Revised handling of TIFFTAG_INKNAMES and related
- TIFFTAG_NUMBEROFINKS value
-
-In order to solve the buffer overflow issues related to TIFFTAG_INKNAMES and
related TIFFTAG_NUMBEROFINKS value, a revised handling of those tags within
LibTiff is proposed:
-
-Behaviour for writing:
-`NumberOfInks` MUST fit to the number of inks in the `InkNames` string.
-`NumberOfInks` is automatically set when `InkNames` is set.
-If `NumberOfInks` is different to the number of inks within `InkNames`
string, that will be corrected and a warning is issued.
-If `NumberOfInks` is not equal to samplesperpixel only a warning will be
issued.
-
-Behaviour for reading:
-When reading `InkNames` from a TIFF file, the `NumberOfInks` will be set
automatically to the number of inks in `InkNames` string.
-If `NumberOfInks` is different to the number of inks within `InkNames`
string, that will be corrected and a warning is issued.
-If `NumberOfInks` is not equal to samplesperpixel only a warning will be
issued.
-
-This allows the safe use of the NumberOfInks value to read out the InkNames
without buffer overflow
-
-This MR will close the following issues: #149, #150, #152, #168 (to be
checked), #250, #269, #398 and #456.
-
-It also fixes the old bug at
http://bugzilla.maptools.org/show_bug.cgi?id=2599, for which the limitation of
`NumberOfInks = SPP` was introduced, which is in my opinion not necessary and
does not solve the general issue.
-
-CVE: CVE-2022-3599 CVE-2022-4645
-Upstream-Status: Backport
[https://gitlab.com/libtiff/libtiff/-/commit/e813112545942107551433d61afd16ac094ff246.patch]
-Signed-off-by: Ross Burton
-Signed-off-by: Pawan Badganchi
- libtiff/tif_dir.c | 119 -
- libtiff/tif_dir.h | 2 +
- libtiff/tif_dirinfo.c | 2 +-
- libtiff/tif_dirwrite.c | 5 ++
- libtiff/tif_print.c| 4 ++
- 5 files changed, 82 insertions(+), 50 deletions(-)
-
-diff --git a/libtiff/tif_dir.c b/libtiff/tif_dir.c
-index 793e8a79..816f7756 100644
a/libtiff/tif_dir.c
-+++ b/libtiff/tif_dir.c
-@@ -136,32 +136,30 @@ setExtraSamples(TIFF* tif, va_list ap, uint32_t* v)
- }
-
- /*
-- * Confirm we have "samplesperpixel" ink names separated by \0. Returns
-+ * Count ink names separated by \0. Returns
- * zero if the ink names are not as expected.
- */
--static uint32_t
--checkInkNamesString(TIFF* tif, uint32_t slen, const char* s)
-+static uint16_t
-+countInkNamesString(TIFF *tif, uint32_t slen, const char *s)
- {
-- TIFFDirectory* td = >tif_dir;
-- uint16_t i = td->td_samplesperpixel;
-+ uint16_t i = 0;
-+ const char *ep = s + slen;
-+ const char *cp = s;
-
- if (slen > 0) {
-- const char* ep = s+slen;
-- const char* cp = s;
-- for (; i > 0; i--) {
-+ do {
- for (; cp < ep && *cp != '\0'; cp++) {}
- if (cp >= ep)
- goto bad;
- cp++; /* skip \0 */
-- }
-- return ((uint32_t)(cp - s));
-+ i++;
-+ } while (cp < ep);
-+ return (i);
- }
- bad:
- TIFFErrorExt(tif->tif_clientdata, "TIFFSetField",
-- "%s: Invalid InkNames value; expecting %"PRIu16" names, found
%"PRIu16,
-- tif->tif_name,
-- td->td_samplesperpixel,
-- (uint16_t)(td->td_samplesperpixel-i));
-+ "%s: Invalid InkNames value; no NUL at given buffer end
location %"PRIu32", after %"PRIu16" ink",
-+ tif->tif_name, slen, i);
- return (0);
- }
-
-@@ -478,13 +476,61 @@ _TIFFVSetField(TIFF* tif, uint32_t tag, va_list ap)
- _TIFFsetFloatArray(>td_refblackwhite, va_arg(ap, float*),
6);
- break;
- case TIFFTAG_INKNAMES:
-- v = (uint16_t) va_arg(ap, uint16_vap);
-- s = va_arg(ap, char*);
-- v = checkInkNamesString(tif,
Re: [OE-core] [yocto] QA notification for completed autobuilder build (yocto-3.1.25.rc1)
Hi All, QA for yocto-3.1.25.rc1 is completed. This is the full report for this release: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults === Summary No high milestone defects. No new issue found. Thanks, Jing Hui > -Original Message- > From: yo...@lists.yoctoproject.org On > Behalf Of Pokybuild User > Sent: Saturday, May 6, 2023 5:33 PM > To: yo...@lists.yoctoproject.org > Cc: qa-build-notificat...@lists.yoctoproject.org > Subject: [yocto] QA notification for completed autobuilder build (yocto- > 3.1.25.rc1) > > > A build flagged for QA (yocto-3.1.25.rc1) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.1.25.rc1 > > > Build hash information: > > bitbake: e16a9ca7e9286790ac37a067fdc8fde3a35a1c44 > meta-agl: bb1af1fb2458c495e75400f9ef6e853f654418ca > meta-arm: b1fe8443a7a72c65fa0fc3371f607c6671b3a882 > meta-aws: baa97b9aa3b9de36369b0ff1bb74e1596828b967 > meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac > meta-intel: 488af577a3f21f038c551612bb0af077fa2b743d > meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 > meta-openembedded: e39b002df9675776cc99dccdcac07607ce783b15 > meta-virtualization: beea119eb529b4a11f266004aee8b548427aea39 > oecore: fd4cc8d7b5156c43d162a1a5a809fae507457ef4 > poky: a631bfc3a38f7d00b2c61a89a758a0af9831 > > > > This is an automated message from the Yocto Project Autobuilder > Git: git://git.yoctoproject.org/yocto-autobuilder2 > Email: richard.pur...@linuxfoundation.org > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181126): https://lists.openembedded.org/g/openembedded-core/message/181126 Mute This Topic: https://lists.openembedded.org/mt/98754358/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-yocto: fix missing pahole and elfutils when CONFIG_DEBUG_INFO_BTF enabled in devshell
Hi Richard and Bruce, Thanks for your suggestion, On 5/11/23 00:25, Bruce Ashfield wrote: 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. On Wed, May 10, 2023 at 12:16 PM Richard Purdie wrote: On Mon, 2023-05-08 at 09:33 +0800, Xiangyu Chen wrote: From: Xiangyu Chen after enable the kernel CONFIG_DEBUG_INFO_BTF in devshell, the make would report some errors due to pahole and elfuitls is missing, since this is a debug option, so conditionally add an option named "btf" in KERNEL_DEBUG_OPTIONS, if someone need enable CONFIG_DEBUG_INFO_BTF option in devshell, they can add KERNEL_DEBUG_OPTIONS += "btf" in local.conf to solve the pahole and elfutils dependency. Is this a defined workflow somewhere? Is KERNEL_DEBUG_OPTIONS with this option documented somewhere? I also think the mention of devshell in the commit message is misleading, this issue happens regardless of how you enable the option. There are also other ways of enabling this than local.conf, you'd likely not want people doing that at the end of development. I'm curious on Bruce's opinion but to me this at the very least needs a commit message rewrite and I'd question whether the docs elsewhere would allow someone to discover this workflow anyway. I missed this entirely, thanks for replying to it, or I never would have noticed. This mechanism isn't appropriate for these dependencies. I only added it to work around pkgconfig issues (which we can more cleanly solve in newer kernels (see what I've been doing with make-mod-scripts) .. so it can eventually be dropped). We are already enabling elfutils-native conditionally on a per-architecture basis (currently only x86-64). If we need it on more arches now, we should enable it in the version specific recipes, or actually, we have moved far enough into newer kernel's that it could be in the .inc now. This commit's background was some kernel debug options needs elfutils and pahole native package, since the issue happens on enabling kernel debug options and not all people needs it, so I conditionally add the dependency in KERNEL_DEBUG_OPTION. If possible we can enable it in .inc because newer kernel tools like btf are support using pkg-config to locate the libelf instead of finding it from /usr/ folder, so we can use elfutils-natvie instead of installing elfutils package on host PC. Similarly, we should enable the pahole-native dependency on a per-arch basis. As Richard mentioned, what's the reproducer to see the errors ? it must be more than devshell. Yes, this happens on devshell and normal world if some kernel debug options are enabled. We can reproduce this issue with following steps(I have found the issue with kernel 5.15): 1. enable kernel option CONFIG_DEBUG_KERNEL CONFIG_DEBUG_INFO and CONFIG_DEBUG_INFO_BTF 2. build the kernel image, the compiler would report missing libelf.h and gelf.h which contains in elfutils-native(this step not happens on x86-64 due to it has been enabled). 3. enable elfutils-native by manual, the kernel source code can be compiled successfully but failed in final step due to missing pahole. If you can follow up with the steps to reproduce, I can take on the refactoring and broader dependency cleanup question, since I can test the wider matrix at the same time. Thanks, my local setup might missing some corner case, this is another reason I enable those native packages limit in KERNEL_DEBUG_OPTION :). Xiangyu Bruce Cheers, Richard -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181125): https://lists.openembedded.org/g/openembedded-core/message/181125 Mute This Topic: https://lists.openembedded.org/mt/98753313/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 v2][kirkstone] linux-yocto: Exclude 121 CVEs already fixed upstream
Thanks for the quick turnaround! Steve On Wed, May 10, 2023 at 9:58 AM Yoann Congal wrote: > > Exclude CVEs that are fixed in both current linux-yocto version > v5.10.175 and v5.15.108. > > To get the commit fixing a CVE, I used the Debian kernel-sec repo [1]. > > [1]: > https://salsa.debian.org/kernel-team/kernel-sec/-/commit/86d5040aee9275f9555458fcaf9cb43710dff398 > > Signed-off-by: Yoann Congal > --- > meta/recipes-kernel/linux/cve-exclusion.inc | 875 > meta/recipes-kernel/linux/linux-yocto.inc | 3 + > 2 files changed, 878 insertions(+) > create mode 100644 meta/recipes-kernel/linux/cve-exclusion.inc > > diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc > b/meta/recipes-kernel/linux/cve-exclusion.inc > new file mode 100644 > index 00..45b7a3dffe > --- /dev/null > +++ b/meta/recipes-kernel/linux/cve-exclusion.inc > @@ -0,0 +1,875 @@ > +# 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
Re: [OE-core][Patch v2 1/3] libtraceevent: import from meta-openembedded
On Tue, May 9, 2023 at 1:09 PM Jose Quaresma wrote:
>
> Hi Max,
>
> This also needs an entry on meta/conf/distro/include/maintainers.inc
>
Max,
I'm already maintaining perf, so if you want to put my name beside
libraceevent for a v3, that's fine with me.
Bruce
> Jose
>
> Max Krummenacher escreveu no dia terça, 9/05/2023 à(s)
> 17:13:
>>
>> From: Max Krummenacher
>>
>> Import from meta-openembedded at commit d250a0dc0 ("libtraceevent:
>> upgrade 1.7.1 -> 1.7.2").
>> Starting with kernel 6.4 libtraceevent is a dependency of perf. While
>> one can still build perf without it by opting out one would loose its
>> functionality compared with building perf from kernels before 6.4
>>
>> Signed-off-by: Max Krummenacher
>> ---
>> ...not-preserve-ownership-in-cp-command.patch | 40 +++
>> .../libtraceevent/libtraceevent_1.7.2.bb | 25
>> 2 files changed, 65 insertions(+)
>> create mode 100644
>> meta/recipes-kernel/libtraceevent/libtraceevent/0001-makefile-Do-not-preserve-ownership-in-cp-command.patch
>> create mode 100644 meta/recipes-kernel/libtraceevent/libtraceevent_1.7.2.bb
>>
>> diff --git
>> a/meta/recipes-kernel/libtraceevent/libtraceevent/0001-makefile-Do-not-preserve-ownership-in-cp-command.patch
>>
>> b/meta/recipes-kernel/libtraceevent/libtraceevent/0001-makefile-Do-not-preserve-ownership-in-cp-command.patch
>> new file mode 100644
>> index 00..5e88048817
>> --- /dev/null
>> +++
>> b/meta/recipes-kernel/libtraceevent/libtraceevent/0001-makefile-Do-not-preserve-ownership-in-cp-command.patch
>> @@ -0,0 +1,40 @@
>> +From ed0a31000305d937abe47c44d705b5b52bb36f79 Mon Sep 17 00:00:00 2001
>> +From: Khem Raj
>> +Date: Thu, 22 Dec 2022 18:32:17 -0800
>> +Subject: [PATCH] makefile: Do not preserve ownership in cp command
>> +
>> +Fixes
>> +
>> +ERROR: libtraceevent-1.7.0-r0 do_package_qa: QA Issue: libtraceevent:
>> /usr/lib/libtraceevent.a is owned by uid 1000, which is the same as the user
>> running bitbake. This may be due to host contamination
>> [host-user-contaminated]
>> +
>> +Upstream-Status: Pending
>> +Signed-off-by: Khem Raj
>> +---
>> + Makefile | 4 ++--
>> + 1 file changed, 2 insertions(+), 2 deletions(-)
>> +
>> +diff --git a/Makefile b/Makefile
>> +index 965ff47..0e782cb 100644
>> +--- a/Makefile
>> b/Makefile
>> +@@ -287,7 +287,7 @@ $(BUILD_PREFIX): force
>> + $(Q)$(call build_prefix,$(prefix))
>> +
>> + define do_make_pkgconfig_file
>> +- cp -f ${PKG_CONFIG_SOURCE_FILE}.template ${PKG_CONFIG_FILE};\
>> ++ install -m 0644 ${PKG_CONFIG_SOURCE_FILE}.template
>> ${PKG_CONFIG_FILE}; \
>> + sed -i "s|INSTALL_PREFIX|${1}|g" ${PKG_CONFIG_FILE};\
>> + sed -i "s|LIB_VERSION|${EVENT_PARSE_VERSION}|g" ${PKG_CONFIG_FILE}; \
>> + sed -i "s|LIB_DIR|${libdir_relative}|g" ${PKG_CONFIG_FILE}; \
>> +@@ -335,7 +335,7 @@ install: install_libs install_plugins
>> +
>> + install_libs: libs install_headers install_pkgconfig
>> + $(Q)$(call do_install,$(LIBTRACEEVENT_SHARED),$(libdir_SQ)); \
>> +- cp -fpR $(LIB_INSTALL) $(DESTDIR)$(libdir_SQ)
>> ++ cp --no-preserve=ownership --recursive $(LIB_INSTALL)
>> $(DESTDIR)$(libdir_SQ)
>> + $(Q)$(call install_ld_config)
>> +
>> + install_pkgconfig: $(PKG_CONFIG_FILE)
>> +--
>> +2.39.0
>> +
>> diff --git a/meta/recipes-kernel/libtraceevent/libtraceevent_1.7.2.bb
>> b/meta/recipes-kernel/libtraceevent/libtraceevent_1.7.2.bb
>> new file mode 100644
>> index 00..089b6814c7
>> --- /dev/null
>> +++ b/meta/recipes-kernel/libtraceevent/libtraceevent_1.7.2.bb
>> @@ -0,0 +1,25 @@
>> +# Copyright (C) 2022 Khem Raj
>> +# Released under the MIT license (see COPYING.MIT for the terms)
>> +
>> +SUMMARY = "API to access the kernel tracefs directory"
>> +HOMEPAGE = "https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/;
>> +LICENSE = "GPL-2.0-or-later & LGPL-2.1-or-later"
>> +LIC_FILES_CHKSUM =
>> "file://LICENSES/GPL-2.0;md5=e6a75371ba4d16749254a51215d13f97 \
>> +
>> file://LICENSES/LGPL-2.1;md5=b370887980db5dd40659b50909238dbd"
>> +SECTION = "libs"
>> +
>> +SRCREV = "1c6f0f3b2bb47571fc455dc565dc343152517d98"
>> +SRC_URI =
>> "git://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git;branch=${BPN};protocol=https
>> \
>> +
>> file://0001-makefile-Do-not-preserve-ownership-in-cp-command.patch"
>> +
>> +S = "${WORKDIR}/git"
>> +
>> +inherit pkgconfig
>> +
>> +do_install() {
>> +oe_runmake install DESTDIR=${D} pkgconfig_dir=${libdir}/pkgconfig
>> +}
>> +
>> +PACKAGES += "${PN}-plugins"
>> +
>> +FILES:${PN}-plugins += "${libdir}/traceevent/plugins"
>> --
>> 2.35.3
>>
>>
>>
>>
>
>
> --
> Best regards,
>
> José Quaresma
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181123):
[OE-core] [PATCH v2][kirkstone] linux-yocto: Exclude 121 CVEs already fixed upstream
Exclude CVEs that are fixed in both current linux-yocto version v5.10.175 and v5.15.108. To get the commit fixing a CVE, I used the Debian kernel-sec repo [1]. [1]: https://salsa.debian.org/kernel-team/kernel-sec/-/commit/86d5040aee9275f9555458fcaf9cb43710dff398 Signed-off-by: Yoann Congal --- meta/recipes-kernel/linux/cve-exclusion.inc | 875 meta/recipes-kernel/linux/linux-yocto.inc | 3 + 2 files changed, 878 insertions(+) create mode 100644 meta/recipes-kernel/linux/cve-exclusion.inc diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc new file mode 100644 index 00..45b7a3dffe --- /dev/null +++ b/meta/recipes-kernel/linux/cve-exclusion.inc @@ -0,0 +1,875 @@ +# 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
[OE-core] [PATCH][mickledore] cpio: fix appending to archives larger than 2GB
From: Ross Burton Backport a patch to fix appending to archives larger than 2GB. [ YOCTO #11674 ] Signed-off-by: Ross Burton --- ...appending-to-archives-bigger-than-2G.patch | 312 ++ meta/recipes-extended/cpio/cpio_2.13.bb | 1 + 2 files changed, 313 insertions(+) create mode 100644 meta/recipes-extended/cpio/cpio-2.13/0001-Fix-appending-to-archives-bigger-than-2G.patch diff --git a/meta/recipes-extended/cpio/cpio-2.13/0001-Fix-appending-to-archives-bigger-than-2G.patch b/meta/recipes-extended/cpio/cpio-2.13/0001-Fix-appending-to-archives-bigger-than-2G.patch new file mode 100644 index 000..fefd5b2894e --- /dev/null +++ b/meta/recipes-extended/cpio/cpio-2.13/0001-Fix-appending-to-archives-bigger-than-2G.patch @@ -0,0 +1,312 @@ +From 0987d63384f0419b4b14aecdc6a61729b75ce86a Mon Sep 17 00:00:00 2001 +From: Sergey Poznyakoff +Date: Fri, 28 Apr 2023 15:23:46 +0300 +Subject: [PATCH] Fix appending to archives bigger than 2G + +* src/extern.h (last_header_start): Change type to off_t. +* src/global.c: Likewise. +* src/util.c (prepare_append): Use off_t for file offsets. + +Upstream-Status: Backport +Signed-off-by: Ross Burton +--- + src/extern.h | 11 - + src/global.c | 2 +- + src/util.c | 66 ++-- + 3 files changed, 39 insertions(+), 40 deletions(-) + +diff --git a/src/extern.h b/src/extern.h +index df7d0ce..6afbdd2 100644 +--- a/src/extern.h b/src/extern.h +@@ -68,7 +68,7 @@ extern int ignore_dirnlink_option; + + extern bool to_stdout_option; + +-extern int last_header_start; ++extern off_t last_header_start; + extern int copy_matching_files; + extern int numeric_uid; + extern char *pattern_file_name; +@@ -128,7 +128,7 @@ void field_width_error (const char *filename, const char *fieldname, + + /* copypass.c */ + void process_copy_pass (void); +-int link_to_maj_min_ino (char *file_name, int st_dev_maj, ++int link_to_maj_min_ino (char *file_name, int st_dev_maj, +int st_dev_min, ino_t st_ino); + int link_to_name (char const *link_name, char const *link_target); + +@@ -176,7 +176,7 @@ void copy_files_tape_to_disk (int in_des, int out_des, off_t num_bytes); + void copy_files_disk_to_tape (int in_des, int out_des, off_t num_bytes, char *filename); + void copy_files_disk_to_disk (int in_des, int out_des, off_t num_bytes, char *filename); + void warn_if_file_changed (char *file_name, off_t old_file_size, +- time_t old_file_mtime); ++ time_t old_file_mtime); + void create_all_directories (char const *name); + void prepare_append (int out_file_des); + char *find_inode_file (ino_t node_num, +@@ -190,7 +190,7 @@ void set_new_media_message (char *message); + #ifdef HPUX_CDF + char *add_cdf_double_slashes (char *filename); + #endif +-void write_nuls_to_file (off_t num_bytes, int out_des, ++void write_nuls_to_file (off_t num_bytes, int out_des, +void (*writer) (char *in_buf, +int out_des, off_t num_bytes)); + #define DISK_IO_BLOCK_SIZE512 +@@ -234,6 +234,5 @@ void delay_set_stat (char const *file_name, struct stat *st, +mode_t invert_permissions); + int repair_delayed_set_stat (struct cpio_file_stat *file_hdr); + void apply_delayed_set_stat (void); +- +-int arf_stores_inode_p (enum archive_format arf); + ++int arf_stores_inode_p (enum archive_format arf); +diff --git a/src/global.c b/src/global.c +index d33516f..7c4bca8 100644 +--- a/src/global.c b/src/global.c +@@ -113,7 +113,7 @@ int debug_flag = false; + + /* File position of last header read. Only used during -A to determine +where the old TRAILER!!! record started. */ +-int last_header_start = 0; ++off_t last_header_start = 0; + + /* With -i; if true, copy only files that match any of the given patterns; +if false, copy only files that do not match any of the patterns. (-f) */ +diff --git a/src/util.c b/src/util.c +index a38333a..7415e10 100644 +--- a/src/util.c b/src/util.c +@@ -59,8 +59,8 @@ tape_empty_output_buffer (int out_des) + static long output_bytes_before_lseek = 0; + + /* Some tape drivers seem to have a signed internal seek pointer and +- they lose if it overflows and becomes negative (e.g. when writing +- tapes > 2Gb). Doing an lseek (des, 0, SEEK_SET) seems to reset the ++ they lose if it overflows and becomes negative (e.g. when writing ++ tapes > 2Gb). Doing an lseek (des, 0, SEEK_SET) seems to reset the + seek pointer and prevent it from overflowing. */ + if (output_is_special + && ( (output_bytes_before_lseek += output_size) >= 1073741824L) ) +@@ -104,7 +104,7 @@ static ssize_t sparse_write (int fildes, char *buf, size_t nbyte, bool flush); +descriptor OUT_DES and reset `output_size' and `out_buff'. +If `swapping_halfwords' or `swapping_bytes' is set, +do the appropriate swapping first. Our
Re: [OE-core] [PATCH V2] Fix error SRCDIR when using usrmerge DISTRO_FEATURES
First, please use the commit message convention: the shortlog should start with
"e2fsprogs:”.
> In Makefile.in, SRCDIR is set by prefix and libdir.
> @echo "SRCDIR=${prefix}${libdir}/e2fsprogs/ptest/test" >> test_one
> @echo "SRCDIR=${prefix}${libdir}/e2fsprogs/ptest/test" >> test_script
> prefix=/usr
> libdir=/usr/lib (when usrmerge is set)
> solution
> After ptest compiling, check and modify SRCDIR in test_script and test_one.
The reason is correct, but the fix is wrong.
$libdir *always* includes $prefix. This only works in non-usrmerge builds
because for historical reasons we pass —libdir=$(base_libdir), which sets
libdir=/lib. This happens to work because /usr/lib is actually where the ptest
files are installed, but that is pure coincidence.
Also, this broken part of the Makefile is a rule that *we patch in* (see
ptest.patch), so simply fix that patch instead of working around it in with a
sed.
Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181120):
https://lists.openembedded.org/g/openembedded-core/message/181120
Mute This Topic: https://lists.openembedded.org/mt/98532823/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-yocto: fix missing pahole and elfutils when CONFIG_DEBUG_INFO_BTF enabled in devshell
On Wed, May 10, 2023 at 12:16 PM Richard Purdie wrote: > > On Mon, 2023-05-08 at 09:33 +0800, Xiangyu Chen wrote: > > From: Xiangyu Chen > > > > after enable the kernel CONFIG_DEBUG_INFO_BTF in devshell, the make would > > report some > > errors due to pahole and elfuitls is missing, since this is a debug option, > > so conditionally > > add an option named "btf" in KERNEL_DEBUG_OPTIONS, if someone need enable > > CONFIG_DEBUG_INFO_BTF > > option in devshell, they can add KERNEL_DEBUG_OPTIONS += "btf" in > > local.conf to solve the pahole > > and elfutils dependency. > > Is this a defined workflow somewhere? Is KERNEL_DEBUG_OPTIONS with this > option documented somewhere? > > I also think the mention of devshell in the commit message is > misleading, this issue happens regardless of how you enable the option. > There are also other ways of enabling this than local.conf, you'd > likely not want people doing that at the end of development. > > I'm curious on Bruce's opinion but to me this at the very least needs a > commit message rewrite and I'd question whether the docs elsewhere > would allow someone to discover this workflow anyway. I missed this entirely, thanks for replying to it, or I never would have noticed. This mechanism isn't appropriate for these dependencies. I only added it to work around pkgconfig issues (which we can more cleanly solve in newer kernels (see what I've been doing with make-mod-scripts) .. so it can eventually be dropped). We are already enabling elfutils-native conditionally on a per-architecture basis (currently only x86-64). If we need it on more arches now, we should enable it in the version specific recipes, or actually, we have moved far enough into newer kernel's that it could be in the .inc now. Similarly, we should enable the pahole-native dependency on a per-arch basis. As Richard mentioned, what's the reproducer to see the errors ? it must be more than devshell. If you can follow up with the steps to reproduce, I can take on the refactoring and broader dependency cleanup question, since I can test the wider matrix at the same time. Bruce > > Cheers, > > Richard > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181119): https://lists.openembedded.org/g/openembedded-core/message/181119 Mute This Topic: https://lists.openembedded.org/mt/98753313/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] apt: Use a valid download location for 2.4.5 release tarball
On Wed, May 10, 2023 at 9:10 AM Richard Purdie wrote: > > On Sat, 2023-04-29 at 17:20 +0200, Alexander Kanavin wrote: > > Does the upstream version check still work? > > I'm very nervous about moving away from the release location like this > even if it is no longer there, I think I'd prefer to leave this and let > our mirror fallback handle it until we upgrade. > ok > Cheers, > > Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181118): https://lists.openembedded.org/g/openembedded-core/message/181118 Mute This Topic: https://lists.openembedded.org/mt/98578451/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][kirkstone 04/15] linux-yocto: Exclude 121 CVEs already fixed upstream
On Wed, May 10, 2023 at 5:32 AM Yoann Congal wrote: > > Hi Steve! > > On 5/10/23 00:32, Steve Sakoman wrote: > > From: Yoann Congal > > > > Exclude CVEs that are fixed in both current linux-yocto version > > v5.10.175 and v5.15.108. > > > > To get the commit fixing a CVE, I used the Debian kernel-sec repo [1]. > > > > [1]: > > https://salsa.debian.org/kernel-team/kernel-sec/-/commit/86d5040aee9275f9555458fcaf9cb43710dff398 > > > > Signed-off-by: Yoann Congal > > Signed-off-by: Steve Sakoman > > --- > > meta/recipes-kernel/linux/cve-exclusion.inc | 875 > > meta/recipes-kernel/linux/linux-yocto.inc | 3 + > > 2 files changed, 878 insertions(+) > > create mode 100644 meta/recipes-kernel/linux/cve-exclusion.inc > > > > diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc > > b/meta/recipes-kernel/linux/cve-exclusion.inc > > new file mode 100644 > > index 00..7fd362881a > > --- /dev/null > > +++ b/meta/recipes-kernel/linux/cve-exclusion.inc > > @@ -0,0 +1,875 @@ > > +# Kernel CVE exclusion file > > + > > .../... > > + > > +# https://nvd.nist.gov/vuln/detail/CVE-2022-2503 > > +# Patched in kernel since v5.19 4caae58406f8ceb741603eee460d79bacca9b1b5 > > +# Backported in version v5.4.197 fd2f7e9984850a0162bfb6948b98ffac9fb5fa58 > > +# Backported in version v5.10.120 8df42bcd364cc3b41105215d841792aea787b133 > > +# Backported in version v5.15.45 69712b170237ec5979f168149cd31e851a465853 > > +CVE_CHECK_IGNORE += "CVE-2022-2503" > > + > > +# https://nvd.nist.gov/vuln/detail/CVE-2022-26365 > > +# Patched in kernel since v5.19 2f446ffe9d737e9a844b97887919c4fda18246e7 > > +# Backported in version v5.4.204 42112e8f94617d83943f8f3b8de2b66041905506 > > +# Backported in version v5.10.129 cfea428030be836d79a7690968232bb7fa4410f1 > > +# Backported in version v5.15.53 7ed65a4ad8fa9f40bc3979b32c54243d6a684ec9 > > +CVE_CHECK_IGNORE += "CVE-2022-26365" > > + > > +# https://nvd.nist.gov/vuln/detail/CVE-2022-2663 > > +# Patched in kernel since v6.0 e8d5dfd1d8747b56077d02664a8838c71ced948e > > +# Backported in version v5.4.215 d0a24bc8e2aa703030d80affa3e5237fe3ad4dd2 > > +# Backported in version v5.10.146 9a5d7e0acb41bb2aac552f8eeb4b404177f3f66d > > +# Backported in version v5.15.71 dc33ffbc361e2579a8f31b8724ef85d4117440e4 > > +# Backported in version v5.19.12 510ea9eae5ee45f4e443023556532bda99387351 > > +CVE_CHECK_IGNORE += "CVE-2022-2663" > > I just noticed that the list in not sorted :( > > I'll send a V2 sorted (This will make the next iterations cleaner) I'm just about to finalize the patchset for the upcoming 4.0.10 release, so I'll need to get the v2 today if you want it in the release! Thanks for doing this! Steve -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181117): https://lists.openembedded.org/g/openembedded-core/message/181117 Mute This Topic: https://lists.openembedded.org/mt/98795092/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-yocto: fix missing pahole and elfutils when CONFIG_DEBUG_INFO_BTF enabled in devshell
On Mon, 2023-05-08 at 09:33 +0800, Xiangyu Chen wrote: > From: Xiangyu Chen > > after enable the kernel CONFIG_DEBUG_INFO_BTF in devshell, the make would > report some > errors due to pahole and elfuitls is missing, since this is a debug option, > so conditionally > add an option named "btf" in KERNEL_DEBUG_OPTIONS, if someone need enable > CONFIG_DEBUG_INFO_BTF > option in devshell, they can add KERNEL_DEBUG_OPTIONS += "btf" in local.conf > to solve the pahole > and elfutils dependency. Is this a defined workflow somewhere? Is KERNEL_DEBUG_OPTIONS with this option documented somewhere? I also think the mention of devshell in the commit message is misleading, this issue happens regardless of how you enable the option. There are also other ways of enabling this than local.conf, you'd likely not want people doing that at the end of development. I'm curious on Bruce's opinion but to me this at the very least needs a commit message rewrite and I'd question whether the docs elsewhere would allow someone to discover this workflow anyway. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181116): https://lists.openembedded.org/g/openembedded-core/message/181116 Mute This Topic: https://lists.openembedded.org/mt/98753313/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] apt: Use a valid download location for 2.4.5 release tarball
On Sat, 2023-04-29 at 17:20 +0200, Alexander Kanavin wrote: > Does the upstream version check still work? I'm very nervous about moving away from the release location like this even if it is no longer there, I think I'd prefer to leave this and let our mirror fallback handle it until we upgrade. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181115): https://lists.openembedded.org/g/openembedded-core/message/181115 Mute This Topic: https://lists.openembedded.org/mt/98578451/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] qemu: Further updates to the ppc patch after upstream discussion
On Wed, 2023-05-10 at 08:04 -0700, Khem Raj wrote: > On Wed, May 10, 2023 at 4:26 AM Richard Purdie > wrote: > > > > After someone tested real hardware, the patch needs tweaks to match the 3.0 > > ISA > > behaviour. It won't change much from our perspective but may as well keep > > the > > patch in sync. > > > > Signed-off-by: Richard Purdie > > --- > > meta/recipes-devtools/qemu/qemu/ppc.patch | 89 +++ > > 1 file changed, 44 insertions(+), 45 deletions(-) > > > > diff --git a/meta/recipes-devtools/qemu/qemu/ppc.patch > > b/meta/recipes-devtools/qemu/qemu/ppc.patch > > index 1fe6a3b4139..22d26e23d9b 100644 > > --- a/meta/recipes-devtools/qemu/qemu/ppc.patch > > +++ b/meta/recipes-devtools/qemu/qemu/ppc.patch > > @@ -1,11 +1,12 @@ > > -From d92b63b7d15d4fd202c5802dfe444a96f5d8109c Mon Sep 17 00:00:00 2001 > > +From 31f02021ac17442c514593f7b9ed750ea87c21b1 Mon Sep 17 00:00:00 2001 > > From: Richard Purdie > > Date: Sat, 6 May 2023 07:42:35 +0100 > > Cc: Víctor Colombo > > Cc: Matheus Ferst > > Cc: Daniel Henrique Barboza > > Cc: Richard Henderson > > -Subject: [PATCH v2] target/ppc: Fix fallback to MFSS for MFFS* > > instructions on > > +Cc: Philippe Mathieu-Daudé > > +Subject: [PATCH v3] target/ppc: Fix fallback to MFSS for MFFS* > > instructions on > > pre 3.0 ISAs > > > > The following commits changed the code such that the fallback to MFSS for > > MFFSCRN, > > @@ -22,25 +23,23 @@ instructions which is used in glibc libm functions for > > example. > > The fallback for MFFSCDRN and MFFSCDRNI added in a later patch was also > > missing. > > > > This patch restores the fallback to MFSS for these instructions on pre > > 3.0s ISAs > > -as the hardware decoder would, fixing the segfaulting libm code. It and > > also ensures > > -the MFSS instruction is used for currently reserved bits to handle other > > potential > > -ISA additions more correctly. > > - > > -Upstream-Status: Submitted > > [https://lore.kernel.org/qemu-devel/20230506065240.3177798-1-richard.pur...@linuxfoundation.org/] > > I think you dropped this line accidentally. Ah, yes. Patch merge issues, fixed in master-next. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181114): https://lists.openembedded.org/g/openembedded-core/message/181114 Mute This Topic: https://lists.openembedded.org/mt/98803453/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][kirkstone 04/15] linux-yocto: Exclude 121 CVEs already fixed upstream
Hi Steve! On 5/10/23 00:32, Steve Sakoman wrote: > From: Yoann Congal > > Exclude CVEs that are fixed in both current linux-yocto version > v5.10.175 and v5.15.108. > > To get the commit fixing a CVE, I used the Debian kernel-sec repo [1]. > > [1]: > https://salsa.debian.org/kernel-team/kernel-sec/-/commit/86d5040aee9275f9555458fcaf9cb43710dff398 > > Signed-off-by: Yoann Congal > Signed-off-by: Steve Sakoman > --- > meta/recipes-kernel/linux/cve-exclusion.inc | 875 > meta/recipes-kernel/linux/linux-yocto.inc | 3 + > 2 files changed, 878 insertions(+) > create mode 100644 meta/recipes-kernel/linux/cve-exclusion.inc > > diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc > b/meta/recipes-kernel/linux/cve-exclusion.inc > new file mode 100644 > index 00..7fd362881a > --- /dev/null > +++ b/meta/recipes-kernel/linux/cve-exclusion.inc > @@ -0,0 +1,875 @@ > +# Kernel CVE exclusion file > + .../... > + > +# https://nvd.nist.gov/vuln/detail/CVE-2022-2503 > +# Patched in kernel since v5.19 4caae58406f8ceb741603eee460d79bacca9b1b5 > +# Backported in version v5.4.197 fd2f7e9984850a0162bfb6948b98ffac9fb5fa58 > +# Backported in version v5.10.120 8df42bcd364cc3b41105215d841792aea787b133 > +# Backported in version v5.15.45 69712b170237ec5979f168149cd31e851a465853 > +CVE_CHECK_IGNORE += "CVE-2022-2503" > + > +# https://nvd.nist.gov/vuln/detail/CVE-2022-26365 > +# Patched in kernel since v5.19 2f446ffe9d737e9a844b97887919c4fda18246e7 > +# Backported in version v5.4.204 42112e8f94617d83943f8f3b8de2b66041905506 > +# Backported in version v5.10.129 cfea428030be836d79a7690968232bb7fa4410f1 > +# Backported in version v5.15.53 7ed65a4ad8fa9f40bc3979b32c54243d6a684ec9 > +CVE_CHECK_IGNORE += "CVE-2022-26365" > + > +# https://nvd.nist.gov/vuln/detail/CVE-2022-2663 > +# Patched in kernel since v6.0 e8d5dfd1d8747b56077d02664a8838c71ced948e > +# Backported in version v5.4.215 d0a24bc8e2aa703030d80affa3e5237fe3ad4dd2 > +# Backported in version v5.10.146 9a5d7e0acb41bb2aac552f8eeb4b404177f3f66d > +# Backported in version v5.15.71 dc33ffbc361e2579a8f31b8724ef85d4117440e4 > +# Backported in version v5.19.12 510ea9eae5ee45f4e443023556532bda99387351 > +CVE_CHECK_IGNORE += "CVE-2022-2663" I just noticed that the list in not sorted :( I'll send a V2 sorted (This will make the next iterations cleaner) -- Yoann Congal Smile ECS - Tech Expert -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181113): https://lists.openembedded.org/g/openembedded-core/message/181113 Mute This Topic: https://lists.openembedded.org/mt/98795092/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] qemu: Further updates to the ppc patch after upstream discussion
On Wed, May 10, 2023 at 4:26 AM Richard Purdie
wrote:
>
> After someone tested real hardware, the patch needs tweaks to match the 3.0
> ISA
> behaviour. It won't change much from our perspective but may as well keep the
> patch in sync.
>
> Signed-off-by: Richard Purdie
> ---
> meta/recipes-devtools/qemu/qemu/ppc.patch | 89 +++
> 1 file changed, 44 insertions(+), 45 deletions(-)
>
> diff --git a/meta/recipes-devtools/qemu/qemu/ppc.patch
> b/meta/recipes-devtools/qemu/qemu/ppc.patch
> index 1fe6a3b4139..22d26e23d9b 100644
> --- a/meta/recipes-devtools/qemu/qemu/ppc.patch
> +++ b/meta/recipes-devtools/qemu/qemu/ppc.patch
> @@ -1,11 +1,12 @@
> -From d92b63b7d15d4fd202c5802dfe444a96f5d8109c Mon Sep 17 00:00:00 2001
> +From 31f02021ac17442c514593f7b9ed750ea87c21b1 Mon Sep 17 00:00:00 2001
> From: Richard Purdie
> Date: Sat, 6 May 2023 07:42:35 +0100
> Cc: Víctor Colombo
> Cc: Matheus Ferst
> Cc: Daniel Henrique Barboza
> Cc: Richard Henderson
> -Subject: [PATCH v2] target/ppc: Fix fallback to MFSS for MFFS* instructions
> on
> +Cc: Philippe Mathieu-Daudé
> +Subject: [PATCH v3] target/ppc: Fix fallback to MFSS for MFFS* instructions
> on
> pre 3.0 ISAs
>
> The following commits changed the code such that the fallback to MFSS for
> MFFSCRN,
> @@ -22,25 +23,23 @@ instructions which is used in glibc libm functions for
> example.
> The fallback for MFFSCDRN and MFFSCDRNI added in a later patch was also
> missing.
>
> This patch restores the fallback to MFSS for these instructions on pre 3.0s
> ISAs
> -as the hardware decoder would, fixing the segfaulting libm code. It and also
> ensures
> -the MFSS instruction is used for currently reserved bits to handle other
> potential
> -ISA additions more correctly.
> -
> -Upstream-Status: Submitted
> [https://lore.kernel.org/qemu-devel/20230506065240.3177798-1-richard.pur...@linuxfoundation.org/]
I think you dropped this line accidentally.
> +as the hardware decoder would, fixing the segfaulting libm code. It doesn't
> have
> +the fallback for 3.0 onwards to match hardware behaviour.
>
> Signed-off-by: Richard Purdie
> ---
> - target/ppc/insn32.decode | 19 ---
> - target/ppc/translate/fp-impl.c.inc | 30 --
> - 2 files changed, 36 insertions(+), 13 deletions(-)
> + target/ppc/insn32.decode | 20 +---
> + target/ppc/translate/fp-impl.c.inc | 22 --
> + 2 files changed, 29 insertions(+), 13 deletions(-)
>
> +v3 - drop fallback to MFFS for 3.0 ISA to match hardware
> v2 - switch to use decodetree pattern groups per feedback
>
> diff --git a/target/ppc/insn32.decode b/target/ppc/insn32.decode
> -index f8f589e9fd..3c4e2c2fc2 100644
> +index f8f589e9fd..4fcf3af8d0 100644
> --- a/target/ppc/insn32.decode
> +++ b/target/ppc/insn32.decode
> -@@ -390,13 +390,18 @@ SETNBCR 01 . . - 00 -
> @X_bi
> +@@ -390,13 +390,19 @@ SETNBCR 01 . . - 00 -
> @X_bi
>
> ### Move To/From FPSCR
>
> @@ -51,9 +50,11 @@ index f8f589e9fd..3c4e2c2fc2 100644
> -MFFSCRNI11 . 10111 ---.. 1001000111 - @X_imm2
> -MFFSCDRNI 11 . 10101 --... 1001000111 - @X_imm3
> -MFFSL 11 . 11000 - 1001000111 - @X_t
> -+{
> ++{
> + # Before Power ISA v3.0, MFFS bits 11~15 were reserved and should be
> ignored
> ++ MFFS_ISA207 11 . - - 1001000111 . @X_t_rc
> + [
> ++MFFS11 . 0 - 1001000111 . @X_t_rc
> +MFFSCE 11 . 1 - 1001000111 - @X_t
> +MFFSCRN 11 . 10110 . 1001000111 - @X_tb
> +MFFSCDRN11 . 10100 . 1001000111 - @X_tb
> @@ -61,84 +62,82 @@ index f8f589e9fd..3c4e2c2fc2 100644
> +MFFSCDRNI 11 . 10101 --... 1001000111 - @X_imm3
> +MFFSL 11 . 11000 - 1001000111 - @X_t
> + ]
> -+ MFFS11 . - - 1001000111 . @X_t_rc
> +}
>
> ### Decimal Floating-Point Arithmetic Instructions
>
> diff --git a/target/ppc/translate/fp-impl.c.inc
> b/target/ppc/translate/fp-impl.c.inc
> -index 57d8437851..10dfd91aa4 100644
> +index 57d8437851..874774eade 100644
> --- a/target/ppc/translate/fp-impl.c.inc
> +++ b/target/ppc/translate/fp-impl.c.inc
> -@@ -584,7 +584,10 @@ static bool trans_MFFSCE(DisasContext *ctx, arg_X_t *a)
> - {
> - TCGv_i64 fpscr;
> +@@ -568,6 +568,22 @@ static void store_fpscr_masked(TCGv_i64 fpscr, uint64_t
> clear_mask,
> + gen_helper_store_fpscr(cpu_env, fpscr_masked, st_mask);
> + }
>
> --REQUIRE_INSNS_FLAGS2(ctx, ISA300);
> ++static bool trans_MFFS_ISA207(DisasContext *ctx, arg_X_t_rc *a)
> ++{
> +if (!(ctx->insns_flags2 & PPC2_ISA300)) {
> -+return false;
> ++/*
> ++ * Before Power ISA v3.0, MFFS bits 11~15 were reserved, any
> instruction
> ++ * with OPCD=63 and
[OE-core] [PATCH] populate_sdk_base.bbclass: respect MLPREFIX for ptest-pkgs's ptest-runner
* since "populate_sdk_base: ensure ptest-pkgs pulls in ptest-runner" change:
https://git.openembedded.org/openembedded-core/commit/?id=ecff0642be5781f7f6cca617158b04ac9a0e85f0
in multilib build when building lib32-foo-image it can pick wrong
ptest-runner package if it was built in the same TMPDIR before the
image, do_rootfs then fails to find it, if the package manager config
doesn't have 64-bit feed enabled:
opkg_prepare_url_for_install: Couldn't find anything to satisfy 'ptest-runner'
Signed-off-by: Martin Jansa
---
meta/classes-recipe/populate_sdk_base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/populate_sdk_base.bbclass
b/meta/classes-recipe/populate_sdk_base.bbclass
index 1c619ef3cf..b23ea26d40 100644
--- a/meta/classes-recipe/populate_sdk_base.bbclass
+++ b/meta/classes-recipe/populate_sdk_base.bbclass
@@ -15,7 +15,7 @@ COMPLEMENTARY_GLOB[staticdev-pkgs] = '*-staticdev'
COMPLEMENTARY_GLOB[doc-pkgs] = '*-doc'
COMPLEMENTARY_GLOB[dbg-pkgs] = '*-dbg'
COMPLEMENTARY_GLOB[src-pkgs] = '*-src'
-COMPLEMENTARY_GLOB[ptest-pkgs] = '*-ptest ptest-runner'
+COMPLEMENTARY_GLOB[ptest-pkgs] = '*-ptest ${MLPREFIX}ptest-runner'
COMPLEMENTARY_GLOB[bash-completion-pkgs] = '*-bash-completion'
def complementary_globs(featurevar, d):
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18):
https://lists.openembedded.org/g/openembedded-core/message/18
Mute This Topic: https://lists.openembedded.org/mt/98806880/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 3/3] qemurunner: add boot logs to do_testimage task logs in real time
Complex boot sequences take a lot of time to reach serial console login.
In our case boot involves multiple bootloaders like u-boot and grub,
then hypervisors like xen, then initramfs images which do things like
validating secure boot and encrypting the main rootfs. All these happen
before main rootfs serial console login prompt is reached and thus many
things can go wrong, including race conditions, hangs and deadlocks, and
thus logging the details is important for development.
This change adds the qemu serial console logs to do_testimage task logs while
they are being read out. The logs are not added to bitbake output. This
enables debugging and tracing the do_testimage via task log file while the boot
and tests are running.
Signed-off-by: Mikko Rapeli
---
meta/lib/oeqa/utils/qemurunner.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/lib/oeqa/utils/qemurunner.py
b/meta/lib/oeqa/utils/qemurunner.py
index c06268f5bc..7f520d47c3 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -480,6 +480,7 @@ class QemuRunner:
self.logger.error('Invalid file type: %s\n%s' % (file))
read = b''
+self.logger.debug2('Partial boot log:\n%s' %
(read.decode('utf-8', errors='ignore')))
data = data + read
if data:
bootlog += data
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181110):
https://lists.openembedded.org/g/openembedded-core/message/181110
Mute This Topic: https://lists.openembedded.org/mt/98805041/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/3] qemurunner: avoid leaking server_socket
close() the server_socket before qemusock replaces it. Signed-off-by: Mikko Rapeli --- meta/lib/oeqa/utils/qemurunner.py | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/lib/oeqa/utils/qemurunner.py b/meta/lib/oeqa/utils/qemurunner.py index 3b7398b872..c06268f5bc 100644 --- a/meta/lib/oeqa/utils/qemurunner.py +++ b/meta/lib/oeqa/utils/qemurunner.py @@ -491,6 +491,7 @@ class QemuRunner: decodedlog = self.decode_qemulog(bootlog) if self.boot_patterns['search_reached_prompt'] in decodedlog: +self.server_socket.close() self.server_socket = qemusock stopread = True reachedlogin = True -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181109): https://lists.openembedded.org/g/openembedded-core/message/181109 Mute This Topic: https://lists.openembedded.org/mt/98805040/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/3] qemurunner: support serial console login via qemu stdout
runqemu script works with qemu machines which provide login
and serial console to the qemu process stdout. Add the same support
to qemurunner so that testing with testimage.bbclass is possible.
Default qemu machines provide serial console boot logs and login via
socket to qemu process but I don't see a reason why qemu process stdout
should not be supported too since they work with runqemu as well.
Signed-off-by: Mikko Rapeli
---
meta/lib/oeqa/utils/qemurunner.py | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/meta/lib/oeqa/utils/qemurunner.py
b/meta/lib/oeqa/utils/qemurunner.py
index 6734cee48d..3b7398b872 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -451,7 +451,7 @@ class QemuRunner:
self.logger.debug("Waiting at most %d seconds for login banner (%s)" %
(self.boottime, time.strftime("%D %H:%M:%S")))
endtime = time.time() + self.boottime
-socklist = [self.server_socket]
+filelist = [self.server_socket, self.runqemu.stdout]
reachedlogin = False
stopread = False
qemusock = None
@@ -459,24 +459,32 @@ class QemuRunner:
data = b''
while time.time() < endtime and not stopread:
try:
-sread, swrite, serror = select.select(socklist, [], [], 5)
+sread, swrite, serror = select.select(filelist, [], [], 5)
except InterruptedError:
continue
-for sock in sread:
-if sock is self.server_socket:
+for file in sread:
+if file is self.server_socket:
qemusock, addr = self.server_socket.accept()
-qemusock.setblocking(0)
-socklist.append(qemusock)
-socklist.remove(self.server_socket)
+qemusock.setblocking(False)
+filelist.append(qemusock)
+filelist.remove(self.server_socket)
self.logger.debug("Connection from %s:%s" % addr)
else:
# try to avoid reading only a single character at a time
time.sleep(0.1)
-data = data + sock.recv(1024)
+if hasattr(file, 'read'):
+read = file.read(1024)
+elif hasattr(file, 'recv'):
+read = file.recv(1024)
+else:
+self.logger.error('Invalid file type: %s\n%s' % (file))
+read = b''
+
+data = data + read
if data:
bootlog += data
if self.serial_ports < 2:
-# this socket has mixed console/kernel data, log
it to logfile
+# this file has mixed console/kernel data, log it
to logfile
self.log(data)
data = b''
@@ -493,8 +501,8 @@ class QemuRunner:
# no need to check if reachedlogin unless we support
multiple connections
self.logger.debug("QEMU socket disconnected before
login banner reached. (%s)" %
time.strftime("%D %H:%M:%S"))
-socklist.remove(sock)
-sock.close()
+filelist.remove(file)
+file.close()
stopread = True
if not reachedlogin:
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181108):
https://lists.openembedded.org/g/openembedded-core/message/181108
Mute This Topic: https://lists.openembedded.org/mt/98805039/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] qemu: Further updates to the ppc patch after upstream discussion
After someone tested real hardware, the patch needs tweaks to match the 3.0 ISA
behaviour. It won't change much from our perspective but may as well keep the
patch in sync.
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/qemu/qemu/ppc.patch | 89 +++
1 file changed, 44 insertions(+), 45 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu/ppc.patch
b/meta/recipes-devtools/qemu/qemu/ppc.patch
index 1fe6a3b4139..22d26e23d9b 100644
--- a/meta/recipes-devtools/qemu/qemu/ppc.patch
+++ b/meta/recipes-devtools/qemu/qemu/ppc.patch
@@ -1,11 +1,12 @@
-From d92b63b7d15d4fd202c5802dfe444a96f5d8109c Mon Sep 17 00:00:00 2001
+From 31f02021ac17442c514593f7b9ed750ea87c21b1 Mon Sep 17 00:00:00 2001
From: Richard Purdie
Date: Sat, 6 May 2023 07:42:35 +0100
Cc: Víctor Colombo
Cc: Matheus Ferst
Cc: Daniel Henrique Barboza
Cc: Richard Henderson
-Subject: [PATCH v2] target/ppc: Fix fallback to MFSS for MFFS* instructions on
+Cc: Philippe Mathieu-Daudé
+Subject: [PATCH v3] target/ppc: Fix fallback to MFSS for MFFS* instructions on
pre 3.0 ISAs
The following commits changed the code such that the fallback to MFSS for
MFFSCRN,
@@ -22,25 +23,23 @@ instructions which is used in glibc libm functions for
example.
The fallback for MFFSCDRN and MFFSCDRNI added in a later patch was also
missing.
This patch restores the fallback to MFSS for these instructions on pre 3.0s
ISAs
-as the hardware decoder would, fixing the segfaulting libm code. It and also
ensures
-the MFSS instruction is used for currently reserved bits to handle other
potential
-ISA additions more correctly.
-
-Upstream-Status: Submitted
[https://lore.kernel.org/qemu-devel/20230506065240.3177798-1-richard.pur...@linuxfoundation.org/]
+as the hardware decoder would, fixing the segfaulting libm code. It doesn't
have
+the fallback for 3.0 onwards to match hardware behaviour.
Signed-off-by: Richard Purdie
---
- target/ppc/insn32.decode | 19 ---
- target/ppc/translate/fp-impl.c.inc | 30 --
- 2 files changed, 36 insertions(+), 13 deletions(-)
+ target/ppc/insn32.decode | 20 +---
+ target/ppc/translate/fp-impl.c.inc | 22 --
+ 2 files changed, 29 insertions(+), 13 deletions(-)
+v3 - drop fallback to MFFS for 3.0 ISA to match hardware
v2 - switch to use decodetree pattern groups per feedback
diff --git a/target/ppc/insn32.decode b/target/ppc/insn32.decode
-index f8f589e9fd..3c4e2c2fc2 100644
+index f8f589e9fd..4fcf3af8d0 100644
--- a/target/ppc/insn32.decode
+++ b/target/ppc/insn32.decode
-@@ -390,13 +390,18 @@ SETNBCR 01 . . - 00 -
@X_bi
+@@ -390,13 +390,19 @@ SETNBCR 01 . . - 00 -
@X_bi
### Move To/From FPSCR
@@ -51,9 +50,11 @@ index f8f589e9fd..3c4e2c2fc2 100644
-MFFSCRNI11 . 10111 ---.. 1001000111 - @X_imm2
-MFFSCDRNI 11 . 10101 --... 1001000111 - @X_imm3
-MFFSL 11 . 11000 - 1001000111 - @X_t
-+{
++{
+ # Before Power ISA v3.0, MFFS bits 11~15 were reserved and should be ignored
++ MFFS_ISA207 11 . - - 1001000111 . @X_t_rc
+ [
++MFFS11 . 0 - 1001000111 . @X_t_rc
+MFFSCE 11 . 1 - 1001000111 - @X_t
+MFFSCRN 11 . 10110 . 1001000111 - @X_tb
+MFFSCDRN11 . 10100 . 1001000111 - @X_tb
@@ -61,84 +62,82 @@ index f8f589e9fd..3c4e2c2fc2 100644
+MFFSCDRNI 11 . 10101 --... 1001000111 - @X_imm3
+MFFSL 11 . 11000 - 1001000111 - @X_t
+ ]
-+ MFFS11 . - - 1001000111 . @X_t_rc
+}
### Decimal Floating-Point Arithmetic Instructions
diff --git a/target/ppc/translate/fp-impl.c.inc
b/target/ppc/translate/fp-impl.c.inc
-index 57d8437851..10dfd91aa4 100644
+index 57d8437851..874774eade 100644
--- a/target/ppc/translate/fp-impl.c.inc
+++ b/target/ppc/translate/fp-impl.c.inc
-@@ -584,7 +584,10 @@ static bool trans_MFFSCE(DisasContext *ctx, arg_X_t *a)
- {
- TCGv_i64 fpscr;
+@@ -568,6 +568,22 @@ static void store_fpscr_masked(TCGv_i64 fpscr, uint64_t
clear_mask,
+ gen_helper_store_fpscr(cpu_env, fpscr_masked, st_mask);
+ }
--REQUIRE_INSNS_FLAGS2(ctx, ISA300);
++static bool trans_MFFS_ISA207(DisasContext *ctx, arg_X_t_rc *a)
++{
+if (!(ctx->insns_flags2 & PPC2_ISA300)) {
-+return false;
++/*
++ * Before Power ISA v3.0, MFFS bits 11~15 were reserved, any
instruction
++ * with OPCD=63 and XO=583 should be decoded as MFFS.
++ */
++return trans_MFFS(ctx, a);
+}
++/*
++ * For Power ISA v3.0+, return false and let the pattern group
++ * select the correct instruction.
++ */
++return false;
++}
+
+ static bool trans_MFFS(DisasContext *ctx, arg_X_t_rc *a)
+ {
+
[OE-core] [PATCH 2/2] oe-setup-build: add a tool for discovering config templates and setting up builds
This is the last (I believe) piece of the puzzle in setting up builds from
nothing
without having to write custom scripts or use external tools.
After layers have been fetched and placed into their respective locations by
oe-setup-layers, one would surely want to proceed to the actual build, and
here's how:
1. Without arguments or with 'list-config-templates', the tool reads available
layers
from .oe-layers.json file (written out by oe-setup-layers) and prints what
templates it has found, as seen below. If the following is not enough
information,
adding '-v' will also print conf-notes.txt for each of the templates:
$ oe-setup-build
Available build configuration templates (re-run with -v to see their
descriptions):
/srv/work/alex/poky/scripts/oe-setup-build setup-build-env -c
/srv/work/alex/poky/meta-poky/conf/templates/default
will create a build configuration in /srv/work/alex/build-meta-poky-default
/srv/work/alex/poky/scripts/oe-setup-build setup-build-env -c
/srv/work/alex/meta-alex/conf/templates/configuration-gizmo
will create a build configuration in
/srv/work/alex/build-meta-alex-configuration-gizmo
/srv/work/alex/poky/scripts/oe-setup-build setup-build-env -c
/srv/work/alex/meta-alex/conf/templates/configuration-gadget
will create a build configuration in
/srv/work/alex/build-meta-alex-configuration-gadget
2. Then the user picks one command of the above and runs it. This will land
them in a shell ready to run bitbake:
$ oe-setup-build setup-build-env -c
/srv/work/alex/meta-alex/conf/templates/configuration-gizmo
Running:
TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/configuration-gizmo .
/srv/work/alex/poky/oe-init-build-env
/srv/work/alex/build-meta-alex-configuration-gizmo && /bin/bash
(...standard Yocto banner omitted...)
This configuration template will set up a build for the purposes of supporting
gizmo.
Please refer to meta-alex/README for additional details and available bitbake
targets.
3. The full set of command line options is:
$ oe-setup-build -h
usage: oe-setup-build [-h] {list-config-templates,setup-build-env} ...
A script that discovers available build configuration templates and sets up a
build environment based on one of them
positional arguments:
{list-config-templates,setup-build-env}
list-config-templates
List available configuration templates
setup-build-env Set up a build environment and open a shell session
with it, ready to run builds.
optional arguments:
-h, --helpshow this help message and exit
$ oe-setup-build list-config-templates -h
usage: oe-setup-build list-config-templates [-h] [--layerlist LAYERLIST] [-v]
optional arguments:
-h, --help show this help message and exit
--layerlist LAYERLIST
Where to look for available layers (as written out by
setup-layers script) (default is
/srv/storage/alex/yocto/build-64-alt/.oe-layers.json).
-v Print a description for each available build configuration
template.
$ oe-setup-build setup-build-env -h
usage: oe-setup-build setup-build-env [-h] -c template_path [-b build_path]
[--no-shell]
optional arguments:
-h, --helpshow this help message and exit
-c template_path Use a build configuration template in template_path to set
up a build environment (run this script with 'list-config-templates' to see
what is available)
-b build_path Set up a build directory in build_path (run this script
with 'list-config-templates' to see where it would be by default)
--no-shellCreate a build directory but do not start a shell session
with the build environment from it.
4. There's an an added hint in oe-setup-layers about how to proceed (as it is
really not user-friendly
to fetch the layer repos successfully and then exit without a word), and a
symlink to the script
from the top level layer checkout directory.
5. The selftest to check layer setup has been adjusted to run a basic check for
template
discovery and build setup. The revision of poky to be cloned has been bumped to
4.1,
as that's the first version with a default template in a standard location.
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/selftest/cases/bblayers.py | 23 ++-
scripts/oe-setup-build | 77
scripts/oe-setup-layers | 10 +++
3 files changed, 108 insertions(+), 2 deletions(-)
create mode 100755 scripts/oe-setup-build
diff --git a/meta/lib/oeqa/selftest/cases/bblayers.py
b/meta/lib/oeqa/selftest/cases/bblayers.py
index 65426a67829..73fefb5d195 100644
--- a/meta/lib/oeqa/selftest/cases/bblayers.py
+++ b/meta/lib/oeqa/selftest/cases/bblayers.py
@@ -151,12 +151,12 @@ class BitbakeLayers(OESelftestTestCase):
self.validate_layersjson(jsonfile)
# The revision-under-test may not necessarily be available on the
remote server,
-# so replace it with a revision that has a yocto-4.0 tag.
+# so
[OE-core] [PATCH 1/2] scripts/oe-setup-layers: write a list of layer paths into the checkout's top dir
This is beneficial for setting up builds, as this list can be used
to determine reliably where the actual layers are, and discover
available configurations from them.
Also adjust the selftest to check the presence of that file rather
than any specific layer in a hardcoded location.
Sample output (paths are written relative to the file for relocatability
and ease of reading):
{
"layers": [
"meta-openembedded/meta-filesystems",
"meta-openembedded/meta-gnome",
"meta-openembedded/meta-initramfs",
"meta-openembedded/meta-multimedia",
"meta-openembedded/meta-networking",
"meta-openembedded/meta-oe",
"meta-openembedded/meta-perl",
"meta-openembedded/meta-python",
"meta-openembedded/meta-webserver",
"meta-openembedded/meta-xfce",
"poky/bitbake/lib/layerindexlib/tests/testdata/layer1",
"poky/bitbake/lib/layerindexlib/tests/testdata/layer2",
"poky/bitbake/lib/layerindexlib/tests/testdata/layer3",
"poky/bitbake/lib/layerindexlib/tests/testdata/layer4",
"poky/meta-poky",
"poky/meta-selftest",
"poky/meta-skeleton",
"poky/meta-yocto-bsp",
"poky/meta"
],
"version": "1.0"
}
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/selftest/cases/bblayers.py | 6 ++
scripts/oe-setup-layers | 15 +++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/bblayers.py
b/meta/lib/oeqa/selftest/cases/bblayers.py
index b0489483869..65426a67829 100644
--- a/meta/lib/oeqa/selftest/cases/bblayers.py
+++ b/meta/lib/oeqa/selftest/cases/bblayers.py
@@ -162,7 +162,5 @@ class BitbakeLayers(OESelftestTestCase):
testcheckoutdir = os.path.join(self.builddir, 'test-layer-checkout')
result = runCmd('{}/setup-layers --destdir
{}'.format(self.testlayer_path, testcheckoutdir))
-# May not necessarily be named 'poky' or 'openembedded-core'
-oecoredir = os.listdir(testcheckoutdir)[0]
-testcheckoutfile = os.path.join(testcheckoutdir, oecoredir,
"oe-init-build-env")
-self.assertTrue(os.path.exists(testcheckoutfile), "File {} not found
in test layer checkout".format(testcheckoutfile))
+layers_json = os.path.join(testcheckoutdir, ".oe-layers.json")
+self.assertTrue(os.path.exists(layers_json), "File {} not found in
test layer checkout".format(layers_json))
diff --git a/scripts/oe-setup-layers b/scripts/oe-setup-layers
index c8012fa6705..cbf94ddb08b 100755
--- a/scripts/oe-setup-layers
+++ b/scripts/oe-setup-layers
@@ -49,11 +49,24 @@ def _is_repo_at_remote_uri(repodir, remote, uri):
def _contains_submodules(repodir):
return os.path.exists(os.path.join(repodir,".gitmodules"))
+def _write_layer_list(dest, repodirs):
+layers = []
+for r in repodirs:
+for root, dirs, files in os.walk(r):
+if os.path.basename(root) == 'conf' and 'layer.conf' in files:
+layers.append(os.path.relpath(os.path.dirname(root), dest))
+layers_f = os.path.join(dest, ".oe-layers.json")
+print("Writing list of layers into {}".format(layers_f))
+with open(layers_f, 'w') as f:
+json.dump({"version":"1.0","layers":layers}, f, sort_keys=True,
indent=4)
+
def _do_checkout(args, json):
repos = json['sources']
+repodirs = []
for r_name in repos:
r_data = repos[r_name]
repodir = os.path.abspath(os.path.join(args['destdir'],
r_data['path']))
+repodirs.append(repodir)
if 'contains_this_file' in r_data.keys():
force_arg = 'force_bootstraplayer_checkout'
@@ -96,6 +109,8 @@ def _do_checkout(args, json):
if _contains_submodules(repodir):
print("Repo {} contains submodules, use 'git submodule update'
to ensure they are up to date".format(repodir))
+_write_layer_list(args['destdir'], repodirs)
+
parser = argparse.ArgumentParser(description="A self contained python script
that fetches all the needed layers and sets them to correct revisions using
data in a json format from a separate file. The json data can be created from
an active build directory with 'bitbake-layers create-layers-setup destdir' and
there's a sample file and a schema in meta/files/")
parser.add_argument('--force-bootstraplayer-checkout', action='store_true',
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181105):
https://lists.openembedded.org/g/openembedded-core/message/181105
Mute This Topic: https://lists.openembedded.org/mt/98802402/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 11/27] meson: update 1.0.1 ->1.1.0
On Wed, 10 May 2023 at 02:55, Khem Raj wrote: > > Upstream-Status: Submitted > > [https://github.com/mesonbuild/meson/pull/10218] > > This is merged upstreamed with a slightly different fix see > https://github.com/mesonbuild/meson/commit/24ea1d3f1968bff52ccaaf33fcdd59e810459aa9 > > If we have this fix already in 1.1.0 which seems to be the case. then > the full patch here can be dropped. Thanks, I've queued a followup patch that does this. So that v2 or a respin of the whole patchset can be avoided. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181104): https://lists.openembedded.org/g/openembedded-core/message/181104 Mute This Topic: https://lists.openembedded.org/mt/98788924/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] systemd-systemctl: fix instance template WantedBy symlink construction
Fix issue of the below instance template systemd service dependency
[Install]
WantedBy=svc-wants@%i.service
creating the symlink (instance "a" example)
/etc/systemd/system/svc-wants@%i.service.wants/svc-wanted-by@a.service
which should be
/etc/systemd/system/svc-wants@a.service.wants/svc-wanted-by@a.service
as implemented by this change.
The functionality appears regressed just after "thud" baseline when the
logic was refactored from shell script into python (commit
925e30cb104ece7bfa48b78144e758a46dc9ec3f)
(From OE-Core rev: 308397f0bb3d6f3d4e9ec2c6a10823184049c9b5)
Signed-off-by: Martin Siegumfeldt
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
---
.../systemd/systemd-systemctl/systemctl | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl
b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index cddae75a06..b45a2dc2f7 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -195,12 +195,19 @@ class SystemdUnit():
raise SystemdUnitNotFoundError(self.root, unit)
-def _process_deps(self, config, service, location, prop, dirstem):
+def _process_deps(self, config, service, location, prop, dirstem,
instance):
systemdir = self.root / SYSCONFDIR / "systemd" / "system"
target = ROOT / location.relative_to(self.root)
try:
for dependent in config.get('Install', prop):
+# determine whether or not dependent is a template with an
actual
+# instance (i.e. a '@%i')
+dependent_is_template =
re.match(r"[^@]+@(?P[^\.]*)\.", dependent)
+if dependent_is_template:
+# if so, replace with the actual instance to achieve
+# svc-wants@a.service.wants/svc-wanted-by@a.service
+dependent =
re.sub(dependent_is_template.group('instance'), instance, dependent, 1)
wants = systemdir / "{}.{}".format(dependent, dirstem) /
service
add_link(wants, target)
@@ -240,8 +247,8 @@ class SystemdUnit():
else:
service = self.unit
-self._process_deps(config, service, path, 'WantedBy', 'wants')
-self._process_deps(config, service, path, 'RequiredBy', 'requires')
+self._process_deps(config, service, path, 'WantedBy', 'wants',
instance)
+self._process_deps(config, service, path, 'RequiredBy', 'requires',
instance)
try:
for also in config.get('Install', 'Also'):
--
2.25.1
This email was scanned by Bitdefender
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181103):
https://lists.openembedded.org/g/openembedded-core/message/181103
Mute This Topic: https://lists.openembedded.org/mt/98801305/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] cve-check: add option to add additional patched CVEs
Hi,
On Wed, May 10, 2023 at 09:37:13AM +1200, Douglas Royds wrote:
> On 9/05/23 9:32 pm, Mikko Rapeli wrote:
> > On Tue, May 09, 2023 at 09:02:59AM +, Ross Burton wrote:
> > > On 8 May 2023, at 09:57, Adrian Freihofer via
> > > lists.openembedded.org
> > > wrote:
> > > Is there any defined language that we can simply adopt?
> > Since a lot of people talk about SPDX solving these issues would be nice
> > to know how that is going to work. I can't parse
> > https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k17-linking-to-a-code-fix-for-a-security-issue
> > and figure out how to mark a CVE issue which has been ignored after
> > analysis.
>
>
> Perhaps this?
>
> https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k16-linking-to-a-vulnerability-disclosure-document
>
>To communicate that a package is not vulnerable to a specific
>vulnerability it is recommended to reference a web page indicating
>why given vulnerabilities are not applicable.
>
>|"externalRefs" : [ { "referenceCategory" : "SECURITY",
>"referenceLocator" :
>"https://example.com/product-x/security-info.html;, "referenceType"
>: "advisory" } ] |
Thanks but IMO this does not encode the information that analysis has been
done and the issue can safely be ignored, but I'm not an SPDX expert,
and frankly I should not need to be.
In recipes CVE_CHECK_IGNORE variable the ignore list is clear, obvious, and
there
is usually a comment or a commit message explaining why. And
the reports generated by cve-check.bbclass for recipes and images show that the
CVE issue can be ignored and maintainer should check the CVEs with
"Unpatched" status instead.
Would be nice for these tools to firstly support yocto upstream stable
and LTS maintainers work in detecting and fixing CVE issues, and secondly
support maintaining CVE security issue/patching status of older releases
with complex layer configurations, when anyone has to use an old release due to
BSP etc dependencies (fact of life which IMO should not be completely ignored).
I have backported the cve-check.bbclass and other CVE management related patches
to really old yocto releases and these frankly saved the product from being
the usual embedded SW security nightmare to actually have only a few
known minor known CVE patching issues when shipping to customers. Older
versions of SPDX standard and open source license checks helped to
identify embedded open source SW but did not really help in the yocto
operating system/rootfs side CVE security patching.
Cheers,
-Mikko
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181102):
https://lists.openembedded.org/g/openembedded-core/message/181102
Mute This Topic: https://lists.openembedded.org/mt/98703185/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
