Re: [PATCH v2 3/5] virt: sevguest: Prep for kernel internal {get, get_ext}_report()

[Dan Williams <dan.j.williams@intel.com>]

Tom Lendacky wrote:
> On 8/14/23 18:24, Dan Williams wrote:
> > Dionna Amalie Glaze wrote:
> >>>
> >>>          switch (ioctl) {
> >>>          case SNP_GET_REPORT:
> >>> -               ret = get_report(snp_dev, &input);
> >>> +               ret = get_report(snp_dev, &input, SNP_UARG);
> >>>                  break;
> >>>          case SNP_GET_DERIVED_KEY:
> >>>                  ret = get_derived_key(snp_dev, &input);
> >>>                  break;
> >>
> >> Do we have an agreement around the continued existence of sev-guest
> >> for supporting derived keys, is that similarly slated for the chopping
> >> block, or is it left undecided?
> >> It appears your choice to not include the uarg/karg extension here is
> >> deliberate.
> > 
> > I do want to understand the argument from James a bit more, but the
> > exlcusion here was simply because there is currently no support for this
> > concept from other vendors.
> > 
> > That said, if it remains a vendor unique concept and continues getting
> > suspicious looks from folks like James, it may indeed be something the
> > kernel wants to jettison.
> 
> I'm not sure why we would want to jettison it. Just because other vendors 
> don't have a key derivation function doesn't mean it can't be useful to 
> customers that want to use it on AMD platforms.

Definitely, instead it was this comment from James that gave me pause:

"To get a bit off topic, I'm not sure derived keys are much use.  The
problem is in SNP that by the time the PSP does the derivation, the key
is both tied to the physical system and derived from a measurement too
general to differentiate between VM images (so one VM could read
another VMs stored secrets)."

http://lore.kernel.org/r/c6576d1682b576ba47556478a98f397ed518a177.camel@HansenPartnership.com