Thought this went away in my Jan-2023 git pull, but apparently not. Looked in my dmesg output and saw this again. process 'sharebin/cingg2301/bin/cin' started with executable stack Why? A consequence of the plug-in system? a poorly designed 3rdparty library? an oversight? stack segments are generally marked as no-exec to protect against using them to execute rogue instructions by saving those instructions in auto-vars on the stack that could be executed by fudging the return address of a function. Just looking for an acknowledgement of this, and any relevant related history at this point.
ср, 11 янв. 2023 г., 13:03 Rob Prowel via Cin <[email protected]>:
Thought this went away in my Jan-2023 git pull, but apparently not. Looked in my dmesg output and saw this again.
process 'sharebin/cingg2301/bin/cin' started with executable stack
Why? A consequence of the plug-in system? a poorly designed 3rdparty library? an oversight?
--
I think this is due to embedding icon 'object' (lots of png files concatenated) into main executable ... from cinelerra/Makefile $(THEME_DATA): cd $(OBJDIR) && \ $(GUICAST)/$(OBJDIR)/bootstrap theme_data.o $(TOPDIR)/picon/cinfinity/*.png (also I thought we hoped to optipng them, if quality not suffer ...) stack segments are generally marked as no-exec to protect against using
them to execute rogue instructions by saving those instructions in auto-vars on the stack that could be executed by fudging the return address of a function.
Just looking for an acknowledgement of this, and any relevant related history at this point.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
ср, 11 янв. 2023 г., 13:30 Andrew Randrianasulu <[email protected]>:
ср, 11 янв. 2023 г., 13:03 Rob Prowel via Cin <[email protected]
:
Thought this went away in my Jan-2023 git pull, but apparently not. Looked in my dmesg output and saw this again.
process 'sharebin/cingg2301/bin/cin' started with executable stack
Why? A consequence of the plug-in system? a poorly designed 3rdparty library? an oversight?
--
I think this is due to embedding icon 'object' (lots of png files concatenated) into main executable ...
from cinelerra/Makefile
$(THEME_DATA): cd $(OBJDIR) && \ $(GUICAST)/$(OBJDIR)/bootstrap theme_data.o $(TOPDIR)/picon/cinfinity/*.png
(also I thought we hoped to optipng them, if quality not suffer ...)
can you check if something like attached patch fixes it for you? i hope it was only o file with missing GNU.stack ~/cinelerra/cinelerra-5.1 $ readelf -SW cinelerra/aarch64/*.o | grep note | wc -l 374 ~/cinelerra/cinelerra-5.1 $ ls cinelerra/aarch64/*.o | wc -l 375 readelf line from https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-... linker flag from https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart note, old linkers may dislike this and also it seems clang linker (lld) default on termux does this by default ....
stack segments are generally marked as no-exec to protect against using
them to execute rogue instructions by saving those instructions in auto-vars on the stack that could be executed by fudging the return address of a function.
Just looking for an acknowledgement of this, and any relevant related history at this point.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On 1/11/23 07:37, Andrew Randrianasulu wrote:
ср, 11 янв. 2023 г., 13:30 Andrew Randrianasulu <[email protected]>:
ср, 11 янв. 2023 г., 13:03 Rob Prowel via Cin <[email protected]
:
Thought this went away in my Jan-2023 git pull, but apparently not. Looked in my dmesg output and saw this again.
process 'sharebin/cingg2301/bin/cin' started with executable stack
Why? A consequence of the plug-in system? a poorly designed 3rdparty library? an oversight?
--
I think this is due to embedding icon 'object' (lots of png files concatenated) into main executable ...
from cinelerra/Makefile
$(THEME_DATA): cd $(OBJDIR) && \ $(GUICAST)/$(OBJDIR)/bootstrap theme_data.o $(TOPDIR)/picon/cinfinity/*.png
(also I thought we hoped to optipng them, if quality not suffer ...)
can you check if something like attached patch fixes it for you?
i hope it was only o file with missing GNU.stack
~/cinelerra/cinelerra-5.1 $ readelf -SW cinelerra/aarch64/*.o | grep note | wc -l 374 ~/cinelerra/cinelerra-5.1 $ ls cinelerra/aarch64/*.o | wc -l 375
under my git repo the aarch64 only exists under the thirdparty tree. when done under cinelerra/x86_64 the output yields 383 and 384 Will note that my latest build have been using clang++, but previous used g++, and both exhibited the stack warning. $ for i in *.o; do readelf -SW *.o | grep note $i > /dev/null; [ $? -ne 0 ] && echo $i; done theme_data.o I think this is what you were looking for? I am beginning to understand the "reason" why the problem exists. With the little I know about it, seems the only "fix" is a redesign of the theme system to not encapsulate all resources in a single blob? Is that correct?
On 1/11/23 07:37, Andrew Randrianasulu wrote:
ср, 11 янв. 2023 г., 13:30 Andrew Randrianasulu <[email protected]>:
can you check if something like attached patch fixes it for you?
i hope it was only o file with missing GNU.stack note, old linkers may dislike this and also it seems clang linker (lld) default on termux does this by default ....
re -- patch -LDFLAGS1 = -Wl,-export-dynamic -g +LDFLAGS1 = -Wl,-export-dynamic -g -Wl,-z,noexecstack Are you sure you want to do this? Is is portable? Might an alternate solution have merit? ie scanning the blob resources and saving their hex data as static arrays and then compiling and linking the resulting .o files, which presumable only contain .data segments? Increases build time and complexity but seems more portable.
чт, 12 янв. 2023 г., 06:21 Rob Prowel <[email protected]>:
On 1/11/23 07:37, Andrew Randrianasulu wrote:
ср, 11 янв. 2023 г., 13:30 Andrew Randrianasulu <[email protected] :
can you check if something like attached patch fixes it for you?
i hope it was only o file with missing GNU.stack note, old linkers may dislike this and also it seems clang linker (lld) default on termux does this by default ....
re -- patch
-LDFLAGS1 = -Wl,-export-dynamic -g +LDFLAGS1 = -Wl,-export-dynamic -g -Wl,-z,noexecstack
Are you sure you want to do this? Is is portable?
I'll try to check on few systems where cingg builds - FreeBSD, NetBSD, various linux from ubuntu to Rosa to Slackware (we do not build on Irix, Solaris, HP-UX .... And cygwin probably uses gnu binutils?) I asked more if patch was working for you in this case ...even if it turned to be unportable we can selectively apply it....
Might an alternate solution have merit? ie scanning the blob resources and saving their hex data as static arrays and then compiling and linking the resulting .o files, which presumable only contain .data segments? Increases build time and complexity but seems more portable.
thanks for idea .... I think pngtoh tool in guicast tries to do that. (turns png into data arrays inside header)
this one чт, 12 янв. 2023 г., 06:58 Andrew Randrianasulu <[email protected]>:
чт, 12 янв. 2023 г., 06:21 Rob Prowel <[email protected]>:
On 1/11/23 07:37, Andrew Randrianasulu wrote:
ср, 11 янв. 2023 г., 13:30 Andrew Randrianasulu < [email protected]>:
can you check if something like attached patch fixes it for you?
i hope it was only o file with missing GNU.stack note, old linkers may dislike this and also it seems clang linker (lld) default on termux does this by default ....
re -- patch
-LDFLAGS1 = -Wl,-export-dynamic -g +LDFLAGS1 = -Wl,-export-dynamic -g -Wl,-z,noexecstack
Are you sure you want to do this? Is is portable?
I'll try to check on few systems where cingg builds - FreeBSD, NetBSD, various linux from ubuntu to Rosa to Slackware (we do not build on Irix, Solaris, HP-UX .... And cygwin probably uses gnu binutils?)
I asked more if patch was working for you in this case ...even if it turned to be unportable we can selectively apply it....
Might an alternate solution have merit? ie scanning the blob resources and saving their hex data as static arrays and then compiling and linking the resulting .o files, which presumable only contain .data segments? Increases build time and complexity but seems more portable.
thanks for idea .... I think pngtoh tool in guicast tries to do that. (turns png into data arrays inside header)
пт, 27 янв. 2023 г., 02:49 Andrew Randrianasulu <[email protected]>:
this one
чт, 12 янв. 2023 г., 06:58 Andrew Randrianasulu <[email protected]>:
чт, 12 янв. 2023 г., 06:21 Rob Prowel <[email protected]>:
On 1/11/23 07:37, Andrew Randrianasulu wrote:
ср, 11 янв. 2023 г., 13:30 Andrew Randrianasulu < [email protected]>:
can you check if something like attached patch fixes it for you?
i hope it was only o file with missing GNU.stack note, old linkers may dislike this and also it seems clang linker (lld) default on termux does this by default ....
re -- patch
-LDFLAGS1 = -Wl,-export-dynamic -g +LDFLAGS1 = -Wl,-export-dynamic -g -Wl,-z,noexecstack
Are you sure you want to do this? Is is portable?
I'll try to check on few systems where cingg builds - FreeBSD, NetBSD, various linux from ubuntu to Rosa to Slackware (we do not build on Irix, Solaris, HP-UX .... And cygwin probably uses gnu binutils?)
I asked more if patch was working for you in this case ...even if it turned to be unportable we can selectively apply it....
Might an alternate solution have merit? ie scanning the blob resources and saving their hex data as static arrays and then compiling and linking the resulting .o files, which presumable only contain .data segments? Increases build time and complexity but seems more portable.
thanks for idea .... I think pngtoh tool in guicast tries to do that. (turns png into data arrays inside header)
Rob, Andrew: Although I was able to build with Andrew's patch and loaded/played a video with audio file, I am quite concerned that there will be fallout from this patch. I will need to do a lot more tests of many various aspects to make sure there is no impact and that will take me some time. But very willing to start tomorrow as I have always want to Quality Control test suite and this would be a good opportunity to create one. As usual I might not succeed in doing so due to interruptions. The good news is that this may just have been written that way in the cinelerra/Makefile without any real thought put into options once it was working! Stay tuned. On Thu, Jan 26, 2023 at 4:50 PM Andrew Randrianasulu < [email protected]> wrote:
пт, 27 янв. 2023 г., 02:49 Andrew Randrianasulu <[email protected]>:
this one
чт, 12 янв. 2023 г., 06:58 Andrew Randrianasulu <[email protected]
:
чт, 12 янв. 2023 г., 06:21 Rob Prowel <[email protected]>:
On 1/11/23 07:37, Andrew Randrianasulu wrote:
ср, 11 янв. 2023 г., 13:30 Andrew Randrianasulu < [email protected]>:
can you check if something like attached patch fixes it for you?
i hope it was only o file with missing GNU.stack note, old linkers may dislike this and also it seems clang linker (lld) default on termux does this by default ....
re -- patch
-LDFLAGS1 = -Wl,-export-dynamic -g +LDFLAGS1 = -Wl,-export-dynamic -g -Wl,-z,noexecstack
Are you sure you want to do this? Is is portable?
I'll try to check on few systems where cingg builds - FreeBSD, NetBSD, various linux from ubuntu to Rosa to Slackware (we do not build on Irix, Solaris, HP-UX .... And cygwin probably uses gnu binutils?)
I asked more if patch was working for you in this case ...even if it turned to be unportable we can selectively apply it....
Might an alternate solution have merit? ie scanning the blob resources and saving their hex data as static arrays and then compiling and linking the resulting .o files, which presumable only contain .data segments? Increases build time and complexity but seems more portable.
thanks for idea .... I think pngtoh tool in guicast tries to do that. (turns png into data arrays inside header)
On 1/26/23 20:42, Phyllis Smith via Cin wrote:
Rob, Andrew: Although I was able to build with Andrew's patch and loaded/played a video with audio file, I am quite concerned that there will be fallout from this patch. I will need to do a lot more tests of many various aspects to make sure there is no impact and that will take me some time. But very willing to start tomorrow as I have always want to Quality Control test suite and this would be a good opportunity to create one. As usual I might not succeed in doing so due to interruptions.
The good news is that this may just have been written that way in the cinelerra/Makefile without any real thought put into options once it was working! Stay tuned.
I'm not really in a spot to test a patch anyhow right now, since the cin-gg build process is a bit problematic for me. I have several problems that stem from what is possibly a single issue: the inclusion of many third-party libraries instead of leveraging the existing packages on most folks distos, thru pkg-config. Intelligent "build only what has changed" seems broken for me. So I end up having to reset to dist-clean and rebuild everything when I attempt to make even a minor change. Often the "make clean" doesn't remove all artifacts and I end up having to copy from a fresh git pull and then reconfigure and subsequently rebuild all third-party stuff too. I tried using the configure option to use local native libs but that goes way down the rabbit hole. When I get time maybe I'll play with it again but for now the executable stack issue is more an FYI than an action item. Besides it is very sporatic. Does not always pop up when I run cin-gg. But Andrews explanation of why it happens makes sense. FWIW, I believe there are generic tools available to package project resources in a way that don't cause the displayed behaviour but that's more a feature change. I use such under Qt framework frequently. Thanks Rob
пт, 27 янв. 2023 г., 16:39 Rob Prowel <[email protected]>:
On 1/26/23 20:42, Phyllis Smith via Cin wrote:
Rob, Andrew: Although I was able to build with Andrew's patch and loaded/played a video with audio file, I am quite concerned that there will be fallout from this patch. I will need to do a lot more tests of many various aspects to make sure there is no impact and that will take me some time. But very willing to start tomorrow as I have always want to Quality Control test suite and this would be a good opportunity to create one. As usual I might not succeed in doing so due to interruptions.
The good news is that this may just have been written that way in the cinelerra/Makefile without any real thought put into options once it was working! Stay tuned.
I'm not really in a spot to test a patch anyhow right now, since the cin-gg build process is a bit problematic for me. I have several problems that stem from what is possibly a single issue: the inclusion of many third-party libraries instead of leveraging the existing packages on most folks distos, thru pkg-config. Intelligent "build only what has changed" seems broken for me.
yeah, *.h files not included in makefiles .... :/ So I end up having to reset to
dist-clean and rebuild everything when I attempt to make even a minor change. Often the "make clean" doesn't remove all artifacts and I end up having to copy from a fresh git pull and then reconfigure and subsequently rebuild all third-party stuff too.
I tried using the configure option to use local native libs but that goes way down the rabbit hole.
I think relatively simple "--without-thirdparty --without-libdpx" (if you do not have this) should be enough .... I also disable lv2 and enable single-user build, but this is just me ....
When I get time maybe I'll play with it again but for now the executable stack issue is more an FYI than an action item. Besides it is very sporatic. Does not always pop up when I run cin-gg.
But Andrews explanation of why it happens makes sense. FWIW, I believe there are generic tools available to package project resources in a way that don't cause the displayed behaviour but that's more a feature change. I use such under Qt framework frequently.
Thanks Rob
In testing the 0001-noexecstack...patch, dmesg did not have the following message anymore: process '/cinelerra-5.1-build/bin/cin' started with executable stack But now I have the message: asus 0003:0B05:1837.0004: Unmapped Asus vendor usagepage code 0xec Soooooo, I just do not know if this patch is a good solution or will create unknown problems. Without more knowledge, it is probably best to leave it out for now unless someone knows for sure that it is a better idea. On Thu, Jan 26, 2023 at 4:50 PM Andrew Randrianasulu < [email protected]> wrote:
пт, 27 янв. 2023 г., 02:49 Andrew Randrianasulu <[email protected]>:
this one
чт, 12 янв. 2023 г., 06:58 Andrew Randrianasulu <[email protected]
:
чт, 12 янв. 2023 г., 06:21 Rob Prowel <[email protected]>:
On 1/11/23 07:37, Andrew Randrianasulu wrote:
ср, 11 янв. 2023 г., 13:30 Andrew Randrianasulu < [email protected]>:
can you check if something like attached patch fixes it for you?
i hope it was only o file with missing GNU.stack note, old linkers may dislike this and also it seems clang linker (lld) default on termux does this by default ....
re -- patch
-LDFLAGS1 = -Wl,-export-dynamic -g +LDFLAGS1 = -Wl,-export-dynamic -g -Wl,-z,noexecstack
Are you sure you want to do this? Is is portable?
I'll try to check on few systems where cingg builds - FreeBSD, NetBSD, various linux from ubuntu to Rosa to Slackware (we do not build on Irix, Solaris, HP-UX .... And cygwin probably uses gnu binutils?)
I asked more if patch was working for you in this case ...even if it turned to be unportable we can selectively apply it....
Might an alternate solution have merit? ie scanning the blob resources and saving their hex data as static arrays and then compiling and linking the resulting .o files, which presumable only contain .data segments? Increases build time and complexity but seems more portable.
thanks for idea .... I think pngtoh tool in guicast tries to do that. (turns png into data arrays inside header)
пт, 3 февр. 2023 г., 02:46 Phyllis Smith <[email protected]>:
In testing the 0001-noexecstack...patch, dmesg did not have the following message anymore: process '/cinelerra-5.1-build/bin/cin' started with executable stack But now I have the message: asus 0003:0B05:1837.0004: Unmapped Asus vendor usagepage code 0xec
I tried web-search and this specific message seems to be related to fancy keyboard? https://gitlab.com/asus-linux/asusctl/-/issues/43 so may be it was unrelated to my patch ...
Soooooo, I just do not know if this patch is a good solution or will create unknown problems. Without more knowledge, it is probably best to leave it out for now unless someone knows for sure that it is a better idea.
On Thu, Jan 26, 2023 at 4:50 PM Andrew Randrianasulu < [email protected]> wrote:
пт, 27 янв. 2023 г., 02:49 Andrew Randrianasulu <[email protected]
:
this one
чт, 12 янв. 2023 г., 06:58 Andrew Randrianasulu <[email protected]
:
чт, 12 янв. 2023 г., 06:21 Rob Prowel <[email protected]>:
On 1/11/23 07:37, Andrew Randrianasulu wrote:
ср, 11 янв. 2023 г., 13:30 Andrew Randrianasulu < [email protected]>:
can you check if something like attached patch fixes it for you?
i hope it was only o file with missing GNU.stack note, old linkers may dislike this and also it seems clang linker (lld) default on termux does this by default ....
re -- patch
-LDFLAGS1 = -Wl,-export-dynamic -g +LDFLAGS1 = -Wl,-export-dynamic -g -Wl,-z,noexecstack
Are you sure you want to do this? Is is portable?
I'll try to check on few systems where cingg builds - FreeBSD, NetBSD, various linux from ubuntu to Rosa to Slackware (we do not build on Irix, Solaris, HP-UX .... And cygwin probably uses gnu binutils?)
I asked more if patch was working for you in this case ...even if it turned to be unportable we can selectively apply it....
Might an alternate solution have merit? ie scanning the blob resources and saving their hex data as static arrays and then compiling and linking the resulting .o files, which presumable only contain .data segments? Increases build time and complexity but seems more portable.
thanks for idea .... I think pngtoh tool in guicast tries to do that. (turns png into data arrays inside header)
participants (3)
-
Andrew Randrianasulu -
Phyllis Smith -
Rob Prowel