From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.11.1.11; helo=mail.windriver.com; envelope-from=bill.paul@windriver.com; receiver=edk2-devel@lists.01.org Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5D0EC2007E814 for ; Tue, 1 May 2018 14:26:05 -0700 (PDT) Received: from ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) by mail.windriver.com (8.15.2/8.15.1) with ESMTPS id w41LQ2oA009881 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 May 2018 14:26:02 -0700 (PDT) Received: from ala-wpaul-lx1.wrs.com (147.11.157.242) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 1 May 2018 14:26:02 -0700 From: Bill Paul Organization: Wind River Systems To: Date: Tue, 1 May 2018 14:25:23 -0700 User-Agent: KMail/1.13.5 (Linux/2.6.32-28-generic; KDE/4.4.5; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Message-ID: <201805011425.24074.wpaul@windriver.com> Subject: Re: Set "db" variable in secure boot setup mode still requires generating PKCS#7? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 21:26:05 -0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Of all the gin joints in all the towns in all the world, David F. had to walk into mine at 14:13 on Tuesday 01 May 2018 and say: > Hi, > > Had a fairly simple task of wanting to install the latest MS .crt > files for KEK, and their two files for the "db" (the Windows CA and > UEFI CA) in a system placed in setup/custom mode. However, even > though it seemed to take the KEK, it never took the "db", always had a > problem on a DH77KC mobo (dumped data headers looked as expected). > Now when I constructed it, I thought I could leave out any PKCS#7 data > (set the expected CertType but in the Hdr dwLength only included > CertType and not any CertData), but looking at the algo in UEFI Spec > 2.6 page 245, it looks like we'd always have to generate the hash, > sign it, create all the PKCS stuff even in setup mode? That would > surely unnecessarily bloat any apps that really only need to update > things in setup mode wouldn't it? So to confirm, that is a > requirement even in setup mode? If so, why? > If I understand correctly, I think the issue is that the PK, KEK, db and dbx are always considered to be secure environment variables, which means when you try to update them with SetVariable(), you always have to include one of the authentication flags and a properly formated authentication header. The difference between variable updates in secure mode vs. setup/custom mode is that in setup/custom mode, the signature is not validated. It still has to be there, but the firmware doesn't care what it says. So the db update could be signed with a completely different KEK than the one loaded into the KEK variable, and it would still be accepted. -Bill > TIA!! > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, wpaul@windriver.com | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin =============================================================================