The duration values have pointless amounts of precision. Removing some of the
least significant digits reduces result size and makes the results easier to read.
(From OE-Core rev: 4ec9bb7e1a02de8223fb7485fc47cb43ad19093c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a789a2e6d97bb8efd663226a17db8d1ca6c1e40f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We've improved the data stored for reproduicible builds. Teach resulttool how
to apply those cleanups when reprocessing data so we can reduce results file
sizes and make the data easier to process.
(From OE-Core rev: cf1b4eb85ca3cb62c9746c6dc8f6dc9c4802c142)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b799c57ae6d61c1b1c7035c8a2c4ba6ee08d1a81)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Improve the rawlogs handling to include ltp logs as well as the ptest ones to
reduce the size of the results git repos.
(From OE-Core rev: 0309366b04dd2d0819c4af409269995c08c7abb3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a0a1954d559609c2c1ca16936d0d68eb3c4c6b45)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Storing the log files inside the testresults git repo isn't scaling and isn't
really appropriate use of a git repository. Allow these to be optionally stored
in a separate filesystem location so the git repo can remain managable.
(From OE-Core rev: 1084e88534f7a1341249ab453b82a35f0cddba87)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1afc0f3d7e93fa8496be241e9622d3b9a6904bd5)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When using store mode, --all was broken as not all files were being preserved.
Fix this by limiting the scope of the git rm command.
(From OE-Core rev: 25173a06c4c1b4c6f1f8cdfe49f0b600cd3efd65)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9604561d2022b6c76b1cb4186d40800d1affdd2b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Tweak the gitarchive exclude handling not to error if excluded files
don't match.
Also return the tagname created so that other code can then use it.
(From OE-Core rev: 2df9c2248ac4996ad1fd1fe9f492eb2d71b758cb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1adba3430faffdf6217b6a00533a3b48a9388abc)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Using 4 space indentation in resulted in hundreds of megabytes of extra file size
in general use. Reduce this to make filesizes more managable and reduce the processing
cost. Some level of indentation and spacing does make the files more readable and allows
use of git diff so we need to retain some of it.
(From OE-Core rev: cae6106f152c8c44e2d85179ad7e6831b974ffd5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a274cdcaf852cca9497f0358f44dda99c06aacbe)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We have a challenge on the autobuilder where test results from both OE-Core
and poky are being mixed together during result storage which is confusing the
data. Add a way to filter to specific revisions as the least worst way to fix
the various issues this is causing.
(From OE-Core rev: 5588459188ea21cb7a2064828245d39f1328c6cb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3f276a0dc65341668788853be2cf27ab6aa12b13)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
There are several problems with these paths. Firstly they contain full
system paths which depend upon where the test was run. These are pretty
pointless and just take up a lot of space making the results files large.
Secondly, they contain the same path twice. The reference and target path
will always be the same thing in two different locations.
Strip off the prefix and remove the duplication. This does change the output
data but that can't really be avoided. It does shrink the results data and makes
it more readable.
(From OE-Core rev: 13d844b15deba49a54676fa6f83ab4526ec74b9a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 81a44de36e864b08687451fd85aeba7c529fd7f7)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The "rawlogs" data consists of a long string of results data which is
already in a structured data format. I can't see this is adding much
value in duplciating the data but it does create a huge string with a
lot of long problematic pathnames and inflates the results data size.
I suggest we drop this data as obsolete and not necessary.
(From OE-Core rev: 8e6210530042b722a4f7fea17e5d10cddcd8dfab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5b2c70fab2ffa409b861d83f048b65d458d03a90)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Without this change, TIC is the native tic in recipe-sysroot-native.
By default, native tic has set its default terminfo path to native path:
${datadir}/terminfo; $HOME/.terminfo
When sstate cache is used, the cached native tic's terminfo path could
be a path not exist on current host, then native tic will try to install
terminfo to HOME dir, cause host contamination.
Disable the terminfo installation by setting TIC to :
(From OE-Core rev: 33069a688930ccb98a66f02feac40382ecf6cf85)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit fe35ead2c3135a18c346e7baa31d34b15c3e2d95)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The code was changing the timestamps of the files in the do_package output,
particularly the files added for debug sources. This was to do two things:
a) make do_package sstate more reproducible
b) ensure better hash equivalence matching
Unfortuately the debug source files are hardlinks into the source tree for
efficiency so touching these, touches a lot of files in ${B} and ${S}. This
causes unpredictable effects if compile is run again for example, or could
cause compiling in the install task.
The hash equivalence matching is of key importance but we can mimic that
using clamping of the file timestamps in the depsig output used to generate
the hashes.
This patch drops the global timestamp clamping, instead allowing the files
to retain their creation timestamps into sstate. This makes do_package sstate
slightly less reproducibile. We could clamp the sstate timestamps but that
would lead to two different sets of timestamps depending on whether the
data came from sstate or not. I'd prefer to have consistent code behaviour,
rather than differing behavhour depending on whether data came from sstate
or not.
If we wanted to have reproducibiliy and fix the "corruption" of S/B and have
consistent codepaths, the only other option would be two copies of the
sources, which could end up huge and seems the least desireable option.
This patch therefore drops the timestamp clamping in the sstate files
and tweaks the depsig data generation to clamp the timestamps for do_package
instead since this seems the best compromise.
I validated that rpm/deb/ipk files still generate correctly as before.
(From OE-Core rev: 0c93bb692b39af51f0ca109dfd1f949abe7eea9c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 475759fdab7200488b2a568b2ba1aa31a456d113)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
diffoscope before 256 allows directory traversal via an embedded
filename in a GPG file. Contents of any file, such as ../.ssh/id_rsa,
may be disclosed to an attacker. This occurs because the value of the
gpg --use-embedded-filenames option is trusted.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2024-25711
Upstream patches:
458f7f04bc
(From OE-Core rev: da4977e9414361a30eb322d1456a664515b35693)
Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A heap-based buffer overflow was found in the SDHCI device
emulation of QEMU. The bug is triggered when both
`s->data_count` and the size of `s->fifo_buffer` are set to
0x200, leading to an out-of-bound access. A malicious guest
could use this flaw to crash the QEMU process on the host,
resulting in a denial of service condition.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2024-3447
Upstream patch:
2429cb7a9f
(From OE-Core rev: 01d7ac9244364b7f89cd2f99fff11c2417bcad03)
Signed-off-by: Yogita Urade <yogita.urade@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A double free vulnerability was found in QEMU virtio devices
(virtio-gpu, virtio-serial-bus, virtio-crypto), where the
mem_reentrancy_guard flag insufficiently protects against DMA
reentrancy issues. This issue could allow a malicious privileged
guest to crash the QEMU process on the host, resulting in a d
enial of service or allow arbitrary code execution within the
context of the QEMU process on the host.
CVE-2024-3446-0004, CVE-2024-3446-0005, CVE-2024-3446-0006
are CVE fix and CVE-2024-3446-0001, CVE-2024-3446-0002,
CVE-2024-3446-0003 are dependent commits to fix the CVE.
References:
https://nvd.nist.gov/vuln/detail/CVE-2024-3446
Upstream patches:
9c86c97f12f63192b054ec0504b989ba28e0ff4db4295bff25f4729ec39a
(From OE-Core rev: db7e3a56656db0bc61ec2e35ccc149e9b90a389b)
Signed-off-by: Yogita Urade <yogita.urade@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Same was done in newer Yocto releases.
See commit 72f2d4cf44b795f766ecdee0b8362c7e162c5efc
(From OE-Core rev: 390421edf8b6eb6031de657cdcaf0c7d50b605be)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Same was done in newer Yocto releases.
See commit: f99b25355133fe8f65a55737270e67ea10b79d52
See commit: 40cd768368167f81de5bb55e9ff0584035f4c1b4
(From OE-Core rev: 823f7ab85cff010c777616ed5db0e0c41f6cc4e6)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The CVE has disputed flag in NVD DB.
(From OE-Core rev: bd01091c33c1de6ae7e1605301e3f73350ee7e7e)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This is vulnerability of libksba and we use fixed libksba version
(currently 1.6.4).
(From OE-Core rev: 12007a6d19db220e6540948de9818332192ecde1)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Same was done in newer Yocto releases.
See commit See commit 0f2cd2bbaddba3b8c80d71db274bbcd941d0e60e
(From OE-Core rev: 50d8a653104abb9b5cd8a708a7bd97446e894bcf)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2 is susceptible to a vulnerability in the CreateHob() function,
allowing a user to trigger a integer overflow to buffer overflow
via a local network. Successful exploitation of this vulnerability
may result in a compromise of confidentiality, integrity, and/or
availability.
References:
https://nvd.nist.gov/vuln/detail/CVE-2022-36765
Upstream-patches:
59f024c76eaeaee8944f9a75b030cf
(From OE-Core rev: 260fc2182e6a83d7c93b2e8efd95255cd9168a79)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2's Network Package is susceptible to a predictable TCP Initial
Sequence Number. This vulnerability can be exploited by an attacker
to gain unauthorized access and potentially lead to a loss of
Confidentiality.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45236
Upstream-patch:
1904a64bcc
(From OE-Core rev: a9cd3321558e95f61ed4c5eca0dcf5a3f4704925)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2's Network Package is susceptible to a predictable TCP Initial Sequence
Number. This vulnerability can be exploited by an attacker to gain
unauthorized access and potentially lead to a loss of Confidentiality.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45237
Upstream-patches:
cf07238e5f4c4ceb2ceb
(From OE-Core rev: 6f8bdaad9d22e65108f859a695277ce1b20ef7c6)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2's Network Package is susceptible to an out-of-bounds read
vulnerability when processing the IA_NA or IA_TA option in a DHCPv6
Advertise message. This vulnerability can be exploited by an attacker
to gain unauthorized access and potentially lead to a loss of
Confidentiality.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45229
Upstream-patches:
1dbb10cc5207362769ab1c440a5ece1d0b95f645
(From OE-Core rev: 23a87c571ae4cdd285a96af0d458906aaf8c4571)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2's Network Package is susceptible to a buffer overflow vulnerability
when handling Server ID option from a DHCPv6 proxy Advertise message.
This vulnerability can be exploited by an attacker to gain unauthorized
access and potentially lead to a loss of Confidentiality, Integrity
and/or Availability.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45235
Upstream-patches:
fac297724eff2986358f
(From OE-Core rev: dd26902517c30f34cc661cf9f79fc589d0358412)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2's Network Package is susceptible to a buffer overflow vulnerability
when processing DNS Servers option from a DHCPv6 Advertise message. This
vulnerability can be exploited by an attacker to gain unauthorized access
and potentially lead to a loss of Confidentiality, Integrity and/or
Availability.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45234
Upstream-patches:
1b53515d53458c582685
(From OE-Core rev: d9d9e66349ac0a2e58f54b104fb1b30f1633c1ab)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
CVE-2023-45232:
EDK2's Network Package is susceptible to an infinite loop vulnerability
when parsing unknown options in the Destination Options header of IPv6.
This vulnerability can be exploited by an attacker to gain unauthorized
access and potentially lead to a loss of Availability.
CVE-2023-45233:
EDK2's Network Package is susceptible to an infinite lop vulnerability
when parsing a PadN option in the Destination Options header of IPv6.
This vulnerability can be exploited by an attacker to gain unauthorized
access and potentially lead to a loss of Availability.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45232https://nvd.nist.gov/vuln/detail/CVE-2023-45233
Upstream-patches:
4df0229ef9c9c87f08dd
(From OE-Core rev: c84eb03f07687d2e0df1e2033599fa2cf79c6b4d)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2's Network Package is susceptible to an out-of-bounds read
vulnerability when processing Neighbor Discovery Redirect message. This
vulnerability can be exploited by an attacker to gain unauthorized access
and potentially lead to a loss of Confidentiality.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45231
Upstream-patches:
bbfee34f416f77463d72
(From OE-Core rev: bdff14d8e6f4dad7b873442c813672ef0ec6fb01)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2's Network Package is susceptible to a buffer overflow vulnerability
via a long server ID option in DHCPv6 client. This vulnerability can be
exploited by an attacker to gain unauthorized access and potentially lead
to a loss of Confidentiality, Integrity and/or Availability.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45230
Upstream-patches:
f31453e8d65f3658197b
(From OE-Core rev: 50b50174f057a9a5fb9773e67b4f183ae942ff10)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2 is susceptible to a vulnerability in the Tcg2MeasurePeImage()
function, allowing a user to trigger a heap buffer overflow via a local
network. Successful exploitation of this vulnerability may result in a
compromise of confidentiality, integrity, and/or availability.
References:
https://nvd.nist.gov/vuln/detail/CVE-2022-36764
Upstream-patches:
c7b27944210d341c01ee8f6d343ae6
(From OE-Core rev: aba14824159e549fd77cb90e3a9a327c527b366f)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
EDK2 is susceptible to a vulnerability in the Tcg2MeasureGptTable()
function, allowing a user to trigger a heap buffer overflow via a local
network. Successful exploitation of this vulnerability may result in a
compromise of confidentiality, integrity, and/or availability.
References:
https://nvd.nist.gov/vuln/detail/CVE-2022-36763
Upstream-patches:
22444654324776a1b39e1ddcb9fc6b
(From OE-Core rev: 26db24533f9f32c32189e4621102b628a9ea6729)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
First, libcheck has the ability to increase all test timeouts by an arbitrary
multiplier. Because we run our tests on loaded build machines,
increase all timeouts by 10x to reduce the chance of load causing failures.
Second, use GST_CHECKS_IGNORE to list test cases that should be skipped.
Drop skip-aggregator-test.patch as this is now redundant, and also skip
gstnetclientclock.c:test_functioning as this is very sensitive to load.
[ YOCTO #14808 ]
(From OE-Core rev: 13b13b81b91f618c13cf972067c47bd810de852f)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 669d0df81f651f7c033c8cb7872cac5bfe670a4f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
python 3.13 removed the pipes module. Thus build fails for host machines that run python 3.13
This commit adds a backport patch to use subprocess module instead
(From OE-Core rev: 1a02cf1997216cb943d8965fe74f971a8cb2f70f)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
TL;DR version:
with this, and the previous compression level changes
I am seeing drastic speedups in package_write_rpm completion times:
webkitgtk goes from 78 seconds to 37 seconds
glibc-locale goes from 399 seconds to 58 seconds (!)
The long version:
rpm uses multithreading for two purposes:
- spawning compressors (which are nowadays themselves
multi-threaded, so the feature is not as useful as it once
was)
- parallel file classification
While the former behaves well on massively parallel CPUs
(it was written and verified here :), the latter was then added
by upstream and only benchmarked on their very old, slow laptop,
apparently:
41f0e214f2
On anything more capable it starts showing pathologic behavior,
presumably from spawning massive amount of very short-lived threads,
and then having to synchronize them. For example classifying glibc-locale
takes
5m20s with 256 threads (default on my machine!)
1m49s with 64 threads
59s with 16 threads
48s with 8 threads
Even a more typical recipe like webkitgtk is affected:
47s with 256 threads
32s with 64 threads
27s with 16 or 8 threads
I have found that the optimal amount is actually four: this also
means that only four compressors are running at a time, but
as they're themselves using threads, and typical recipes are dominated
by just two or three large packages, this does not affect overall
completion time.
(From OE-Core rev: 896192604d84a6f77095f23cd13232e249b7aac5)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
zstd uses 3 by default, while 19 is the highest and slowest.
It's not clear why 19 was picked to begin with, possibly
I copy-pasted it from rpm's examples without thinking:
https://git.yoctoproject.org/poky/commit/?h=master-next&id=4a4d5f78a6962dda5f63e9891825c80a8a87bf66
This brings significant speedups in rpm's compression step:
for example compressing webkitgtk takes 11s instead of 36s.
The rpm size increases from 175648k to 234860k. I think it's
a worthy default tradeoff.
(From OE-Core rev: c377ced95ef7fd060316db1325529826d0985790)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A vulnerability was found in FFmpeg up to 7.0.1. It has been classified as critical.
This affects the function pnm_decode_frame in the library /libavcodec/pnmdec.c.
The manipulation leads to heap-based buffer overflow. It is possible to initiate
the attack remotely. The exploit has been disclosed to the public and may be used.
Upgrading to version 7.0.2 is able to address this issue. It is recommended to upgrade
the affected component. The associated identifier of this vulnerability is VDB-273651.
(From OE-Core rev: 7335a81112673616240f010d4930b4982b10c355)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local
attacker to execute arbitrary code via the libavfilter/f_reverse.c:269:26
in areverse_request_frame.
(From OE-Core rev: ec7301d63376197ed3e89282545109f046d63888)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Buffer Overflow vulnerability in Ffmpeg v.n6.1-3-g466799d4f5 allows a local attacker
to execute arbitrary code via theav_samples_set_silence function in the
libavutil/samplefmt.c:260:9 component.
(From OE-Core rev: 88a1fc5a6445e72e6cc78c39a6feff3aa96beea6)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker
to execute arbitrary code via a floating point exception (FPE) error at
libavfilter/vf_minterpolate.c:1078:60 in interpolate.
(From OE-Core rev: b6c00d2c64036b2b851cdbb3b6efd60bc839fa5b)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Backport patch with tweaks for the current version to fix
CVE-2024-0684.
(From OE-Core rev: 3d9a4cacd5f051134f190afcab2c71b3286cf9e5)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Builder is a common word and there are many other builder components
which makes us to ignore CVEs for all of them.
There is already 1 ignored and currently 3 new ones.
Instead, set product to yocto to filter them.
(From OE-Core rev: 941a645b3b18418e020ada9ebdd19f425f03dfc8)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
