Re: [PATCH edk2-platforms v3 1/5] Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe

[Laszlo Ersek <lersek@redhat.com>]

On 11/20/18 15:40, Ard Biesheuvel wrote:
> On Tue, 20 Nov 2018 at 15:30, Ming Huang <ming.huang@linaro.org> wrote:
>>
>>
>>
>> On 11/20/2018 8:58 PM, Leif Lindholm wrote:
>>> On Tue, Nov 20, 2018 at 08:40:28PM +0800, Ming Huang wrote:
>>>>
>>>>
>>>> On 11/20/2018 8:13 PM, Leif Lindholm wrote:
>>>>> On Tue, Nov 20, 2018 at 05:01:46PM +0800, Ming Huang wrote:
>>>>>> Now that the generic Variable Runtime DXE code no longer
>>>>>> distinguishes between gEfiVariableGuid and
>>>>>> gEfiAuthenticatedVariableGuid in the varstore FV header.
>>>>>> We can relax the check in the flashFvb driver to accept
>>>>>> either GUID regardless of whether we are running a secure
>>>>>> boot capable build or not.
>>>>>
>>>>> We are still in a situation where D06 is not buildable with Secure
>>>>> Boot enabled though.
>>>>>
>>>>> If you build with -D SECURE_BOOT_ENABLE=TRUE, you still end up with
>>>>> /work/git/edk2-platforms/Platform/Hisilicon/D06/D06.dsc(...): error
>>>>> 4000: Instance of library class [PlatformSecureLib] is not found
>>>>>       in [/work/git/edk2/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf] [AARCH64]
>>>>>       consumed by module [/work/git/edk2/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf]
>>>>>
>>>>> And all Hisilicon platforms still use
>>>>> AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
>>>>> regardless of Secure Boot setting.
>>>>>
>>>>> So what problem does this patch solve? A runtime one?
>>>>
>>>> This patch solve bug in FlashFvbDxe.
>>>
>>> Yes, but what bug? What is the symptom? What _specific_ problem goes
>>> away by adding this patch? That information should have been in the
>>> original commit message. I have no information available to me as I
>>> now build -rc1 to suggest that this patch should be included.
>>
>> The bug is that gEfiAuthenticatedVariableGuid should be used in FlashFvbDxe,
>> not gEfiVariableGuid when enable secure boot.
>>
>>>
>>>> Should I add a patch before this patch
>>>> to solve build error with -D SECURE_BOOT_ENABLE=TRUE in v4?
>>>
>>> That would require a sane implementation of PlatformSecureLib,
>>> implementing a real UserPhysicalPresent().
>>> Can you turn that around within the next few hours?
>>
>> My original idea is using OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.
>> There is not enough time to implement a real UserPhysicalPresent.
>> This patch will add when we implement real secure boot in future.
>>
> 
> I think it is a terrible idea to enable secure boot now in an insecure
> manner, and enable 'real' secure boot later.
> 
> Note that it is impossible to implement secure boot in a secure manner
> using the generic VariableRuntimeDxe. The crypto routines that perform
> the authentication are located in EfiRuntimeServicesCode memory
> regions, which are writable by the OS, and so any exploit on the OS
> side can modify that code to defeat the checks. Also, the SPI flash
> that backs the variable store is accessible by the OS directly.
> 
> That means a proper secure boot implementation will not be based on
> any of the components in use currently, and so enabling it does
> nothing except confuse people or give them a false sense of security.
> If this is based on OS or firmware test results, please disregard
> those - this is a tick the box mentality that is wholly incompatible
> with building secure systems.
> 

Yup.

Thanks,
Laszlo