acrn-hypervisor/hypervisor/release/hypercall.c

34 lines
843 B
C
Raw Normal View History

/*
* Copyright (C) 2018 Intel Corporation.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
#include <types.h>
#include <errno.h>
#include <asm/guest/vm.h>
hv: hypercalls: refactor permission-checking and dispatching logic The current permission-checking and dispatching mechanism of hypercalls is not unified because: 1. Some hypercalls require the exact vCPU initiating the call, while the others only need to know the VM. 2. Different hypercalls have different permission requirements: the trusty-related ones are enabled by a guest flag, while the others require the initiating VM to be the Service OS. Without a unified logic it could be hard to scale when more kinds of hypercalls are added later. The objectives of this patch are as follows. 1. All hypercalls have the same prototype and are dispatched by a unified logic. 2. Permissions are checked by a unified logic without consulting the hypercall ID. To achieve the first objective, this patch modifies the type of the first parameter of hcall_* functions (which are the callbacks implementing the hypercalls) from `struct acrn_vm *` to `struct acrn_vcpu *`. The doxygen-style documentations are updated accordingly. To achieve the second objective, this patch adds to `struct hc_dispatch` a `permission_flags` field which specifies the guest flags that must ALL be set for a VM to be able to invoke the hypercall. The default value (which is 0UL) indicates that this hypercall is for SOS only. Currently only the `permission_flag` of trusty-related hypercalls have the non-zero value GUEST_FLAG_SECURE_WORLD_ENABLED. With `permission_flag`, the permission checking logic of hypercalls is unified as follows. 1. General checks i. If the VM is neither SOS nor having any guest flag that allows certain hypercalls, it gets #UD upon executing the `vmcall` instruction. ii. If the VM is allowed to execute the `vmcall` instruction, but attempts to execute it in ring 1, 2 or 3, the VM gets #GP(0). 2. Hypercall-specific checks i. If the hypercall is for SOS (i.e. `permission_flag` is 0), the initiating VM must be SOS and the specified target VM cannot be a pre-launched VM. Otherwise the hypercall returns -EINVAL without further actions. ii. If the hypercall requires certain guest flags, the initiating VM must have all the required flags. Otherwise the hypercall returns -EINVAL without further actions. iii. A hypercall with an unknown hypercall ID makes the hypercall returns -EINVAL without further actions. The logic above is different from the current implementation in the following aspects. 1. A pre-launched VM now gets #UD (rather than #GP(0)) when it attempts to execute `vmcall` in ring 1, 2 or 3. 2. A pre-launched VM now gets #UD (rather than the return value -EPERM) when it attempts to execute a trusty hypercall in ring 0. 3. The SOS now gets the return value -EINVAL (rather than -EPERM) when it attempts to invoke a trusty hypercall. 4. A post-launched VM with trusty support now gets the return value -EINVAL (rather than #UD) when it attempts to invoke a non-trusty hypercall or an invalid hypercall. v1 -> v2: - Update documentation that describe hypercall behavior. - Fix Doxygen warnings Tracked-On: #5924 Signed-off-by: Junjie Mao <junjie.mao@intel.com> Acked-by: Eddie Dong <eddie.dong@intel.com>
2021-05-07 13:17:22 +08:00
int32_t hcall_setup_sbuf(__unused struct acrn_vcpu *vcpu, __unused struct acrn_vm *target_vm,
__unused uint64_t param1, __unused uint64_t param2)
{
return -EPERM;
}
hv: hypercalls: refactor permission-checking and dispatching logic The current permission-checking and dispatching mechanism of hypercalls is not unified because: 1. Some hypercalls require the exact vCPU initiating the call, while the others only need to know the VM. 2. Different hypercalls have different permission requirements: the trusty-related ones are enabled by a guest flag, while the others require the initiating VM to be the Service OS. Without a unified logic it could be hard to scale when more kinds of hypercalls are added later. The objectives of this patch are as follows. 1. All hypercalls have the same prototype and are dispatched by a unified logic. 2. Permissions are checked by a unified logic without consulting the hypercall ID. To achieve the first objective, this patch modifies the type of the first parameter of hcall_* functions (which are the callbacks implementing the hypercalls) from `struct acrn_vm *` to `struct acrn_vcpu *`. The doxygen-style documentations are updated accordingly. To achieve the second objective, this patch adds to `struct hc_dispatch` a `permission_flags` field which specifies the guest flags that must ALL be set for a VM to be able to invoke the hypercall. The default value (which is 0UL) indicates that this hypercall is for SOS only. Currently only the `permission_flag` of trusty-related hypercalls have the non-zero value GUEST_FLAG_SECURE_WORLD_ENABLED. With `permission_flag`, the permission checking logic of hypercalls is unified as follows. 1. General checks i. If the VM is neither SOS nor having any guest flag that allows certain hypercalls, it gets #UD upon executing the `vmcall` instruction. ii. If the VM is allowed to execute the `vmcall` instruction, but attempts to execute it in ring 1, 2 or 3, the VM gets #GP(0). 2. Hypercall-specific checks i. If the hypercall is for SOS (i.e. `permission_flag` is 0), the initiating VM must be SOS and the specified target VM cannot be a pre-launched VM. Otherwise the hypercall returns -EINVAL without further actions. ii. If the hypercall requires certain guest flags, the initiating VM must have all the required flags. Otherwise the hypercall returns -EINVAL without further actions. iii. A hypercall with an unknown hypercall ID makes the hypercall returns -EINVAL without further actions. The logic above is different from the current implementation in the following aspects. 1. A pre-launched VM now gets #UD (rather than #GP(0)) when it attempts to execute `vmcall` in ring 1, 2 or 3. 2. A pre-launched VM now gets #UD (rather than the return value -EPERM) when it attempts to execute a trusty hypercall in ring 0. 3. The SOS now gets the return value -EINVAL (rather than -EPERM) when it attempts to invoke a trusty hypercall. 4. A post-launched VM with trusty support now gets the return value -EINVAL (rather than #UD) when it attempts to invoke a non-trusty hypercall or an invalid hypercall. v1 -> v2: - Update documentation that describe hypercall behavior. - Fix Doxygen warnings Tracked-On: #5924 Signed-off-by: Junjie Mao <junjie.mao@intel.com> Acked-by: Eddie Dong <eddie.dong@intel.com>
2021-05-07 13:17:22 +08:00
int32_t hcall_setup_hv_npk_log(__unused struct acrn_vcpu *vcpu, __unused struct acrn_vm *target_vm,
__unused uint64_t param1, __unused uint64_t param2)
{
return -EPERM;
}
hv: hypercalls: refactor permission-checking and dispatching logic The current permission-checking and dispatching mechanism of hypercalls is not unified because: 1. Some hypercalls require the exact vCPU initiating the call, while the others only need to know the VM. 2. Different hypercalls have different permission requirements: the trusty-related ones are enabled by a guest flag, while the others require the initiating VM to be the Service OS. Without a unified logic it could be hard to scale when more kinds of hypercalls are added later. The objectives of this patch are as follows. 1. All hypercalls have the same prototype and are dispatched by a unified logic. 2. Permissions are checked by a unified logic without consulting the hypercall ID. To achieve the first objective, this patch modifies the type of the first parameter of hcall_* functions (which are the callbacks implementing the hypercalls) from `struct acrn_vm *` to `struct acrn_vcpu *`. The doxygen-style documentations are updated accordingly. To achieve the second objective, this patch adds to `struct hc_dispatch` a `permission_flags` field which specifies the guest flags that must ALL be set for a VM to be able to invoke the hypercall. The default value (which is 0UL) indicates that this hypercall is for SOS only. Currently only the `permission_flag` of trusty-related hypercalls have the non-zero value GUEST_FLAG_SECURE_WORLD_ENABLED. With `permission_flag`, the permission checking logic of hypercalls is unified as follows. 1. General checks i. If the VM is neither SOS nor having any guest flag that allows certain hypercalls, it gets #UD upon executing the `vmcall` instruction. ii. If the VM is allowed to execute the `vmcall` instruction, but attempts to execute it in ring 1, 2 or 3, the VM gets #GP(0). 2. Hypercall-specific checks i. If the hypercall is for SOS (i.e. `permission_flag` is 0), the initiating VM must be SOS and the specified target VM cannot be a pre-launched VM. Otherwise the hypercall returns -EINVAL without further actions. ii. If the hypercall requires certain guest flags, the initiating VM must have all the required flags. Otherwise the hypercall returns -EINVAL without further actions. iii. A hypercall with an unknown hypercall ID makes the hypercall returns -EINVAL without further actions. The logic above is different from the current implementation in the following aspects. 1. A pre-launched VM now gets #UD (rather than #GP(0)) when it attempts to execute `vmcall` in ring 1, 2 or 3. 2. A pre-launched VM now gets #UD (rather than the return value -EPERM) when it attempts to execute a trusty hypercall in ring 0. 3. The SOS now gets the return value -EINVAL (rather than -EPERM) when it attempts to invoke a trusty hypercall. 4. A post-launched VM with trusty support now gets the return value -EINVAL (rather than #UD) when it attempts to invoke a non-trusty hypercall or an invalid hypercall. v1 -> v2: - Update documentation that describe hypercall behavior. - Fix Doxygen warnings Tracked-On: #5924 Signed-off-by: Junjie Mao <junjie.mao@intel.com> Acked-by: Eddie Dong <eddie.dong@intel.com>
2021-05-07 13:17:22 +08:00
int32_t hcall_get_hw_info(__unused struct acrn_vcpu *vcpu, __unused struct acrn_vm *target_vm,
__unused uint64_t param1, __unused uint64_t param2)
{
return -EPERM;
}
hv: hypercalls: refactor permission-checking and dispatching logic The current permission-checking and dispatching mechanism of hypercalls is not unified because: 1. Some hypercalls require the exact vCPU initiating the call, while the others only need to know the VM. 2. Different hypercalls have different permission requirements: the trusty-related ones are enabled by a guest flag, while the others require the initiating VM to be the Service OS. Without a unified logic it could be hard to scale when more kinds of hypercalls are added later. The objectives of this patch are as follows. 1. All hypercalls have the same prototype and are dispatched by a unified logic. 2. Permissions are checked by a unified logic without consulting the hypercall ID. To achieve the first objective, this patch modifies the type of the first parameter of hcall_* functions (which are the callbacks implementing the hypercalls) from `struct acrn_vm *` to `struct acrn_vcpu *`. The doxygen-style documentations are updated accordingly. To achieve the second objective, this patch adds to `struct hc_dispatch` a `permission_flags` field which specifies the guest flags that must ALL be set for a VM to be able to invoke the hypercall. The default value (which is 0UL) indicates that this hypercall is for SOS only. Currently only the `permission_flag` of trusty-related hypercalls have the non-zero value GUEST_FLAG_SECURE_WORLD_ENABLED. With `permission_flag`, the permission checking logic of hypercalls is unified as follows. 1. General checks i. If the VM is neither SOS nor having any guest flag that allows certain hypercalls, it gets #UD upon executing the `vmcall` instruction. ii. If the VM is allowed to execute the `vmcall` instruction, but attempts to execute it in ring 1, 2 or 3, the VM gets #GP(0). 2. Hypercall-specific checks i. If the hypercall is for SOS (i.e. `permission_flag` is 0), the initiating VM must be SOS and the specified target VM cannot be a pre-launched VM. Otherwise the hypercall returns -EINVAL without further actions. ii. If the hypercall requires certain guest flags, the initiating VM must have all the required flags. Otherwise the hypercall returns -EINVAL without further actions. iii. A hypercall with an unknown hypercall ID makes the hypercall returns -EINVAL without further actions. The logic above is different from the current implementation in the following aspects. 1. A pre-launched VM now gets #UD (rather than #GP(0)) when it attempts to execute `vmcall` in ring 1, 2 or 3. 2. A pre-launched VM now gets #UD (rather than the return value -EPERM) when it attempts to execute a trusty hypercall in ring 0. 3. The SOS now gets the return value -EINVAL (rather than -EPERM) when it attempts to invoke a trusty hypercall. 4. A post-launched VM with trusty support now gets the return value -EINVAL (rather than #UD) when it attempts to invoke a non-trusty hypercall or an invalid hypercall. v1 -> v2: - Update documentation that describe hypercall behavior. - Fix Doxygen warnings Tracked-On: #5924 Signed-off-by: Junjie Mao <junjie.mao@intel.com> Acked-by: Eddie Dong <eddie.dong@intel.com>
2021-05-07 13:17:22 +08:00
int32_t hcall_profiling_ops(__unused struct acrn_vcpu *vcpu, __unused struct acrn_vm *target_vm,
__unused uint64_t param1, __unused uint64_t param2)
{
return -EPERM;
}