From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::d41; helo=mail-io1-xd41.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4BCAC21191729 for ; Tue, 20 Nov 2018 06:40:23 -0800 (PST) Received: by mail-io1-xd41.google.com with SMTP id l14so1370812ioj.5 for ; Tue, 20 Nov 2018 06:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nnw60D20G5GifZZcRY1dR8AW75ugK/KHKuqtQaBehe4=; b=Xsx2kbt1PdkYc0zHWVIoTmKKUsVBcWFXh1IndT4ETNnoI/t2mzeKAu/ds+pb5CnAT7 39ih4/wP379C9nh9utRF6GqcKLTu6PWwqMw/wirsC78Et6eYWQ84YLLazRyqbnh0tUh7 thWJ1GJKZBGA7e6HegWa59Tg5nEZypfr1t2jA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nnw60D20G5GifZZcRY1dR8AW75ugK/KHKuqtQaBehe4=; b=biUEF3IJV7bnLeThafGOkHhfVS7/yyl5cM+WuqGs3KXkIzoEW3bjNbSRvYYH/b+SWd k5jrngWN5KwM+lyRUv76JIxcQlJirjRAGKwRrZIqkzSJkQZJaHsLJqjCf2EpOC7j9mu3 5nuMaFSj6D4uU+2JSU9sTfEU3ufM0qCCTNuNXpoHXNR/w3yEizrpONaDm/Uo7P9Ai4CW JTPw2ZibauNy0WH/gfHzZvCxDCort8uV1XO677h4jB691ORcv4oGekNiwg9mwHAdyi9u hmGxguYN5n1BrvlIszP3+QBB1K2/smKCpdIeUNX1PHVD3n/m1jN8nrxZ/WNWiTpgvlU3 QfjQ== X-Gm-Message-State: AA+aEWZ/Y08XBA5TeeiXIeTlIU6Uo+NXoGGiaUYxmnI12VlnvOGgZO1n JpiaZLa5Ch6uI6nA0sYsJt9/cLU7uFCbplivRP4szw== X-Google-Smtp-Source: AFSGD/Wh4Gg+tkm6Qpw2DpuFqTIhAZKfGQHl86tK/E0sfzKexhy4u/e3kbs/ns8Rj3tN9ATjru0a9o54v9K45J2Foww= X-Received: by 2002:a6b:7a46:: with SMTP id k6mr1827415iop.60.1542724822369; Tue, 20 Nov 2018 06:40:22 -0800 (PST) MIME-Version: 1.0 References: <20181120090150.1102-1-ming.huang@linaro.org> <20181120090150.1102-2-ming.huang@linaro.org> <20181120121309.mwsoxljgjwy4yv7i@bivouac.eciton.net> <20181120125805.jn6xfxbg47izxwo2@bivouac.eciton.net> <1e4db632-9c2c-79e0-2bbe-cdc7913aa0c5@linaro.org> In-Reply-To: <1e4db632-9c2c-79e0-2bbe-cdc7913aa0c5@linaro.org> From: Ard Biesheuvel Date: Tue, 20 Nov 2018 15:40:11 +0100 Message-ID: To: Ming Huang Cc: Leif Lindholm , linaro-uefi , "edk2-devel@lists.01.org" , Graeme Gregory , "Kinney, Michael D" , Laszlo Ersek , wanghuiqiang , huangming , Jason Zhang , huangdaode@hisilicon.com, John Garry , Xinliang Liu , zhangfeng56@huawei.com Subject: Re: [PATCH edk2-platforms v3 1/5] Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 14:40:23 -0000 Content-Type: text/plain; charset="UTF-8" On Tue, 20 Nov 2018 at 15:30, Ming Huang 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.