Add checking in virt-host-validate for secure guest support
on x86 for AMD Secure Encrypted Virtualization.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
---
docs/kbase/launch_security_sev.rst | 7 ++++--
tools/virt-host-validate-common.c | 36 ++++++++++++++++++++++++++++--
tools/virt-host-validate-common.h | 1 +
3 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/docs/kbase/launch_security_sev.rst b/docs/kbase/launch_security_sev.rst
index fa602c7432..45166b3886 100644
--- a/docs/kbase/launch_security_sev.rst
+++ b/docs/kbase/launch_security_sev.rst
@@ -30,8 +30,11 @@ Enabling SEV on the host
========================
Before VMs can make use of the SEV feature you need to make sure your
-AMD CPU does support SEV. You can check whether SEV is among the CPU
-flags with:
+AMD CPU does support SEV. You can run ``libvirt-host-validate``
+(libvirt >= 6.4.0) to check if your host supports secure guests or you
+can follow the manual checks below.
+
+You can manually check whether SEV is among the CPU flags with:
::
diff --git a/tools/virt-host-validate-common.c b/tools/virt-host-validate-common.c
index dd73bd0dea..67aa420d35 100644
--- a/tools/virt-host-validate-common.c
+++ b/tools/virt-host-validate-common.c
@@ -41,7 +41,8 @@ VIR_ENUM_IMPL(virHostValidateCPUFlag,
"vmx",
"svm",
"sie",
- "158");
+ "158",
+ "sev");
static bool quiet;
@@ -447,15 +448,19 @@ int virHostValidateSecureGuests(const char *hvname,
virHostValidateLevel level)
{
virBitmapPtr flags;
- bool hasFac158 = false;
+ bool hasFac158 = false, hasAMDSev = false;
virArch arch = virArchFromHost();
g_autofree char *cmdline = NULL;
static const char *kIBMValues[] = {"y", "Y", "1"};
+ static const char *kAMDValues[] = {"on"};
+ g_autofree char *mod_value = NULL;
flags = virHostValidateGetCPUFlags();
if (flags && virBitmapIsBitSet(flags, VIR_HOST_VALIDATE_CPU_FLAG_FACILITY_158))
hasFac158 = true;
+ else if (flags && virBitmapIsBitSet(flags, VIR_HOST_VALIDATE_CPU_FLAG_SEV))
+ hasAMDSev = true;
virBitmapFree(flags);
@@ -485,6 +490,33 @@ int virHostValidateSecureGuests(const char *hvname,
virHostMsgFail(level, "Hardware or firmware does not provide "
"support for IBM Secure Execution");
}
+ } else if (hasAMDSev) {
+ if (virFileReadValueString(&mod_value, "/sys/module/kvm_amd/parameters/sev") < 0) {
+ virHostMsgFail(level, "AMD Secure Encrypted Virtualization not "
+ "supported by the currently used kernel");
+ return 0;
+ }
+ if (mod_value[0] != '1') {
+ virHostMsgFail(level,
+ "AMD Secure Encrypted Virtualization appears to be "
+ "disabled in kernel. Add mem_encrypt=on "
+ "kvm_amd.sev=1 to kernel cmdline arguments");
+ return 0;
+ }
+ if (virFileReadValueString(&cmdline, "/proc/cmdline") < 0)
+ return -1;
+ if (virKernelCmdlineMatchParam(cmdline, "mem_encrypt", kAMDValues,
+ G_N_ELEMENTS(kAMDValues),
+ VIR_KERNEL_CMDLINE_FLAGS_SEARCH_LAST |
+ VIR_KERNEL_CMDLINE_FLAGS_CMP_EQ)) {
+ virHostMsgPass();
+ return 1;
+ } else {
+ virHostMsgFail(level,
+ "AMD Secure Encrypted Virtualization appears to be "
+ "disabled in kernel. Add mem_encrypt=on "
+ "kvm_amd.sev=1 to kernel cmdline arguments");
+ }
} else {
virHostMsgFail(level,
"Unknown if this platform has Secure Guest support");
diff --git a/tools/virt-host-validate-common.h b/tools/virt-host-validate-common.h
index 44b5544a12..3df5ea0c7e 100644
--- a/tools/virt-host-validate-common.h
+++ b/tools/virt-host-validate-common.h
@@ -38,6 +38,7 @@ typedef enum {
VIR_HOST_VALIDATE_CPU_FLAG_SVM,
VIR_HOST_VALIDATE_CPU_FLAG_SIE,
VIR_HOST_VALIDATE_CPU_FLAG_FACILITY_158,
+ VIR_HOST_VALIDATE_CPU_FLAG_SEV,
VIR_HOST_VALIDATE_CPU_FLAG_LAST,
} virHostValidateCPUFlag;
--
2.25.1
On Mon, May 11, 2020 at 06:42:00PM +0200, Boris Fiuczynski wrote: > Add checking in virt-host-validate for secure guest support > on x86 for AMD Secure Encrypted Virtualization. > > Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> > Reviewed-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> > Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> > --- > docs/kbase/launch_security_sev.rst | 7 ++++-- > tools/virt-host-validate-common.c | 36 ++++++++++++++++++++++++++++-- > tools/virt-host-validate-common.h | 1 + > 3 files changed, 40 insertions(+), 4 deletions(-) > > diff --git a/docs/kbase/launch_security_sev.rst b/docs/kbase/launch_security_sev.rst > index fa602c7432..45166b3886 100644 > --- a/docs/kbase/launch_security_sev.rst > +++ b/docs/kbase/launch_security_sev.rst > @@ -30,8 +30,11 @@ Enabling SEV on the host > ======================== > > Before VMs can make use of the SEV feature you need to make sure your > -AMD CPU does support SEV. You can check whether SEV is among the CPU > -flags with: > +AMD CPU does support SEV. You can run ``libvirt-host-validate`` > +(libvirt >= 6.4.0) to check if your host supports secure guests or you > +can follow the manual checks below. > + > +You can manually check whether SEV is among the CPU flags with: ^this change should go along the (<6.4.0) in one of the earlier patches into a standalone patch. Otherwise looking good. -- Erik Skultety
On 5/18/20 3:01 PM, Erik Skultety wrote:
> On Mon, May 11, 2020 at 06:42:00PM +0200, Boris Fiuczynski wrote:
>> Add checking in virt-host-validate for secure guest support
>> on x86 for AMD Secure Encrypted Virtualization.
>>
>> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
>> Reviewed-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com>
>> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
>> ---
>> docs/kbase/launch_security_sev.rst | 7 ++++--
>> tools/virt-host-validate-common.c | 36 ++++++++++++++++++++++++++++--
>> tools/virt-host-validate-common.h | 1 +
>> 3 files changed, 40 insertions(+), 4 deletions(-)
>>
>> diff --git a/docs/kbase/launch_security_sev.rst b/docs/kbase/launch_security_sev.rst
>> index fa602c7432..45166b3886 100644
>> --- a/docs/kbase/launch_security_sev.rst
>> +++ b/docs/kbase/launch_security_sev.rst
>> @@ -30,8 +30,11 @@ Enabling SEV on the host
>> ========================
>>
>> Before VMs can make use of the SEV feature you need to make sure your
>> -AMD CPU does support SEV. You can check whether SEV is among the CPU
>> -flags with:
>> +AMD CPU does support SEV. You can run ``libvirt-host-validate``
>> +(libvirt >= 6.4.0) to check if your host supports secure guests or you
>> +can follow the manual checks below.
>> +
>> +You can manually check whether SEV is among the CPU flags with:
>
> ^this change should go along the (<6.4.0) in one of the earlier patches into a
> standalone patch.
Actually the earlier patches fix the stale cap cache and this update is
because of a new support in libvirt-host-validate. I am not sure that we
should tie these to into one patch.
I would prefer to keep the two doc changes separate and with the changes
that caused the update.
>
> Otherwise looking good.
>
Thanks but the changes need also to be adjusted as discussed on patch 3.
I will do so in a followup version.
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
... > > > diff --git a/docs/kbase/launch_security_sev.rst b/docs/kbase/launch_security_sev.rst > > > index fa602c7432..45166b3886 100644 > > > --- a/docs/kbase/launch_security_sev.rst > > > +++ b/docs/kbase/launch_security_sev.rst > > > @@ -30,8 +30,11 @@ Enabling SEV on the host > > > ======================== > > > Before VMs can make use of the SEV feature you need to make sure your > > > -AMD CPU does support SEV. You can check whether SEV is among the CPU > > > -flags with: > > > +AMD CPU does support SEV. You can run ``libvirt-host-validate`` > > > +(libvirt >= 6.4.0) to check if your host supports secure guests or you > > > +can follow the manual checks below. > > > + > > > +You can manually check whether SEV is among the CPU flags with: > > > > ^this change should go along the (<6.4.0) in one of the earlier patches into a > > standalone patch. > > Actually the earlier patches fix the stale cap cache and this update is > because of a new support in libvirt-host-validate. I am not sure that we > should tie these to into one patch. > I would prefer to keep the two doc changes separate and with the changes > that caused the update. I won't argue against that logic. However, both patch 3 and this one update the same knowledge article. What IMO matters here the most is that once all of the changes you're introducing are applied as a unit, the article needs to reflect both the changes. From that perspective, at least to me it makes total sense to group the docs changes from both 3/6 and this patch to a single update to the SEV article accordingly. -- Erik Skultety
On 5/19/20 8:25 AM, Erik Skultety wrote:
> ...
>>>> diff --git a/docs/kbase/launch_security_sev.rst b/docs/kbase/launch_security_sev.rst
>>>> index fa602c7432..45166b3886 100644
>>>> --- a/docs/kbase/launch_security_sev.rst
>>>> +++ b/docs/kbase/launch_security_sev.rst
>>>> @@ -30,8 +30,11 @@ Enabling SEV on the host
>>>> ========================
>>>> Before VMs can make use of the SEV feature you need to make sure your
>>>> -AMD CPU does support SEV. You can check whether SEV is among the CPU
>>>> -flags with:
>>>> +AMD CPU does support SEV. You can run ``libvirt-host-validate``
>>>> +(libvirt >= 6.4.0) to check if your host supports secure guests or you
>>>> +can follow the manual checks below.
>>>> +
>>>> +You can manually check whether SEV is among the CPU flags with:
>>>
>>> ^this change should go along the (<6.4.0) in one of the earlier patches into a
>>> standalone patch.
>>
>> Actually the earlier patches fix the stale cap cache and this update is
>> because of a new support in libvirt-host-validate. I am not sure that we
>> should tie these to into one patch.
>> I would prefer to keep the two doc changes separate and with the changes
>> that caused the update.
>
> I won't argue against that logic. However, both patch 3 and this one update the
> same knowledge article. What IMO matters here the most is that once all of the
> changes you're introducing are applied as a unit, the article needs to
> reflect both the changes. From that perspective, at least to me it makes total
> sense to group the docs changes from both 3/6 and this patch to a single update
> to the SEV article accordingly.
>
Fine, I will sort out the changes and create a single AMD doc update patch.
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
© 2016 - 2026 Red Hat, Inc.