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
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
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
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
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
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
6 matches
Mail list logo