2019-10-21 23:28:15 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
// Copyright (C) 2019 Arm Ltd.
|
|
|
|
|
|
|
|
#include <linux/arm-smccc.h>
|
|
|
|
#include <linux/kvm_host.h>
|
|
|
|
|
|
|
|
#include <asm/kvm_emulate.h>
|
|
|
|
|
|
|
|
#include <kvm/arm_hypercalls.h>
|
|
|
|
#include <kvm/arm_psci.h>
|
|
|
|
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
#define KVM_ARM_SMCCC_STD_FEATURES \
|
|
|
|
GENMASK(KVM_REG_ARM_STD_BMAP_BIT_COUNT - 1, 0)
|
2022-05-03 07:38:47 +08:00
|
|
|
#define KVM_ARM_SMCCC_STD_HYP_FEATURES \
|
|
|
|
GENMASK(KVM_REG_ARM_STD_HYP_BMAP_BIT_COUNT - 1, 0)
|
2022-05-03 07:38:48 +08:00
|
|
|
#define KVM_ARM_SMCCC_VENDOR_HYP_FEATURES \
|
|
|
|
GENMASK(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_COUNT - 1, 0)
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
|
2020-12-09 14:09:29 +08:00
|
|
|
static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
|
|
|
|
{
|
|
|
|
struct system_time_snapshot systime_snapshot;
|
|
|
|
u64 cycles = ~0UL;
|
|
|
|
u32 feature;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* system time and counter value must captured at the same
|
|
|
|
* time to keep consistency and precision.
|
|
|
|
*/
|
|
|
|
ktime_get_snapshot(&systime_snapshot);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is only valid if the current clocksource is the
|
|
|
|
* architected counter, as this is the only one the guest
|
|
|
|
* can see.
|
|
|
|
*/
|
|
|
|
if (systime_snapshot.cs_id != CSID_ARM_ARCH_COUNTER)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The guest selects one of the two reference counters
|
|
|
|
* (virtual or physical) with the first argument of the SMCCC
|
|
|
|
* call. In case the identifier is not supported, error out.
|
|
|
|
*/
|
|
|
|
feature = smccc_get_arg1(vcpu);
|
|
|
|
switch (feature) {
|
|
|
|
case KVM_PTP_VIRT_COUNTER:
|
|
|
|
cycles = systime_snapshot.cycles - vcpu_read_sys_reg(vcpu, CNTVOFF_EL2);
|
|
|
|
break;
|
|
|
|
case KVM_PTP_PHYS_COUNTER:
|
|
|
|
cycles = systime_snapshot.cycles;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This relies on the top bit of val[0] never being set for
|
|
|
|
* valid values of system time, because that is *really* far
|
|
|
|
* in the future (about 292 years from 1970, and at that stage
|
|
|
|
* nobody will give a damn about it).
|
|
|
|
*/
|
|
|
|
val[0] = upper_32_bits(systime_snapshot.real);
|
|
|
|
val[1] = lower_32_bits(systime_snapshot.real);
|
|
|
|
val[2] = upper_32_bits(cycles);
|
|
|
|
val[3] = lower_32_bits(cycles);
|
|
|
|
}
|
|
|
|
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
static bool kvm_hvc_call_default_allowed(u32 func_id)
|
|
|
|
{
|
|
|
|
switch (func_id) {
|
|
|
|
/*
|
|
|
|
* List of function-ids that are not gated with the bitmapped
|
|
|
|
* feature firmware registers, and are to be allowed for
|
|
|
|
* servicing the call by default.
|
|
|
|
*/
|
|
|
|
case ARM_SMCCC_VERSION_FUNC_ID:
|
|
|
|
case ARM_SMCCC_ARCH_FEATURES_FUNC_ID:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
/* PSCI 0.2 and up is in the 0:0x1f range */
|
|
|
|
if (ARM_SMCCC_OWNER_NUM(func_id) == ARM_SMCCC_OWNER_STANDARD &&
|
|
|
|
ARM_SMCCC_FUNC_NUM(func_id) <= 0x1f)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* KVM's PSCI 0.1 doesn't comply with SMCCC, and has
|
|
|
|
* its own function-id base and range
|
|
|
|
*/
|
|
|
|
if (func_id >= KVM_PSCI_FN(0) && func_id <= KVM_PSCI_FN(3))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool kvm_hvc_call_allowed(struct kvm_vcpu *vcpu, u32 func_id)
|
|
|
|
{
|
|
|
|
struct kvm_smccc_features *smccc_feat = &vcpu->kvm->arch.smccc_feat;
|
|
|
|
|
|
|
|
switch (func_id) {
|
|
|
|
case ARM_SMCCC_TRNG_VERSION:
|
|
|
|
case ARM_SMCCC_TRNG_FEATURES:
|
|
|
|
case ARM_SMCCC_TRNG_GET_UUID:
|
|
|
|
case ARM_SMCCC_TRNG_RND32:
|
|
|
|
case ARM_SMCCC_TRNG_RND64:
|
|
|
|
return test_bit(KVM_REG_ARM_STD_BIT_TRNG_V1_0,
|
|
|
|
&smccc_feat->std_bmap);
|
2022-05-03 07:38:47 +08:00
|
|
|
case ARM_SMCCC_HV_PV_TIME_FEATURES:
|
|
|
|
case ARM_SMCCC_HV_PV_TIME_ST:
|
|
|
|
return test_bit(KVM_REG_ARM_STD_HYP_BIT_PV_TIME,
|
|
|
|
&smccc_feat->std_hyp_bmap);
|
2022-05-03 07:38:48 +08:00
|
|
|
case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
|
|
|
|
case ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID:
|
|
|
|
return test_bit(KVM_REG_ARM_VENDOR_HYP_BIT_FUNC_FEAT,
|
|
|
|
&smccc_feat->vendor_hyp_bmap);
|
|
|
|
case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
|
|
|
|
return test_bit(KVM_REG_ARM_VENDOR_HYP_BIT_PTP,
|
|
|
|
&smccc_feat->vendor_hyp_bmap);
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
default:
|
|
|
|
return kvm_hvc_call_default_allowed(func_id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-10-21 23:28:15 +08:00
|
|
|
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
2022-05-03 07:38:47 +08:00
|
|
|
struct kvm_smccc_features *smccc_feat = &vcpu->kvm->arch.smccc_feat;
|
2019-10-21 23:28:15 +08:00
|
|
|
u32 func_id = smccc_get_function(vcpu);
|
2020-12-09 14:09:25 +08:00
|
|
|
u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
|
2019-10-21 23:28:15 +08:00
|
|
|
u32 feature;
|
2019-10-21 23:28:18 +08:00
|
|
|
gpa_t gpa;
|
2019-10-21 23:28:15 +08:00
|
|
|
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
if (!kvm_hvc_call_allowed(vcpu, func_id))
|
|
|
|
goto out;
|
|
|
|
|
2019-10-21 23:28:15 +08:00
|
|
|
switch (func_id) {
|
|
|
|
case ARM_SMCCC_VERSION_FUNC_ID:
|
2020-12-09 14:09:25 +08:00
|
|
|
val[0] = ARM_SMCCC_VERSION_1_1;
|
2019-10-21 23:28:15 +08:00
|
|
|
break;
|
|
|
|
case ARM_SMCCC_ARCH_FEATURES_FUNC_ID:
|
|
|
|
feature = smccc_get_arg1(vcpu);
|
|
|
|
switch (feature) {
|
|
|
|
case ARM_SMCCC_ARCH_WORKAROUND_1:
|
2020-09-16 06:30:17 +08:00
|
|
|
switch (arm64_get_spectre_v2_state()) {
|
|
|
|
case SPECTRE_VULNERABLE:
|
2019-10-21 23:28:15 +08:00
|
|
|
break;
|
2020-09-16 06:30:17 +08:00
|
|
|
case SPECTRE_MITIGATED:
|
2020-12-09 14:09:25 +08:00
|
|
|
val[0] = SMCCC_RET_SUCCESS;
|
2019-10-21 23:28:15 +08:00
|
|
|
break;
|
2020-09-16 06:30:17 +08:00
|
|
|
case SPECTRE_UNAFFECTED:
|
2020-12-09 14:09:25 +08:00
|
|
|
val[0] = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
|
2019-10-21 23:28:15 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case ARM_SMCCC_ARCH_WORKAROUND_2:
|
2020-09-18 21:08:54 +08:00
|
|
|
switch (arm64_get_spectre_v4_state()) {
|
|
|
|
case SPECTRE_VULNERABLE:
|
2019-10-21 23:28:15 +08:00
|
|
|
break;
|
2020-09-18 21:08:54 +08:00
|
|
|
case SPECTRE_MITIGATED:
|
|
|
|
/*
|
|
|
|
* SSBS everywhere: Indicate no firmware
|
|
|
|
* support, as the SSBS support will be
|
|
|
|
* indicated to the guest and the default is
|
|
|
|
* safe.
|
|
|
|
*
|
|
|
|
* Otherwise, expose a permanent mitigation
|
|
|
|
* to the guest, and hide SSBS so that the
|
|
|
|
* guest stays protected.
|
|
|
|
*/
|
|
|
|
if (cpus_have_final_cap(ARM64_SSBS))
|
|
|
|
break;
|
|
|
|
fallthrough;
|
|
|
|
case SPECTRE_UNAFFECTED:
|
2020-12-09 14:09:25 +08:00
|
|
|
val[0] = SMCCC_RET_NOT_REQUIRED;
|
2019-10-21 23:28:15 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
2021-12-10 19:16:18 +08:00
|
|
|
case ARM_SMCCC_ARCH_WORKAROUND_3:
|
|
|
|
switch (arm64_get_spectre_bhb_state()) {
|
|
|
|
case SPECTRE_VULNERABLE:
|
|
|
|
break;
|
|
|
|
case SPECTRE_MITIGATED:
|
|
|
|
val[0] = SMCCC_RET_SUCCESS;
|
|
|
|
break;
|
|
|
|
case SPECTRE_UNAFFECTED:
|
|
|
|
val[0] = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
2019-10-21 23:28:16 +08:00
|
|
|
case ARM_SMCCC_HV_PV_TIME_FEATURES:
|
2022-05-03 07:38:47 +08:00
|
|
|
if (test_bit(KVM_REG_ARM_STD_HYP_BIT_PV_TIME,
|
|
|
|
&smccc_feat->std_hyp_bmap))
|
|
|
|
val[0] = SMCCC_RET_SUCCESS;
|
2019-10-21 23:28:16 +08:00
|
|
|
break;
|
2019-10-21 23:28:15 +08:00
|
|
|
}
|
|
|
|
break;
|
2019-10-21 23:28:16 +08:00
|
|
|
case ARM_SMCCC_HV_PV_TIME_FEATURES:
|
2020-12-09 14:09:25 +08:00
|
|
|
val[0] = kvm_hypercall_pv_features(vcpu);
|
2019-10-21 23:28:16 +08:00
|
|
|
break;
|
2019-10-21 23:28:18 +08:00
|
|
|
case ARM_SMCCC_HV_PV_TIME_ST:
|
|
|
|
gpa = kvm_init_stolen_time(vcpu);
|
|
|
|
if (gpa != GPA_INVALID)
|
2020-12-09 14:09:25 +08:00
|
|
|
val[0] = gpa;
|
|
|
|
break;
|
|
|
|
case ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID:
|
|
|
|
val[0] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0;
|
|
|
|
val[1] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1;
|
|
|
|
val[2] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2;
|
|
|
|
val[3] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3;
|
|
|
|
break;
|
|
|
|
case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
|
2022-05-03 07:38:48 +08:00
|
|
|
val[0] = smccc_feat->vendor_hyp_bmap;
|
2020-12-09 14:09:29 +08:00
|
|
|
break;
|
|
|
|
case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
|
|
|
|
kvm_ptp_get_time(vcpu, val);
|
2019-10-21 23:28:18 +08:00
|
|
|
break;
|
2021-01-06 18:34:53 +08:00
|
|
|
case ARM_SMCCC_TRNG_VERSION:
|
|
|
|
case ARM_SMCCC_TRNG_FEATURES:
|
|
|
|
case ARM_SMCCC_TRNG_GET_UUID:
|
|
|
|
case ARM_SMCCC_TRNG_RND32:
|
|
|
|
case ARM_SMCCC_TRNG_RND64:
|
|
|
|
return kvm_trng_call(vcpu);
|
2019-10-21 23:28:15 +08:00
|
|
|
default:
|
|
|
|
return kvm_psci_call(vcpu);
|
|
|
|
}
|
|
|
|
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
out:
|
2020-12-09 14:09:25 +08:00
|
|
|
smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
|
2019-10-21 23:28:15 +08:00
|
|
|
return 1;
|
|
|
|
}
|
2022-05-03 07:38:45 +08:00
|
|
|
|
|
|
|
static const u64 kvm_arm_fw_reg_ids[] = {
|
|
|
|
KVM_REG_ARM_PSCI_VERSION,
|
|
|
|
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1,
|
|
|
|
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2,
|
|
|
|
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3,
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
KVM_REG_ARM_STD_BMAP,
|
2022-05-03 07:38:47 +08:00
|
|
|
KVM_REG_ARM_STD_HYP_BMAP,
|
2022-05-03 07:38:48 +08:00
|
|
|
KVM_REG_ARM_VENDOR_HYP_BMAP,
|
2022-05-03 07:38:45 +08:00
|
|
|
};
|
|
|
|
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
void kvm_arm_init_hypercalls(struct kvm *kvm)
|
|
|
|
{
|
|
|
|
struct kvm_smccc_features *smccc_feat = &kvm->arch.smccc_feat;
|
|
|
|
|
|
|
|
smccc_feat->std_bmap = KVM_ARM_SMCCC_STD_FEATURES;
|
2022-05-03 07:38:47 +08:00
|
|
|
smccc_feat->std_hyp_bmap = KVM_ARM_SMCCC_STD_HYP_FEATURES;
|
2022-05-03 07:38:48 +08:00
|
|
|
smccc_feat->vendor_hyp_bmap = KVM_ARM_SMCCC_VENDOR_HYP_FEATURES;
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
}
|
|
|
|
|
2022-05-03 07:38:45 +08:00
|
|
|
int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return ARRAY_SIZE(kvm_arm_fw_reg_ids);
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(kvm_arm_fw_reg_ids); i++) {
|
|
|
|
if (put_user(kvm_arm_fw_reg_ids[i], uindices++))
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define KVM_REG_FEATURE_LEVEL_MASK GENMASK(3, 0)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Convert the workaround level into an easy-to-compare number, where higher
|
|
|
|
* values mean better protection.
|
|
|
|
*/
|
|
|
|
static int get_kernel_wa_level(u64 regid)
|
|
|
|
{
|
|
|
|
switch (regid) {
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
|
|
|
|
switch (arm64_get_spectre_v2_state()) {
|
|
|
|
case SPECTRE_VULNERABLE:
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
|
|
|
|
case SPECTRE_MITIGATED:
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL;
|
|
|
|
case SPECTRE_UNAFFECTED:
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED;
|
|
|
|
}
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL;
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
|
|
|
|
switch (arm64_get_spectre_v4_state()) {
|
|
|
|
case SPECTRE_MITIGATED:
|
|
|
|
/*
|
|
|
|
* As for the hypercall discovery, we pretend we
|
|
|
|
* don't have any FW mitigation if SSBS is there at
|
|
|
|
* all times.
|
|
|
|
*/
|
|
|
|
if (cpus_have_final_cap(ARM64_SSBS))
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
|
|
|
|
fallthrough;
|
|
|
|
case SPECTRE_UNAFFECTED:
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
|
|
|
|
case SPECTRE_VULNERABLE:
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3:
|
|
|
|
switch (arm64_get_spectre_bhb_state()) {
|
|
|
|
case SPECTRE_VULNERABLE:
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_AVAIL;
|
|
|
|
case SPECTRE_MITIGATED:
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_AVAIL;
|
|
|
|
case SPECTRE_UNAFFECTED:
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_REQUIRED;
|
|
|
|
}
|
|
|
|
return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_AVAIL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
|
|
|
|
{
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
struct kvm_smccc_features *smccc_feat = &vcpu->kvm->arch.smccc_feat;
|
2022-05-03 07:38:45 +08:00
|
|
|
void __user *uaddr = (void __user *)(long)reg->addr;
|
|
|
|
u64 val;
|
|
|
|
|
|
|
|
switch (reg->id) {
|
|
|
|
case KVM_REG_ARM_PSCI_VERSION:
|
|
|
|
val = kvm_psci_version(vcpu);
|
|
|
|
break;
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3:
|
|
|
|
val = get_kernel_wa_level(reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
|
|
|
|
break;
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
case KVM_REG_ARM_STD_BMAP:
|
|
|
|
val = READ_ONCE(smccc_feat->std_bmap);
|
|
|
|
break;
|
2022-05-03 07:38:47 +08:00
|
|
|
case KVM_REG_ARM_STD_HYP_BMAP:
|
|
|
|
val = READ_ONCE(smccc_feat->std_hyp_bmap);
|
|
|
|
break;
|
2022-05-03 07:38:48 +08:00
|
|
|
case KVM_REG_ARM_VENDOR_HYP_BMAP:
|
|
|
|
val = READ_ONCE(smccc_feat->vendor_hyp_bmap);
|
|
|
|
break;
|
2022-05-03 07:38:45 +08:00
|
|
|
default:
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
struct kvm *kvm = vcpu->kvm;
|
|
|
|
struct kvm_smccc_features *smccc_feat = &kvm->arch.smccc_feat;
|
|
|
|
unsigned long *fw_reg_bmap, fw_reg_features;
|
|
|
|
|
|
|
|
switch (reg_id) {
|
|
|
|
case KVM_REG_ARM_STD_BMAP:
|
|
|
|
fw_reg_bmap = &smccc_feat->std_bmap;
|
|
|
|
fw_reg_features = KVM_ARM_SMCCC_STD_FEATURES;
|
|
|
|
break;
|
2022-05-03 07:38:47 +08:00
|
|
|
case KVM_REG_ARM_STD_HYP_BMAP:
|
|
|
|
fw_reg_bmap = &smccc_feat->std_hyp_bmap;
|
|
|
|
fw_reg_features = KVM_ARM_SMCCC_STD_HYP_FEATURES;
|
|
|
|
break;
|
2022-05-03 07:38:48 +08:00
|
|
|
case KVM_REG_ARM_VENDOR_HYP_BMAP:
|
|
|
|
fw_reg_bmap = &smccc_feat->vendor_hyp_bmap;
|
|
|
|
fw_reg_features = KVM_ARM_SMCCC_VENDOR_HYP_FEATURES;
|
|
|
|
break;
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
default:
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for unsupported bit */
|
|
|
|
if (val & ~fw_reg_features)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(&kvm->lock);
|
|
|
|
|
2022-05-17 00:32:54 +08:00
|
|
|
if (test_bit(KVM_ARCH_FLAG_HAS_RAN_ONCE, &kvm->arch.flags) &&
|
|
|
|
val != *fw_reg_bmap) {
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
WRITE_ONCE(*fw_reg_bmap, val);
|
|
|
|
out:
|
|
|
|
mutex_unlock(&kvm->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-05-03 07:38:45 +08:00
|
|
|
int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
|
|
|
|
{
|
|
|
|
void __user *uaddr = (void __user *)(long)reg->addr;
|
|
|
|
u64 val;
|
|
|
|
int wa_level;
|
|
|
|
|
|
|
|
if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
switch (reg->id) {
|
|
|
|
case KVM_REG_ARM_PSCI_VERSION:
|
|
|
|
{
|
|
|
|
bool wants_02;
|
|
|
|
|
|
|
|
wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features);
|
|
|
|
|
|
|
|
switch (val) {
|
|
|
|
case KVM_ARM_PSCI_0_1:
|
|
|
|
if (wants_02)
|
|
|
|
return -EINVAL;
|
|
|
|
vcpu->kvm->arch.psci_version = val;
|
|
|
|
return 0;
|
|
|
|
case KVM_ARM_PSCI_0_2:
|
|
|
|
case KVM_ARM_PSCI_1_0:
|
|
|
|
case KVM_ARM_PSCI_1_1:
|
|
|
|
if (!wants_02)
|
|
|
|
return -EINVAL;
|
|
|
|
vcpu->kvm->arch.psci_version = val;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3:
|
|
|
|
if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (get_kernel_wa_level(reg->id) < val)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
|
|
|
|
if (val & ~(KVM_REG_FEATURE_LEVEL_MASK |
|
|
|
|
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* The enabled bit must not be set unless the level is AVAIL. */
|
|
|
|
if ((val & KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED) &&
|
|
|
|
(val & KVM_REG_FEATURE_LEVEL_MASK) != KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Map all the possible incoming states to the only two we
|
|
|
|
* really want to deal with.
|
|
|
|
*/
|
|
|
|
switch (val & KVM_REG_FEATURE_LEVEL_MASK) {
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
|
|
|
|
wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL;
|
|
|
|
break;
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
|
|
|
|
case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
|
|
|
|
wa_level = KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We can deal with NOT_AVAIL on NOT_REQUIRED, but not the
|
|
|
|
* other way around.
|
|
|
|
*/
|
|
|
|
if (get_kernel_wa_level(reg->id) < wa_level)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return 0;
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
case KVM_REG_ARM_STD_BMAP:
|
2022-05-03 07:38:47 +08:00
|
|
|
case KVM_REG_ARM_STD_HYP_BMAP:
|
2022-05-03 07:38:48 +08:00
|
|
|
case KVM_REG_ARM_VENDOR_HYP_BMAP:
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
return kvm_arm_set_fw_reg_bmap(vcpu, reg->id, val);
|
2022-05-03 07:38:45 +08:00
|
|
|
default:
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|