| Message ID | c0e598696af9be3f567751a8641effb08431a7d2.1496979431.git.raj.khem@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Fix imagetests with harderning flags | expand |
On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote: > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" > These tend to go into security-flags.inc, not the recipe. Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote: > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote: > >> +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" >> > > These tend to go into security-flags.inc, not the recipe. > I know that's been the case but I think having a global file is error prone its better to have it in recipe context since it can get attention at upgrade time to test if this has been fixed in new release etc > > Ross > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote: > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote: > > > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote: > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" > > > > > > > These tend to go into security-flags.inc, not the recipe. > > > > I know that's been the case but I think having a global file is error > prone > its better to have it in recipe context since it can get attention at > upgrade time to test if this has been fixed in new release etc Isn't one of the main root causes really that bitbake passes -fpie -pie even when the recipe is building a shared library? (Maybe not in this case here, though). Obviously, bitbake doesn't really know about shared libraries, and yes, each recipe's build system could filter out pie flags for shared library targets, but that's probably better done at libtool level: http://lists.openembedded.org/pipermail/openembedded-devel/2016-November/110048.html Cheers, Andre' -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, Jun 9, 2017 at 7:02 AM, André Draszik <git@andred.net> wrote: > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote: >> On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote: >> >> > >> > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote: >> > >> > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" >> > > >> > >> > These tend to go into security-flags.inc, not the recipe. >> > >> >> I know that's been the case but I think having a global file is error >> prone >> its better to have it in recipe context since it can get attention at >> upgrade time to test if this has been fixed in new release etc > > Isn't one of the main root causes really that bitbake passes -fpie -pie even > when the recipe is building a shared library? thats a different case not relevant to this one as much. here we have textrel in pulseaudio PIE executable (Maybe not in this case here, > though). Obviously, bitbake doesn't really know about shared libraries, and > yes, each recipe's build system could filter out pie flags for shared > library targets, but that's probably better done at libtool level: > > http://lists.openembedded.org/pipermail/openembedded-devel/2016-November/110048.html > > > Cheers, > Andre' > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote: > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote: > > > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote: > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" > > > > > > > These tend to go into security-flags.inc, not the recipe. > > > > I know that's been the case but I think having a global file is error prone > its better to have it in recipe context since it can get attention at > upgrade time to test if this has been fixed in new release etc Do you mean that there's some bug in pulseaudio, and this is a workaround for it? Is the bug that there are textrels? Ross saw textrels in pulseaudio before (see the discussion starting at [1]), but I was unable to reproduce that. If you give instructions for reproducing the problem, I'll see if I can fix pulseaudio (until then I'm fine with having a workaround). [1] http://lists.openembedded.org/pipermail/openembedded-core/2017-February/133215.html -- Tanu https://www.patreon.com/tanuk -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi> wrote: > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote: >> On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote: >> >> > >> > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote: >> > >> > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" >> > > >> > >> > These tend to go into security-flags.inc, not the recipe. >> > >> >> I know that's been the case but I think having a global file is error prone >> its better to have it in recipe context since it can get attention at >> upgrade time to test if this has been fixed in new release etc > > Do you mean that there's some bug in pulseaudio, and this is a > workaround for it? Is the bug that there are textrels? Ross saw > textrels in pulseaudio before (see the discussion starting at [1]), but > I was unable to reproduce that. If you give instructions for > reproducing the problem, I'll see if I can fix pulseaudio (until then > I'm fine with having a workaround). > yes there is a bug lurking when compiling with hardening flags are turned on so you can do something like in local.conf require conf/distro/include/security_flags.inc then MACHINE=qemux86 bitbake pulseaudio it also happens on arm so qemuarm will reproduce it too. some assembly code is probably missing using GOT relative accesses > [1] http://lists.openembedded.org/pipermail/openembedded-core/2017-February/133215.html > > -- > Tanu > > https://www.patreon.com/tanuk -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote: > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi> wrote: > > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote: > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> wrote: > > > > > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote: > > > > > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" > > > > > > > > > > > > > These tend to go into security-flags.inc, not the recipe. > > > > > > > > > > I know that's been the case but I think having a global file is error prone > > > its better to have it in recipe context since it can get attention at > > > upgrade time to test if this has been fixed in new release etc > > > > Do you mean that there's some bug in pulseaudio, and this is a > > workaround for it? Is the bug that there are textrels? Ross saw > > textrels in pulseaudio before (see the discussion starting at [1]), but > > I was unable to reproduce that. If you give instructions for > > reproducing the problem, I'll see if I can fix pulseaudio (until then > > I'm fine with having a workaround). > > > > yes there is a bug lurking when compiling with hardening flags are turned on > so you can do something like > > in local.conf > > require conf/distro/include/security_flags.inc > > then > > MACHINE=qemux86 bitbake pulseaudio > > it also happens on arm so qemuarm will reproduce it too. > > some assembly code is probably missing using GOT relative accesses Resurrecting this ancient thread... I finally tried to reproduce this problem with the given instructions. No success. Have you still been running into this issue? -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote: > > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi> wrote: > > > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote: > > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> > wrote: > > > > > > > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote: > > > > > > > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" > > > > > > > > > > > > > > > > These tend to go into security-flags.inc, not the recipe. > > > > > > > > > > > > > I know that's been the case but I think having a global file is > error prone > > > > its better to have it in recipe context since it can get attention at > > > > upgrade time to test if this has been fixed in new release etc > > > > > > Do you mean that there's some bug in pulseaudio, and this is a > > > workaround for it? Is the bug that there are textrels? Ross saw > > > textrels in pulseaudio before (see the discussion starting at [1]), but > > > I was unable to reproduce that. If you give instructions for > > > reproducing the problem, I'll see if I can fix pulseaudio (until then > > > I'm fine with having a workaround). > > > > > > > yes there is a bug lurking when compiling with hardening flags are > turned on > > so you can do something like > > > > in local.conf > > > > require conf/distro/include/security_flags.inc > > > > then > > > > MACHINE=qemux86 bitbake pulseaudio > > > > it also happens on arm so qemuarm will reproduce it too. > > > > some assembly code is probably missing using GOT relative accesses > > Resurrecting this ancient thread... I finally tried to reproduce this > problem with the given instructions. No success. Have you still been > running into this issue? I don’t know for sure if this still exists but we did disable assembly in few packages which addresses this issue since in assembly PIC has to be respected In hand written code You might have to check if we did something similar for pulseaudio > > > -- > Tanu > > https://www.patreon.com/tanuk > https://liberapay.com/tanuk > > <div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen <<a href="mailto:tanuk@iki.fi">tanuk@iki.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:<br> > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <<a href="mailto:tanuk@iki.fi" target="_blank">tanuk@iki.fi</a>> wrote:<br> > > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote:<br> > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <<a href="mailto:ross.burton@intel.com" target="_blank">ross.burton@intel.com</a>> wrote:<br> > > > <br> > > > > On 9 June 2017 at 04:41, Khem Raj <<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>> wrote:<br> > > > > <br> > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"<br> > > > > > <br> > > > > <br> > > > > These tend to go into security-flags.inc, not the recipe.<br> > > > > <br> > > > <br> > > > I know that's been the case but I think having a global file is error prone<br> > > > its better to have it in recipe context since it can get attention at<br> > > > upgrade time to test if this has been fixed in new release etc<br> > > <br> > > Do you mean that there's some bug in pulseaudio, and this is a<br> > > workaround for it? Is the bug that there are textrels? Ross saw<br> > > textrels in pulseaudio before (see the discussion starting at [1]), but<br> > > I was unable to reproduce that. If you give instructions for<br> > > reproducing the problem, I'll see if I can fix pulseaudio (until then<br> > > I'm fine with having a workaround).<br> > > <br> > <br> > yes there is a bug lurking when compiling with hardening flags are turned on<br> > so you can do something like<br> > <br> > in local.conf<br> > <br> > require conf/distro/include/security_flags.inc<br> > <br> > then<br> > <br> > MACHINE=qemux86 bitbake pulseaudio<br> > <br> > it also happens on arm so qemuarm will reproduce it too.<br> > <br> > some assembly code is probably missing using GOT relative accesses<br> <br> Resurrecting this ancient thread... I finally tried to reproduce this<br> problem with the given instructions. No success. Have you still been<br> running into this issue?</blockquote><div dir="auto"><br></div><div dir="auto">I don’t know for sure if this still exists but we did disable assembly in few packages which addresses this issue since in assembly PIC has to be respected</div><div dir="auto">In hand written code </div><div dir="auto"><br></div><div dir="auto">You might have to check if we did something similar for pulseaudio </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> <br> -- <br> Tanu<br> <br> <a href="https://www.patreon.com/tanuk" rel="noreferrer" target="_blank">https://www.patreon.com/tanuk</a><br> <a href="https://liberapay.com/tanuk" rel="noreferrer" target="_blank">https://liberapay.com/tanuk</a><br> <br> </blockquote></div></div> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Mon, 2019-04-22 at 14:28 -0600, Khem Raj wrote: > On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote: > > > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi> wrote: > > > > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote: > > > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross <ross.burton@intel.com> > > wrote: > > > > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> wrote: > > > > > > > > > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" > > > > > > > > > > > > > > > > > > > These tend to go into security-flags.inc, not the recipe. > > > > > > > > > > > > > > > > I know that's been the case but I think having a global file is > > error prone > > > > > its better to have it in recipe context since it can get attention at > > > > > upgrade time to test if this has been fixed in new release etc > > > > > > > > Do you mean that there's some bug in pulseaudio, and this is a > > > > workaround for it? Is the bug that there are textrels? Ross saw > > > > textrels in pulseaudio before (see the discussion starting at [1]), but > > > > I was unable to reproduce that. If you give instructions for > > > > reproducing the problem, I'll see if I can fix pulseaudio (until then > > > > I'm fine with having a workaround). > > > > > > > > > > yes there is a bug lurking when compiling with hardening flags are > > turned on > > > so you can do something like > > > > > > in local.conf > > > > > > require conf/distro/include/security_flags.inc > > > > > > then > > > > > > MACHINE=qemux86 bitbake pulseaudio > > > > > > it also happens on arm so qemuarm will reproduce it too. > > > > > > some assembly code is probably missing using GOT relative accesses > > > > Resurrecting this ancient thread... I finally tried to reproduce this > > problem with the given instructions. No success. Have you still been > > running into this issue? > > I don’t know for sure if this still exists but we did disable assembly in > few packages which addresses this issue since in assembly PIC has to be > respected > In hand written code > > You might have to check if we did something similar for pulseaudio There seem to be no such changes to the pulseaudio recipe. Some upstream fix seems unlikely as well. The only possibly relevant change that I could find was removing a buggy implementation of reading the cpuid register (the removed code was replaced with the __get_cpuid() macro that compilers provide in cpuid.h). Oh well, if the problem reappears, let me know.
On Fri, 2019-04-26 at 15:53 +0300, Tanu Kaskinen wrote: > On Mon, 2019-04-22 at 14:28 -0600, Khem Raj wrote: > > On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > > > On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote: > > > > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen <tanuk@iki.fi> > > > > wrote: > > > > > On Fri, 2017-06-09 at 13:07 +0000, Khem Raj wrote: > > > > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross < > > > > > > ross.burton@intel.com> > > > wrote: > > > > > > > On 9 June 2017 at 04:41, Khem Raj <raj.khem@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" > > > > > > > > > > > > > > > > > > > > > > These tend to go into security-flags.inc, not the recipe. > > > > > > > > > > > > > > > > > > > I know that's been the case but I think having a global > > > > > > file is > > > error prone > > > > > > its better to have it in recipe context since it can get > > > > > > attention at > > > > > > upgrade time to test if this has been fixed in new release > > > > > > etc > > > > > > > > > > Do you mean that there's some bug in pulseaudio, and this is > > > > > a > > > > > workaround for it? Is the bug that there are textrels? Ross > > > > > saw > > > > > textrels in pulseaudio before (see the discussion starting at > > > > > [1]), but > > > > > I was unable to reproduce that. If you give instructions for > > > > > reproducing the problem, I'll see if I can fix pulseaudio > > > > > (until then > > > > > I'm fine with having a workaround). > > > > > > > > > > > > > yes there is a bug lurking when compiling with hardening flags > > > > are > > > turned on > > > > so you can do something like > > > > > > > > in local.conf > > > > > > > > require conf/distro/include/security_flags.inc > > > > > > > > then > > > > > > > > MACHINE=qemux86 bitbake pulseaudio > > > > > > > > it also happens on arm so qemuarm will reproduce it too. > > > > > > > > some assembly code is probably missing using GOT relative > > > > accesses > > > > > > Resurrecting this ancient thread... I finally tried to reproduce > > > this > > > problem with the given instructions. No success. Have you still > > > been > > > running into this issue? > > > > I don’t know for sure if this still exists but we did disable > > assembly in > > few packages which addresses this issue since in assembly PIC has > > to be > > respected > > In hand written code > > > > You might have to check if we did something similar for pulseaudio > > There seem to be no such changes to the pulseaudio recipe. Some > upstream fix seems unlikely as well. The only possibly relevant > change > that I could find was removing a buggy implementation of reading the > cpuid register (the removed code was replaced with the __get_cpuid() > macro that compilers provide in cpuid.h). > > Oh well, if the problem reappears, let me know. Shortly after this, Khem submitted: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c91314ec160420a320007d552cec6c7da4d54833 and http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6733a7873ca121295a2e309a6915b9816e1ae36b which I suspect made this other change unnecessary? Cheers, Richard
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb index f3a85737fc..3ea35e592a 100644 --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb @@ -8,6 +8,8 @@ SRC_URI = "http://freedesktop.org/software/pulseaudio/releases/${BP}.tar.xz \ SRC_URI[md5sum] = "4950d2799bf55ab91f6b7f990b7f0971" SRC_URI[sha256sum] = "a3186824de9f0d2095ded5d0d0db0405dc73133983c2fbb37291547e37462f57" +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}" + do_compile_prepend() { mkdir -p ${S}/libltdl cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
Fixes WARNING: pulseaudio-10.0-r0 do_package_qa: QA Issue: ELF binary '/mnt/a/oe/build/tmp/work/i586-bec-linux-musl/pulseaudio/10.0-r0/packages-split/pulseaudio-server/usr/bin/pulseaudio' has relocations in .text [textrel] This also makes bitbake -c testimage core-image-sato (hardened) build to pass all tests Fixes AssertionError: 1 != 0 : Log: /mnt/a/oe/build/tmp/work/qemux86-bec-linux-musl/core-image-sato/1.0-r0/dmesg_output.log ----------------------- Central error: [ 20.726960] pulseaudio[729]: segfault at 80052b6c ip b771b4fc sp bfc97940 error 7 in libc.so[b76b6000+97000] Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb | 2 ++ 1 file changed, 2 insertions(+) -- 2.13.1 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core