- 11 Jun, 2022 34 commits
-
-
Sean Christopherson authored
Assert that KVM_SET_MSRS returns '0' or '1' when setting XSS to a non-zero value. The ioctl() itself should "succeed", its only the setting of the XSS MSR that should fail/fault. Signed-off-by:
Sean Christopherson <seanjc@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Sean Christopherson authored
Cache the list of MSRs to save restore, mostly to justify not freeing the list in the caller, which simplifies consumption of the list. Opportunistically move the XSS test's so called is_supported_msr() to common code as kvm_msr_is_in_save_restore_list(). The XSS is "supported" by KVM, it's simply not in the save/restore list because KVM doesn't yet allow a non-zero value. Signed-off-by:
-
Sean Christopherson authored
Rework the KVM_ENABLE_CAP helpers to take the cap and arg0; literally every current user, and likely every future user, wants to set 0 or 1 arguments and nothing else. Signed-off-by:
-
Sean Christopherson authored
Add __vm_enable_cap() and use it for negative tests that expect KVM_ENABLE_CAP to fail. Opportunistically clean up the MAX_VCPU_ID test error messages. Signed-off-by:
-
Sean Christopherson authored
Add a backpointer to 'struct vcpu' so that tests can get at the owning VM when passing around a vCPU object. Long term, this will be little more than a nice-to-have feature, but in the short term it is a critical step toward purging the VM+vcpu_id ioctl mess without introducing even more churn. Signed-off-by:
-
Sean Christopherson authored
Move the asserts for the many REDIST_REGS accesses into common helpers instead of copy+pasting the same, unhelpful asserts over and over. Not providing the actual (or expected) value makes it unnecessarily painful to debug failures, especially since test_assert() prints the errno unconditionally, e.g. on success, it may print a stale, misleading errno. Use kvm_device_attr_get() to handle the "success" check so that the "success" and "expected == actual" asserts are separated, which will make it far less likely that a user incorrectly assumes the ioctl() failed. Signed-off-by:
-
Sean Christopherson authored
Split the get/set device_attr helpers instead of using a boolean param to select between get and set. Duplicating upper level wrappers is a very, very small price to pay for improved readability, and having constant (at compile time) inputs will allow the selftests framework to sanity check ioctl() invocations. Signed-off-by:
-
Sean Christopherson authored
Drop 'int' returns from *_device_has_attr() helpers that assert the return is '0', there's no point in returning '0' and "requiring" the caller to perform a redundant assertion. Signed-off-by:
-
Sean Christopherson authored
Rename kvm_device_check_attr() and its variants to kvm_has_device_attr() to be consistent with the ioctl names and with other helpers in the KVM selftests framework. Signed-off-by:
-
Sean Christopherson authored
Multiplex the return value and fd (on success) in __kvm_create_device() to mimic common library helpers that return file descriptors, e.g. open(). Signed-off-by:
-
Sean Christopherson authored
Move KVM_CREATE_DEVICE_TEST to its own helper, identifying "real" versus "test" device creation based on a hardcoded boolean buried in the middle of a param list is painful for readers. Signed-off-by:
-
Sean Christopherson authored
Remove the two calls that pass @test=true to kvm_create_device() and drop the @test param entirely. The two removed calls don't check the return value of kvm_create_device(), so other than verifying KVM doesn't explode, which is extremely unlikely given that the non-test variant was _just_ called, they are pointless and provide no validation coverage. Signed-off-by:
-
Sean Christopherson authored
Use the KVM_IOCTL_ERROR() macro to generate error messages for a handful of one-off arm64 ioctls. The calls in question are made without an associated struct kvm_vm/kvm_vcpu as they are used to configure those structs, i.e. can't be easily converted to e.g. vcpu_ioctl(). Signed-off-by:
-
Sean Christopherson authored
Fold kvm_util_internal.h into kvm_util_base.h, i.e. make all KVM utility stuff "public". Hiding struct implementations from tests has been a massive failure, as it has led to pointless and poorly named wrappers, unnecessarily opaque code, etc... Not to mention that the approach was a complete failure as evidenced by the non-zero number of tests that were including kvm_util_internal.h. Signed-off-by:
-
Sean Christopherson authored
Make regs_dump() and sregs_dump() static, they're only implemented by x86 and only used internally. Signed-off-by:
-
Sean Christopherson authored
Use __KVM_SYSCALL_ERROR() to report and pretty print non-KVM syscall and ioctl errors, e.g. for mmap(), munmap(), uffd ioctls, etc... Signed-off-by:
-
Sean Christopherson authored
Use the recently introduced KVM-specific ioctl() helpers instead of open coding calls to ioctl() just to pretty print the ioctl name. Signed-off-by:
-
Sean Christopherson authored
Make kvm_ioctl() a macro wrapper and print the _name_ of the ioctl on failure instead of the number. Deliberately do not use __stringify(), as that will expand the ioctl all the way down to its numerical sequence, again the intent is to print the name of the macro. Signed-off-by:
-
Sean Christopherson authored
Use the recently introduced VM-specific ioctl() helpers instead of open coding calls to ioctl() just to pretty print the ioctl name. Keep a few open coded assertions that provide additional info. Signed-off-by:
-
Sean Christopherson authored
Make vm_ioctl() a macro wrapper and print the _name_ of the ioctl on failure instead of the number. Deliberately do not use __stringify(), as that will expand the ioctl all the way down to its numerical sequence. Again the intent is to print the name of the macro. Signed-off-by:
-
Sean Christopherson authored
Add vcpu_get() to wrap vcpu_find() and deduplicate a pile of code that asserts the requested vCPU exists. Signed-off-by:
-
Sean Christopherson authored
Drop vcpu_get_fd(), it no longer has any users, and really should not exist as the framework has failed if tests need to manually operate on a vCPU fd. Signed-off-by:
-
Sean Christopherson authored
Use vcpu_access_device_attr() in arm's arch_timer test instead of manually retrieving the vCPU's fd. This will allow dropping vcpu_get_fd() in a future patch. Signed-off-by:
-
Sean Christopherson authored
Add __vcpu_run() so that tests that want to avoid asserts on KVM_RUN failures don't need to open code the ioctl() call. Signed-off-by:
-
Sean Christopherson authored
Use the recently introduced vCPU-specific ioctl() helpers instead of open coding calls to ioctl() just to pretty print the ioctl name. Signed-off-by:
-
Sean Christopherson authored
Split vcpu_nested_state_set() into a wrapper that asserts, and an inner helper that does not. Passing a bool is all kinds of awful as it's unintuitive for readers and requires returning an 'int' from a function that for most users can never return anything other than "success". Signed-off-by:
-
Sean Christopherson authored
Drop @mode from vm_create() and have it use VM_MODE_DEFAULT. Add and use an inner helper, __vm_create(), to service the handful of tests that want something other than VM_MODE_DEFAULT. Signed-off-by:
-
Sean Christopherson authored
Make vcpu_ioctl() a macro wrapper and pretty the _name_ of the ioctl on failure instead of the number. Add inner macros to allow handling cases where the name of the ioctl needs to be resolved higher up the stack, and to allow using the formatting for non-ioctl syscalls without being technically wrong. Deliberately do not use __stringify(), as that will expand the ioctl all the way down to its numerical sequence, again the intent is to print the name of the macro. Signed-off-by:
-
Sean Christopherson authored
Add a second underscore to inner ioctl() helpers to better align with commonly accepted kernel coding style, and to allow using a single underscore variant in the future for macro shenanigans. Signed-off-by:
-
Sean Christopherson authored
Drop the @perm param from vm_create() and always open VM file descriptors with O_RDWR. There's no legitimate use case for other permissions, and if a selftest wants to do oddball negative testing it can open code the necessary bits instead of forcing a bunch of tests to provide useless information. Signed-off-by:
-
Sean Christopherson authored
Drop declarations for allocate_kvm_dirty_log() and vm_create_device(), which no longer have implementations. Signed-off-by:
-
Sean Christopherson authored
When iterating over vCPUs, invoke access_v3_redist_reg() on the "current" vCPU instead of vCPU0, which is presumably what was intended by iterating over all vCPUs. Signed-off-by:
-
Sean Christopherson authored
Update 'ret' with the return value of _kvm_device_access() prior to asserting that ret is non-zero. In the current code base, the flaw is benign as 'ret' is guaranteed to be -EBUSY from the previous run_vcpu(), which also means that errno==EBUSY prior to _kvm_device_access(), thus the "errno == EFAULT" part of the assert means that a false negative is impossible (unless the kernel is being truly mean and spuriously setting errno=EFAULT while returning success). Signed-off-by:
-
Sean Christopherson authored
The x86-only KVM_CAP_TRIPLE_FAULT_EVENT was (appropriately) renamed to KVM_CAP_X86_TRIPLE_FAULT_EVENT when the patches were applied, but the docs and selftests got left behind. Fix them. Signed-off-by:
-
- 10 Jun, 2022 6 commits
-
-
Sean Christopherson authored
Bug the VM and terminate emulation if an out-of-bounds read into the emulator's data cache occurs. Knowingly contuining on all but guarantees that KVM will overwrite random kernel data, which is far, far worse than killing the VM. Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20220526210817.3428868-9-seanjc@google.com> Signed-off-by:
-
Sean Christopherson authored
Bug the VM if KVM's emulator attempts to inject a bogus exception vector. The guest is likely doomed even if KVM continues on, and propagating a bad vector to the rest of KVM runs the risk of breaking other assumptions in KVM and thus triggering a more egregious bug. All existing users of emulate_exception() have hardcoded vector numbers (__load_segment_descriptor() uses a few different vectors, but they're all hardcoded), and future users are likely to follow suit, i.e. the change to emulate_exception() is a glorified nop. As for the ctxt->exception.vector check in x86_emulate_insn(), the few known times the WARN has been triggered in the past is when the field was not set when synthesizing a fault, i.e. for all intents and purposes the check protects against consumption of uninitialized data. Signed-off-by:
-
Sean Christopherson authored
Bug the VM, i.e. kill it, if the emulator accesses a non-existent GPR, i.e. generates an out-of-bounds GPR index. Continuing on all but gaurantees some form of data corruption in the guest, e.g. even if KVM were to redirect to a dummy register, KVM would be incorrectly read zeros and drop writes. Note, bugging the VM doesn't completely prevent data corruption, e.g. the current round of emulation will complete before the vCPU bails out to userspace. But, the very act of killing the guest can also cause data corruption, e.g. due to lack of file writeback before termination, so taking on additional complexity to cleanly bail out of the emulator isn't justified, the goal is purely to stem the bleeding and alert userspace that something has gone horribly wrong, i.e. to avoid _silent_ data corruption. Signed-off-by:
-
Sean Christopherson authored
Reduce the number of GPRs emulated by 32-bit KVM from 16 to 8. KVM does not support emulating 64-bit mode on 32-bit host kernels, and so should never generate accesses to R8-15. Opportunistically use NR_EMULATOR_GPRS in rsm_load_state_{32,64}() now that it is precise and accurate for both flavors. Wrap the definition with full #ifdef ugliness; sadly, IS_ENABLED() doesn't guarantee a compile-time constant as far as BUILD_BUG_ON() is concerned. Signed-off-by: -
Sean Christopherson authored
Use a u16 instead of a u32 to track the dirty/valid status of GPRs in the emulator. Unlike struct kvm_vcpu_arch, x86_emulate_ctxt tracks only the "true" GPRs, i.e. doesn't include RIP in its array, and so only needs to track 16 registers. Note, maxing out at 16 GPRs is a fundamental property of x86-64 and will not change barring a massive architecture update. Legacy x86 ModRM and SIB encodings use 3 bits for GPRs, i.e. support 8 registers. x86-64 uses a single bit in the REX prefix for each possible reference type to double the number of supported GPRs to 16 registers (4 bits). Reviewed-by:
-
Sean Christopherson authored
Omit RIP from the emulator's _regs array, which is used only for GPRs, i.e. registers that can be referenced via ModRM and/or SIB bytes. The emulator uses the dedicated _eip field for RIP, and manually reads from _eip to handle RIP-relative addressing. To avoid an even bigger, slightly more dangerous change, hardcode the number of GPRs to 16 for the time being even though 32-bit KVM's emulator technically should only have 8 GPRs. Add a TODO to address that in a future commit. See also the comments above the read_gpr() and write_gpr() declarations, and obviously the handling in writeback_registers(). No functional change intended. Signed-off-by:
-
