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. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
