Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fis-gtm does not run due to missing support for executable stack #286

Closed
shabiel opened this issue Apr 28, 2016 · 56 comments
Labels

Comments

@shabiel
Copy link

@shabiel shabiel commented Apr 28, 2016

This is what I see.

samha@DESKTOP-9LM60MK:/usr/lib/fis-gtm/V6.0-003_x86_64$ ./mumps _date.m
%GTM-E-DLLNOOPEN, Failed to load external dynamic library ./libgtmshr.so
%GTM-E-TEXT, ./libgtmshr.so: cannot enable executable stack as shared object requires: Invalid argument

It seems that dlopen fails.

Here's what strace says:
samha@DESKTOP-9LM60MK:/usr/lib/fis-gtm/V6.0-003_x86_64$ strace ./mumps _date.m
strace: Test for PTRACE_O_TRACESYSGOOD failed, giving up using this feature.
execve("./mumps", ["./mumps", "_date.m"], [/* 17 vars */]) = 0
brk(0) = 0x603000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff5ffee0000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=22386, ...}) = 0
mmap(NULL, 22386, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff5ffff9000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\16\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14664, ...}) = 0
mmap(NULL, 2109744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff5ff9f0000
mprotect(0x7ff5ff9f3000, 2093056, PROT_NONE) = 0
mmap(0x7ff5ffbf2000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7ff5ffbf2000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1840928, ...}) = 0
mmap(NULL, 3949248, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff5ff620000
mprotect(0x7ff5ff7db000, 2093056, PROT_NONE) = 0
mmap(0x7ff5ff9da000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ba000) = 0x7ff5ff9da000
mmap(0x7ff5ff9e0000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff5ff9e0000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff5ffed0000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff5ffec0000
arch_prctl(ARCH_SET_FS, 0x7ff5ffec0740) = 0
mprotect(0x7ff5ff9da000, 16384, PROT_READ) = 0
mprotect(0x7ff5ffbf2000, 4096, PROT_READ) = 0
mprotect(0x601000, 4096, PROT_READ) = 0
mprotect(0x7ff5ffe22000, 4096, PROT_READ) = 0
munmap(0x7ff5ffff9000, 22386) = 0
brk(0) = 0x603000
brk(0x624000) = 0x624000
open("./libgtmshr.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\362\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0664, st_size=2239248, ...}) = 0
getcwd("/usr/lib/fis-gtm/V6.0-003_x86_64", 128) = 33
mmap(NULL, 4522072, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff5ff1c0000
mprotect(0x7ff5ff3d2000, 2093056, PROT_NONE) = 0
mmap(0x7ff5ff5d1000, 73728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x211000) = 0x7ff5ff5d1000
mmap(0x7ff5ff5e3000, 184408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff5ff5e3000
mprotect(0x7ff5ffe22000, 3668, PROT_READ|PROT_WRITE) = 0
mprotect(0x7ff5ffe22000, 3668, PROT_READ) = 0
mprotect(0x7ff5fffef000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)
close(3) = 0
write(2, "%GTM-E-DLLNOOPEN, Failed to load"..., 73%GTM-E-DLLNOOPEN, Failed to load external dynamic library ./libgtmshr.so
) = 73
write(2, "%GTM-E-TEXT, ./libgtmshr.so: can"..., 104%GTM-E-TEXT, ./libgtmshr.so: cannot enable executable stack as shared object requires: Invalid argument
) = 104
exit_group(150379250) = ?
<... exit_group resumed> _exit returned!
) = ?
+++ exited with 242 +++

@shabiel

This comment has been minimized.

Copy link
Author

@shabiel shabiel commented May 14, 2016

I just upgraded to Build 14342. Same errors.

@stehufntdev

This comment has been minimized.

Copy link
Collaborator

@stehufntdev stehufntdev commented May 17, 2016

Thanks for reporting the issue. The "cannot enable executable stack as shared object requires: Invalid argument" is coming from the loader because of this failure:

mprotect(0x7ff5fffef000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)

WSL does not currently have support for the PROT_GROWSDOWN flag. In some cases, the executable stack flag isn't needed so you might want to create a backup of the original binary and run execstack -c libgtmshr.so to manually clear the executable stack flag in the binary.

Please give us feedback for this scenario on the uservoice so we can prioritize.

@stehufntdev stehufntdev added the feature label May 17, 2016
@shabiel

This comment has been minimized.

Copy link
Author

@shabiel shabiel commented May 17, 2016

I actually know the source code of this application to some extent as I am
involved in porting it to other platforms. It NEEDS an executable stack.
Having said that, I will try your suggestion and see what happens.

On Tue, May 17, 2016 at 7:25 AM, stehufntdev notifications@github.com
wrote:

Thanks for reporting the issue. The "cannot enable executable stack as
shared object requires: Invalid argument" is coming from the loader because
of this failure:

mprotect(0x7ff5fffef000, 4096,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid
argument)

WSL does not currently have support for the PROT_GROWSDOWN flag. In some
cases, the executable stack flag isn't needed so you might want to create a
backup of the original binary and run execstack -c libgtmshr.so to
manually clear the executable stack flag in the binary.

Please give us feedback for this scenario on the uservoice
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo
so we can prioritize.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#286 (comment)

Sam Habiel, Pharm.D.
VISTA Expertise Network

@ksbhaskar

This comment has been minimized.

Copy link

@ksbhaskar ksbhaskar commented May 18, 2016

Sam, as a possible workaround until the issue is fixed in WSL, see whether not specifying auto-relink in $gtmroutines / $zroutines gets you past this.

@shabiel

This comment has been minimized.

Copy link
Author

@shabiel shabiel commented May 19, 2016

I tried this and it worked. Now it complains that semget isn't there, which
I know.

On Wed, May 18, 2016 at 6:51 AM, K.S. Bhaskar notifications@github.com
wrote:

Sam, as a possible workaround until the issue is fixed in WSL, see whether
not specifying auto-relink in $gtmroutines / $zroutines gets you past this.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#286 (comment)

Sam Habiel, Pharm.D.
VISTA Expertise Network

@shabiel

This comment has been minimized.

Copy link
Author

@shabiel shabiel commented May 19, 2016

Before I forget, let me say thank you for your help. I can buy you a beer
if you live in Seattle.

I put this on uservoice. Alas, I am the only one who wants that feature!

The next issue is shared memory/semaphores. I contributed my votes to that
on uservoice.

On Wed, May 18, 2016 at 10:12 PM, Sam Habiel sam.habiel@gmail.com wrote:

I tried this and it worked. Now it complains that semget isn't there,
which I know.

On Wed, May 18, 2016 at 6:51 AM, K.S. Bhaskar notifications@github.com
wrote:

Sam, as a possible workaround until the issue is fixed in WSL, see
whether not specifying auto-relink in $gtmroutines / $zroutines gets you
past this.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#286 (comment)

Sam Habiel, Pharm.D.
VISTA Expertise Network

Sam Habiel, Pharm.D.
VISTA Expertise Network

@JMoVS

This comment has been minimized.

Copy link

@JMoVS JMoVS commented Aug 16, 2016

I am currently trying out a lot of packages and thing with linuxbrew on lxss and am runnig into the "cannot enable executable stack as shared object requires: invalid argument" problem quite often (one occurence for reference: Homebrew/linuxbrew-core#765). Is that something that is going to be implemented?

@andresau

This comment has been minimized.

Copy link

@andresau andresau commented Aug 24, 2016

This also happens to me trying to run this example: http://docs.opencv.org/master/db/df5/tutorial_linux_gcc_cmake.html using OpenCV 3.1

$ ./DisplayImage lena.jpg
./DisplayImage: error while loading shared libraries: libopencv_core.so.3.1: cannot enable executable stack as shared object requires: Invalid argument
@Adnino

This comment has been minimized.

Copy link

@Adnino Adnino commented Aug 28, 2016

Hi @andresau ,
I am having the same error when trying to import cv2 in Bash on windows. Did you find a solution ?

@abodyai

This comment has been minimized.

Copy link

@abodyai abodyai commented Aug 30, 2016

Hi @andresau ,
I am having the same error when trying to import cv2 in Bash on windows. Did you find a solution ?

I'm having the same issue when trying to compile OpenCV with Bash On Windows. Please fix this soon. Thanks.

@burstingninja

This comment has been minimized.

Copy link

@burstingninja burstingninja commented Sep 6, 2016

Hi there you need to install execstack
and run this command
execstack -c /usr/local/lib/opencv.so*

here is the source
http://stackoverflow.com/questions/39136040/python3-4-error-cannot-enable-executable-stack-as-shared-object-requires-inva

@ejoebstl

This comment has been minimized.

Copy link

@ejoebstl ejoebstl commented Sep 19, 2016

Make sure to catch all opencv libraries:

sudo execstack -q /usr/local/lib/*opencv*.so*

@yamsergey

This comment has been minimized.

Copy link

@yamsergey yamsergey commented Nov 2, 2016

Similar problem for Apple Swift:
swift-build: error while loading shared libraries: libFoundation.so: cannot enable executable stack as shared object requires: Invalid argument

@andresau

This comment has been minimized.

Copy link

@andresau andresau commented Nov 7, 2016

Hi @andresau ,
I am having the same error when trying to import cv2 in Bash on windows. Did you find a solution ?

Hello @Adnino,
No solutions so far, I had to install a VM in order to run it.

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Nov 26, 2016

I just ran into the executable stack issue when trying to get Swift 3.0.1 running under WSL on Windows 14965.

Had to clear the executable stack flag in libFoundation.so ("execstack -c <pathToSwift>/usr/lib/swift/linux/libFoundation.so"), but once I did that helloworld.swift demo ran using "swift helloworld.swift".

@metorm

This comment has been minimized.

Copy link

@metorm metorm commented Nov 28, 2016

I encountered this issue today.

My solution is to #apt install execstack and execstack -s program_to_run

Then the program runs well

@yorickdowne

This comment has been minimized.

Copy link

@yorickdowne yorickdowne commented Dec 24, 2016

Same issue for perl6 / rakudo *, unsurprisingly.

@stehufntdev Do you have a roadmap as to when this feature might be implemented? Is this targeted for the upcoming Creators Update?

@dheine Thank you! That allowed me to build perl6, as well.

  • A brief description

Attempt to install perl6 using rakudobrew as per http://rakudo.org/how-to-get-rakudo/#Installing-Rakudo-Star-Source-Prerequisites-Debian

  • Expected results

moar builds successfully

  • Actual results (with terminal output if applicable)

This fails with an error message on libmoar.so:
"/home/tbehrens/.rakudobrew/moar-nom/install/bin/moar: error while loading shared libraries: libmoar.so: cannot enable executable stack as shared object requires: Invalid argument"

The relevant strace is in moar-strace.txt.21832, and the relevant lines are:

open("//home/tbehrens/.rakudobrew/moar-nom/install/lib/libmoar.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240r\25\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0666, st_size=4883504, ...}) = 0
mmap(NULL, 6843296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa619f70000
mprotect(0x7fa61a345000, 2093056, PROT_NONE) = 0
mmap(0x7fa61a544000, 729088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3d4000) = 0x7fa61a544000
mmap(0x7fa61a5f6000, 2976, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa61a5f6000
mprotect(0x7fffe01a3000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)

I'm assuming the offender is PROT_EXEC, which is not (yet) supported by WSL.

  • Your Windows build number

14986.1001

  • Steps / All commands required to reproduce the error from a brand new installation
sudo apt-get install build-essential git libssl-dev
git clone https://github.com/tadzik/rakudobrew ~/.rakudobrew
echo 'export PATH=~/.rakudobrew/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
rakudobrew build moar

After this failure, it is possible to successfully build moar, and the rest of perl6, by clearing the execstack flag on libmoar.so:

sudo apt-get install execstack
execstack -c ~/.rakudobrew/moar-nom/install/lib/libmoar.so
execstack -c ~/.rakudobrew/moar-nom/nqp/MoarVM/libmoar.so
rakudobrew build moar
rakudobrew build panda
panda install Task::Star
  • Strace of the failing command

moar-strace.zip

@stehufntdev

This comment has been minimized.

Copy link
Collaborator

@stehufntdev stehufntdev commented Jan 3, 2017

No current ETA on PROT_GROWSDOWN support. We've been prioritizing work by scenarios and feedback on uservoice. Please give us feedback for this scenario on the uservoice so we can prioritize - https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/.

@yorickdowne

This comment has been minimized.

Copy link

@yorickdowne yorickdowne commented Jan 4, 2017

Thanks @stehufntdev . Given http://www.xinotes.net/notes/note/1030/ and https://news.ycombinator.com/item?id=11599909 , I am leaning towards "executable stack support is not critical".

The GNU assembler has a quirk: If you don't tell it .section .note.GNU-stack,"",@progbits in manually written ASM code (.S files), then it will assume execstack. Oops, what a trap for programmers.
Ulrich Drepper asserts that "Executable stack memory is one of the biggest security problems."

fis-gtm actually needs executable stack memory and so it's in a bit of a bind.

But Perl6 does not. The library that requests it, dyncall, is running into that GNU ASM quirk. This can (and I am hopeful it will) be solved by the dyncall devs upstream to rakudo Star, and then MoarVM/Perl6/Rakudo will build without issue.

Apple Swift is likely a similar situation: Requests execstack but doesn't need it. @dheine , if you'd like to collaborate with me on that, I'm game.

So for my particular itch, I'm good. No WSL changes needed.

@andrewfinnell

This comment has been minimized.

Copy link

@andrewfinnell andrewfinnell commented Jan 22, 2018

@FelipeMartin Solution to what? Which package do you want to use?
You can clear the execstack bit, "execstack -c", on the offending bit of code (often a library), and that will allow it to run on WSL.
Executable stack is a seriously bad idea, and in all cases we've looked into so far, it being requested was an artifact of the GNU tool chain defaulting to it for assembly files, not a case of the code actually needing executable stack.

I'm confused as to the meaning of this comment. Does this mean WSL is NOT looking to support this feature as they deem it a 'bad idea'? Or does it mean that, while we think it's a bad idea, it's on the roadmap as many toolchains require it's support. e.g. certbot.. and all the other ones people have mentioned. Apparently even azure's cli was failing, which is ironic considering...

@yorickdowne

This comment has been minimized.

Copy link

@yorickdowne yorickdowne commented Jan 22, 2018

@andrew-finnell That comment is my opinion as a user of WSL. I'm not employed by MS and whatever I'm saying has no bearing on the direction WSL is taking.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

@therealkenc therealkenc commented Jan 22, 2018

I'm confused as to the meaning of this comment. Does this mean WSL is NOT looking to support this feature as they deem it a 'bad idea'?

I asked that three months ago but got no response. But the public statement from MSFT wasn't actually confusing:

If you see "cannot enable executable stack" errors - please contact the owner of the affected component and ask them (politely, of course) to please double-check that they've not accidentally enabled stack-execution. Or if they've enabled it deliberately, please ask them to consider disabling stack execution, and using an alternative approach.

That position might be Right™ or Wrong™ depending on one's disposition, but not confusing. What I have been wondering, idly, is whether it is technically feasible, or whether it is just plain difficult to implement given the practical constraints they have to work with and competing priorities. I don't know the answer to that. But whether it is on the "roadmap" has been asked and answered (until someone says otherwise).

Anyway, like some dude on the Internet said:

Because in the end, those users really do matter. Without those users,
your system may be "secure", but all your security work was still just
masturbation. You didn't do anything useful at all in the end.

Which is to say, meh, you can always run Docker if WSL does not meet your requirements (certbot or otherwise). [In the context I personally take no position on a rehash of a 20 year old debate over whether "executable stack is a seriously bad idea", or not, because it was boooring 20 years ago and it is still boooring today.]

I'm not employed by MS and whatever I'm saying has no bearing on the direction WSL is taking.

What he said.⬆️

@FelipeMartin

This comment has been minimized.

Copy link

@FelipeMartin FelipeMartin commented Jan 22, 2018

For me this is an old thread and I have no intention to extend this discussion (seriously !) but when I came here my thought was: "If this is possible in Linux, so maybe Microsoft will release it soon".
I wasn't questioning if this is right or wrong, bad or good idea.
And I see no reason to emphasize that it was a request of a homework or a real demand of an important project.
The reason I think most of people came here was to find a solution, not a sermon (no offense).
If you emulate a system, is natural to see people trying to do the same things they could in the real one.
That being said, let's move on guys.

@tiagogl

This comment has been minimized.

Copy link

@tiagogl tiagogl commented Feb 5, 2018

Configuring the installer for this system's environment...

Launching installer...

failed to open </tmp/install.dir.30/Linux/resource/jre/jre/lib/amd64/default/libjvm.so> - reason: </tmp/install.dir.30/Linux/resource/jre/jre/lib/amd64/default/libjvm.so: cannot enable executable stack as shared object requires: Invalid argument>
Failed to find VM - aborting

I installed JVM , JDK and JRE. Tried install using root too. Anyone can help me?

@mrlifetime

This comment has been minimized.

Copy link

@mrlifetime mrlifetime commented Feb 24, 2018

encountering same issue when using our 64-bit build of https:

/opt/bb/lib64/apt/methods/https: error while loading shared libraries: libcrypto.so.1.0.0: cannot enable executable stack as shared object requires: Invalid argument
/opt/bb/lib64/apt/methods/https: error while loading shared libraries: libcrypto.so.1.0.0: cannot enable executable stack as shared object requires: Invalid argument
E: Method https has died unexpectedly!

Let's give this the visibility it needs on uservoice, this is clearly affecting many different apps!
https://wpdev.uservoice.com/forums/266908-command-prompt-console-windows-subsystem-for-l/suggestions/13904454-mprotect-prot-growsdown-support

PS: #286 (comment) workaround does seem to work in my case though!

@yorickdowne

This comment has been minimized.

Copy link

@yorickdowne yorickdowne commented Feb 24, 2018

@mrlifetime , that means this issue is upstream, in the libcrypto library, not in WSL. Likely, libcrypto has asm code and relies on standard GCC behavior, which flags for executable stack even when it's not needed.
If you'd like to point me to the repository / community for this project, I'm happy to help you fix that permanently. The includes necessary to do so have been thoroughly vetted by now.

@mrlifetime

This comment has been minimized.

Copy link

@mrlifetime mrlifetime commented Feb 24, 2018

@yorickdowne Unfortunately, I can't provide access to this repo as it is not public but if you could please point me to either some docs or ref material that can help fix this, I would be more than happy to pass this on to responsible devs! I am suspecting this wasn't compiled properly and/or the code for libcrypto we are using is perhaps a bit old and needs updating.

@yorickdowne

This comment has been minimized.

Copy link

@yorickdowne yorickdowne commented Feb 24, 2018

Sure thing! Here's a snippet on how dyncall handles it. In their case, this goes into a .S file, but you could also have a #define in a .h and then the .S just calls that #define. I like that better because it means changes to the method have to be made in only one section. What they're testing against here, the DC__ are custom defines, which you can look up at http://hg.dyncall.org/pub/dyncall/dyncall/file/03f0b683918a/dyncall/dyncall_macros.h

 /* Use .note.GNU-stack to explicitly indicate a non-exec stack, b/c of bad   */
 /* default behaviour when translating handwritten assembly files (needed on  */
 /* GNU/* platforms, Android and FreeBSD, as tests have shown).               */
 #if (defined(DC__C_CLANG) || defined(DC__C_GNU)) && defined(__ELF__) && (defined(DC__OS_Linux) || defined(DC__OS_FreeBSD))
 .section .note.GNU-stack,"",%progbits
 #endif

Here's how Apple's Swift handles it. They define in a .h and then call NO_EXEC_STACK_DIRECTIVE at the end of every .S. Note they're testing differently than dyncall on whether they need this. dyncall lives on more platforms, consider their tests to be the more portable version.

#if defined(__GNU__) || defined(__GNUC__) || defined(__ANDROID__) || defined(__FreeBSD__)
#define NO_EXEC_STACK_DIRECTIVE .section .note.GNU-stack,"",%progbits
#else
#define NO_EXEC_STACK_DIRECTIVE

In my mind, the best approach would be to use dyncall's tests and Apple's "define in a .h, then reference at the end of every .S" approach. That way, it's highly portable, and if you ever need to change the tests, you only need to do so in one location.

@yorickdowne

This comment has been minimized.

Copy link

@yorickdowne yorickdowne commented Jun 9, 2018

dyncall 1.0 has been released 2018-04-23 and contains code to avoid setting execstack. I've updated MoarVM/MoarVM#470. There are other issues with dyncall on MoarVM, hopefully we'll see dyncall 1.0 pulled in MoreSoonerish(tm). perl6 on WSL. It'll happen. Eventually, but it'll happen :).

@uecker

This comment has been minimized.

Copy link

@uecker uecker commented Aug 6, 2018

I have a project which started to use nested function. I will probably just tell people not to use WSL. This was a nice way to support windows... but it is probably not worth rewriting everything.

BTW: noexec stack is just pseudo security. It is based on the idea that code is fundamentally something else than data. But it is not! So it is not surprising that even with a non-executable stack you can exploit buffer overruns using return-oriented programming. Misguided people now conclude that return addresses are not really data and need to be protected. They we then learn that it is possible to exploit a program in different ways using buffer runs by exploiting control flow changes which depend on local variables... The only way to fix this is to protect against buffer overruns directly. Everything else is pseudo security.

@ksbhaskar

This comment has been minimized.

Copy link

@ksbhaskar ksbhaskar commented Aug 6, 2018

@shoffmeister

This comment has been minimized.

Copy link

@shoffmeister shoffmeister commented Aug 6, 2018

The only way

In security, there is no "only way".

Security (which is defensive) is all about putting layer on top of layer on top of aspect on top of concern, making it ever more difficult for unauthorized things to happen.

Lack of an executable stack reduces attack surface. That's good.

General reading suggestion would be the ever so technical https://en.wikipedia.org/wiki/Executable_space_protection#Linux

@yorickdowne

This comment has been minimized.

Copy link

@yorickdowne yorickdowne commented Aug 7, 2018

Linus famously maintains that "vulnerabilities are just bugs", and security folk tend to go on about defense in depth. That seems like an intractable debate.

I'll offer this thought to appeal to software engineers who want their stuff to work cross-platform. Requiring an executable stack will break your code on NetBSD and OpenBSD (source: http://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=porting-tools/execstack/README), and in severely hardened SELinux environments (https://www.akkadia.org/drepper/selinux-mem.html).

The same way that I can't come into this thread and credibly tell a software engineer to stop using executable stack, as they may have good reasons and it may fit their deployment case, a software engineer can't tell OS designers or customers to stop using executable stack protection. They may have good reason, such as designing for defense in depth.

The dyncall and libffi libraries allow dynamic callbacks and the like without the need for execstack, that's worth a look.

Ultimately, if you want to use nested functions, go for it. Live with the fact it won't work on NetBSD, OpenBSD, SELinux with memprotect, and WSL. That may be acceptable, those might not be target environments.

For me personally, I'll keep going after the low-hanging fruit: The projects that require execstack only because GNU "as" has quirky behavior. I've updated my recommended code snippet that can be used for any project with .S files that doesn't actually need execstack. It combines the dyncall approach (maximum portability) with the Swift approach (minimal code to add to .S; most everything lives in .h). That's at https://yorickdowne.wordpress.com/2017/01/04/wsl-bash-on-windows-as-a-dev-environment/

@uecker

This comment has been minimized.

Copy link

@uecker uecker commented Aug 7, 2018

The accepted trade-off is to have a non-executable stack be default but have an executable stack for programs which need them. Not supporting this is just a deficiency in WSL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.