Re: [edk2] varstore compatibility between auth and non-auth

2016-02-15 Thread Laszlo Ersek
On 02/15/16 03:08, Zeng, Star wrote: > Just get back from Chinese New Year holiday. > > On 2016/2/6 1:55, Laszlo Ersek wrote: >> On 02/05/16 13:37, Laszlo Ersek wrote: >>> On 02/05/16 13:18, Gerd Hoffmann wrote: Hi, > So, my question is: is this intended and supported behavior

Re: [edk2] varstore compatibility between auth and non-auth

2016-02-14 Thread Zeng, Star
Just get back from Chinese New Year holiday. On 2016/2/6 1:55, Laszlo Ersek wrote: On 02/05/16 13:37, Laszlo Ersek wrote: On 02/05/16 13:18, Gerd Hoffmann wrote: Hi, So, my question is: is this intended and supported behavior (that is, going from a Secure Boot-capable build to a Secure

Re: [edk2] varstore compatibility between auth and non-auth

2016-02-05 Thread Laszlo Ersek
On 02/05/16 13:37, Laszlo Ersek wrote: > On 02/05/16 13:18, Gerd Hoffmann wrote: >> Hi, >> >>> So, my question is: is this intended and supported behavior (that is, >>> going from a Secure Boot-capable build to a Secure Boot-disabled build, >>> while preserving the contents & functionality of

Re: [edk2] varstore compatibility between auth and non-auth

2016-02-05 Thread Gerd Hoffmann
Hi, > So, my question is: is this intended and supported behavior (that is, > going from a Secure Boot-capable build to a Secure Boot-disabled build, > while preserving the contents & functionality of the variables), or just > a lucky coincidence that results from the design choices you made

[edk2] varstore compatibility between auth and non-auth

2016-02-05 Thread Laszlo Ersek
Hi Star, before you merged the two separate variable drivers in July 2015, each of the authenticated and the non-authenticated variable drivers would enforce its own GUID in the VARIABLE_STORE_HEADER.Signature field -- gEfiAuthenticatedVariableGuid and gEfiVariableGuid. The consequence was that

Re: [edk2] varstore compatibility between auth and non-auth

2016-02-05 Thread Laszlo Ersek
On 02/05/16 13:18, Gerd Hoffmann wrote: > Hi, > >> So, my question is: is this intended and supported behavior (that is, >> going from a Secure Boot-capable build to a Secure Boot-disabled build, >> while preserving the contents & functionality of the variables), or just >> a lucky coincidence