Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Provide a way to positively detect WSL from an app compiled on Linux. #423

Closed
dmiller-nmap opened this issue May 25, 2016 · 33 comments
Closed

Comments

@dmiller-nmap
Copy link

I understand that support is always improving, but it seems unlikely that the specific network functionality (raw sockets, packet sniffing, netlink routes) required by Nmap will ever be supported in WSL/BashOnWindows. We would like to be able to detect WSL and provide users with a helpful message pointing them to our Windows-native build, while allowing our app to continue until the first crash/error.

Is there any stable, predictable method for detecting whether our built-on-Linux program is being run on Windows Subsystem for Linux?

@therealkenc
Copy link
Collaborator

Can't speculate on 'stable', but /proc/version has the string 'Microsoft' which seems a pretty safe bet.

@benhillis
Copy link
Member

@therealkenc For the time being this is probably the best way to do it. I can't promise that we'll never change the content of these ProcFs files, but I think it's unlikely we'll change it to something that doesn't contain "Microsoft" or "WSL".

/proc/sys/kernel/osrelease
/proc/version

@fpqc
Copy link

fpqc commented May 25, 2016

@benhillis Do you guys over at Microsoft think you might ever support any/most/all of this low-level functionality used by nmap, eventually, in the (distant) future? Are there reasons in principle why you wouldn't want to or couldn't realistically support them?

@benhillis
Copy link
Member

@fpqc There's a lot of surface areas and features to cover in limited time. The best way to help us prioritize work is by adding items to our User Voice page.

@fpqc
Copy link

fpqc commented May 26, 2016

@benhillis Yes absolutely you only have a limited time before the Anniversary update for Win10. I was just asking if the team over at Microsoft is planning on eventually seeing the project through to something on which the whole of the Linux userland can run (albeit maybe sometimes requiring tweaks). I mean, of course, Microsoft is a business, not a charity, and ultimately development will continue only if WSL meets business goals, but I was just asking whether the current plan is that development will continue by the WSL team improving compatibility for the foreseeable future.

I think WSL is really Windows 10's new "Killer App" (to use some cliched marketing lingo), and I personally know several people already who have moved (or are prepared to move) back to a Windows ecosystem from Linux because it's such an exciting project.

My biggest worry is that MS is going to take the project to something like 85% completion and then let it stagnate. WSL is something for which I would be willing to pay and for which my company would also be willing to pay, so I hope that development will continue past the anniversary release.

@benhillis
Copy link
Member

benhillis commented May 27, 2016

@fpqc This question is definitely above my pay-grade but I'll try to answer as best I can.

I will say that as a developer on this feature I'm excited about the future of the project don't see it stagnating any time soon. We have some exciting things planned that make me optimistic about the future of our technology.

Thank you for your kind words. I'm sorry if I'm being somewhat vague but I'm trying to err on the side of not putting my foot in my mouth :)

@thorsteneb thorsteneb mentioned this issue Dec 3, 2016
karelzak pushed a commit to util-linux/util-linux that referenced this issue Jan 31, 2017
Windows 10 implements Windows Subsystem for Linux (WSL).

WSL does not implement support for SIGSEGV handler, which is used inside
is_vmware_platform(). As a result, lscpu crashes there.

Implement WSL detection, and as a side effect, work around the crash.
Note that none of existing virtualization types exactly matches.
But the the closest would be "container".

References:

Provide a way to positively detect WSL from an app compiled on Linux.
microsoft/WSL#423

missing support for SIGSEGV handler
microsoft/WSL#1637

Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
@benhillis
Copy link
Member

Closing this out since the discussion has run its course.

karelzak pushed a commit to util-linux/util-linux that referenced this issue Feb 21, 2017
Windows 10 implements Windows Subsystem for Linux (WSL).

WSL does not implement support for SIGSEGV handler, which is used inside
is_vmware_platform(). As a result, lscpu crashes there.

Implement WSL detection, and as a side effect, work around the crash.
Note that none of existing virtualization types exactly matches.
But the the closest would be "container".

References:

Provide a way to positively detect WSL from an app compiled on Linux.
microsoft/WSL#423

missing support for SIGSEGV handler
microsoft/WSL#1637

Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
@haydentech
Copy link

haydentech commented Jul 26, 2017

It would be great if someone would update config.guess to detect Ubuntu on Windows. Currently, Ubuntu and Ubuntu-on-Windows return identical results.

@fpqc
Copy link

fpqc commented Jul 26, 2017

