From: "Singh, Brijesh" <brijesh.singh@amd.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Singh, Brijesh" <brijesh.singh@amd.com>,
Nathaniel McCallum <npmccallum@redhat.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Natarajan, Janakarajan" <Janakarajan.Natarajan@amd.com>,
"Hook, Gary" <Gary.Hook@amd.com>,
"Lendacky, Thomas" <Thomas.Lendacky@amd.com>
Subject: Re: [PATCH] crypto: ccp: introduce SEV_GET_ID2 command
Date: Mon, 25 Feb 2019 22:46:46 +0000 [thread overview]
Message-ID: <196eb0d3-dc9f-970f-d785-be4ad91fd54d@amd.com> (raw)
In-Reply-To: <20190222043707.6kzqeztgx3rvv3a4@gondor.apana.org.au>
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
prev parent reply other threads:[~2019-02-25 22:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 19:23 [PATCH] crypto: ccp: introduce SEV_GET_ID2 command Singh, Brijesh
2019-02-14 16:57 ` Nathaniel McCallum
2019-02-14 19:33 ` Singh, Brijesh
2019-02-22 4:37 ` Herbert Xu
2019-02-25 22:46 ` Singh, Brijesh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=196eb0d3-dc9f-970f-d785-be4ad91fd54d@amd.com \
--to=brijesh.singh@amd.com \
--cc=Gary.Hook@amd.com \
--cc=Janakarajan.Natarajan@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npmccallum@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).