There was a weird error in OE-Core where "devtool modify virtual/kernel"
was showing basehash mismatch errors. This was due to SRCPV sometimes being:
AUTOINC+b867b78b50_47b80ef7bd and sometimes AUTOINC+b867b78b50_255a750d28.
The latter hash comes from KBRANCH and meant sometimes the correct branch
was seen, sometimes it was not. The issue was complicated by the execution
using a remote datastore over tinfoil.
The problem turns out to be a fetcher caching error. If the datastore
changes, the cached url data may not be valid.
We therefore ensure we match cached url data against the datastore that
generated it, which appears to fix this issue.
(Bitbake rev: 4ce50bbd34eefeabfeca89a6a66c71598d3c58f6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bitbake-worker child on the SIGTERM signal handling send the SIGTERM to all
processes in it's process group. In cases when the bitbake-worker child got
SIGTERM after registering own SIGTERM handler and before the os.setsid() call
it can send SIGTERM to unwanted processes.
In the worst case during SIGTERM processing the bitbake-worker child can be in
the group of the process that started BitBake itself. As a result it can kill
processes that not related to BitBake at all.
(Bitbake rev: b7483a7738daf69902ef590a8144a557576bbce0)
Signed-off-by: Ivan Efimov <i.efimov@inango-systems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Sudo before 1.8.28, an attacker with access to a Runas ALL sudoer
account can bypass certain policy blacklists and session PAM modules,
and can cause incorrect logging, by invoking sudo with a crafted user
ID. For example, this allows bypass of !root configuration, and USER=
logging, for a "sudo -u \#$((0xffffffff))" command.
(From OE-Core rev: 650dd9486d6e5410665d5376be30732c7625396d)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 4e11cd561f2bdaa6807cf02ee7c9870881826308)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
(cherry picked from commit b1e0149c41e3c344a0496e64ab3b0c9dd4685ea4)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Libgcrypt 1.8.4, the C implementation of AES is vulnerable to a
flush-and-reload side-channel attack because physical addresses are
available to other processes. (The C implementation is used on platforms
where an assembly-language implementation is unavailable.)
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2019-12904
Patches from:
1374254c29daedbbb554a4c561aab1
(From OE-Core rev: a981d9b753a13e100af1f654fb3384f0bcda0b65)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 37e390ff05b6a4509019db358ed496731d80cc51)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
(cherry picked from commit 4c207cb1ad46c0d2005ab3eae70d78c937e084b5)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set OPENSSL_ENGINES to the path where engines are actually installed.
(From OE-Core rev: 041fb2743a94d7fb065b073efbe5fe5cf46cde53)
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 59565fec0b3f3e24eb01c03b671913599cd3134d)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
(cherry picked from commit 578f41124565a7cda738c7fe3d25702ee41b08ed)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes:
ERROR: python-2.7.16-r0 do_package_qa: QA Issue:
/usr/lib/python2.7/lib-dynload/_tkinter.so contained in package
python-tkinter requires libtk8.6.so, but no providers found in
RDEPENDS_python-tkinter? [file-rdeps]
(From OE-Core rev: f83ecbabb911c46de77708ede759a0b768928ea2)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit f78248a2380bbbbf271b5bb02c762f5bc7a3a92e)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The other active kernel versions have this feature available. To
consistently enable the same video output for qemu, we can cherry
pick the feature to 4.19.
(From OE-Core rev: a777e0f34e106455f963bd58fd8728a16c588c4d)
(From OE-Core rev: 2b7444e41e47e462a8aae0e3e1e95b04cdbaff22)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding the following fragments from meta-security to make them
centrally available and easier to maintain:
283939d5c9e kernel-cache: add yama security fragments
0b86f3fa241 kernel-cache: add ima fragments
731b466654d kernel-cache: add smack
813afe8ff47 kernel-cache: add apparmor fragments
(From OE-Core rev: 3063d64984e993d3e7dc2f4c80fb74005f5d6d7e)
(From OE-Core rev: f5ae4010dd29484627a169b8ab02b1012d1dd1d4)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>From the kernel patch:
[
It was observed that the kernel embeds the path in the x86 boot
artifacts.
From https://bugzilla.yoctoproject.org/show_bug.cgi?id=13458:
[
If you turn on the buildpaths QA test, or try a reproducible build, you
discover that the kernel image contains build paths.
$ strings bzImage-5.0.19-yocto-standard |grep tmp/
out of pgt_buf in
/data/poky-tmp/reproducible/tmp/work-shared/qemux86-64/kernel-source/arch/x86/boot/compressed/kaslr_64.c!?
But what's this in the top-level Makefile:
$ git grep prefix-map
Makefile:KBUILD_CFLAGS += $(call
cc-option,-fmacro-prefix-map=$(srctree)/=)
So the __FILE__ shouldn't be using the full path. However
arch/x86/boot/compressed/Makefile has this:
KBUILD_CFLAGS := -m$(BITS) -O2
So that clears KBUILD_FLAGS, removing the -fmacro-prefix-map option.
]
Other architectures do not clear the flags, but instead prune before
adding boot or specific options. There's no obvious reason why x86 isn't
doing the same thing (pruning vs clearing) and no build or boot issues
have been observed.
So we make x86 can do the same thing, and we no longer have embedded paths.
]
This issue has been reported upstream, and a patch submission is
pending, but for now, we'll soak the proposed patch in linux-yocto to
see if any issues are found
[YOCTO: #13458]
(From OE-Core rev: 78b0ff5960814af935a8089ec49c51d76f148149)
(From OE-Core rev: a45a6e12d6ce3a531ad924d3e548de8a95055866)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While we don't normally do a dual h/w and virt BSP (since they
tend to have conflicting requirements over time). A minimal overhead
option to do this was submitted to linux-yocto. Since it has no
impact on the h/w reference, has SDK testing value and can serve
as a template on how to do this for other arm boards, it is worth
making the configuration available.
The original commit log follows:
[
If the kernel supports Qemu's virt machine, runqemu works almost for free.
The device tree for machine virt is included in Qemu, which simplifies
everything quite a bit.
This change adds ARCH_VIRT=y and some drivers to the beaglebone kernel
configuration which allows to:
export MACHINE="beaglebone-yocto"
bitbake core-image-minimale
runqemu
This also works out of an eSDK. Whithout this feature usually two
different SDKs need to be compiled and maintained. One SDK is used for development
in Qemu, another one is used to develop for the real target hardware.
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
]
(From OE-Core rev: cc1fca6d464775daa15032f11c02d16b99759407)
(From OE-Core rev: 61eed761a51fcb5ac293b76b4dc6edbd6dbbb32f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updating the scsi-debug fragment to include the core scsi config
options. This allows standalone use of the fragment, since all
supporting options will be enabled simply by including the top
level config in a BSP.
This also removes a configuration warning on qemuarm, since we
will no longer have missing / unavailable options during the
config audit.
(From OE-Core rev: c65826e96a77928938fef69fc0cbc65ec7431cb2)
(From OE-Core rev: 6c2c6bed0bd5f0a303b9aacfab7db6daec3ee878)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If one has provided external key/certificate for modules signing, Kbuild
will skip creating signing_key.pem and will write only signing_key.x509
certificate. Thus we have to check for .x509 file existence rather than
.pem one.
(From OE-Core rev: 6ab0206b8252755367f2357f49007dd78336fec0)
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2527e731eba43bd36d0ea268aca6b03155376134)
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Entails all the cover pages for the release date. Used
November 2019 for now. Updated poky.ent and the
mega-manual.sed file. Good to go.
(From yocto-docs rev: f7bf30b96ba7feaf33df544162a713204520b389)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12760]
Updated the cmake.bbclass description to tell what directory
to insall custom CMake toolchain files into. Also, updated
the two areas in the "Writing a New Recipe" section that
mention CMake. Placed a couple notes there concerning the
same directory stuff.
(From yocto-docs rev: cacdedf4e1186a96ce00f94e0f42817dfb724ac7)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was in a moving to YP version 1.8 migration section.
(From yocto-docs rev: 76e63455276aff8a03c00e2fd12c728c5aeb6e2c)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variable values that result from parsing multiconfig should be
included in the cooker data hash, otherwise changes to these files won't
be detected, which will allow the parsing cache to be loaded with the
old values for the multiconfigs. This can either manifest as the
variable values simply not updating, or getting basehash changed errors
when building.
This bug was previously undetected because all of the multiconfig base
files were a direct file dependency in all parsed recipes. This was
fixed in 34137a00f60 ("bitbake: bitbake: cooker: Rename __depends in all
multiconfigs"), exposing this bug.
[YOCTO #13541]
(Bitbake rev: 75d6648f232a06b99c54a1e33324a7fc1cd15b38)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes the following error:
TOPDIR/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:254:16: error: static declaration of ‘gettid’ follows non-static declaration
254 | _syscall0(int, gettid)
| ^~~~~~
TOPDIR/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:185:13: note: in definition of macro ‘_syscall0’
185 | static type name (void) \
| ^~~~
In file included from /usr/include/unistd.h:1170,
from TOPDIR/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/include/qemu/osdep.h:90,
from TOPDIR/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:20:
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here
34 | extern __pid_t gettid (void) __THROW;
| ^~~~~~
(From OE-Core rev: fbedc2d73ff472c89ba273a890408f93015e8f17)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently systemd 241 does break for kernels 5.2+ with the error described here:
* https://github.com/systemd/systemd/issues/12784
The issue has been fixed in master and will be fixed in the release 243. The
necessary patches have been backported to systemd/systemd-stable in the branch
v241-stable, but currently in warrior an old version of that branch is pulled
in.
This patch updates the SRCREV to the latest commit from that branch and
therefore pulls in the needed fix to run systemd 241 on 5.2+ kernels.
(From OE-Core rev: 8b9703454cb2a8a0aa6b7942498f191935d547ea)
Signed-off-by: Jan Klare <jan.klare@bisdn.de>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's INITRAMFS_FSTYPES that can be set differently.
(From OE-Core rev: 66c05bb2ca6ecdb621ae1e5bdf28e7aa768d9aba)
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In recent years AMD CPUs have had various problems with RDRAND
giving either non-random data or no result at all, which is
problematic if either build or target machine has a CPU with
this problem.
The fallback is /dev/urandom, and I'd trust the kernel here.
--enable-rdrand was added in an upgrade to a new upstream
version without mentioning any reason.
[YOCTO #13534]
(From OE-Core rev: 07b19cd9ef127ec87f727e154eda62272a828275)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The main issue is to make the x86 checks apply to x86 targets only. We may
end up with better checks on other architectures but this adapts the code to
allow for that and its still controlled by whether QB_CPU_KVM is set.
The code needed minor refactoring so the qemu-system-XXX name is set
earlier so the kvm code can use it.
(From OE-Core rev: acc0f4a6a99fe9367e57a5c2a4f995b6f4db4a9f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows kvm acceleration on arm systems that support it. "host" is the
best option I can find right now to attempt to use the acceleration. It
potentially might not be correct but arm systems are sensitive to the
correct values and I don't want to encode the autobuilders CPU type here.
(From OE-Core rev: 20a61476a45d5116dc7081e802b2aaa0bab7e77f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f13788541f64774a586971ed57699e4397b38b32)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As detailed at [1] the XML feeds provided by NIST are being discontinued on
October 9th 2019. As cve-check-tool uses these feeds, cve-check.bbclass will be
inoperable after this date.
To ensure that cve-check continues working, backport the following commits from
master to move away from the unmaintained cve-check-tool to our own Python code
that fetches the JSON:
546d14135c5 cve-update-db: New recipe to update CVE database
bc144b028f6 cve-check: Remove dependency to cve-check-tool-native
7f62a20b32a cve-check: Manage CVE_PRODUCT with more than one name
3bf63bc6084 cve-check: Consider CVE that affects versions with less than operator
c0eabd30d7b cve-update-db: Use std library instead of urllib3
27eb839ee65 cve-check: be idiomatic
09be21f4d17 cve-update-db: Manage proxy if needed.
975793e3825 cve-update-db: do_populate_cve_db depends on do_fetch
0325dd72714 cve-update-db: Catch request.urlopen errors.
4078da92b49 cve-check: Depends on cve-update-db-native
f7676e9a38d cve-update-db: Use NVD CPE data to populate PRODUCTS table
bc0195be1b1 cve-check: Update unpatched CVE matching
c807c2a6409 cve-update-db-native: Skip recipe when cve-check class is not loaded.
07bb8b25e17 cve-check: remove redundant readline CVE whitelisting
5388ed6d137 cve-check-tool: remove
270ac00cb43 cve-check.bbclass: initialize to_append
e6bf9000987 cve-check: allow comparison of Vendor as well as Product
91770338f76 cve-update-db-native: use SQL placeholders instead of format strings
7069302a4cc cve-check: Replace CVE_CHECK_CVE_WHITELIST by CVE_CHECK_WHITELIST
78de2cb39d7 cve-update-db-native: Remove hash column from database.
4b301030cf9 cve-update-db-native: use os.path.join instead of +
f0d822fad2a cve-update-db: actually inherit native
b309840b6aa cve-update-db-native: use executemany() to optimise CPE insertion
bb4e53af33d cve-update-db-native: improve metadata parsing
94227459792 cve-update-db-native: clean up JSON fetching
95438d52b73 cve-update-db-native: fix https proxy issues
1f9a963b9ff glibc: exclude child recipes from CVE scanning
[1] https://nvd.nist.gov/General/News/XML-Vulnerability-Feed-Retirement
(From OE-Core rev: 8c87e78547c598cada1bce92e7b25d85b994e2eb)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
AArch64 images are not self-decompressing, thus usually much larger.
Boot times can be reduced by compressing them in FIT and uImages.
This commit is a backport of commit a725d188b5 (kernel-uboot: compress
arm64 kernels) and commit 60bc7e180e (kernel-uboot: remove useless
special casing of arm64 Image) from master. Both commit were melted
into one to avoid some useless churn.
(From OE-Core rev: 91c42f92cd978a922fff87cb1d0f358c7d9747ea)
Signed-off-by: Alban Bedel <alban.bedel@aerq.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
