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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Aug 2023 14:03:03 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Tom Lendacky <thomas.lendacky@....com>,
        Dan Williams <dan.j.williams@...el.com>,
        Dionna Amalie Glaze <dionnaglaze@...gle.com>
CC:     <linux-coco@...ts.linux.dev>, Borislav Petkov <bp@...en8.de>,
        "Brijesh Singh" <brijesh.singh@....com>, <peterz@...radead.org>,
        <x86@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/5] virt: sevguest: Prep for kernel internal {get,
 get_ext}_report()

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