lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <beedd453a1ec674d3986f7c3851f30df516d2fbb.camel@linux.ibm.com> Date: Fri, 22 Oct 2021 13:31:57 -0400 From: Mimi Zohar <zohar@...ux.ibm.com> To: Nayna <nayna@...ux.vnet.ibm.com>, linux-integrity@...r.kernel.org, keyrings@...r.kernel.org Cc: dhowells@...hat.com, jarkko@...nel.org, seth.forshee@...onical.com, linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>, Nayna Jain <nayna@...ux.ibm.com> Subject: Re: [PATCH v3] integrity: support including firmware ".platform" keys at build time On Tue, 2021-10-19 at 14:25 -0400, Nayna wrote: > Gentle reminder for v3. Is this version good now for acceptance ? > > Thanks & Regards, > > - Nayna > > On 10/4/21 10:52 AM, Nayna Jain wrote: > > Some firmware support secure boot by embedding static keys to verify the > > Linux kernel during boot. However, these firmware do not expose an > > interface for the kernel to load firmware keys onto ".platform" keyring. > > This would prevent kernel signature verification on kexec. > > > > For these environments, a new function load_builtin_platform_cert() is > > defined to load compiled in certificates onto the ".platform" keyring. > > > > load_certificate_list() is currently used for parsing compiled in > > certificates to be loaded onto the .builtin or .blacklist keyrings. > > Export load_certificate_list() allowing it to be used for parsing compiled > > in ".platform" keyring certificates as well. > > > > Reported-by: kernel test robot <lkp@...el.com>(auto build test ERROR) > > Signed-off-by: Nayna Jain <nayna@...ux.ibm.com> > > --- > > NOTE: I am wondering if we should split this patch into two: > > (https://lore.kernel.org/linux-integrity/be4bd13d-659d-710d-08b9-1a34a65e5c5d@linux.vnet.ibm.com/). > > I can do so if you also prefer the same. Yes, splitting this patch would make it easier to review and upstream. thanks, Mimi
Powered by blists - more mailing lists