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

Open
shabiel opened this Issue Apr 28, 2016 · 51 comments

Comments

Projects
None yet
@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.

Show comment
Hide comment
@shabiel

shabiel May 14, 2016

I just upgraded to Build 14342. Same errors.

shabiel commented May 14, 2016

I just upgraded to Build 14342. Same errors.

@stehufntdev

This comment has been minimized.

Show comment
Hide comment
@stehufntdev

stehufntdev May 17, 2016

Collaborator

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.

Collaborator

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.

Show comment
Hide comment
@shabiel

shabiel 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

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.

Show comment
Hide comment
@ksbhaskar

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

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.

Show comment
Hide comment
@shabiel

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

Show comment
Hide comment
@shabiel

shabiel 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

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.

Show comment
Hide comment
@JMoVS

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

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

@andresau

This comment has been minimized.

Show comment
Hide comment
@andresau

andresau 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

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.

Show comment
Hide comment
@Adnino

Adnino 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 ?

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 ?

@themissingpieces

This comment has been minimized.

Show comment
Hide comment
@themissingpieces

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

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.

Show comment
Hide comment
@burstingninja

burstingninja 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

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.

Show comment
Hide comment
@ejoebstl

ejoebstl Sep 19, 2016

Make sure to catch all opencv libraries:

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

Make sure to catch all opencv libraries:

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

@yamsergey

This comment has been minimized.

Show comment
Hide comment
@yamsergey

yamsergey 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

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.

Show comment
Hide comment
@andresau

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

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.

@sjackman sjackman referenced this issue in Linuxbrew/brew Nov 23, 2016

Closed

node 7.0.0 did not build (WSL) #178

2 of 2 tasks complete
@dheine

This comment has been minimized.

Show comment
Hide comment
@dheine

dheine 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".

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

Show comment
Hide comment
@metorm

metorm 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

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.

Show comment
Hide comment
@yorickdowne

yorickdowne 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

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.

Show comment
Hide comment
@stehufntdev

stehufntdev Jan 3, 2017

Collaborator

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

Collaborator

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.

Show comment
Hide comment
@yorickdowne

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

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

This comment has been minimized.

Show comment
Hide comment
@shabiel

shabiel Jan 4, 2017

shabiel commented Jan 4, 2017

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jan 4, 2017

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

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

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jan 5, 2017

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

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

@dheine

This comment has been minimized.

Show comment
Hide comment
@dheine

dheine Jan 5, 2017

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

dheine commented Jan 5, 2017

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

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jan 5, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@stehufntdev

stehufntdev Jan 5, 2017

Collaborator

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.

Collaborator

stehufntdev commented Jan 5, 2017

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.

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jan 6, 2017

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

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

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jan 11, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@warpdesign

warpdesign Jan 18, 2017

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.

warpdesign commented Jan 18, 2017

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.

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jun 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@FelipeMartin

FelipeMartin Jun 7, 2017

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

FelipeMartin commented Jun 7, 2017

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

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jun 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@FelipeMartin

FelipeMartin Jun 8, 2017

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

FelipeMartin commented Jun 8, 2017

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

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jun 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@KindDragon

KindDragon Jun 16, 2017

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"

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"

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jun 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@KindDragon

KindDragon Jun 16, 2017

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

KindDragon commented Jun 16, 2017

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

@yorickdowne

This comment has been minimized.

Show comment
Hide comment
@yorickdowne

yorickdowne Jun 16, 2017

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

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

@benhillis benhillis changed the title from fis-gtm does not run to fis-gtm does not run due to missing support for executable stack Aug 17, 2017

@shabbir-hasan

This comment has been minimized.

Show comment
Hide comment
@shabbir-hasan

shabbir-hasan Sep 22, 2017

The Command execstack -c isn't working
image
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

shabbir-hasan commented Sep 22, 2017

The Command execstack -c isn't working
image
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

dhermes added a commit to dhermes/bezier that referenced this issue Oct 9, 2017

dhermes added a commit to dhermes/bezier that referenced this issue Oct 13, 2017

@andrewfinnell

This comment has been minimized.

Show comment
Hide comment
@andrewfinnell

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

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.

Show comment
Hide comment
@yorickdowne

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

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

Show comment
Hide comment
@therealkenc

therealkenc Jan 22, 2018

Collaborator

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.⬆️

Collaborator

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.

Show comment
Hide comment
@FelipeMartin

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

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.

Show comment
Hide comment
@tiagogl

tiagogl 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?

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.

Show comment
Hide comment
@mrlifetime

mrlifetime 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!

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.

Show comment
Hide comment
@yorickdowne

yorickdowne 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 , 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.

Show comment
Hide comment
@mrlifetime

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

Show comment
Hide comment
@yorickdowne

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

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.

Show comment
Hide comment
@yorickdowne

yorickdowne 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 :).

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 :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment