You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 10, 2024. It is now read-only.
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.
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.
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.
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:As such, on a Linux VM booted with EFI and Secure Boot,
IsVirtualWorld()
fails withoperation 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
The text was updated successfully, but these errors were encountered: