Skip to content
This repository has been archived by the owner on May 10, 2024. It is now read-only.

vmcheck: kernel_lockdown (and Secure Boot) blocks iopl call #20

Open
lucab opened this issue Sep 22, 2020 · 1 comment
Open

vmcheck: kernel_lockdown (and Secure Boot) blocks iopl call #20

lucab opened this issue Sep 22, 2020 · 1 comment

Comments

@lucab
Copy link
Contributor

lucab commented Sep 22, 2020

This is a followup to coreos/ignition#1092, which is an application/consumer which experienced breakage because of this issue.

On Linux, according to kernel_lockdown manpage:

On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled if the system boots in EFI Secure Boot mode.
[...]
When lockdown is in effect, a number of features are disabled or have their use restricted. This includes [...] the ability to directly configure and control devices, so as to prevent the use of a device to access or modify a kernel image:
[...]

  • The use of the ioperm and iopl instructions on x86.

As such, on a Linux VM booted with EFI and Secure Boot, IsVirtualWorld() fails with operation not permitted because of this logic:
https://github.com/vmware/vmw-guestinfo/blob/687661b8bd8e72a55ac988ecdb2a1cdef76fa78d/vmcheck/vmcheck_linux.go#L19-L22

Empirically, we have observed that older versions of this library were not performing the iopl and still somehow managed to work, however we fear this may be just the result of lucky non-deterministic behavior.
It looks like open-vm-tools nowadays may be using a different transport to communicate with the hypervisor, via a vsocket:
https://github.com/vmware/open-vm-tools/blob/f72e314e8b0df4e80c6b5f9b0c66ad2e9ce02e19/open-vm-tools/lib/rpcChannel/vsockChannel.c

I can provide a quick hotfix to conditionally bypass the iopl call here if you want, but I'd like to see a larger discussion/plan about how to better address this in the longer term.

/cc @frapposelli @sigma

@lucab
Copy link
Contributor Author

lucab commented Sep 28, 2020

I can provide a quick hotfix to conditionally bypass the iopl call here if you want, but I'd like to see a larger discussion/plan about how to better address this in the longer term.

In the meanwhile I posted this short-term hotfix at #21, to get things moving. It does not completely fix the underlying problem (see "non-deterministic behavior" above).
The longer term approach is still to be discussed/agreed, pending feedback from the VMware devs of this repo. I'll keep the ticket open till then.

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

No branches or pull requests

1 participant