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
