vmware: kernel_lockdown breaks guestinfo fetching #1092
Comments
lucab
changed the title
|
For reference, this used to work on v0.x releases due to a lucky mess, possibly in a non-deterministic way. This bug only affects v2.x releases, starting with v2.0.0-beta. On 0.35.0 Ignition is using an ancient/incomplete fork of the vmware library: https://github.com/coreos/ignition/tree/v0.35.0/vendor/github.com/sigma. This version does not perform any The library was updated in #793, which went into v2.0.0-beta. It now performs an |
|
The underlying library bug is tracked at vmware-archive/vmw-guestinfo#20. I posted a short-term hotfix at vmware-archive/vmw-guestinfo#21, which does alleviate the symptoms in Ignition in most cases. |
|
This is not fixed upstream. Reopening. |
|
Heh, we started carrying a patch in Fedora (https://src.fedoraproject.org/rpms/ignition/pull-request/91) just in time for the upstream PR to get merged - vmware-archive/vmw-guestinfo#21 (comment) |
|
#1332 revendors vmw-guestinfo to pick up the upstream workaround. Leaving this open to track a potential longer-term fix. |
Disable Secure Boot due to coreos/ignition#1092. Co-authored-by: Joseph Callen <jcallen@redhat.com>
Fetch-Offline: -------------- Right now, even if fetch-offline gets ErrNeedNet, it might've still logged info about configs which it did fetch before hitting the error. This then results in double-logging of e.g. the base config and at least the first layer of user configs when fetch re-fetches them. But it's also misleading, because anything which runs between fetch-offline and fetch and sees the journal messages will think that Ignition did successfully fetch and cache the merged user config, when it did not. And sadly, we still have code which peek at the cached config for $reasons (legacy-style RHCOS LUKS is one of them, RHCOS FIPS support is another), and those bits get thrown off by seeing the logging messages yet not seeing a cached Ignition config. Let's tweak things so that we buffer those messages and only actually write them out once we've successfully acquired the configs. While we're here, clean up the base config logging hack now that the fetch stages are canonical. VMware Kernel Lockdown: ----------------------- This is a quickfix to avoid performing an `iopl`, which is blocked by kernel_lockdown under SecureBoot. Refs: * https://bugzilla.redhat.com/show_bug.cgi?id=1877995 * https://github.com/lucab/vmw_backdoor-rs/issues/6 * #1092
Operating System Version
RHCOS 4.6 nightly (likely recent FCOS too, haven't directly checked)
Ignition Version
2.6.0
Environment
VMware vSphere 7.0, with EFI and Secure Boot enabled.
Reproduction Steps
Actual Behavior
Enabling Secure Boot turns on kernel_lockdown, which in turn blocks the
ioplcall. Ignition performs that in order to get access to the I/O ports for hypervisor backdoor.Symptoms are:
operation not permittedLockdown: iopl is restrictedon the consoleHere below is a screenshot from the emergency console.
Ref:
The text was updated successfully, but these errors were encountered: