From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:400e:c05::234; helo=mail-pg0-x234.google.com; envelope-from=df7729@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 9E3772007E7E2 for ; Tue, 1 May 2018 19:23:40 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id z129-v6so5319406pgz.3 for ; Tue, 01 May 2018 19:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RZM7GzmGxamhQhOdSc9hZVAmfLM2jlajFILCWVpapc4=; b=q9fSjVuGtkTv0OTRPqrjhSu/kU4AqQOABQ+y08GIJjRVeIrtztaQ/0P4sdNHxF7pkK n0GO2qqUkLhvnQqcsFGEFIHW/yJpDupMC9c8tFbnd8E7WqieA2q0z91ifi4MOWr7mUrB 6wBWp3cVil8N24XOleQLx9lInJ6I/PgjIj/N6cVzrybeiqp8pcv7EprzFAPR7Mm8AGMT U9IX8aN+ui8DLXCtU9IFg95JGVInsvKhTZ5nzDiRk5c5IkJJHRCvs4qHMUNJ3ao/l0DD GatKWcwoRFmWM9bYpvc8RgJNihEJWorL0JoZ9uAQL2JSq8Jog9JVyENonQUGtMk6AHF7 ksTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RZM7GzmGxamhQhOdSc9hZVAmfLM2jlajFILCWVpapc4=; b=fmDlKweKweU2t3T9jVSoZ9zx7LA2nv0rwvUf3qBNBivglgWZfhXMD7Tq1KtEk9Bvon lNuxIqOt9/M/jQlBXevfRXFIKP6gc6IAtFI04Lf1GTnNAnR0JXn23MxYKCtOD4c8Kz5F nZDRrYKJRXweO63xb+fHS31/scLu+0zBURMnwNf6ndc6LSnjdWuS1PGbMJldtYQKJQ3O zdMvh5fL8qRrVX5yUP3WP8YIVlERZkFCS6mD8mouiDnfFrt6jMAov7nriNX/cZrtTa9E 1S0dpc5gi0fB/2h7S22EJnJlucvN5nWDcQD37JNyxMsP/v4flJdBWzGnO+0WUldxx672 J+UA== X-Gm-Message-State: ALQs6tBN07zv0q4PnRTWvBkOWOJL9HMV06Vgs5HfyGWQTB2XgiewYuhi k+IoGt2hIZHwLLptHrOKsg5TOZFyP3Ta4P3jVeU= X-Google-Smtp-Source: AB8JxZp8KzI/MNmpK9zv4GIgpIOpAKxXUpMDRSJfTo0fcVTgFq2MwTyGpw2ANYjvGXXxqvx7pH5V8lyjt6O8b8z8Kgw= X-Received: by 2002:a63:a74b:: with SMTP id w11-v6mr14601432pgo.351.1525227820061; Tue, 01 May 2018 19:23:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.172.9 with HTTP; Tue, 1 May 2018 19:23:39 -0700 (PDT) In-Reply-To: <201805011425.24074.wpaul@windriver.com> References: <201805011425.24074.wpaul@windriver.com> From: "David F." Date: Tue, 1 May 2018 19:23:39 -0700 Message-ID: To: Bill Paul Cc: edk2 developers list 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: Wed, 02 May 2018 02:23:40 -0000 Content-Type: text/plain; charset="UTF-8" I'm with you, but the question I would have is how much checking does it end up doing? In other words, how can a fake PKCS#7 be created in a small amount of code that would make the guard happy enough to let it through in setup mode? I just don't see the point of even having to create one when it is going to be ignored anyway? Thanks. On Tue, May 1, 2018 at 2:25 PM, Bill Paul wrote: > 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 > =============================================================================