linux-kernel - Re: [PATCH] crypto: ccp: introduce SEV_GET

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <196eb0d3-dc9f-970f-d785-be4ad91fd54d@amd.com>
Date:   Mon, 25 Feb 2019 22:46:46 +0000
From:   "Singh, Brijesh" <brijesh.singh@....com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
CC:     "Singh, Brijesh" <brijesh.singh@....com>,
        Nathaniel McCallum <npmccallum@...hat.com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Natarajan, Janakarajan" <Janakarajan.Natarajan@....com>,
        "Hook, Gary" <Gary.Hook@....com>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>
Subject: Re: [PATCH] crypto: ccp: introduce SEV_GET_ID2 command



On 2/21/19 10:37 PM, Herbert Xu wrote:
> On Thu, Feb 14, 2019 at 07:33:29PM +0000, Singh, Brijesh wrote:
>>
>>
>> On 2/14/19 10:57 AM, Nathaniel McCallum wrote:
>>> I'm a little concerned that this immediately disables SEV_GET_ID.
>>> IMHO, we should continue to support both for a period of time. One
>>> justification for immediate disablement would be that if keeping it
>>> around is likely to enabled incorrect or insecure userspace behavior
>>> with a firmware change.
>>
>>
>> There are not many programs using the GET_ID today, my preference
>> is to force userspace running on a kernel which supports the GET_ID2
>> to use GET_ID2 and not fallback to GET_ID.
>>
>> The current GET_ID is *broken*.
>>
>> Here is one case I am trying to navigate:
>> - AMD releases a new CPU
>> - The kernel used in your distro does not support this CPU yet.
>>     You updated the kernel to get the CPU support.
>> - The GET_ID on this CPU returned a 10 bytes (instead of 64)
>> - You gave the 64-bytes of data to AMD to get the certificate.
>>     AMD server rejects the request because ID given to it does not
>>     exist in its database.
>>
>> If we drop the support for GET_ID in kernel, then GET_ID will fail and
>> user will required to take action.
> 
> Sorry, but we can't drop a kernel API just to force userspace
> to upgrade to a new one.
> 
> So I agree with Nathaniel that we should keep compatibility until
> such a time when user-space is no longer using the old API.
> 
> You can use other mechanisms to encourage user-space to switch
> over to the new API, e.g., a once-only warning if the old API
> is used.
> 


Sure, I will resubmit the patch to keep the old API and maybe
print once-only warning.

thanks