kernel_lockdown denies iopl calls

[cgwalters]

See https://bugzilla.redhat.com/show_bug.cgi?id=1862851
specifically: https://bugzilla.redhat.com/show_bug.cgi?id=1862851#c7

Basically in Secure Boot mode iopl() isn't accessible to userspace. Is there a non-iopl() mechanism to talk to the hypervisor? If not, we may need a kernel module to proxy this.

[lucab]

Thanks for forwarding this.
I've started digging through but I'm a bit puzzled as this is a straightforward port of the same logic in Go (which is used by Ignition) which is also going through iopl: https://github.com/vmware/vmw-guestinfo/blob/25eff159a728be87e103a0b8045e08273f4dbec4/vmcheck/vmcheck_linux.go#L19-L22

[lucab]

Indeed the Go logic seems to be broken in the same way, coreos/ignition#1092.

Without going to kernel modules, I think there is a vsock-based alternative: https://github.com/vmware/open-vm-tools/blob/f72e314e8b0df4e80c6b5f9b0c66ad2e9ce02e19/open-vm-tools/lib/rpcChannel/vsockChannel.c.

However I still need to check details, hw-version compatibility and any other caveat for that transport.

[cgwalters]

Based on web searches I'm not finding anyone saying that open-vm-tools fails in this scenario, so we likely need to do the same thing indeed.

(It'd be nice to share code here between ignition and afterburn...dunno how easily we could expose a C library that go could link to that just does what ignition needs)

[lucab]

https://github.com/lucab/vmw_backdoor-rs/pull/8 introduced a dual privileged/unprivileged path in 0.2.0 which should be enough to bypass this iopl() failure via a fallback approach. I'm keeping this ticket open in case we consider implementing the vsock approach at some point in the future.