| Message ID | 20190402181505.25037-1-cclaudio@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Enabling secure boot on PowerNV systems | expand |
On Tue, Apr 2, 2019 at 11:15 AM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: > 1. Enable efivarfs by selecting CONFIG_EFI in the CONFIG_OPAL_SECVAR > introduced in this patch set. With CONFIG_EFIVAR_FS, userspace tools can > be used to manage the secure variables. efivarfs has some pretty significant behavioural semantics that directly reflect the EFI specification. Using it to expose non-EFI variable data feels like it's going to increase fragility - there's a risk that we'll change things in a way that makes sense for the EFI spec but breaks your use case. Is the desire to use efivarfs to maintain consistency with existing userland tooling, or just to avoid having a separate filesystem?
On 4/2/19 4:36 PM, Matthew Garrett wrote: > On Tue, Apr 2, 2019 at 11:15 AM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: >> 1. Enable efivarfs by selecting CONFIG_EFI in the CONFIG_OPAL_SECVAR >> introduced in this patch set. With CONFIG_EFIVAR_FS, userspace tools can >> be used to manage the secure variables. > efivarfs has some pretty significant behavioural semantics that > directly reflect the EFI specification. Using it to expose non-EFI > variable data feels like it's going to increase fragility - there's a > risk that we'll change things in a way that makes sense for the EFI > spec but breaks your use case. Is the desire to use efivarfs to > maintain consistency with existing userland tooling, or just to avoid > having a separate filesystem? > We want to use the efivarfs for compatibility with existing userspace tools. We will track and match any EFI changes that affect us. Our use case is restricted to secure boot - this is not going to be a general purpose EFI variable implementation. Claudio
On Tue, Apr 2, 2019 at 2:11 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: > We want to use the efivarfs for compatibility with existing userspace > tools. We will track and match any EFI changes that affect us. So you implement the full PK/KEK/db/dbx/dbt infrastructure, and updates are signed in the same way? > Our use case is restricted to secure boot - this is not going to be a > general purpose EFI variable implementation. In that case we might be better off with a generic interface for this purpose that we can expose on all platforms that implement a secure boot key hierarchy. Having an efivarfs that doesn't allow the creation of arbitrary attributes may break other existing userland expectations.
On 4/2/19 6:51 PM, Matthew Garrett wrote: > On Tue, Apr 2, 2019 at 2:11 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: >> We want to use the efivarfs for compatibility with existing userspace >> tools. We will track and match any EFI changes that affect us. > So you implement the full PK/KEK/db/dbx/dbt infrastructure, and > updates are signed in the same way? For the first version, our firmware will implement a simplistic PK, KEK and db infrastructure (without dbx and dbt) where only the Setup and User modes will be supported. PK, KEK and db updates will be signed the same way, that is, using userspace tooling like efitools in PowerNV. As for the authentication descriptors, only the EFI_VARIABLE_AUTHENTICATION_2 descriptor will be supported. >> Our use case is restricted to secure boot - this is not going to be a >> general purpose EFI variable implementation. > In that case we might be better off with a generic interface for this > purpose that we can expose on all platforms that implement a secure > boot key hierarchy. Having an efivarfs that doesn't allow the creation > of arbitrary attributes may break other existing userland > expectations. > For what it's worth, gsmi uses the efivars infrastructure for EFI-like variables. What might a generic interface look like? It would have to work for existing secure boot solutions - including EFI - which would seem to imply changes to userspace tools. Claudio
Hi Claudio, Thanks for posting this. Claudio Carvalho <cclaudio@linux.ibm.com> writes: > This patch set is part of a series that implements secure boot on > PowerNV systems. > > In order to verify the OS kernel on PowerNV, secure boot requires X.509 > certificates trusted by the platform, the secure boot modes, and several > other pieces of information. These are stored in secure variables > controlled by OPAL, also known as OPAL secure variables. > > This patch set adds the following features: > > 1. Enable efivarfs by selecting CONFIG_EFI in the CONFIG_OPAL_SECVAR > introduced in this patch set. With CONFIG_EFIVAR_FS, userspace tools can > be used to manage the secure variables. > 2. Add support for OPAL secure variables by overwriting the EFI hooks > (get_variable, get_next_variable, set_variable and query_variable_info) > with OPAL call wrappers. There is probably a better way to add this > support, for example, we are investigating if we could register the > efivar_operations rather than overwriting the EFI hooks. In this patch > set, CONFIG_OPAL_SECVAR selects CONFIG_EFI. If, instead, we registered > efivar_operations, CONFIG_EFIVAR_FS would need to depend on > CONFIG_EFI|| CONFIG_OPAL_SECVAR. Comments or suggestions on the > preferred technique would be greatly appreciated. I am *very* reluctant to start selecting CONFIG_EFI on powerpc. Simply because we don't actually have EFI, and I worry we're going to both break assumptions in the EFI code as well as impose requirements on the powerpc code that aren't really necessary. So I'd definitely prefer we go the route of enabling efivarfs with an alternate backend. Better still would be a generic secure variable interface as Matt suggests, if the userspace tools can be relatively easily adapted to use that interface. cheers
On 4/3/19 10:21 AM, Michael Ellerman wrote: > Hi Claudio, > > Thanks for posting this. > > Claudio Carvalho <cclaudio@linux.ibm.com> writes: >> This patch set is part of a series that implements secure boot on >> PowerNV systems. >> >> In order to verify the OS kernel on PowerNV, secure boot requires X.509 >> certificates trusted by the platform, the secure boot modes, and several >> other pieces of information. These are stored in secure variables >> controlled by OPAL, also known as OPAL secure variables. >> >> This patch set adds the following features: >> >> 1. Enable efivarfs by selecting CONFIG_EFI in the CONFIG_OPAL_SECVAR >> introduced in this patch set. With CONFIG_EFIVAR_FS, userspace tools can >> be used to manage the secure variables. >> 2. Add support for OPAL secure variables by overwriting the EFI hooks >> (get_variable, get_next_variable, set_variable and query_variable_info) >> with OPAL call wrappers. There is probably a better way to add this >> support, for example, we are investigating if we could register the >> efivar_operations rather than overwriting the EFI hooks. In this patch >> set, CONFIG_OPAL_SECVAR selects CONFIG_EFI. If, instead, we registered >> efivar_operations, CONFIG_EFIVAR_FS would need to depend on >> CONFIG_EFI|| CONFIG_OPAL_SECVAR. Comments or suggestions on the >> preferred technique would be greatly appreciated. > I am *very* reluctant to start selecting CONFIG_EFI on powerpc. > > Simply because we don't actually have EFI, and I worry we're going to > both break assumptions in the EFI code as well as impose requirements on > the powerpc code that aren't really necessary. Yes, we agree. We are working on the v2 and it is not going to depend on CONFIG_EFI. Rather, the IMA arch policies will make the OPAL calls directly. > > So I'd definitely prefer we go the route of enabling efivarfs with an > alternate backend. Right, I'm investigating how we can do that, but it looks like we should post that as a separate patchset to avoid delaying upstreaming signature verification based on the secure boot variables. Thanks, Claudio > > Better still would be a generic secure variable interface as Matt > suggests, if the userspace tools can be relatively easily adapted to use > that interface. > > cheers >
On Tue, Apr 2, 2019 at 4:31 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: > > > On 4/2/19 6:51 PM, Matthew Garrett wrote: > > So you implement the full PK/KEK/db/dbx/dbt infrastructure, and > > updates are signed in the same way? > > For the first version, our firmware will implement a simplistic PK, KEK and > db infrastructure (without dbx and dbt) where only the Setup and User modes > will be supported. Not supporting dbx seems like a pretty significant shortcoming. How are signatures meant to be revoked? > PK, KEK and db updates will be signed the same way, that is, using > userspace tooling like efitools in PowerNV. As for the authentication > descriptors, only the EFI_VARIABLE_AUTHENTICATION_2 descriptor will be > supported. Is this API documented? > > In that case we might be better off with a generic interface for this > > purpose that we can expose on all platforms that implement a secure > > boot key hierarchy. Having an efivarfs that doesn't allow the creation > > of arbitrary attributes may break other existing userland > > expectations. > > > For what it's worth, gsmi uses the efivars infrastructure for EFI-like > variables. My recollection is that at the time the Chromebook firmware still had EFI underpinnings and the gsmi code was largely just an alternate mechanism for calling into something that was fundamentally the EFI variable store. With hindsight I don't think layering this was the right move - we've adjusted the semantics of efivarfs on more than one occasion to deal with the behaviour of real-world EFI platforms, and I don't think it's helpful to end up in a situation where we're trying to keep behaviour consistent among entirely different firmware interfaces. > What might a generic interface look like? It would have to work for > existing secure boot solutions - including EFI - which would seem to imply > changes to userspace tools. I think that depends on exactly what problem you're trying to solve. Some aspects of the EFI secure boot design end up mirroring the economics of the PC ecosystem rather than being inherently good design goals, so it'd be helpful to know whether you're taking this solution because you want the same three-level key infrastructure or because that just leaves you compatible with the tooling.
On 4/3/19 7:27 PM, Matthew Garrett wrote: > On Tue, Apr 2, 2019 at 4:31 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: >> >> On 4/2/19 6:51 PM, Matthew Garrett wrote: >>> So you implement the full PK/KEK/db/dbx/dbt infrastructure, and >>> updates are signed in the same way? >> For the first version, our firmware will implement a simplistic PK, KEK and >> db infrastructure (without dbx and dbt) where only the Setup and User modes >> will be supported. > Not supporting dbx seems like a pretty significant shortcoming. How > are signatures meant to be revoked? We began by focusing on certificates for keys that can be added at runtime. Before adding support for revocation, we plan to gather additional use cases. In the meantime, unwanted certificates can be removed by the administrator. > >> PK, KEK and db updates will be signed the same way, that is, using >> userspace tooling like efitools in PowerNV. As for the authentication >> descriptors, only the EFI_VARIABLE_AUTHENTICATION_2 descriptor will be >> supported. > Is this API documented? The API is still a work in progress. We are planning to publish a document describing the current API and overall design shortly. Perhaps the biggest departure is that the secure variables are stored in flash memory that is not lockable. In order to protect the secure variables, hashes of the flash regions where they're stored are written to TPM NVRAM indices. The TPM NVRAM indices we use are write locked at runtime. The sysadmin enqueues update commands in flash. During the next boot, the firmware verifies and processes the commands to update the certificate store and accompanying integrity hashes in the TPM NVRAM indices and write locks them. Before certificates read from flash are used, the certificate store is hashed and compared against the hashes stored from the TPM. The one exception is the PK. We store it in a TPM NVRAM index by itself rather than flash because updates to it must be guaranteed to be atomic. >>> In that case we might be better off with a generic interface for this >>> purpose that we can expose on all platforms that implement a secure >>> boot key hierarchy. Having an efivarfs that doesn't allow the creation >>> of arbitrary attributes may break other existing userland >>> expectations. >>> >> For what it's worth, gsmi uses the efivars infrastructure for EFI-like >> variables. > My recollection is that at the time the Chromebook firmware still had > EFI underpinnings and the gsmi code was largely just an alternate > mechanism for calling into something that was fundamentally the EFI > variable store. With hindsight I don't think layering this was the > right move - we've adjusted the semantics of efivarfs on more than one > occasion to deal with the behaviour of real-world EFI platforms, and I > don't think it's helpful to end up in a situation where we're trying > to keep behaviour consistent among entirely different firmware > interfaces. > >> What might a generic interface look like? It would have to work for >> existing secure boot solutions - including EFI - which would seem to imply >> changes to userspace tools. > I think that depends on exactly what problem you're trying to solve. > Some aspects of the EFI secure boot design end up mirroring the > economics of the PC ecosystem rather than being inherently good design > goals, so it'd be helpful to know whether you're taking this solution > because you want the same three-level key infrastructure or because > that just leaves you compatible with the tooling. In our use case, the three-level key hierarchy conveniently supports the concept of (1) an administrator authority, who authorizes (2) other organizations, e.g., distros, to provide (3) certificates for their code signing keys. By using efivars, we leverage pre-existing userspace EFI tools to generate authenticated updates and certificates. Additionally, pre-existing kernel infrastructure simplifies efivars processing. Thanks, Claudio
On Fri, Apr 5, 2019 at 2:11 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: > > > On 4/3/19 7:27 PM, Matthew Garrett wrote: > > Not supporting dbx seems like a pretty significant shortcoming. How > > are signatures meant to be revoked? > > > We began by focusing on certificates for keys that can be added at > runtime. Before adding support for revocation, we plan to gather > additional use cases. In the meantime, unwanted certificates can be > removed by the administrator. Based on our experience doing this in UEFI, that's insufficient - you want to be able to block individual binaries or leaf certificates without dropping trust in an intermediate certificate entirely. > > > > >> PK, KEK and db updates will be signed the same way, that is, using > >> userspace tooling like efitools in PowerNV. As for the authentication > >> descriptors, only the EFI_VARIABLE_AUTHENTICATION_2 descriptor will be > >> supported. > > Is this API documented? > > > The API is still a work in progress. We are planning to publish a document > describing the current API and overall design shortly. Ok. How are the attributes interpreted by the API? > Perhaps the biggest departure is that the secure variables are stored in > flash memory that is not lockable. In order to protect the secure > variables, hashes of the flash regions where they're stored are written to > TPM NVRAM indices. The TPM NVRAM indices we use are write locked at > runtime. The sysadmin enqueues update commands in flash. During the next > boot, the firmware verifies and processes the commands to update the > certificate store and accompanying integrity hashes in the TPM NVRAM > indices and write locks them. Before certificates read from flash are > used, the certificate store is hashed and compared against the hashes > stored from the TPM. The one exception is the PK. We store it in a TPM > NVRAM index by itself rather than flash because updates to it must be > guaranteed to be atomic. What's the behaviour if multiple updates are enqueued? Does reading back show a mocked up updated variable or the original state? > > I think that depends on exactly what problem you're trying to solve. > > Some aspects of the EFI secure boot design end up mirroring the > > economics of the PC ecosystem rather than being inherently good design > > goals, so it'd be helpful to know whether you're taking this solution > > because you want the same three-level key infrastructure or because > > that just leaves you compatible with the tooling. > > > In our use case, the three-level key hierarchy conveniently supports the > concept of (1) an administrator authority, who authorizes (2) other > organizations, e.g., distros, to provide (3) certificates for their code > signing keys. By using efivars, we leverage pre-existing userspace EFI > tools to generate authenticated updates and certificates. Additionally, > pre-existing kernel infrastructure simplifies efivars processing. I'm not really clear on the workflow here. Who's the administrator authority? When would they be updating the second level of keys? If there's no support for revocation, why would distributions need two levels of key in the system database rather than just distributing a single intermediate and signing their actual signing certs with that?
On 4/5/19 7:19 PM, Matthew Garrett wrote: > On Fri, Apr 5, 2019 at 2:11 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: >> >> On 4/3/19 7:27 PM, Matthew Garrett wrote: >>> Not supporting dbx seems like a pretty significant shortcoming. How >>> are signatures meant to be revoked? >> >> We began by focusing on certificates for keys that can be added at >> runtime. Before adding support for revocation, we plan to gather >> additional use cases. In the meantime, unwanted certificates can be >> removed by the administrator. > Based on our experience doing this in UEFI, that's insufficient - you > want to be able to block individual binaries or leaf certificates > without dropping trust in an intermediate certificate entirely. We agree that a dbx would be useful for blacklisting particular kernels signed with given certificate. However, we have been avoiding doing so for the initial release of secure boot on OpenPOWER. We don't have individual firmware binaries in OpenPOWER. Kernels are currently the only concern for the OS secure boot certificates we're discussing here. Also, we have a very limited keystore space in POWER9. Petitboot doesn't have standardized OS kernel verification at all right now. Having the capability even without dbx seems valuable. > >>>> PK, KEK and db updates will be signed the same way, that is, using >>>> userspace tooling like efitools in PowerNV. As for the authentication >>>> descriptors, only the EFI_VARIABLE_AUTHENTICATION_2 descriptor will be >>>> supported. >>> Is this API documented? >> >> The API is still a work in progress. We are planning to publish a document >> describing the current API and overall design shortly. > Ok. How are the attributes interpreted by the API? We support a subset of standard EFI variable attributes, and we only use EFI variables that relate to secure boot. Our goal is not to implement UEFI. However, we do seek to be compatible with user space tooling and reuse as much existing infrastructure as possible. We don’t support the following: EFI_VARIABLE_HARDWARE_ERROR_RECORD, EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS and EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS. > >> Perhaps the biggest departure is that the secure variables are stored in >> flash memory that is not lockable. In order to protect the secure >> variables, hashes of the flash regions where they're stored are written to >> TPM NVRAM indices. The TPM NVRAM indices we use are write locked at >> runtime. The sysadmin enqueues update commands in flash. During the next >> boot, the firmware verifies and processes the commands to update the >> certificate store and accompanying integrity hashes in the TPM NVRAM >> indices and write locks them. Before certificates read from flash are >> used, the certificate store is hashed and compared against the hashes >> stored from the TPM. The one exception is the PK. We store it in a TPM >> NVRAM index by itself rather than flash because updates to it must be >> guaranteed to be atomic. > What's the behaviour if multiple updates are enqueued? Does reading > back show a mocked up updated variable or the original state? Our secure variable updates are only applied at boot time. If any one of them fails, they all fail. > >>> I think that depends on exactly what problem you're trying to solve. >>> Some aspects of the EFI secure boot design end up mirroring the >>> economics of the PC ecosystem rather than being inherently good design >>> goals, so it'd be helpful to know whether you're taking this solution >>> because you want the same three-level key infrastructure or because >>> that just leaves you compatible with the tooling. >> >> In our use case, the three-level key hierarchy conveniently supports the >> concept of (1) an administrator authority, who authorizes (2) other >> organizations, e.g., distros, to provide (3) certificates for their code >> signing keys. By using efivars, we leverage pre-existing userspace EFI >> tools to generate authenticated updates and certificates. Additionally, >> pre-existing kernel infrastructure simplifies efivars processing. > I'm not really clear on the workflow here. Who's the administrator > authority? When would they be updating the second level of keys? If > there's no support for revocation, why would distributions need two > levels of key in the system database rather than just distributing a > single intermediate and signing their actual signing certs with that? In OpenPOWER systems, we enable our customers and business partners to establish and manage the platform key certificate, which is the root of our key hierarchy. From there, through the KEK, they can delegate authority to intermediate level organizations, e.g. distros or IT departments or business operations. Those intermediate level organizations then manage the code signing certificates in the DB. If this answer doesn’t address your question, can you please rephrase? Thanks, Claudio
(Cc:ing Peter Jones) On Tue, Apr 9, 2019 at 3:55 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: > > > On 4/5/19 7:19 PM, Matthew Garrett wrote: > > Based on our experience doing this in UEFI, that's insufficient - you > > want to be able to block individual binaries or leaf certificates > > without dropping trust in an intermediate certificate entirely. > > > We agree that a dbx would be useful for blacklisting particular kernels > signed with given certificate. However, we have been avoiding doing so for > the initial release of secure boot on OpenPOWER. We don't have individual > firmware binaries in OpenPOWER. Kernels are currently the only concern for > the OS secure boot certificates we're discussing here. Also, we have a very > limited keystore space in POWER9. > > Petitboot doesn't have standardized OS kernel verification at all right > now. Having the capability even without dbx seems valuable. I don't see the benefit in attempting to maintain compatibility with existing tooling unless you're going to be *completely* compatible with existing tooling. That means supporting dbx and dbt. > >> The API is still a work in progress. We are planning to publish a document > >> describing the current API and overall design shortly. > > Ok. How are the attributes interpreted by the API? > > > We support a subset of standard EFI variable attributes, and we only use > EFI variables that relate to secure boot. Our goal is not to implement > UEFI. However, we do seek to be compatible with user space tooling and > reuse as much existing infrastructure as possible. We don’t support the > following: EFI_VARIABLE_HARDWARE_ERROR_RECORD, > EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS and > EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS. Ok. I think that's realistically fine. > > > > >> Perhaps the biggest departure is that the secure variables are stored in > >> flash memory that is not lockable. In order to protect the secure > >> variables, hashes of the flash regions where they're stored are written to > >> TPM NVRAM indices. The TPM NVRAM indices we use are write locked at > >> runtime. The sysadmin enqueues update commands in flash. During the next > >> boot, the firmware verifies and processes the commands to update the > >> certificate store and accompanying integrity hashes in the TPM NVRAM > >> indices and write locks them. Before certificates read from flash are > >> used, the certificate store is hashed and compared against the hashes > >> stored from the TPM. The one exception is the PK. We store it in a TPM > >> NVRAM index by itself rather than flash because updates to it must be > >> guaranteed to be atomic. > > What's the behaviour if multiple updates are enqueued? Does reading > > back show a mocked up updated variable or the original state? > > > Our secure variable updates are only applied at boot time. If any one of > them fails, they all fail. So I do the following: 1) Boot 2) Extend the contents of db 3) Extend the contents of db again 4) Read back the contents of db through efivarfs 5) Reboot 6) Read back the contents of db through efivarfs Is what I see in (4) and (6) the same? Does it contain the values form both extensions? > > I'm not really clear on the workflow here. Who's the administrator > > authority? When would they be updating the second level of keys? If > > there's no support for revocation, why would distributions need two > > levels of key in the system database rather than just distributing a > > single intermediate and signing their actual signing certs with that? > > > In OpenPOWER systems, we enable our customers and business partners to > establish and manage the platform key certificate, which is the root of our > key hierarchy. From there, through the KEK, they can delegate authority to > intermediate level organizations, e.g. distros or IT departments or > business operations. Those intermediate level organizations then manage the > code signing certificates in the DB. If this answer doesn’t address your > question, can you please rephrase? Why would the intermediate level organisations not just have entries in db? The main reason we don't do it this way in UEFI is because we need to support dbx, and if you're not supporting dbx I'm not sure I see the benefit.
Hi Matthew, Thanks for the feedback and sorry for the delay in responding. On 4/10/19 2:36 PM, Matthew Garrett wrote: > (Cc:ing Peter Jones) > > On Tue, Apr 9, 2019 at 3:55 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: >> >> On 4/5/19 7:19 PM, Matthew Garrett wrote: >>> Based on our experience doing this in UEFI, that's insufficient - you >>> want to be able to block individual binaries or leaf certificates >>> without dropping trust in an intermediate certificate entirely. >> >> We agree that a dbx would be useful for blacklisting particular kernels >> signed with given certificate. However, we have been avoiding doing so for >> the initial release of secure boot on OpenPOWER. We don't have individual >> firmware binaries in OpenPOWER. Kernels are currently the only concern for >> the OS secure boot certificates we're discussing here. Also, we have a very >> limited keystore space in POWER9. >> >> Petitboot doesn't have standardized OS kernel verification at all right >> now. Having the capability even without dbx seems valuable. > I don't see the benefit in attempting to maintain compatibility with > existing tooling unless you're going to be *completely* compatible > with existing tooling. That means supporting dbx and dbt. Before addressing that, I'd like to share some of the current OpenPOWER secure boot design. Different from UEFI, secure boot in OpenPOWER systems have two distinct domains. Each one has its own key hierarchy and signing and signature verification mechanisms. In the firmware secure boot domain (work already upstream): - Every image loaded up to skiroot is wrapped in a secure boot container. Skiroot is a Linux zimage with petitboot (kexec bootloader) embedded in the initramfs. - Within the secure boot container, the payload image is protected by a chain of signatures anchored in the root ECDSA keys, also known as hardware keys. - All public keys required to verify the container are stored in the container itself, but a hash of the trusted public hardware keys is stored in a protected SEEPROM region outside of the container. Firmware uses it to check if the container is anchored in the trusted hardware keys. If not, the container payload is not executed and the boot is aborted. - The hash of the hardware keys is set by the firmware supplier, for instance, the platform manufacturer. In OS secure boot domain (work in progress): - The skiroot container is verified as part of firmware secure boot. - Skiroot uses UEFI-like secure variables (PK, KEK and db) to verify OS kernels. Only X.509 certificates will be supported for these secure variables. - OS kernels are signed using the Linux kernel sign-file tool, as if they were kernel modules. - In the skiroot kernel, if secure boot is enabled, the db certificates will be loaded into the platform keyring and IMA-appraisal will verify the kexec image against the platform keyring. - The PK is set by whoever controls the platform, for instance, the manufacturer or the end customer. How about dbx and dbt? The db keys will be used to verify only OS kernels via kexecs initiated by petitboot. So we only need the dbx to revoke kernel images, either via certs or hashes. Currently, the kernel loads certs and hashes from the dbx to the system blacklist keyring. The revoked certs are checked during pkcs7 signature verification and loading of keys. However, there doesn't appear to be any verification against blacklisted hashes. Should kernel images be revoked only by keys and not hashes? We tried to find published revoked kernel lists but couldn't find any. How is kernel image revocation handled in practice? Also, we didn't see the shim or kernel loading anything from dbt. In general, how do you think the kernel ought to support blacklists? > >>>> The API is still a work in progress. We are planning to publish a document >>>> describing the current API and overall design shortly. >>> Ok. How are the attributes interpreted by the API? >> >> We support a subset of standard EFI variable attributes, and we only use >> EFI variables that relate to secure boot. Our goal is not to implement >> UEFI. However, we do seek to be compatible with user space tooling and >> reuse as much existing infrastructure as possible. We don’t support the >> following: EFI_VARIABLE_HARDWARE_ERROR_RECORD, >> EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS and >> EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS. > Ok. I think that's realistically fine. > >>>> Perhaps the biggest departure is that the secure variables are stored in >>>> flash memory that is not lockable. In order to protect the secure >>>> variables, hashes of the flash regions where they're stored are written to >>>> TPM NVRAM indices. The TPM NVRAM indices we use are write locked at >>>> runtime. The sysadmin enqueues update commands in flash. During the next >>>> boot, the firmware verifies and processes the commands to update the >>>> certificate store and accompanying integrity hashes in the TPM NVRAM >>>> indices and write locks them. Before certificates read from flash are >>>> used, the certificate store is hashed and compared against the hashes >>>> stored from the TPM. The one exception is the PK. We store it in a TPM >>>> NVRAM index by itself rather than flash because updates to it must be >>>> guaranteed to be atomic. >>> What's the behaviour if multiple updates are enqueued? Does reading >>> back show a mocked up updated variable or the original state? >> >> Our secure variable updates are only applied at boot time. If any one of >> them fails, they all fail. > So I do the following: > > 1) Boot > 2) Extend the contents of db > 3) Extend the contents of db again > 4) Read back the contents of db through efivarfs > 5) Reboot > 6) Read back the contents of db through efivarfs > > Is what I see in (4) and (6) the same? Does it contain the values form > both extensions? In (2) and (3) the extensions are added to the update queue, which is processed only in (5) by firmware. So, in (4) you should see the db content without the extensions. In (5), firmware (skiboot) will process the update queue. The extensions will be applied only if *all* of them are valid and pass signature verification. Only in this case should you be able to see the extensions in (6). If any of the extensions fail, firmware will discard all of them, clear the queue, and do the proper logging. >>> I'm not really clear on the workflow here. Who's the administrator >>> authority? When would they be updating the second level of keys? If >>> there's no support for revocation, why would distributions need two >>> levels of key in the system database rather than just distributing a >>> single intermediate and signing their actual signing certs with that? >> >> In OpenPOWER systems, we enable our customers and business partners to >> establish and manage the platform key certificate, which is the root of our >> key hierarchy. From there, through the KEK, they can delegate authority to >> intermediate level organizations, e.g. distros or IT departments or >> business operations. Those intermediate level organizations then manage the >> code signing certificates in the DB. If this answer doesn’t address your >> question, can you please rephrase? > Why would the intermediate level organisations not just have entries > in db? Because that seems to add more complexity than having three levels (PK, KEK and db). Typically, the intermediate level organisations (or KEK) are used to authorize new additions to db. However, if we also have them in the db, who would authorize the new additions to db. If that would be the intermediate level organisation entries now in the db, it seems we would need to implement a mechanism to determine which entries are for authorizing new additions and which are for kernel signature verification. If that would be the PK, we'd be burdening the PK owner to sign every new db addition if the platform is owned by a company that has intermediate level organizations. > The main reason we don't do it this way in UEFI is because we > need to support dbx, and if you're not supporting dbx I'm not sure I > see the benefit. I'm not sure I understand your question. We would be using dbx to prevent kernels from being loaded. How is that related to having three levels in the key hierarchy (PK, KEK and db)? Thanks, Claudio
On Fri, May 10, 2019 at 2:31 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote: > On 4/10/19 2:36 PM, Matthew Garrett wrote: > > I don't see the benefit in attempting to maintain compatibility with > > existing tooling unless you're going to be *completely* compatible > > with existing tooling. That means supporting dbx and dbt. (snip) > In OS secure boot domain (work in progress): > - The skiroot container is verified as part of firmware secure boot. > - Skiroot uses UEFI-like secure variables (PK, KEK and db) to verify OS > kernels. Only X.509 certificates will be supported for these secure variables. You don't support hashes? If so, this isn't compatible with UEFI Secure Boot and we shouldn't try to make it look like UEFI Secure Boot. > How about dbx and dbt? > > The db keys will be used to verify only OS kernels via kexecs initiated by > petitboot. So we only need the dbx to revoke kernel images, either via > certs or hashes. Currently, the kernel loads certs and hashes from the dbx > to the system blacklist keyring. The revoked certs are checked during pkcs7 > signature verification and loading of keys. However, there doesn't appear > to be any verification against blacklisted hashes. Should kernel images be > revoked only by keys and not hashes? We tried to find published revoked > kernel lists but couldn't find any. How is kernel image revocation handled > in practice? Hash-based revocation is in active use in the UEFI world - to the best of my knowledge, all existing dbx entries are hashes with the exception of the invalidation of the Microsoft Windows 2010 CA. > Also, we didn't see the shim or kernel loading anything from dbt. dbt is currently only used for validation at the firmware level - the way grub and kernel signatures are currently managed means it doesn't make a huge amount of sense to use it in shim, but it would probably be reasonable to extend shim's validation to include dbt. > > So I do the following: > > > > 1) Boot > > 2) Extend the contents of db > > 3) Extend the contents of db again > > 4) Read back the contents of db through efivarfs > > 5) Reboot > > 6) Read back the contents of db through efivarfs > > > > Is what I see in (4) and (6) the same? Does it contain the values form > > both extensions? > > In (2) and (3) the extensions are added to the update queue, which is > processed only in (5) by firmware. So, in (4) you should see the db content > without the extensions. Ok, this is not what we expect from UEFI systems. I'm strongly against providing what looks like the same ABI on multiple platforms but carrying subtle differences between those platforms - it's guaranteed to break tooling in unexpected ways. > In (5), firmware (skiboot) will process the update queue. The extensions > will be applied only if *all* of them are valid and pass signature > verification. Only in this case should you be able to see the extensions in > (6). If any of the extensions fail, firmware will discard all of them, > clear the queue, and do the proper logging. I believe that this is also a violation of expectations. > > Why would the intermediate level organisations not just have entries > > in db? > > Because that seems to add more complexity than having three levels (PK, KEK > and db). > > Typically, the intermediate level organisations (or KEK) are used to > authorize new additions to db. However, if we also have them in the db, who > would authorize the new additions to db. If that would be the intermediate > level organisation entries now in the db, it seems we would need to > implement a mechanism to determine which entries are for authorizing new > additions and which are for kernel signature verification. If that would be > the PK, we'd be burdening the PK owner to sign every new db addition if the > platform is owned by a company that has intermediate level organizations. Ok, in this scenario I don't understand why you wouldn't just want the intermediates in PK. Or, put another way - if you have a business justification for three layers of hierarchy, what do you do when someone has a business justification for four? The three layer hierarchy represents the weirdness of the PC industry where you have Microsoft needing to be in KEK (because they need to be able to issue updates to machines from multiple vendors) but not wanting to be in PK (because vendors don't want Microsoft to have ultimate control over their systems). If it weren't for this conflict, we'd just have a two layer hierarchy, and if some other aspect of the market had evolved over time we'd have a four layer hierarchy. > > > The main reason we don't do it this way in UEFI is because we > > need to support dbx, and if you're not supporting dbx I'm not sure I > > see the benefit. > > I'm not sure I understand your question. We would be using dbx to prevent > kernels from being loaded. How is that related to having three levels in > the key hierarchy (PK, KEK and db)? dbx entries come from Microsoft, so we need the KEK layer so Microsoft can update dbx. If Microsoft didn't need to update dbx then we'd leave Microsoft out of KEK, and then KEK and PK would be the same and we'd be able to get rid of KEK.