diff options
author | Sean Christopherson <seanjc@google.com> | 2022-05-26 21:08:15 +0000 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2022-06-10 10:01:33 -0400 |
commit | 1cca2f8c501fa01e6c0d2aefbf97f8c3c89c0186 (patch) | |
tree | 318aa3d8ca38f3e3d790fba775332538b0d8adcd /samples/hw_breakpoint | |
parent | b443183a25ab61840a12de92f8822849e017b9c8 (diff) | |
download | linux-stable-1cca2f8c501fa01e6c0d2aefbf97f8c3c89c0186.tar.gz linux-stable-1cca2f8c501fa01e6c0d2aefbf97f8c3c89c0186.tar.bz2 linux-stable-1cca2f8c501fa01e6c0d2aefbf97f8c3c89c0186.zip |
KVM: x86: Bug the VM if the emulator accesses a non-existent GPR
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 <seanjc@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220526210817.3428868-7-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'samples/hw_breakpoint')
0 files changed, 0 insertions, 0 deletions