[OE-core] [PATCH] make: disable use of posix_spawn on mips
After make-4.3 migration child_execute_job function started using posix_spawn function, which happens to be broken on mips. It manifests itself as when make executed by root, it switches real user id to wrong value because of some issues with direct setresuid system call done in glibc __spawni_child function through inline assemble and/or gcc compiling it produces wrong code. I.e instead of passing -1 posix_spawn function incorrectly passes 127 as ruid. Subsequently job started by make can fail with permission issue because they run under wrong user. For now workaround is used by explicitly disabling posix_spawn call use by make on mips through configure variable. Signed-off-by: Victor Kamensky --- meta/recipes-devtools/make/make_4.3.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-devtools/make/make_4.3.bb b/meta/recipes-devtools/make/make_4.3.bb index 70caf0ae16..5fa7059169 100644 --- a/meta/recipes-devtools/make/make_4.3.bb +++ b/meta/recipes-devtools/make/make_4.3.bb @@ -12,6 +12,9 @@ SRC_URI += "\ EXTRA_OECONF += "--without-guile" +EXTRA_OECONF_append_mips=" ac_cv_func_posix_spawn=no" +EXTRA_OECONF_append_mips64=" ac_cv_func_posix_spawn=no" + SRC_URI[md5sum] = "d5c40e7bd1e97a7404f5d3be982f479a" SRC_URI[sha256sum] = "de1a441c4edf952521db30bfca80baae86a0ff1acd0a00402999344f04c45e82" -- 2.21.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] linux-yocto: Fix systemtap issue on armv7
On Sun, 10 Mar 2019, Bruce Ashfield wrote: On Sun, Mar 10, 2019 at 11:12 PM Richard Purdie wrote: Testing stap on armv7 machines was failing due to intermixing of thumb/arm instructions. Patch the kernel to always use the v7 march options since we know our gcc versions support it to avoid the failure and allow systemtap to work. I'd rather just merge this into the kernel directly. I can do a quick merge and bump of the SRCREV. If you send the patch against linux-yocto, that makes it easier for me to grab and integrate it, versus having to dig it out of here (since my access is pretty limited at the moment). BTW please note I posted on ARM linux kernel mailing list IMO more appropriate and possibly upstreamable fix for the same issue http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/637809.html It seems quite urgent so Richard's fix might work as well as short term. More inline. Bruce [YOCTO #13153] Signed-off-by: Richard Purdie --- ...0001-arm-Makefile-Fix-systemtap-4.19.patch | 60 +++ .../0001-arm-Makefile-Fix-systemtap.patch | 60 +++ meta/recipes-kernel/linux/linux-yocto_4.19.bb | 3 +- meta/recipes-kernel/linux/linux-yocto_5.0.bb | 3 +- 4 files changed, 124 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-kernel/linux/linux-yocto/0001-arm-Makefile-Fix-systemtap-4.19.patch create mode 100644 meta/recipes-kernel/linux/linux-yocto/0001-arm-Makefile-Fix-systemtap.patch diff --git a/meta/recipes-kernel/linux/linux-yocto/0001-arm-Makefile-Fix-systemtap-4.19.patch b/meta/recipes-kernel/linux/linux-yocto/0001-arm-Makefile-Fix-systemtap-4.19.patch new file mode 100644 index 000..53bd53b276c --- /dev/null +++ b/meta/recipes-kernel/linux/linux-yocto/0001-arm-Makefile-Fix-systemtap-4.19.patch @@ -0,0 +1,60 @@ +From c2995494e311c113177db50ff140cebd94fd4011 Mon Sep 17 00:00:00 2001 +From: Richard Purdie +Date: Sun, 10 Mar 2019 06:43:15 + +Subject: [PATCH] arm/Makefile: Fix systemtap + +Currently systemtap fails to operate correctly on armv7 systems such as beaglebone and +soon, qemuarm. + + +root@qemuarm:/usr/src/kernel# env -uARCH -uKBUILD_EXTMOD -uCROSS_COMPILE -uKBUILD_IMAGE -uKCONFIG_CONFIG -uINSTALL_PATH -uLD_LIBRARY_PATH PATH=/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin make -C /lib/modules/4.19.19-yocto-standard/build M=/tmp/staptcNU6M modules CONFIG_DEBUG_INFO= CONFIG_STACK_VALIDATION= ARCH=arm stap_4321_src.i --no-print-directory -j2 V=1 +test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ +echo >&2; \ +echo >&2 " ERROR: Kernel configuration is invalid."; \ +echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ +echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ +echo >&2 ; \ +/bin/false) +mkdir -p /tmp/staptcNU6M/.tmp_versions ; rm -f /tmp/staptcNU6M/.tmp_versions/* +make -f ./scripts/Makefile.build obj=/tmp/staptcNU6M +(cat /dev/null; echo kernel//tmp/staptcNU6M/stap_4321.ko;) > /tmp/staptcNU6M/modules.order + gcc -Wp,-MD,/tmp/staptcNU6M/.stap_4321_src.o.d -nostdinc -isystem /usr/lib/gcc/arm-poky-linux-gnueabi/8.3.0/include -I./arch/arm/include -I./arch/arm/include/generated -I./include -I./arch/arm/include/uapi -I./arch/arm/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -DCC_HAVE_ASM_GOTO -fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -fno-ipa-sra -mabi=aapcs-linux -mfpu=vfp -funwind-tables -marm -Wa,-mno-warn-deprecated -D__LINUX_ARM_ARCH__=7 -march=armv5t -Wa,-march=armv7-a -msoft-float -Uarm -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Os -Wno-maybe-uninitialized --param=allow-s t ore-data-races=0 -Wframe-larger-than=1024 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -pg -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -Wno-packed-not-aligned -Iinclude2/asm/mach-default -I/lib/modules/4.19.19-yocto-standard/build -include /tmp/staptcNU6M/stapconf_4321.h -D "STP_NO_VELREL_CHECK" -freorder-blocks -fasynchronous-unwind-tables
Re: [OE-core] [PATCH] sysklogd: add alternatives for klogd and syslogd
Hi Mark,
On Mon, 29 Oct 2018, Mark Hatle wrote:
On 10/26/18 2:55 AM, Victor Kamensky wrote:
On Fri, 26 Oct 2018, Markus Lehtonen wrote:
'why would you want to have multiple, alternative
syslog daemons on the system? Wouldn't a better
fix be to move the syslogd and klogd symlinks to the
busybox-syslog package? It doesn't seem to make much
sense to have a syslogd binary on the system without
an init script(?)
The original problem really was related to managing
init scripts with alternatives (and I think that
problem still persists, and, it shouldn't be done).
So, using alternatives for the binaries wouldn't
cause any problems. The question is just why to
do this, instead of "fixing" the (binary) package
content so that existing rconflicts would handle it.
Thank you, Markus. Please see ChenQi reply on the
thread. I has already been fixed by Richard in the
way you suggested.
My problem was because similar fix was not present
in meta-selinux busybox.bbappend ... meta-selinux practically
has a copy of alternative handling for busybox
because of SELinux labeling requirements and it was
negating Richard's change.
As a maintainer for meta-selinux, if meta-selinux is broken.. it's
meta-selinux's fault.. NOT oe-core.
oe-core must work for itself first.
Fix OE-core properly and the other layers will follow.
Please see
http://lists.openembedded.org/pipermail/openembedded-core/2018-October/157078.html
oe-core is fine: ef11c54ba9. In order to follow
meta-selinux needs something like this to avoid
'update-alternatives: Error:' mentioned on the thead:
From dd75b2ca77b3bfcb14030c353e6b2bfc7df8dfec Mon Sep 17 00:00:00 2001
From: Victor Kamensky
Date: Mon, 29 Oct 2018 11:16:09 -0700
Subject: [PATCH] busybox: Put klogd/syslogd alternative links in syslog
package
Port "ef11c54ba9 busybox: Put klogd/syslogd alternative links in
syslog package" from oe-core to meta-selinux copy of
update-alternative handling in busybox.bbappend
Signed-off-by: Victor Kamensky
---
recipes-core/busybox/busybox_selinux.inc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/recipes-core/busybox/busybox_selinux.inc
b/recipes-core/busybox/busybox_selinux.inc
index df7c117..b8cfcd7 100644
--- a/recipes-core/busybox/busybox_selinux.inc
+++ b/recipes-core/busybox/busybox_selinux.inc
@@ -37,7 +37,11 @@ python create_sh_wrapper_reset_alternative_vars () {
# Match coreutils
if alt_name == '[':
alt_name = 'lbracket'
-d.appendVar('ALTERNATIVE_%s' % (pn), ' ' + alt_name)
+if alt_name == 'klogd' or alt_name == 'syslogd':
+d.appendVar('ALTERNATIVE_%s-syslog' % (pn), ' ' + alt_name)
+else:
+d.appendVar('ALTERNATIVE_%s' % (pn), ' ' + alt_name)
+
d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name, alt_link_name)
if os.path.exists(alt_wppath_dest):
d.setVarFlag('ALTERNATIVE_TARGET', alt_name, alt_wppath)
--
2.14.4
I don't know yet what mailing list I should use for meta-selinux. As
time permits I'll try to figure out and post above patch there, if
it is still needed.
Thanks,
Victor
--Mark
So it is sorted out now.
Thanks,
Victor
Cheers,
Markus
On 26/10/2018, 7.55, "Victor Kamensky" wrote:
Otherwise when used in presense of busybox that provides
its own version of klogd and syslogd, image packaging
complains that klogd exists and it is not syymbolic link.
Failure happens only if image packaging script install
sysklogd package first followed by installtion of busybox
package. If during packaging reverse installtion order
happens, busybox first followed by sysklogd, packaging
succeed.
Note this fix along with recently committed
55ba9dc1f8 sysklogd: Re-enable alternatives for syslogd.8 man page
effectively reverts this commit
988aad01b2 sysklogd: don't use update-alternatives
Signed-off-by: Victor Kamensky
---
Hi Guys,
Here is more details. Example of failure that I observe:
update-alternatives: Error: not linking
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
to /usr/lib/busybox/sbin/klogd since
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
exists and is not a link
Also 988aad01b2 says:
> Using update-alternatives for managing init scripts has proved to be
> problematic. And, sysklogd rconflicts with other syslog daemons so there
> is no point in using update-alternatives from this perspective, either.
I am not sure why "managing init scripts has proved to be problematic" and
syslogd and klogd are not really init script per se, aren't they? Also
klogd and syslogd actually come from busybox, not busybox-syslog as listed
in sysklogd RCONFLICTS. Maybe it what has changed since 988aad01b2.
busybox-syslog now contains only init script
[OE-core] [PATCH] meson: map powerpc64 TARGET_ARCH to ppc64 for the cross file
Meson uses 'ppc64' for 64 bit powerpc. Issue came up while building systemd for MACHINE that uses ppc64e5500 tune. Signed-off-by: Victor Kamensky --- BTW very nice diagnostic message through https://wiki.yoctoproject.org/wiki/Meson/UnknownCPU, that led directly to the fix meta/classes/meson.bbclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass index 7e63e12588..3cbdcf18c2 100644 --- a/meta/classes/meson.bbclass +++ b/meta/classes/meson.bbclass @@ -52,6 +52,8 @@ def meson_cpu_family(var, d): arch = d.getVar(var) if arch == 'powerpc': return 'ppc' +elif arch == 'powerpc64': +return 'ppc64' elif arch == 'mipsel': return 'mips' elif re.match(r"i[3-6]86", arch): -- 2.14.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sysklogd: add alternatives for klogd and syslogd
On Fri, 26 Oct 2018, Markus Lehtonen wrote:
'why would you want to have multiple, alternative
syslog daemons on the system? Wouldn't a better
fix be to move the syslogd and klogd symlinks to the
busybox-syslog package? It doesn't seem to make much
sense to have a syslogd binary on the system without
an init script(?)
The original problem really was related to managing
init scripts with alternatives (and I think that
problem still persists, and, it shouldn't be done).
So, using alternatives for the binaries wouldn't
cause any problems. The question is just why to
do this, instead of "fixing" the (binary) package
content so that existing rconflicts would handle it.
Thank you, Markus. Please see ChenQi reply on the
thread. I has already been fixed by Richard in the
way you suggested.
My problem was because similar fix was not present
in meta-selinux busybox.bbappend ... meta-selinux practically
has a copy of alternative handling for busybox
because of SELinux labeling requirements and it was
negating Richard's change.
So it is sorted out now.
Thanks,
Victor
Cheers,
Markus
On 26/10/2018, 7.55, "Victor Kamensky" wrote:
Otherwise when used in presense of busybox that provides
its own version of klogd and syslogd, image packaging
complains that klogd exists and it is not syymbolic link.
Failure happens only if image packaging script install
sysklogd package first followed by installtion of busybox
package. If during packaging reverse installtion order
happens, busybox first followed by sysklogd, packaging
succeed.
Note this fix along with recently committed
55ba9dc1f8 sysklogd: Re-enable alternatives for syslogd.8 man page
effectively reverts this commit
988aad01b2 sysklogd: don't use update-alternatives
Signed-off-by: Victor Kamensky
---
Hi Guys,
Here is more details. Example of failure that I observe:
update-alternatives: Error: not linking
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
to /usr/lib/busybox/sbin/klogd since
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
exists and is not a link
Also 988aad01b2 says:
> Using update-alternatives for managing init scripts has proved to be
> problematic. And, sysklogd rconflicts with other syslog daemons so there
> is no point in using update-alternatives from this perspective, either.
I am not sure why "managing init scripts has proved to be problematic" and
syslogd and klogd are not really init script per se, aren't they? Also
klogd and syslogd actually come from busybox, not busybox-syslog as listed
in sysklogd RCONFLICTS. Maybe it what has changed since 988aad01b2.
busybox-syslog now contains only init script for syslog and its
configuration.
Adding Markus for further comments.
meta/recipes-extended/sysklogd/sysklogd.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc
b/meta/recipes-extended/sysklogd/sysklogd.inc
index f151dd87f7..4393a39180 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -60,9 +60,14 @@ FILES_${PN} +=
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${exec_prefix}
ALTERNATIVE_PRIORITY = "100"
+ALTERNATIVE_${PN} = "syslogd klogd"
+
ALTERNATIVE_${PN}-doc = "syslogd.8"
ALTERNATIVE_LINK_NAME[syslogd.8] = "${mandir}/man8/syslogd.8"
+ALTERNATIVE_LINK_NAME[syslogd] = "${base_sbindir}/syslogd"
+ALTERNATIVE_LINK_NAME[klogd] = "${base_sbindir}/klogd"
+
pkg_prerm_${PN} () {
if test "x$D" = "x"; then
if test "$1" = "upgrade" -o "$1" = "remove"; then
--
2.17.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sysklogd: add alternatives for klogd and syslogd
Hi Chen,
On Fri, 26 Oct 2018, ChenQi wrote:
On 10/26/2018 12:53 PM, Victor Kamensky via Openembedded-core wrote:
Otherwise when used in presense of busybox that provides
its own version of klogd and syslogd, image packaging
complains that klogd exists and it is not syymbolic link.
Failure happens only if image packaging script install
sysklogd package first followed by installtion of busybox
package.
Hi Victor,
I think this problem has been fixed by the following commit.
"""
commit ef11c54ba99af261a70ec31091216cdd1556da24
Author: Richard Purdie
Date: Wed Sep 5 17:39:31 2018 +0100
busybox: Put klogd/syslogd alternative links in syslog package
Currently these are in ${PN} and ${PN}-syslog may get replaced by
other packages but update-alternatives would error in the postinst
if other files were installed first. Avoid the problems by putting
the links in the correct package.
Signed-off-by: Richard Purdie
"""
For the current status, the update-alternatives operations for syslogd and
klogd should be in the busybox-syslog package, which conflicts with sysklogd
package.
Could you please help check this?
Thank you! That helps. I see it now. Apprently busybox.bbappend
from meta-selinux layer:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/tree/recipes-core/busybox/busybox_selinux.inc
is effectively undoing effect of above commit in my workspace.
meta-selinux is doing it because of
http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=521ca9c9cf370840e9f8c808a7955aa5da7c356e
It seems changes similar to above Richard's commit needed to
be applied there as well. After applying that to busybox_selinux.inc
in meta-selinux my problem goes away.
No need for proposed below patch.
Thanks,
Victor
Best Regards,
Chen Qi
If during packaging reverse installtion order
happens, busybox first followed by sysklogd, packaging
succeed.
Note this fix along with recently committed
55ba9dc1f8 sysklogd: Re-enable alternatives for syslogd.8 man page
effectively reverts this commit
988aad01b2 sysklogd: don't use update-alternatives
Signed-off-by: Victor Kamensky
---
Hi Guys,
Here is more details. Example of failure that I observe:
update-alternatives: Error: not linking
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
to /usr/lib/busybox/sbin/klogd since
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
exists and is not a link
Also 988aad01b2 says:
Using update-alternatives for managing init scripts has proved to be
problematic. And, sysklogd rconflicts with other syslog daemons so there
is no point in using update-alternatives from this perspective, either.
I am not sure why "managing init scripts has proved to be problematic" and
syslogd and klogd are not really init script per se, aren't they? Also
klogd and syslogd actually come from busybox, not busybox-syslog as listed
in sysklogd RCONFLICTS. Maybe it what has changed since 988aad01b2.
busybox-syslog now contains only init script for syslog and its
configuration.
Adding Markus for further comments.
meta/recipes-extended/sysklogd/sysklogd.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc
b/meta/recipes-extended/sysklogd/sysklogd.inc
index f151dd87f7..4393a39180 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -60,9 +60,14 @@ FILES_${PN} +=
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${exec_prefix}
ALTERNATIVE_PRIORITY = "100"
+ALTERNATIVE_${PN} = "syslogd klogd"
+
ALTERNATIVE_${PN}-doc = "syslogd.8"
ALTERNATIVE_LINK_NAME[syslogd.8] = "${mandir}/man8/syslogd.8"
+ALTERNATIVE_LINK_NAME[syslogd] = "${base_sbindir}/syslogd"
+ALTERNATIVE_LINK_NAME[klogd] = "${base_sbindir}/klogd"
+
pkg_prerm_${PN} () {
if test "x$D" = "x"; then
if test "$1" = "upgrade" -o "$1" = "remove"; then
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sysklogd: add alternatives for klogd and syslogd
Otherwise when used in presense of busybox that provides
its own version of klogd and syslogd, image packaging
complains that klogd exists and it is not syymbolic link.
Failure happens only if image packaging script install
sysklogd package first followed by installtion of busybox
package. If during packaging reverse installtion order
happens, busybox first followed by sysklogd, packaging
succeed.
Note this fix along with recently committed
55ba9dc1f8 sysklogd: Re-enable alternatives for syslogd.8 man page
effectively reverts this commit
988aad01b2 sysklogd: don't use update-alternatives
Signed-off-by: Victor Kamensky
---
Hi Guys,
Here is more details. Example of failure that I observe:
update-alternatives: Error: not linking
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
to /usr/lib/busybox/sbin/klogd since
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
exists and is not a link
Also 988aad01b2 says:
> Using update-alternatives for managing init scripts has proved to be
> problematic. And, sysklogd rconflicts with other syslog daemons so there
> is no point in using update-alternatives from this perspective, either.
I am not sure why "managing init scripts has proved to be problematic" and
syslogd and klogd are not really init script per se, aren't they? Also
klogd and syslogd actually come from busybox, not busybox-syslog as listed
in sysklogd RCONFLICTS. Maybe it what has changed since 988aad01b2.
busybox-syslog now contains only init script for syslog and its
configuration.
Adding Markus for further comments.
meta/recipes-extended/sysklogd/sysklogd.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc
b/meta/recipes-extended/sysklogd/sysklogd.inc
index f151dd87f7..4393a39180 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -60,9 +60,14 @@ FILES_${PN} +=
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${exec_prefix}
ALTERNATIVE_PRIORITY = "100"
+ALTERNATIVE_${PN} = "syslogd klogd"
+
ALTERNATIVE_${PN}-doc = "syslogd.8"
ALTERNATIVE_LINK_NAME[syslogd.8] = "${mandir}/man8/syslogd.8"
+ALTERNATIVE_LINK_NAME[syslogd] = "${base_sbindir}/syslogd"
+ALTERNATIVE_LINK_NAME[klogd] = "${base_sbindir}/klogd"
+
pkg_prerm_${PN} () {
if test "x$D" = "x"; then
if test "$1" = "upgrade" -o "$1" = "remove"; then
--
2.17.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemtap: 3.3 -> 4.0
Hi Guys, On Wed, 17 Oct 2018, Victor Kamensky wrote: stap-exporter service is a new feature in SystemTap 4.0, I've never used it before. I'll dig in and will try to make sure that it is functional in resulting OE image. I've had a chance to look at stap-exporter and its service more closely. It looks like it is simple HTTP server that allows to run stap scripts on target and relay its information to Prometheus monitoring system. Please check. https://www.mankier.com/8/stap-exporter https://prometheus.io Since it is HTTP server, and its man page says that it is not supposed to run in untrusted environment I am quite hesitant to have it enabled by default. Moreover, it comes with some default example scripts that actually fail to compile in OE core-image-lsb-sdk because it does not include kernel-vmlinux package by default. stap-exporter is not prepared to handle script compilation failure and tries to compile it in the loop, so in core-image-lsb-sdk systemd image where stap-exporter.service would be enabled by default it would trash the system. Considering all that I suggest stap-exporter to be moved in separate systemtap-exporter package, so it can be installed explcitely. I posted patch for it at http://lists.openembedded.org/pipermail/openembedded-core/2018-October/157073.html BTW in FC it is separate systemtap-exporter package. I've tested systemtap-exporter and stap-exporter, if installed along with proper prerequisites (kernel-vmlinux) is functioning OK with given default example as far as my manual http testing with curl shows. I did not test it with prometheus. Thanks, Victor -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemtap: move systemtap-exporter into separate package
stap-exporter runs a set of systemtap scripts and relays
their procfs outputs to remote HTTP clients on demand.
systemtap-exporter is not supposed to run in untrusted
environment. It starts HTTP server on some port. It does
not look safe enough to be included by default along with
the rest of systemtap.
Move systemtap-exporter, its systemd unit, configuration
files and examples scripts into separate package. So if one
needs it and understand its implication, he/she can include
it explicitely.
Signed-off-by: Victor Kamensky
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 904ecdd106..6ee3e1c0f7 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -27,7 +27,16 @@ PACKAGECONFIG[python3-probes] =
"--with-python3-probes,--without-python3-probes,
inherit autotools gettext pkgconfig distutils3-base systemd
-SYSTEMD_SERVICE_${PN} = "stap-exporter.service"
+PACKAGES =+ "${PN}-exporter"
+
+FILES_${PN}-exporter = "${sysconfdir}/stap-exporter/* \
+${sysconfdir}/sysconfig/stap-exporter \
+${systemd_unitdir}/system/stap-exporter.service \
+${sbindir}/stap-exporter"
+
+RDEPENDS_${PN}-exporter = "${PN} python3-core python3-netclient"
+
+SYSTEMD_SERVICE_${PN}-exporter = "stap-exporter.service"
do_configure_prepend () {
# Improve reproducibility for c++ object files
--
2.17.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel-devsrc: add selinux include files needed by scripts/selinux build
If CONFIG_SECURITY_SELINUX=y is enabled in kernel configuration, then
'make scripts' command in /usr/src/kernel fails to build
utilities under scripts/selinux that would be pulled in by this config:
HOSTCC scripts/selinux/genheaders/genheaders
scripts/selinux/genheaders/genheaders.c:19:10: fatal error: classmap.h: No such
file or directory
#include "classmap.h"
To address this issue add security/selinux/include files into
kernel-devsrc.
Signed-off-by: Victor Kamensky
---
To reproduce this issue add to conf/local.conf selinux fragment:
KERNEL_EXTRA_FEATURES_append = " cgl/features/selinux/selinux.scc"
build core-image-lsb-sdk and run 'cd /usr/src/kernel; make scripts'
meta/recipes-kernel/linux/kernel-devsrc.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 5758572221..361ad21e1f 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -210,6 +210,9 @@ do_install() {
cp -a --parents kernel/bounds.c $kerneldir/build
cp -a --parents Kbuild $kerneldir/build
fi
+
+# required to build scripts/selinux/genheaders/genheaders
+cp -a --parents security/selinux/include/* $kerneldir/build/
)
# Make sure the Makefile and version.h have a matching timestamp so that
--
2.17.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemtap: 3.3 -> 4.0
On Wed, 17 Oct 2018, Martin Jansa wrote: systemd.bbclass won't include that .service file in FILES_ without setting SYSTEMD_SERVICE_. I'll send fix for that in few minutes. Martin, Richard, thank you for the help. I've reproduced the issue reported by Martin in systemd enabled image, and verified that his fix solves the issue. The lesson I learnt: o Look for WARNINGs o Test systemd enabled image, along with default sysvinit stap-exporter service is a new feature in SystemTap 4.0, I've never used it before. I'll dig in and will try to make sure that it is functional in resulting OE image. Thanks, Victor On Wed, Oct 17, 2018 at 5:07 PM wrote: On Wed, 2018-10-17 at 16:50 +0200, Martin Jansa wrote: > There seems to be one more issue in current master (for which I > haven't seen a fix in master-next or ML): > > ERROR: systemtap-4.0-r0 do_package: QA Issue: systemtap: > Files/directories were installed but not shipped in any package: > /lib > /lib/systemd > /lib/systemd/system > /lib/systemd/system/stap-exporter.service > Please set FILES such that these items are packaged. Alternatively if > they are unneeded, avoid installing them or delete them within > do_install. > systemtap: 4 installed and not shipped files. [installed-vs-shipped] http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=3b77e7b7852549dcfbc426d4ce258e6e857c0acd was supposed to fix that :( Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemtap: 3.3 -> 4.0
On Tue, 16 Oct 2018, Richard Purdie wrote: On Tue, 2018-10-16 at 10:27 +0100, Burton, Ross wrote: On Mon, 15 Oct 2018 at 19:22, Victor Kamensky wrote: Upgrade systemtap from 3.3 to 4.0: Removed backported patch. WARNING: systemtap-4.0-r0 do_package_qa: QA Issue: systemtap: /systemtap/etc/stap-exporter/EXAMPLE is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/EXAMPLE_NOERROR is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/errno.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/syscalllatency.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/timeout.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/topsys.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] There are also other issues from the addition of systemd unit files in 4.0. I've a patch in -next which tweaks both issues which I'll put in for testing. Richard, thank you very prompt help. In the long term it would be beneficial that those issues be fixed in SystemTap itself, correct? If so, I can look at creating proper patches and pushing them into SystemTap. Also on my todo list is to attempt to push few existing OE systemtap patches into SystemTap upstream source. I believe they look like quite legit issues and I hope they could be upstreamed. Thanks, Victor Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemtap: 3.3 -> 4.0
Hi Randy,
On Mon, 15 Oct 2018, Randy MacLeod wrote:
On 10/15/2018 02:21 PM, Victor Kamensky wrote:
Upgrade systemtap from 3.3 to 4.0: Removed backported patch.
Very short summary of major changes from SystemTap 4.0
announcement by Frank Ch. Eigler :
prometheus exporter network service; ebpf support extensions including
strings and implementation of traditional log(), sprintf() functions;
rebuilt rich tapset coverage for 4.17+ syscalls and for
tracepoint-based syscalls; script language tweaks for supporting
machine-generated scripts
Fixes [YOCTO #12950]
Signed-off-by: Victor Kamensky
---
Hi Guys,
I'll let you to decide whether you want to accept
it for 2.6 at this point or push it for the next release.
On one hand after move to 4.18 kernel SystemTap 3.3
fails to trace any system call on x86_64 - it is major
functionality breakage. Look at:
https://bugzilla.redhat.com/show_bug.cgi?id=1596456
Ouch!
On other hand it is quite late to do major version
updates.
It is but nothing depends on systemtap so I think we
don't have much choice and we should do it unless there
are autobuilder tests that regress.
Personally, I agree. I had similar thoughts, since it
is leaf project risk is quite contained.
A quick read through the YP mega-manual suggests that
we don't have to change any of the text.
Victor,
Could you take a look and confirm that please?
I noticed that the link in section:
20.3.3. Documentation
for:
http://sourceware.org/systemtap/langref/
is dead. There is a pdf:
http://sourceware.org/systemtap/langref.pdf
Perhaps this is temporary due to the recent release.
Yes, I agree. It is better to change link to langref.pdf
as you suggested. But I don't know how to do that. Is there
somewhere git that holds YP mega-manual sources?
I did go through limited set of tests on all
supported QEMU targets. As far as these tests
concerned proposed 4.0 matches 3.3 results.
Thanks,
Victor
Thanks Victor.
Talk about hot off the presses, 4.0 was released at:
13-Oct-2018 18:54
Yes :), I was looking how to fix [YOCTO #12950] and was
about to write email to SystemTap guys asking when the
next release is planned and got email from Frank on
SystemTap mailing list announcing 4.0 release. It was
very good timing.
My understanding is that FC28 and FC27 will get SystemTap
4.0 very soon since they moved to 4.18 kernel too.
Thanks,
Victor
$ git log --oneline release-3.3..release-4.0 | wc -l
252
$ git diff release-3.3..release-4.0 | diffstat | tail -1
1574 files changed, 50756 insertions(+), 23604 deletions(-)
Lots of changes to docs, testsuite but also quite a bit to core code
and tapsets:
$ git diff release-3.3..release-4.0 | diffstat | cut -d"/" -f-2 | uniq -c
|grep -v " [1-5] "
770 b/doc
16 b/httpd
8 b/man
9 b/po
18 b/runtime
15 b/stap-exporter
6 b/staprun
440 b/tapset
223 b/testsuite
../Randy
...entrypc-avoid-usage-of-uninitialized.patch | 46 ---
.../systemtap/systemtap_git.inc | 5 +-
2 files changed, 2 insertions(+), 49 deletions(-)
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
diff --git
a/meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
b/meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
deleted file mode 100644
index d0082a1094..00
---
a/meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 8466fca2a074323a235ef38d425f994a2ff7e64f Mon Sep 17 00:00:00 2001
-From: Victor Kamensky
-Date: Mon, 9 Jul 2018 09:31:19 -0700
-Subject: [PATCH] dwflpp::function_entrypc avoid usage of uninitialized
memory
-
-Failure on 3.3 release was observed. Failure was elusive and
-disappeared after seemingly random configure option change, or when
-code was compiled with -O1 or -O0 (vs default -O2). Running failing
-test case under valgrind memcheck pointed to couple places where
-'Conditional jump or move depends on uninitialised value(s)' occured.
-
-After addressing these in two places in dwflpp::function_entrypc,
-valgrind memcheck run is clean and original issue got fixed.
-
-Upstream-Status: Backport
-Signed-off-by: Victor Kamensky
- dwflpp.cxx | 6 +-
- 1 file changed, 5 insertions(+), 1 deletion(-)
-
-diff --git a/dwflpp.cxx b/dwflpp.cxx
-index bfbb6b096..2172e705a 100644
a/dwflpp.cxx
-+++ b/dwflpp.cxx
-@@ -2465,13 +2465,17 @@ bool
- dwflpp::function_entrypc (Dwarf_Addr * addr)
- {
- assert (function);
-+
-+ // assign default value
-+ *addr = 0;
-+
- // PR10574: reject 0, which tends to be eliminated COMDAT
- if (dwarf_entrypc (function, addr) == 0 && *addr != 0)
- return true;
-
- /* Assume the entry pc is the base address, or (if zero)
- the first address of the ranges covering this
[OE-core] [PATCH] systemtap: 3.3 -> 4.0
Upgrade systemtap from 3.3 to 4.0: Removed backported patch.
Very short summary of major changes from SystemTap 4.0
announcement by Frank Ch. Eigler :
> prometheus exporter network service; ebpf support extensions including
> strings and implementation of traditional log(), sprintf() functions;
> rebuilt rich tapset coverage for 4.17+ syscalls and for
> tracepoint-based syscalls; script language tweaks for supporting
> machine-generated scripts
Fixes [YOCTO #12950]
Signed-off-by: Victor Kamensky
---
Hi Guys,
I'll let you to decide whether you want to accept
it for 2.6 at this point or push it for the next release.
On one hand after move to 4.18 kernel SystemTap 3.3
fails to trace any system call on x86_64 - it is major
functionality breakage. Look at:
https://bugzilla.redhat.com/show_bug.cgi?id=1596456
On other hand it is quite late to do major version
updates.
I did go through limitted set of tests on all
supported QEMU targets. As far as these tests
concerned proposed 4.0 matches 3.3 results.
Thanks,
Victor
...entrypc-avoid-usage-of-uninitialized.patch | 46 ---
.../systemtap/systemtap_git.inc | 5 +-
2 files changed, 2 insertions(+), 49 deletions(-)
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
diff --git
a/meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
b/meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
deleted file mode 100644
index d0082a1094..00
---
a/meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 8466fca2a074323a235ef38d425f994a2ff7e64f Mon Sep 17 00:00:00 2001
-From: Victor Kamensky
-Date: Mon, 9 Jul 2018 09:31:19 -0700
-Subject: [PATCH] dwflpp::function_entrypc avoid usage of uninitialized memory
-
-Failure on 3.3 release was observed. Failure was elusive and
-disappeared after seemingly random configure option change, or when
-code was compiled with -O1 or -O0 (vs default -O2). Running failing
-test case under valgrind memcheck pointed to couple places where
-'Conditional jump or move depends on uninitialised value(s)' occured.
-
-After addressing these in two places in dwflpp::function_entrypc,
-valgrind memcheck run is clean and original issue got fixed.
-
-Upstream-Status: Backport
-Signed-off-by: Victor Kamensky
- dwflpp.cxx | 6 +-
- 1 file changed, 5 insertions(+), 1 deletion(-)
-
-diff --git a/dwflpp.cxx b/dwflpp.cxx
-index bfbb6b096..2172e705a 100644
a/dwflpp.cxx
-+++ b/dwflpp.cxx
-@@ -2465,13 +2465,17 @@ bool
- dwflpp::function_entrypc (Dwarf_Addr * addr)
- {
- assert (function);
-+
-+ // assign default value
-+ *addr = 0;
-+
- // PR10574: reject 0, which tends to be eliminated COMDAT
- if (dwarf_entrypc (function, addr) == 0 && *addr != 0)
- return true;
-
- /* Assume the entry pc is the base address, or (if zero)
- the first address of the ranges covering this DIE. */
-- Dwarf_Addr start, end;
-+ Dwarf_Addr start = 0, end;
- if (dwarf_ranges (function, 0, addr, , ) >= 0)
- {
- if (*addr == 0)
---
-2.17.1
-
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc
b/meta/recipes-kernel/systemtap/systemtap_git.inc
index 06924fc240..274fcde5c1 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -1,7 +1,7 @@
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
-SRCREV = "48867d1cface9445d58e3c6e14497770b7eb77e1"
-PV = "3.3"
+SRCREV = "428f84e9e656bce71018e8902e4edb8aacafcc0e"
+PV = "4.0"
SRC_URI = "git://sourceware.org/git/systemtap.git \
file://configure-allow-to-disable-libvirt.patch \
@@ -11,7 +11,6 @@ SRC_URI = "git://sourceware.org/git/systemtap.git \
file://0001-Do-not-let-configure-write-a-python-location-into-th.patch \
file://0001-Install-python-modules-to-correct-library-dir.patch \
file://0001-staprun-stapbpf-don-t-support-installing-a-non-root.patch \
-
file://0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch \
"
COMPATIBLE_HOST = '(x86_64|i.86|powerpc|arm|aarch64|microblazeel|mips).*-linux'
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] cve-report: add scripts to generate CVE reports
On Sat, 4 Aug 2018, Alexander Kanavin wrote: How reliable is NVD database for such automated scans? Previously, we have repeatedly concluded that it should not be trusted, and proper patching of vulnerabilities must involve humans looking at vulnerability reports and making appropriate decisions - same as Debian is doing for example. I don't think scanning NVD database and generating proper reports and having people looking at vulnerability reports are mutually exclusive. I think rather both should be done. The patches and tools we are proposing do scanning and reporting, while looking at versions, pattches applied, for a given image. Correctly analazying CVEs and applying right patches is a separate thing. Just an example please find below reports generated for sumo that I pulled today, core-image-lsb image qemux86-64 MACHINE. As one may see in below report it is not perfect. There are clearly false positives, misplaced entries based on, as you mentioned on not fully reliable NVD data. I.e CVE-2013-4598 reported against gcc the one I could spot - it is wrong. But it does not negate value of cases where it is reported correctly. So it boils down to a question whether value of useful signal against cost of filtering some noise. From our experience using this tool for a while internally to fix outstanding CVEs for krogoth branch, the right signal definitely has very good value. Grygorii, btw I had trouble pulling your patches from email, it seems that there were posted as Text/HTML (at least it is what my mailer tells me). Could you please repost them as Text/PLAIN, i.e using git send-mail report-foss.txt: patched | 5.5 | CVE-2017-15873 | busybox | 1.27.2 patched | 8.8 | CVE-2017-16544 | busybox | 1.27.2 patched | 6.5 | CVE-2016-3189 | bzip2 | 1.0.6 patched | 7.5 | CVE-2017-9814 | cairo | 1.14.12 patched | 9.8 | CVE-2016-6354 | flex | 2.6.0 patched | 7.3 | CVE-2015-8560 | foomatic-filters | 4.0.17 patched | 7.5 | CVE-2015-8327 | foomatic-filters | 4.0.17 patched | 7.8 | CVE-2017-11714 | ghostscript | 9.21 patched | 7.8 | CVE-2017-9835 | ghostscript | 9.21 patched | 8.1 | CVE-2018-11236 | glibc | 2.27 patched | 6.5 | CVE-2017-14166 | libarchive | 3.3.2 patched | 7.5 | CVE-2017-14502 | libarchive | 3.3.2 patched | 5.5 | CVE-2017-8361 | libsndfile | 1.0.28 patched | 5.5 | CVE-2017-8362 | libsndfile | 1.0.28 patched | 5.5 | CVE-2017-8363 | libsndfile | 1.0.28 patched | 5.5 | CVE-2017-8365 | libsndfile | 1.0.28 patched | 8.8 | CVE-2017-6892 | libsndfile | 1.0.28 patched | 6.5 | CVE-2017-18013 | libtiff | 4.0.9 patched | 6.5 | CVE-2018-10963 | libtiff | 4.0.9 patched | 6.5 | CVE-2018-5784 | libtiff | 4.0.9 patched | 6.5 | CVE-2018-7456 | libtiff | 4.0.9 patched | 8.8 | CVE-2018-8905 | libtiff | 4.0.9 patched | 6.5 | CVE-2017-14633 | libvorbis | 1.3.5 patched | 9.8 | CVE-2017-14632 | libvorbis | 1.3.5 patched | 7.5 | CVE-2018-6951 | patch | 2.7.6 patched | 7.8 | CVE-2018-1000156 | patch | 2.7.6 patched | 7.5 | CVE-2017-12837 | perl | 5.24.1 patched | 9.1 | CVE-2017-12883 | perl | 5.24.1 patched | 7.5 | CVE-2017-8779 | rpcbind | 0.2.4 patched | 4.0 | CVE-2014-9913 | unzip | 6.0 patched | 4.0 | CVE-2016-9844 | unzip | 6.0 patched | 4.3 | CVE-2015-7697 | unzip | 6.0 patched | 5.0 | CVE-2014-9636 | unzip | 6.0 patched | 6.8 | CVE-2015-7696 | unzip | 6.0 patched | 5.3 | CVE-2017-13078 | wpa_supplicant | 2.6 patched | 5.3 | CVE-2017-13079 | wpa_supplicant | 2.6 patched | 5.3 | CVE-2017-13080 | wpa_supplicant | 2.6 patched | 5.3 | CVE-2017-13081 | wpa_supplicant | 2.6 patched | 5.3 | CVE-2017-13087 | wpa_supplicant | 2.6 patched | 5.3 | CVE-2017-13088 | wpa_supplicant | 2.6 patched | 6.8 | CVE-2017-13077 | wpa_supplicant | 2.6 patched | 6.8 | CVE-2017-13086 | wpa_supplicant | 2.6 patched | 8.1 | CVE-2017-13082 | wpa_supplicant | 2.6 unpatched | 5.5 | CVE-2018-10372 | binutils | 2.30 unpatched | 5.5 | CVE-2018-10534 | binutils | 2.30 unpatched | 5.5 | CVE-2018-10535 | binutils | 2.30 unpatched | 5.5 | CVE-2018-6759 | binutils | 2.30 unpatched | 5.5 | CVE-2018-6872 | binutils | 2.30 unpatched | 5.5 | CVE-2018-7568 | binutils | 2.30 unpatched | 5.5 | CVE-2018-7569 | binutils | 2.30 unpatched | 5.5 | CVE-2018-7570 | binutils | 2.30 unpatched | 5.5 | CVE-2018-7642 | binutils | 2.30 unpatched | 5.5 | CVE-2018-8945 | binutils | 2.30 unpatched | 5.5 | CVE-2018-9138 | binutils | 2.30 unpatched | 5.5 | CVE-2018-9996 | binutils | 2.30 unpatched | 6.5 | CVE-2018-10373 | binutils | 2.30 unpatched | 7.8 | CVE-2018-6543 | binutils | 2.30 unpatched | 7.8 | CVE-2018-7208 | binutils | 2.30 unpatched | 7.8 | CVE-2018-7643
Re: [OE-core] [PATCH] package: skip strip on signed kernel modules
On Fri, 3 Aug 2018, Ocampo Coronado, Omar wrote: Yes, we would like to keep the symbols on a signed kernel module. Andre shared this link: https://www.kernel.org/doc/html/v4.17/admin-guide/module-signing.html#signed-modules-and-stripping , from conversation topic: Re: [OE-core] Strip kernel modules and signatures Thank you for the pointer. I did not expect that KLM signing will be outside of ELF. Too bad that it is so brittle. Ideally, it would be nice if one could disable KLM signing in kernel makefile machinery and have mechanism to sign KLMs in OE itself, just before packaging but after they got stripped. IMO it would be more practical. I could not imagine if one would want to ship KLMs with debug symbols inside. But even if that is implemented, your code would still should stand ok - if module signed already, it cannot be touched. -28 are the last 28 bytes of the file. The same amount of bytes are being read by dracut to check if a module is signed. And you are correct Victor, I'm unsure if this would work outside x86 arch. I've checked that by building mips64 kernel with KLM signing enabled and I looked at scripts/sign-file.c source, you are fine: magic_number = "~Module signature appended~\n" will be always at the end after KLM signing regardless of architecture. Thanks, Victor Two pending fixes: 1) This patch also needs to fix the mode of the file as the original may not be preserved. 2) Seems like 'return' is not accepted by oe.utils.multiprocess, still getting familiar with OE -Original Message- From: Victor Kamensky [mailto:kamen...@cisco.com] Sent: Friday, August 3, 2018 3:28 PM To: Ocampo Coronado, Omar Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] package: skip strip on signed kernel modules On Fri, 3 Aug 2018, omar.ocampo.coron...@intel.com wrote: From: foocampo Executing strip action on kernel modules removes the signature. Is not possible to strip and keep the signature, therefore avoid strip signed kernel modules. Signed-off-by: foocampo --- meta/lib/oe/package.py | 10 ++ 1 file changed, 10 insertions(+) diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py index fa3428ad61..f7d2d3b7c4 100644 --- a/meta/lib/oe/package.py +++ b/meta/lib/oe/package.py @@ -24,6 +24,9 @@ def runstrip(arg): # kernel module if elftype & 16: +if is_kernel_module_signed(file): +bb.debug(1, "Skip strip on signed module %s" % file) +return It does not look right to me. Above means that signed KLM will go into image with symbols. Or I don't read code correctly? Where is signature stored? Is it some kind of an ELF NOTE? In this case you would just need to drop only "--remove-section=.note" from strip command. Wondering why .notes were stripped in the first place. stripcmd.extend(["--strip-debug", "--remove-section=.comment", "--remove-section=.note", "--preserve-dates"]) I suggest split above into two invocations and do second stripcmd.extend(["--remove-section=.note"]) only for non signed modules. Assuming that signature is in the .note section. If it is not .comment, do that with "--remove-section=.comment" instead. # .so and shared library @@ -46,6 +49,13 @@ def is_kernel_module(path): with open(path) as f: return mmap.mmap(f.fileno(), 0, prot=mmap.PROT_READ).find(b"vermagic=") >= 0 +# Detect if .ko module is signed +def is_kernel_module_signed(path): +with open(path, "rb") as f: +f.seek(-28, 2) Where magic -28 comes from? Is it true for all cases, all CPU arches? I think it could be done more cleanly here. Thanks, Victor +module_tail = f.read() +return "Module signature appended" in "".join(chr(c) for c in + bytearray(module_tail)) + # Return type (bits): # 0 - not elf # 1 - ELF -- 2.18.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] package: skip strip on signed kernel modules
On Fri, 3 Aug 2018, omar.ocampo.coron...@intel.com wrote: From: foocampo Executing strip action on kernel modules removes the signature. Is not possible to strip and keep the signature, therefore avoid strip signed kernel modules. Signed-off-by: foocampo --- meta/lib/oe/package.py | 10 ++ 1 file changed, 10 insertions(+) diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py index fa3428ad61..f7d2d3b7c4 100644 --- a/meta/lib/oe/package.py +++ b/meta/lib/oe/package.py @@ -24,6 +24,9 @@ def runstrip(arg): # kernel module if elftype & 16: +if is_kernel_module_signed(file): +bb.debug(1, "Skip strip on signed module %s" % file) +return It does not look right to me. Above means that signed KLM will go into image with symbols. Or I don't read code correctly? Where is signature stored? Is it some kind of an ELF NOTE? In this case you would just need to drop only "--remove-section=.note" from strip command. Wondering why .notes were stripped in the first place. stripcmd.extend(["--strip-debug", "--remove-section=.comment", "--remove-section=.note", "--preserve-dates"]) I suggest split above into two invocations and do second stripcmd.extend(["--remove-section=.note"]) only for non signed modules. Assuming that signature is in the .note section. If it is not .comment, do that with "--remove-section=.comment" instead. # .so and shared library @@ -46,6 +49,13 @@ def is_kernel_module(path): with open(path) as f: return mmap.mmap(f.fileno(), 0, prot=mmap.PROT_READ).find(b"vermagic=") >= 0 +# Detect if .ko module is signed +def is_kernel_module_signed(path): +with open(path, "rb") as f: +f.seek(-28, 2) Where magic -28 comes from? Is it true for all cases, all CPU arches? I think it could be done more cleanly here. Thanks, Victor +module_tail = f.read() +return "Module signature appended" in "".join(chr(c) for c in bytearray(module_tail)) + # Return type (bits): # 0 - not elf # 1 - ELF -- 2.18.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] systemtap: fix unintialized memory accesses in dwflpp::function_entrypc
Observed failure in SystemTap v3.3 unit testing, It was tracked down
to unintialized memory access in dwflpp::function_entrypc method.
Upstream-Status: Backport
Signed-off-by: Victor Kamensky
---
...entrypc-avoid-usage-of-uninitialized.patch | 46 +++
.../systemtap/systemtap_git.inc | 1 +
2 files changed, 47 insertions(+)
create mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
diff --git
a/meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
b/meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
new file mode 100644
index 00..d0082a1094
--- /dev/null
+++
b/meta/recipes-kernel/systemtap/systemtap/0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch
@@ -0,0 +1,46 @@
+From 8466fca2a074323a235ef38d425f994a2ff7e64f Mon Sep 17 00:00:00 2001
+From: Victor Kamensky
+Date: Mon, 9 Jul 2018 09:31:19 -0700
+Subject: [PATCH] dwflpp::function_entrypc avoid usage of uninitialized memory
+
+Failure on 3.3 release was observed. Failure was elusive and
+disappeared after seemingly random configure option change, or when
+code was compiled with -O1 or -O0 (vs default -O2). Running failing
+test case under valgrind memcheck pointed to couple places where
+'Conditional jump or move depends on uninitialised value(s)' occured.
+
+After addressing these in two places in dwflpp::function_entrypc,
+valgrind memcheck run is clean and original issue got fixed.
+
+Upstream-Status: Backport
+Signed-off-by: Victor Kamensky
+---
+ dwflpp.cxx | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/dwflpp.cxx b/dwflpp.cxx
+index bfbb6b096..2172e705a 100644
+--- a/dwflpp.cxx
b/dwflpp.cxx
+@@ -2465,13 +2465,17 @@ bool
+ dwflpp::function_entrypc (Dwarf_Addr * addr)
+ {
+ assert (function);
++
++ // assign default value
++ *addr = 0;
++
+ // PR10574: reject 0, which tends to be eliminated COMDAT
+ if (dwarf_entrypc (function, addr) == 0 && *addr != 0)
+ return true;
+
+ /* Assume the entry pc is the base address, or (if zero)
+ the first address of the ranges covering this DIE. */
+- Dwarf_Addr start, end;
++ Dwarf_Addr start = 0, end;
+ if (dwarf_ranges (function, 0, addr, , ) >= 0)
+ {
+ if (*addr == 0)
+--
+2.17.1
+
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc
b/meta/recipes-kernel/systemtap/systemtap_git.inc
index a1e05579e6..06924fc240 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -11,6 +11,7 @@ SRC_URI = "git://sourceware.org/git/systemtap.git \
file://0001-Do-not-let-configure-write-a-python-location-into-th.patch \
file://0001-Install-python-modules-to-correct-library-dir.patch \
file://0001-staprun-stapbpf-don-t-support-installing-a-non-root.patch \
+
file://0001-dwflpp-function_entrypc-avoid-usage-of-uninitialized.patch \
"
COMPATIBLE_HOST = '(x86_64|i.86|powerpc|arm|aarch64|microblazeel|mips).*-linux'
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] systemtap: 3.2 -> 3.3
Upgrade systemtap from 3.2 to 3.3: Removed all backported patches.
Removed "remove quotes around -I include" pending patch since 3.3
got similar fix already. Resolved merge conflict in and
regenerated monitor-option.patch patch.
Signed-off-by: Victor Kamensky
---
...dded-a-couple-of-small-sysroot-fixes.patch | 42 ---
...root-path-to-module-name-in-case-of-.patch | 61
...pdating-the-use-of-timers-for-the-4..patch | 277 --
.../systemtap/0001-Fixes-for-gcc-8.patch | 215 --
...sysroot-paths-don-t-end-with-a-slash.patch | 128
...when-looking-for-the-System.map-file.patch | 29 --
...ocate-needs-target-file-path-not-hos.patch | 39 ---
...-remove-quotes-around-I-include-line.patch | 38 ---
...-with-sysroot-case-do-not-remove-sys.patch | 42 ---
...t-release-r-option-handling-follow-u.patch | 40 ---
...-fix-short-release-r-option-handling.patch | 53
...ymbolic-links-with-absolute-name-rel.patch | 117
.../systemtap/systemtap/monitor-option.patch | 15 +-
.../systemtap/systemtap_git.inc | 16 +-
14 files changed, 8 insertions(+), 1104 deletions(-)
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Added-a-couple-of-small-sysroot-fixes.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Delay-adding-sysroot-path-to-module-name-in-case-of-.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Fix-PR22551-by-updating-the-use-of-timers-for-the-4..patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Fixes-for-gcc-8.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Make-sure-sysroot-paths-don-t-end-with-a-slash.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-Use-sysroot-when-looking-for-the-System.map-file.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-_stp_umodule_relocate-needs-target-file-path-not-hos.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-buildrun-remove-quotes-around-I-include-line.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-debuginfo-lookup-with-sysroot-case-do-not-remove-sys.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-sysroot-fix-short-release-r-option-handling-follow-u.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-sysroot-fix-short-release-r-option-handling.patch
delete mode 100644
meta/recipes-kernel/systemtap/systemtap/0001-sysroot-handle-symbolic-links-with-absolute-name-rel.patch
diff --git
a/meta/recipes-kernel/systemtap/systemtap/0001-Added-a-couple-of-small-sysroot-fixes.patch
b/meta/recipes-kernel/systemtap/systemtap/0001-Added-a-couple-of-small-sysroot-fixes.patch
deleted file mode 100644
index c0ceb5a412..00
---
a/meta/recipes-kernel/systemtap/systemtap/0001-Added-a-couple-of-small-sysroot-fixes.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From a714658727206d2a98a7194b7e6d29dbd3e27b8d Mon Sep 17 00:00:00 2001
-From: David Smith
-Date: Mon, 19 Mar 2018 16:50:05 -0500
-Subject: [PATCH] Added a couple of small sysroot fixes.
-
-* tapsets.cxx (dwarf_builder::build): Fix commit 4ffecddf5.
- (path_remove_sysroot): Fix extra '/' present at start of paths.
-
-Upstream-Status: Backport
-Signed-off-by: Victor Kamensky
- tapsets.cxx | 10 +++---
- 1 file changed, 7 insertions(+), 3 deletions(-)
-
-Index: git/tapsets.cxx
-===
git.orig/tapsets.cxx
-+++ git/tapsets.cxx
-@@ -1395,7 +1395,8 @@ string path_remove_sysroot(const systemt
- string retval = path;
- if (!sess.sysroot.empty() &&
- (pos = retval.find(sess.sysroot)) != string::npos)
--retval.replace(pos, sess.sysroot.length(), "/");
-+retval.replace(pos, sess.sysroot.length(),
-+ (sess.sysroot.back() == '/' ? "/": ""));
- return retval;
- }
-
-@@ -8412,8 +8413,11 @@ dwarf_builder::build(systemtap_session &
-
- // PR13338: unquote glob results
- module_name = unescape_glob_chars (module_name);
-- user_path = find_executable (module_name, "", sess.sysenv); //
canonicalize it
-- if (!is_fully_resolved(user_path, sess.sysroot, sess.sysenv))
-+ user_path = find_executable (module_name, sess.sysroot, sess.sysenv);
// canonicalize it
-+ // Note we don't need to pass the sysroot to
-+ // is_fully_resolved(), since we just passed it to
-+ // find_executable().
-+ if (!is_fully_resolved(user_path, "", sess.sysenv))
- throw SEMANTIC_ERROR(_F("cannot find executable '%s'",
- user_path.to_string().c_str()));
-
diff --git
a/meta/recipes-kernel/systemtap/systemtap/0001-Delay-adding-sysroot-path-to-module-name-in-case-of-.patch
b/meta/recipes-kernel/systemtap/systemtap/0001-Delay-adding-sysroot-path-to-module-name-in-case-of-.patch
deleted file mode 100644
index 89951a2f19..00
---
