Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1571448
| From | Ard Biesheuvel <ard.biesheuvel@linaro.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] |
| Date | 2017-02-01 11:20 +0100 |
| Message-ID | <t60b8-4DF-3@gated-at.bofh.it> (permalink) |
| References | <t5InT-2gX-3@gated-at.bofh.it> <t5InT-2gX-15@gated-at.bofh.it> <t5LlM-41b-25@gated-at.bofh.it> <t5LON-4b0-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 31 January 2017 at 18:59, David Howells <dhowells@redhat.com> wrote: > Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > >> > UEFI-2.6 adds a new variable, DeployedMode. If it exists, this must be 1 >> > if we're to engage lockdown mode. >> > >> > Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com> >> > Signed-off-by: David Howells <dhowells@redhat.com> >> >> Interestingly, the string 'DeployedMode' appears zero times in the >> EDK2 codebase, so I wonder if it makes any sense to merge this now. >> The string 'AuditMode' does appear once, but in a comment > > It's in the standard, so shouldn't we check for it? > >> In any case, the logic is not entirely correct either: apologies if it >> was me who caused any confusion here, but it seems DeployedMode could >> legally be 0 or 1 while secure boot is in fact enabled. It is actually >> AuditMode that should be taken into account here, i.e., if AuditMode >> == 1, the firmware ignores invalid or missing signatures. If >> SecureBoot == 0x1, SetupMode == 0x0 and AuditMode == 0x0 (or >> non-existent), signature verification is performed regardless of the >> value (or existence) of DeployedMode. >> >> So I propose to respin this patch to treat AuditMode == 0x1 as 'secure >> boot disabled', and ignore if it is missing. > > Ummm... This might conflict what said: > > | Since you seem to be using this to mean "is the platform locked down?", > | this looks to be no longer complete in the UEFI 2.6 world. If > | DeployedMode == 0, even if SecureBoot == 1 and SetupMode == 0, you can > | remove the platform key by writing 1 to AuditMode and gain control of > | the secure variables. The lock down state becomes DeployedMode == 1, > | SecureBoot == 1 and SetupMode == 0 > | > | See the diagram on page 1817 > | > | http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf > > Looking again at that diagram, should I be checking all four variables > (SecureBoot, SetupMode, DeployedMode and AuditMode)? And/or should I treat > audit mode differently to deployed mode? > Well, we are trying to decide whether the system is locked down or not. AuditMode is only writable before ExitBootServices(), and when AuditMode == 0, signature verification occurs as usual, regardless of the value of DeployedMode. Whether someone could turn on AuditMode on the *next* boot does not sound that relevant to me, since someone could also re-enter SetupMode in the same way. So this patch should take AuditMode into account, but not DeployedMode, i.e., SecureBoot == 0x1 SetupMode == 0x0 AuditMode == 0x0 (or non-existent) implies a locked down state. > Further, there doesn't seem to be a state in which SecureBoot is shown as > being 1. > Yes, that is sloppy. But the fact that EDK2, being the v2.6 reference, does not implement any of this *at all* is much more worrying to me, given that UDK2017 based firmware will certainly turn up in production systems.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] David Howells <dhowells@redhat.com> - 2017-01-31 16:20 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-01-31 19:30 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] David Howells <dhowells@redhat.com> - 2017-01-31 20:00 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] David Howells <dhowells@redhat.com> - 2017-02-01 11:10 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-02-01 11:20 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] David Howells <dhowells@redhat.com> - 2017-02-01 13:40 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-02-01 15:50 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] David Howells <dhowells@redhat.com> - 2017-02-01 16:10 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-02-01 16:10 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] Matt Fleming <matt@codeblueprint.co.uk> - 2017-02-02 22:40 +0100
Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-02-02 22:50 +0100
csiph-web