proposal: runtime: support VMkernel in Go's Linux port

[0xAlcidius]

Proposal Details

This proposal concerns the potential support of the VMkernel which powers the ESXi hypervisor.

Background

Go's Linux port relies on the availability of SYS_EPOLL_PWAIT, a syscall that has been present since Linux 2.6.19. Since Go 1.24, the minimum supported kernel version is 3.2, ensuring that epoll_pwait is available in standard Linux distributions.

However some Linux kernels, such as VMWare's VMkernel used in the ESXi hypervisor 7.0, does not support epoll_pwait.

This discrepancy leads to fatal runtime errors like #24980 when running on the ESXi 7.0 hypervisor.

Motivation

Currently I'm exploring the possibilities running Go binaries for digital forensics and incident response (DFIR) on ESXi hypervisors. I encountered issue #24980 while attempting to run Go binaries on the hypervisor.

Although the Go minimum requirements have been raised, and I understand not everything can be supported. I think this case reveals a practical scenario where running Go binaries on the VMkernel platform would extend Go's applicability in virtualized environments and expand the use cases for Go.

Yet, given the niche use-case, a proposal discussion could help determine if the added complexity is justified.

Proposal

I propose that the Go project considers adding support for the VMkernel within the Linux port. I've recently already proposed a CL where I switched SYS_EPOLL_PWAIT for SYS_EPOLL_WAIT which solved the issue for my use-case, although further work may be required to ensure it doesn't introduce unwanted problems.

[gabyhelp]

Related Code Changes

• syscall: use SYS_EPOLL_WAIT on linux/amd64 for compatibility

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[prattmic]

Is there documentation available on VMkernel somewhere? Specifically, how does it differ from upstream Linux, what system calls it supports?

Do you know the extent of the changes required to support this OS? It sounds like epoll_pwait was the only issue for your application. I wonder if that holds in general. e.g., does all.bash pass on VMkernel with epoll_pwait changed?

[0xAlcidius]

To my knowledge there isn't comprehensive public documentation detailing VMkernel's internal architecture or a complete list of supported system calls. VMkernel is a proprietary kernel which aims to be compatible with Linux.

I've compiled the Go binaries on my own machine and transferred the binaries to the ESXi hypervisor for execution. Simple binaries such as a "Hello World", executes without issues. However running a more complex application like Velociraptor, provides me the issue #24980.

The primary issue identified so far pertains to the epoll_pwait not being available. To further asses the support for Go binaries, I could attempt to install the custom version of Go (with 'epoll_pwait' changed) directly on the ESXi hypervisor and running all.bash. Once performed I can share the results in this issue.

The reason I mention "attempt" is that the ESXi hypervisor is built with a minimalistic design, lacking traditional Linux package managers like apt, yum or snap. Standard methods for installing third-party software aren't applicable, likely making this process more complex.

[thepudds]

Some potentially related discussions in https://groups.google.com/g/golang-dev/c/2nHt1WOyPG4/m/5lbqgwpQAAAJ and #21347