나는 무슨 일이 일어나고 있는지 알아 내려고 노력하고 있습니다. 나는 다음을 관찰했습니다.
- Windows 10에서 컴파일된 exe 바이너리
- CentOS7에서 컴파일된 elf 바이너리
musl - 사용자 1 WSL2: (
elf binary runs, exe binary runs업데이트됨) - 사용자 2 WSL2:
elf binary error, exe binary runs (surprised #1) - 사용자 3 WSL2:
elf binary runs, exe binary runs (surprised #2)
이러한 오류는 프로그램 충돌이 아니라 운영 체제의 실행 가능한 형식 오류입니다.
새 컴퓨터에서 사용자 1의 경험을 재현할 수 있지만 다른 사용자가 왜 그런 경험을 하는지는 알 수 없습니다. 화면 공유를 통해 그들이 무엇을 관찰하고 있는지 확인했습니다.
편집 다음 세션에서 사용자에 대해 자세히 알아볼 수 있을 때 WSL에서 다양한 유형의 실행 파일 실행 호환성과 시간에 따른 변경 방식에 대한 일부 정보가 도움이 될 수 있습니다. https://stackoverflow.com/questions/38920710/how-can-i-run-a-windows-executable-from-wsl-ubuntu-bash
편집 다음번에 사용자를 만날 때 더 많은 정보를 수집할 계획입니다. 예:
- 윈도우 버전
- WSL 버전
- 터미널 쉘 / 터미널 호출 방법
답변1
이것은 완전한 대답은 아니지만, 더 많은 정보를 수집하면 이에 대해 다시 언급하겠습니다.
그런데 이제 elf와 Windows(PE) 바이너리가 모두 실행되고 있는 사용자 #2의 사례에 대해 놀랐다고 언급하셨습니다.
그러나 이는 WSL의 경우 "정상"입니다. WSL은 전체 이름(확장명 포함)이 지정되어 있는 한 Windows 바이너리 실행을 허용합니다 .exe. 예를 들어 notepad.exeWSL에서 실행하면 거의 항상 기본 설정을 사용할 수 있습니다.
이는 init 중에 Linux에 PE 형식을 등록하여 수행됩니다 binfmt_misc. 를 통해 이를 확인할 수 있습니다 cat /proc/sys/fs/binfmt_misc/WSLInterop. (어쨌든 나에게 흥미로운 TIL 관련 참고 사항은 Windows 바이너리용 4d5a를 지정하는 매직 바이트가 원래 DOS PE 형식에서 유래했다는 것입니다. 이는 16진수 ASCII 문자 "mz"로, Mark Zbikowsky의 원본 문서 중 하나입니다. 도스 건축가.
참고로 이 지원은할 수 있는다양한 방법으로 비활성화할 수 있으므로 사용자가 Windows 바이너리를 실행할 수 없는 경우 cat /proc/sys/fs/binfmt_misc/WSLInterop위의 결과를 확인하세요.
또한 말씀하신 대로 WSL 버전과 실행 파일에 대한 자세한 정보를 확인하세요. 실행 파일이 32비트 또는 64비트 아키텍처용으로 컴파일됩니까? 제 기억이 맞다면 WSL1은 64비트 바이너리만 실행할 수 있지만 WSL2는 둘 다 실행할 수 있습니다.
답변2
해당 사용자를 다시 만나지는 못했지만, 무슨 일이 일어났는지 파악했다고 믿습니다.
WSL은 UPX 압축 바이너리 지원에 있어 혼합된 역사를 가지고 있습니다. 우리 바이너리는 항상 UPX 압축되었지만 이에 대한 WSL 지원은 시간이 지남에 따라 변경되었습니다. 이제 UPX 압축을 비활성화했으며 바이너리는 모든 Linux 배포판(WSL 포함)에서 문제 없이 실행됩니다.
새로운 오탐지 Windows Defender 상태로 인해 Windows는 이제 사용자 컴퓨터에서 exe를 자동으로 삭제합니다. 이로 인해 사용자 1은 실제로 프로그램이 존재하지 않았고 완전히 다른 오류였음에도 불구하고 "프로그램이 올바르게 실행되지 않았고 오류가 발생했습니다"라고 보고했습니다. Windows 관련 지원을 이 동작을 유발하지 않는 이전 버전으로 롤백했기 때문에 현재로서는 이 문제에 대한 최선의 해결책이 없습니다.