On Wed, Nov 23, 2016 at 02:13:28PM +0000, David Howells wrote: > Mark Rutland <mark.rutland@xxxxxxx> wrote: > > > > > if (secure_boot < 0) > > > > pr_efi_err(sys_table, > > > > "could not determine UEFI Secure Boot status.\n"); > > > > > > In which case, should this be moved into efi_get_secureboot() and it return a > > > bool? > > > > That would make sense to me, provided we're only likely to call that > > once (and only log once). > > > > I guess it would also make sense to change the latter case to soemthing > > like: > > > > Could not determine UEFI Secure Boot status. Assuming enabled. > > > > ... so as to make it clear what the effect is. > > Actually, the two arches have a different interpretation on how to deal with > an error. Matthew Garrett's original x86 patch assumes that if we get an > error when trying to read SecureBoot and SetupMode that we're *not* in secure > mode, but ARM assumes the opposite. Ok. IIUC, that x86 patch was never upstream, so is there any need to follow that example? Was there a rationale for that, or can we simply follow the upstream ARM example? Perhaps it's best to ask Matthew? Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
