| Message ID | 20200826034455.28707-3-lszubowi@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | integrity: Load certs from EFI MOK config table | expand |
On Tue, 2020-08-25 at 23:44 -0400, Lenny Szubowicz wrote: > Move the loading of certs from the UEFI MokListRT into a separate > routine to facilitate additional MokList functionality. > > There is no visible functional change as a result of this patch. > Although the UEFI dbx certs are now loaded before the MokList certs, > they are loaded onto different key rings. So the order of the keys > on their respective key rings is the same. > > Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
On Wed, Aug 26, 2020 at 6:45 AM Lenny Szubowicz <lszubowi@redhat.com> wrote: > > Move the loading of certs from the UEFI MokListRT into a separate > routine to facilitate additional MokList functionality. > > There is no visible functional change as a result of this patch. > Although the UEFI dbx certs are now loaded before the MokList certs, > they are loaded onto different key rings. So the order of the keys > on their respective key rings is the same. ... > /* > + * load_moklist_certs() - Load MokList certs > + * > + * Returns: Summary error status > + * > + * Load the certs contained in the UEFI MokListRT database into the > + * platform trusted keyring. > + */ Hmm... Is it intentionally kept out of kernel doc format? > +static int __init load_moklist_certs(void) > +{ > + efi_guid_t mok_var = EFI_SHIM_LOCK_GUID; > + void *mok = NULL; > + unsigned long moksize = 0; > + efi_status_t status; > + int rc = 0; Redundant assignment (see below). > + /* Get MokListRT. It might not exist, so it isn't an error > + * if we can't get it. > + */ > + mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status); > + if (!mok) { Why not positive conditional? Sometimes ! is hard to notice. > + if (status == EFI_NOT_FOUND) > + pr_debug("MokListRT variable wasn't found\n"); > + else > + pr_info("Couldn't get UEFI MokListRT\n"); > + } else { > + rc = parse_efi_signature_list("UEFI:MokListRT", > + mok, moksize, get_handler_for_db); > + if (rc) > + pr_err("Couldn't parse MokListRT signatures: %d\n", rc); > + kfree(mok); kfree(...) if (rc) ... return rc; And with positive conditional there will be no need to have redundant 'else' followed by additional level of indentation. > + } > + return rc; return 0; > +} P.S. Yes, I see that the above was in the original code, so, consider my comments as suggestions to improve the code.
On 9/2/20 3:55 AM, Andy Shevchenko wrote: > On Wed, Aug 26, 2020 at 6:45 AM Lenny Szubowicz <lszubowi@redhat.com> wrote: >> >> Move the loading of certs from the UEFI MokListRT into a separate >> routine to facilitate additional MokList functionality. >> >> There is no visible functional change as a result of this patch. >> Although the UEFI dbx certs are now loaded before the MokList certs, >> they are loaded onto different key rings. So the order of the keys >> on their respective key rings is the same. > > ... > >> /* >> + * load_moklist_certs() - Load MokList certs >> + * >> + * Returns: Summary error status >> + * >> + * Load the certs contained in the UEFI MokListRT database into the >> + * platform trusted keyring. >> + */ > > Hmm... Is it intentionally kept out of kernel doc format? Yes. Since this is a static local routine, I thought that it shouldn't be included by kerneldoc. But I wanted to generally adhere to the kernel doc conventions for a routine header. To that end, in V2 I move the "Return:" section to come after the short description. > >> +static int __init load_moklist_certs(void) >> +{ >> + efi_guid_t mok_var = EFI_SHIM_LOCK_GUID; >> + void *mok = NULL; >> + unsigned long moksize = 0; >> + efi_status_t status; >> + int rc = 0; > > Redundant assignment (see below). > >> + /* Get MokListRT. It might not exist, so it isn't an error >> + * if we can't get it. >> + */ >> + mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status); > >> + if (!mok) { > > Why not positive conditional? Sometimes ! is hard to notice. > >> + if (status == EFI_NOT_FOUND) >> + pr_debug("MokListRT variable wasn't found\n"); >> + else >> + pr_info("Couldn't get UEFI MokListRT\n"); >> + } else { >> + rc = parse_efi_signature_list("UEFI:MokListRT", >> + mok, moksize, get_handler_for_db); >> + if (rc) >> + pr_err("Couldn't parse MokListRT signatures: %d\n", rc); >> + kfree(mok); > > kfree(...) > if (rc) > ... > return rc; > > And with positive conditional there will be no need to have redundant > 'else' followed by additional level of indentation. > >> + } > >> + return rc; > > return 0; > >> +} > > P.S. Yes, I see that the above was in the original code, so, consider > my comments as suggestions to improve the code. > I agree that your suggestions improve the code. I've incorporated this into V2. -Lenny.
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c index 253fb9a7fc98..547410d8ffa5 100644 --- a/security/integrity/platform_certs/load_uefi.c +++ b/security/integrity/platform_certs/load_uefi.c @@ -66,6 +66,43 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid, } /* + * load_moklist_certs() - Load MokList certs + * + * Returns: Summary error status + * + * Load the certs contained in the UEFI MokListRT database into the + * platform trusted keyring. + */ +static int __init load_moklist_certs(void) +{ + efi_guid_t mok_var = EFI_SHIM_LOCK_GUID; + void *mok = NULL; + unsigned long moksize = 0; + efi_status_t status; + int rc = 0; + + /* Get MokListRT. It might not exist, so it isn't an error + * if we can't get it. + */ + mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status); + if (!mok) { + if (status == EFI_NOT_FOUND) + pr_debug("MokListRT variable wasn't found\n"); + else + pr_info("Couldn't get UEFI MokListRT\n"); + } else { + rc = parse_efi_signature_list("UEFI:MokListRT", + mok, moksize, get_handler_for_db); + if (rc) + pr_err("Couldn't parse MokListRT signatures: %d\n", rc); + kfree(mok); + } + return rc; +} + +/* + * load_uefi_certs() - Load certs from UEFI sources + * * Load the certs contained in the UEFI databases into the platform trusted * keyring and the UEFI blacklisted X.509 cert SHA256 hashes into the blacklist * keyring. @@ -73,17 +110,16 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid, static int __init load_uefi_certs(void) { efi_guid_t secure_var = EFI_IMAGE_SECURITY_DATABASE_GUID; - efi_guid_t mok_var = EFI_SHIM_LOCK_GUID; - void *db = NULL, *dbx = NULL, *mok = NULL; - unsigned long dbsize = 0, dbxsize = 0, moksize = 0; + void *db = NULL, *dbx = NULL; + unsigned long dbsize = 0, dbxsize = 0; efi_status_t status; int rc = 0; if (!efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE)) return false; - /* Get db, MokListRT, and dbx. They might not exist, so it isn't - * an error if we can't get them. + /* Get db and dbx. They might not exist, so it isn't an error + * if we can't get them. */ if (!uefi_check_ignore_db()) { db = get_cert_list(L"db", &secure_var, &dbsize, &status); @@ -102,20 +138,6 @@ static int __init load_uefi_certs(void) } } - mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status); - if (!mok) { - if (status == EFI_NOT_FOUND) - pr_debug("MokListRT variable wasn't found\n"); - else - pr_info("Couldn't get UEFI MokListRT\n"); - } else { - rc = parse_efi_signature_list("UEFI:MokListRT", - mok, moksize, get_handler_for_db); - if (rc) - pr_err("Couldn't parse MokListRT signatures: %d\n", rc); - kfree(mok); - } - dbx = get_cert_list(L"dbx", &secure_var, &dbxsize, &status); if (!dbx) { if (status == EFI_NOT_FOUND) @@ -131,6 +153,9 @@ static int __init load_uefi_certs(void) kfree(dbx); } + /* Load the MokListRT certs */ + rc = load_moklist_certs(); + return rc; } late_initcall(load_uefi_certs);
Move the loading of certs from the UEFI MokListRT into a separate routine to facilitate additional MokList functionality. There is no visible functional change as a result of this patch. Although the UEFI dbx certs are now loaded before the MokList certs, they are loaded onto different key rings. So the order of the keys on their respective key rings is the same. Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com> --- security/integrity/platform_certs/load_uefi.c | 63 +++++++++++++------ 1 file changed, 44 insertions(+), 19 deletions(-)