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

[shabiel]

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]

I just upgraded to Build 14342. Same errors.

[stehufntdev]

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.

[shabiel]

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 https://github.com/Microsoft/BashOnWindows/issues/286#issuecomment-219734210

Sam Habiel, Pharm.D. VISTA Expertise Network

[ksbhaskar]

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]

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 https://github.com/Microsoft/BashOnWindows/issues/286#issuecomment-220032122

Sam Habiel, Pharm.D. VISTA Expertise Network

[shabiel]

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 https://github.com/Microsoft/BashOnWindows/issues/286#issuecomment-220032122

Sam Habiel, Pharm.D. VISTA Expertise Network

Sam Habiel, Pharm.D. VISTA Expertise Network

[JMoVS]

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: https://github.com/Linuxbrew/homebrew-core/issues/765). Is that something that is going to be implemented?

[andresau]

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]

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

[abodyai]

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]

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]

Make sure to catch all opencv libraries:

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

[yamsergey]

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]

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]

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]

I encountered this issue today.

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

Then the program runs well

[thorsteneb]

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]

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/.

[thorsteneb]

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.

[shabiel]

GT.M does not need an executable stack. I mistakenly thought that; but it turns out it doesn't.

On Wed, Jan 4, 2017 at 9:55 AM, Thorsten Behrens notifications@github.com wrote:

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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[thorsteneb]

@shabiel That's good news! Have a look at https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart . If you have .S files that run into this GNU "as" quirk, simply appending this to the end will solve the problem:

#if defined(__linux__) && defined(__ELF__)
.section .note.GNU-stack,"",%progbits
#endif

This strikes me as a good idea anyway. Marking the stack executable when it does not need to be is a security breach waiting to happen. All it needs is a coding error somewhere to lead to an exploit.

[thorsteneb]

@dheine and @yamsergey , I found the issue with libFoundation.so. Tracking this at https://bugs.swift.org/browse/SR-2700?jql=text%20~%20%22executable%20stack%22 . Hopefully Apple will accept the fix.

[ghost]

@yorickdowne , nice. Thanks for taking this on. And I agree with your earlier comment about executable stacks being a security risk. Can think of very few good reasons for allowing that as an option. We are in a cyber war and we don't want to keep giving the adversaries free weapons and ammunition!

[thorsteneb]

In a way, I'm actually really happy WSL doesn't implement PROT_GROWSDOWN. It can act as a "canary" of sorts to flag projects that really need to be fixed upstream for security reasons.

That could also have happened 3+ years ago with SELinux / Exec Shield, but I get the approach of "we don't want to break the world" and disabling Exec Shield for .so files that request execstack.

Only thing being: I'm one person. As much as I enjoy tilting at windmills, I can only do so much. So if others want to pile in, identify upstream projects that request execstack and should not, then go about contributing fixes to those, that'd be swell.

[stehufntdev]

Good feedback. The executable stack support also scares me :). Luckily we've been able to get other components to update their code (e.g. #302), and most of the time having the executable stack ends up being accidental.

[thorsteneb]

@dheine That was good timing. Apple just accepted the PR, and I was curious when we might see it in a release. Swift 3.1 contributions close January 16th, see https://swift.org/blog/swift-3-1-release-process/ . Swift should work from binary package as soon as 3.1 is out. Fingers crossed.

[thorsteneb]

@themissingpieces Are you familiar with the OpenCV source, or do you know someone who is? I've been playing around with it a bit and it puzzles me. The .so libraries are flagged for execstack, but I don't see any .o files that are, nor system .so that are. I don't currently understand why those OpenCV .so get flagged that way. scanelf finds no component that would cause it and I don't see any options in link.txt that force it, although, for all I know, that's where the culprit lies after all. If it's not object files, it must be linker options, right? The right way to resolve this is to not flag the *.so for execstack. This closes a security hole, it also means it'll work out of the box on SELinux and WSL.

[warpdesign]

I'm getting this error when running the latest Swift snapshot (from January 17) under bash/Ubuntu 16: error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8

I thought the PR of @yorickdowne would fix the problem ?

That's with the latest insider build 15007.

[thorsteneb]

@warpdesign , I believe that's a separate issue. My strace points to PTRACE as the culprit, and there's a fixinbound at https://github.com/Microsoft/BashOnWindows/issues/1692 and an unassigned bug at https://github.com/Microsoft/BashOnWindows/issues/555

