WSL “Bash on Windows” as a dev environment

Edit 2019-05-10: This post references WSL 1. I’m getting hyped for WSL 2, and won’t be pushing to make things like Swift work in WSL 1.

I don’t aim to introduce WSL, or do more than link to installation steps.

I do want to take a quick note of tweaks that have been helpful to me in making WSL more useful as a development environment. This assumes the Ubuntu 18.04 distribution.

• Friendlier colors:
  • Edit .bashrc and add to the bottom:

  • LS_COLORS=$LS_COLORS:'di=1;44:' ; export LS_COLORS

  • Edit .vimrc and add:

  • :set background=dark

  • Optional, not entirely certain about this yet: Right-click the bash icon at the upper left of the bash window, choose Defaults, set “Screen Background” to “Black” (0,0,0) and “Screen Text” to “White” (255,255,255)
• /mnt/* is not a build environment. If you try to compile something you downloaded in Windows from its /mnt/c or /mnt/* location, copy it over to ~/ or /var/tmp first. /mnt/* is not as “Linux-y” a file system as the Ubuntu environment is, and it might (likely: will) trip up your source builds.
• Coding in perl 5: Works out of the box.
• Coding in perl 6: Required dyncall changes are in. This should work if building MoarVM from source.
• Coding in Swift: Required changes for execstack are in; swift REPL still fails as of Windows Insider build 18894
• Coding with a host of other libraries that refuse to link because of execstack: Clearing the executable stack flag on the library will work if the library doesn’t require an executable stack to function.To do so, install scanelf and execstack

  sudo apt install pax-utils
  sudo apt install execstack

  Then look for a library that requests executable stack using “scanelf -lpqe”. You’re looking for .so files with “RWX”.

  yorick@Meep:~$ scanelf -lpqe
  RWX --- --- /lib/klibc-wBFLvVtxy4xJqEadIBJMa78iJz8.so

  And clear the execstack on that library, hoping that it didn’t actually need it.

  execstack -c /path/to/lib.so

  Upstream changes would be best, however, so things start working “out of the box”. Usually the root cause for a library setting the execstack flag is that assembly files are missing a short section to declare the stack not executable. See the Gentoo wiki entry on this. Linux and FreeBSD are really the environments where one needs to care about this.

  My recommendation is to combine the approaches taken by Swift and dyncall for maximum readability and portability.

  Place some code into an include file “.h” that is included at the top of every assembly file “.S”. NB, this needs to be .S not .s, as a preprocessor is required in order to parse the include file.

   /* 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(__GNUC__) || defined (__llvm__) || defined (__clang__)) && defined(__ELF__) && (defined (__linux__) || defined (__linux) || defined (__gnu_linux__) || defined(__FreeBSD__) || defined (__FreeBSD_kernel__))
  #define NO_EXEC_STACK_DIRECTIVE .section .note.GNU-stack,"",%progbits
  #elsif defined(__SUNPRO_C) && defined(__linux__)
  #define NO_EXEC_STACK_DIRECTIVE .section ".note.GNU-stack"
  #else
  #define NO_EXEC_STACK_DIRECTIVE
  #endif

  Then, at the end of every “.S” file, place a single line calling this:

  NO_EXEC_STACK_DIRECTIVE

  That code is portable using GNU “as” across architectures, and should work with SUNPro Tools aka Oracle Developer Studio.

  Extensive testing on execstack portability has been done by Bruno Haible of the dyncall team. Their results show that NetBSD and OpenBSD will terminate your program if execstack is set. So will SELinux if used with execstack protection.

  The dyncall and libffi libraries implement dynamic callback without requiring execstack, they are good choices when a program needs that functionality.

  Linus famously maintains that “vulnerabilities are just bugs”, and security folk should stop getting in the way of usability; security folk take a “defense in depth” approach and want backstops for inevitable bugs. This paper discusses Linux security approaches.

  Please also see the WSL github discussion regarding execstack. This really can use attention and will have positive impact beyond WSL when resolved.