Handle VMMCALL in vctrap()
When SEV guest userland issues a vmmcall instruction, a #VC exception
with code SVM_VMEXIT_VMMCALL will be raised in the guest kernel.
For now we do not allow vmmcalls from guest userland, thus terminate
the userland process with SIGILL.
This is similar to the non-SEV case.
ok mlarkin@
vmm(4): Ignore VMGEXIT request and inject #UD
SEV guest userland processes are allowed to issue the vmgexit
instruction. However, guest userland has no access to the GHCB.
VMEXITs with exit reason SVM_VMEXIT_VMGEXIT initiated by the guest
kernel will always provide a valid GHCB request.
Moreover, as the guest kernel makes sure, that the GHCB contains
no request when guest userland is running, a rouge guest userland
process can only force repeated VMEXITs with an empty GHCB.
Therefore, in vmm(4)'s vmgexit handler inject #UD when the exit
reason is not updated with data from the GHCB and stays on
SVM_VMEXIT_VMGEXIT.
ok mlarkin@
vmm(4): Check for and allow empty GHCB; only clear valid bitmap
The GHCB valid bitmap indicates wether the GHCB contains a request
or not. When no bits are set, ignore the GHCB and do not sync with
vCPU state.
To clear/invalidate the GHCB just zero out the valid bitmap instead
of the full GHCB.
ok mlarkin@
Make sure that the filterset passed along with other objects is present.
For communication with the parent the missing presence of a filter_set
is cause for a panic. This should just never happen. For messages from
bgpctl that are forwarded by the session engine things are more complex.
Make sure the filter_set was sent and only execute the command that
wraps this filter_set is present. If it is not there it may have been
filtered out because it is invalid and then the command depending on
this data should not be executed.
OK tb@
regress: Test vmmcall raises #UD
On AMD/SVM the hypervisor will inject #UD when userland tries to
execute the vmmcall instruction. Same holds for vmgexit which is
encode as "rep vmmcall".
On Intel/VMX vmmcall and vmgexit are invalid instructions, so the
CPU will raise #UD.
ok mlarkin@
regress: Test vmcall raises #UD
On Intel/VMX the hypervisor will inject #UD when userland tries to
execute the vmcall instruction.
On AMD/SVM vmcall is an invalid instruction, so the CPU will raise
ok mlarkin@
On newer hardware generations, no async events are enabled by default,
so explicitly enable the ones we're interested in.
tested by stsp@ as part of a larger diff
ok dlg@