For now we'd need to monitor the behavior on Insider builds, and if 1692 alone isn't enough and 555 is needed as well, bug MS devs to assign someone to the 555 bug.

Have you tried building Swift 3.1 from source to see whether you have the same issue?

[FelipeMartin]

No solution yet ? So we can't enable executable stack ?

[thorsteneb]

@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.

[FelipeMartin]

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.

@yorickdowne I had already tried it. It gives me the following error when trying to run it:

$ gcc -Wall -Wa,--execstack -c -o ex3 ex3.c
$ ./ex3
bash: ./ex3: cannot execute binary file: Erro no formato exec

My Windows is Single Language pt_BR: exec format error

[thorsteneb]

@FelipeMartin , we really can't be discussing your homework in a bug thread. Briefly: In my opinion, trying to execute machine code on the stack is inherently unsound. .S files exist, use them. If you are bound and determined to use the technique you have, may I suggest spinning up an Ubuntu inside VirtualBox and running it there. Really, though: Let's drop this discussion in this forum. This is not a thread for discussing homework assignments, or for learning how to code. StackExchange is better suited for those kind of discussions.

[FelipeMartin]

@yorickdowne I see your point. But I don't know if people will be able to help better in stackoverflow than here. Anyway, yes, my option is to use a VM to do it. I have already it installed but I am not using it since I have heard about Bash on Windows. --execstack was suggested by the question. I would be glad to use another one like you said mmap or mprotect. But by now, I have to uderstand it to know how to replace it.

[KindDragon]

Please everyone vote for this issue https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13904454-mprotect-prot-growsdown-support

[thorsteneb]

@KindDragon According to @shabiel, GT.M does not need executable stack support. Do you know otherwise? It is better not to ask for execstack in the first place, from a security perspective if nothing else. Implementing prot_growsdown strikes me as controversial at best and potentially even unwise, particularly when these issues can be resolved upstream by changing how .S files are built. This discussion here kicked off some in depth investigation into how to do that in a portable manner. The dyncall code is a good reference to that implementation and I can look for the detailed test results.

I think you working with the GT.M devs so it doesn't request execstack any more is the best way to go.

[KindDragon]

I don't know about GT.M, my issue was with OpenCV and OpenCL that also return error "cannot enable executable stack as shared object requires: Invalid argument"

[thorsteneb]

@KindDragon I looked into OpenCL briefly and couldn't figure out where and why it asks for executable stack. None of the .o files seem to have it, so it must be requested during link? If you clear it from the offending .so file with execstack -c, does it then work? If you have experience with OpenCL, I'd be happy to work with you and the upstream devs to figure this out. I don't know OpenCL but I'm getting familiar, bit by bit, with libraries that flag RWX when all they need is RW-, thanks to oddities of the GNU tool chain. With a bit of luck, OpenCL does not actually require an executable stack.

[KindDragon]

If you clear it from the offending .so file with execstack -c, does it then work?

Yes, but I spend half of my day to figure this out

If you have experience with OpenCL, I'd be happy to work with you and the upstream devs to figure this out.

I'm only using libOpenCL.so.1 from NVidia

[thorsteneb]

Great news to hear it works when clearing the flag. That means that it doesn't require an executable stack, and you have a workaround.

For situations like this, I feel strongly that implementing PROT_GROWSDOWN would be the wrong way to go. Requesting execstack is a security risk, and WSL can act as the "canary" to alert us, as a community, to code that really needs to be fixed upstream.

I'm only using libOpenCL.so.1 from NVidia

Chances are high that NVidia has .S or .s (assembly) files in their source, and because of the way GNU tools work on Linux, they end up with an execstack flag where they didn't want one. The fix is trivial, just a bit of an #ifdef and #define to insert a section instructing the GNU tool to not set that flag.

I've created a thread over on the NVidia side offering my assistance. https://devtalk.nvidia.com/default/topic/1014466/cuda-setup-and-installation/libopencl-so-1-fails-out-of-the-box-on-ubuntu-on-windows-wsl-/

[shabbir-hasan]

The Command execstack -c isn't working Please, If Anybody can just tell me what does that error "section file offsets not monotonically increasing" mean?? And how i should try to fix it

[andrewfinnell]

@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...

[thorsteneb]

@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]

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]

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]

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]

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: https://github.com/Microsoft/WSL/issues/286#issuecomment-219734210 workaround does seem to work in my case though!

[thorsteneb]

@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]

@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.

[thorsteneb]

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.