From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::342; helo=mail-wm1-x342.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 361162117D75A for ; Tue, 20 Nov 2018 06:39:17 -0800 (PST) Received: by mail-wm1-x342.google.com with SMTP id y185so1128516wmd.1 for ; Tue, 20 Nov 2018 06:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=vTS9AjKyNxXzUXWYCK0gF1GU0Fm+xcNCX4SoPX8nrec=; b=MWQV5LgviwytjwWyie1YlCuyeje4coHGqFvuO63gD5GAOP0MGImFQ4AmaY4KfEWMHa I95lUdvNlBj4UkMOgbXtMgWFAOpDw63E9c1/wEArWQOuJZaJnDW3DrmJpgGCqjWdHgcc IewQFICkBTZc5S0oeeKu211Gx2QXiWk32gUhg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=vTS9AjKyNxXzUXWYCK0gF1GU0Fm+xcNCX4SoPX8nrec=; b=Ct0KXRuYpZ+qyb72sivcUjICJ9i5DxlnDgq/a526M14A9bnZGf2KEYxBmEWiyfUBGZ 9OuJ/hQtsm81UKQg/Y/iO+s9Sg1kV14DRGu4veau7hZFF4EgtDKJQFBdFB26wGatlJ4X iubJ2SEttO5ukUa3GgaXDg9LPefAbORU5+jnmzVn0ymJlzQ6UhvGrPCbl7Kt24XyMrO5 ZVy8wAjqCuGE3jLhlcDda4C8CcbUD4aPOXRJ9qIN8MQpvPUwtwTpyXwddtmS4rKPft2F D0uNAUr97Fz8WjKnYWQx6IlHPc2gOAECMQyc2WisaGjqE0x8qv3ymRXED7oekMvtMwgY TXAQ== X-Gm-Message-State: AA+aEWbwU+pxl9KPMSuzICM4XkupBnd/9EcWITWbQcCUUNJBSilUZxZA tUvEJ1Uu0zBTIKkOpjC6Z+P6WQ== X-Google-Smtp-Source: AJdET5crblAPcOVgjCQqNEmR6drsnuS62O4MHTXupYYy2EcRoZ+ehheFc9fpbqjg6GnBtMnxy+XeuQ== X-Received: by 2002:a1c:18c:: with SMTP id 134mr2287676wmb.94.1542724755582; Tue, 20 Nov 2018 06:39:15 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id t82-v6sm38096965wme.30.2018.11.20.06.39.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Nov 2018 06:39:14 -0800 (PST) Date: Tue, 20 Nov 2018 14:39:13 +0000 From: Leif Lindholm To: Ming Huang Cc: linaro-uefi@lists.linaro.org, edk2-devel@lists.01.org, graeme.gregory@linaro.org, ard.biesheuvel@linaro.org, michael.d.kinney@intel.com, lersek@redhat.com, wanghuiqiang@huawei.com, huangming23@huawei.com, zhangjinsong2@huawei.com, huangdaode@hisilicon.com, john.garry@huawei.com, xinliang.liu@linaro.org, zhangfeng56@huawei.com Message-ID: <20181120143912.p7jeqwjgtqsgmf75@bivouac.eciton.net> 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> MIME-Version: 1.0 In-Reply-To: <1e4db632-9c2c-79e0-2bbe-cdc7913aa0c5@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) 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:39:17 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 20, 2018 at 10:29:57PM +0800, Ming Huang wrote: > >>> 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. OK, I will ask a third time: what _problem_ does this solve? What is the symptom? When someone uses the buggy firmware, what does not work for them? This information _always_ needs to be in the commit message. > >> 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. If there is not enough time to implement a real PlatformSecureLib, there is no need to have Secure Boot at all. Same thing goes for secure variable store (to hardware devices that are not accessible from Non-secure world). > This patch will add when we implement real secure boot in future. That sounds like the best thing to do. Meanwhile, could you create a patch to get rid of the SECURE_BOOT options completely from the .dsc/.fdf please? I don't like having it in there when we know it doesn't build. / Leif