@haydentech For now, it's better not to mainline patches to add WSL support, because it will start fudging tests that the devs would like to solve by improving their driver. The best way to test that is real-world usage, with software hitting all of the syscalls we would expect on a real Linux system. The team is planning to implement unimplemented syscalls and fix buggy ones.

@therealkenc
Copy link
Collaborator

It would be great if someone would update config.guess

Unfortunately that doesn't work, because the header files (both kernel and glibc) lie by design. "It's a feature". So, say you push a config.guess patch to savanah to return x86_64-pc-wslwin-gnu, and it gets accepted by the FSF. But, then what.

That won't (for example) make PulseAudio (#486) realize that PTHREAD_PRIO_INHERIT is defined in the pthread.h header, but said feature does not actually work on the platform. You are going to have to push a patch to PA's ax_pthread.m4 too. And if you are going to patch PA to teach it about pc-wslwin-gnu, well... might as well be checking /proc/version. No one pushes a compile-time platform check like that mind you, because Stephen is liable fix the thing without notice.

@haydentech
Copy link

@therealkenc I don't expect a config.guess change to magically fix all problems resulting from differences in the 2 platforms. But it would fix my build problem, for one, and be a basis for future enhancements in other products. Right now, there is nothing to build on. Having config.guess return the same result for the two platforms is nonsensical.

@sunilmut
Copy link
Member

I echo @fpqc's sentiment above

@fpqc - Regarding your comment, and specifically about raw sockets, the problem is that Windows does not natively support AF_PACKET socket domain. The functionality is exposed through other means on Windows because there are nmap tools on the internet that works on Windows. But, mapping AF_PACKET directly over that functionality is not feasible because of our commitment to compatibility. We are seriously discussing with the core networking team to light up these scenarios, now that it is pretty high on user voice (thanks for the feedback). As @benhillis mentions, some of these will take time given the surface area. Things are not out of reach technically, if there is demand.

@therealkenc
Copy link
Collaborator

@therealkenc ... Having config.guess return the same result for the two platforms is nonsensical.

That is one thesis. But it isn't me or Microsoft you have to convince. You need to convince the GNU maintainers to accept your patch that adds the new triplet.

@BeErikk
Copy link

BeErikk commented Sep 11, 2017

uname -r | sed -n 's/.*\( *Microsoft *\).*/\1/p'

will output "Microsoft"
Guess that will be pretty unique for WSL :D

@black7375
Copy link

This method does not use external processes.
https://gist.github.com/abl/d004dcad84a16ddd670f5337ba5b896d

if [[ -f "/mnt/c/WINDOWS/system32/wsl.exe" ]]; then
  # We're in WSL, which defaults to umask 0 and causes issues with compaudit
  umask 0022
fi

@therealkenc
Copy link
Collaborator

if [[ -f "/mnt/c/WINDOWS/system32/wsl.exe" ]]; then

That method assumes that the 9p automount point hasn't be changed or turned off with wsl.conf. Use the osversion. There is a more recent landing zone at #4555.

@Lazerbeak12345
Copy link

What about checking for /etc/wsl.conf as a fallback if the directory /run/WSL doesn't exist? It sounds like you would need at least one of those two filesystem nodes.

Something like this bash code is what I have in mind:

if [[ -f "/run/WSL" ]] || [[ -f "/etc/wsl.conf" ]]; then
    echo "is wsl"
fi

@bluca
Copy link
Member

bluca commented May 19, 2021

WSL in /proc/sys/kernel/osrelease is supported everywhere and cannot be broken by the distro image, since it's provided by the kernel.

@josesa-xx
Copy link

Since the distinction between WSL1 and WSL2 is that the first runs inside a container while the second runs in a virtual machine, we can make use of "systemd-detect-virt --container" to differentiate from both environments.

if [ -n "${WSL_DISTRO_NAME}" ]; then
  # In WSL but which one?
  virt_container="$(systemd-detect-virt --container)"
  case ${virt_container} in
    wsl)
      echo "This is WSL 1"
      ;;
    none)
      echo "This is WSL 2"
      ;;
    *)
      echo "Don't known ${virt_container}"
      ;;
  esac
fi

@RokeJulianLockhart

This comment was marked as resolved.

@mlromramse
Copy link

What about systemd-detect-virt?
Responds with wsl

@RokeJulianLockhart
Copy link

RokeJulianLockhart commented Jul 4, 2023

@mlromramse, and returns none on bare metal. That's not bad.

PS /home/rokejulianlockhart> systemd-detect-virt
none
NativeCommandExitException: Program "systemd-detect-virt" ended with non-zero exit code: 1.
PS /home/rokejulianlockhart>

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

No branches or pull requests