2018-03-08 15:48:44 +03:00
|
|
|
/*
|
|
|
|
* QEMU SEV stub
|
|
|
|
*
|
|
|
|
* Copyright Advanced Micro Devices 2018
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Brijesh Singh <brijesh.singh@amd.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "qemu/osdep.h"
|
|
|
|
#include "sev_i386.h"
|
|
|
|
|
|
|
|
SevInfo *sev_get_info(void)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool sev_enabled(void)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t sev_get_me_mask(void)
|
|
|
|
{
|
|
|
|
return ~0;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t sev_get_cbit_position(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t sev_get_reduced_phys_bits(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2018-03-08 15:48:51 +03:00
|
|
|
|
|
|
|
char *sev_get_launch_measurement(void)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
2018-03-08 15:49:00 +03:00
|
|
|
|
2020-06-30 18:35:46 +03:00
|
|
|
SevCapability *sev_get_capabilities(Error **errp)
|
2018-03-08 15:49:00 +03:00
|
|
|
{
|
2020-06-30 18:35:46 +03:00
|
|
|
error_setg(errp, "SEV is not available in this QEMU");
|
2018-03-08 15:49:00 +03:00
|
|
|
return NULL;
|
|
|
|
}
|
2021-01-26 20:36:44 +03:00
|
|
|
|
2020-10-27 20:03:03 +03:00
|
|
|
int sev_inject_launch_secret(const char *hdr, const char *secret,
|
|
|
|
uint64_t gpa, Error **errp)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
sev: Remove false abstraction of flash encryption
When AMD's SEV memory encryption is in use, flash memory banks (which are
initialed by pc_system_flash_map()) need to be encrypted with the guest's
key, so that the guest can read them.
That's abstracted via the kvm_memcrypt_encrypt_data() callback in the KVM
state.. except, that it doesn't really abstract much at all.
For starters, the only call site is in code specific to the 'pc'
family of machine types, so it's obviously specific to those and to
x86 to begin with. But it makes a bunch of further assumptions that
need not be true about an arbitrary confidential guest system based on
memory encryption, let alone one based on other mechanisms:
* it assumes that the flash memory is defined to be encrypted with the
guest key, rather than being shared with hypervisor
* it assumes that that hypervisor has some mechanism to encrypt data into
the guest, even though it can't decrypt it out, since that's the whole
point
* the interface assumes that this encrypt can be done in place, which
implies that the hypervisor can write into a confidential guests's
memory, even if what it writes isn't meaningful
So really, this "abstraction" is actually pretty specific to the way SEV
works. So, this patch removes it and instead has the PC flash
initialization code call into a SEV specific callback.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2021-01-12 03:58:04 +03:00
|
|
|
|
|
|
|
int sev_encrypt_flash(uint8_t *ptr, uint64_t len, Error **errp)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2021-01-26 20:36:44 +03:00
|
|
|
|
|
|
|
bool sev_es_enabled(void)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2021-02-08 17:04:52 +03:00
|
|
|
|
|
|
|
void sev_es_set_reset_vector(CPUState *cpu)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
int sev_es_save_reset_vector(void *flash_ptr, uint64_t flash_size)
|
|
|
|
{
|
|
|
|
abort();
|
|
|
|
}
|