On Thu, Jan 17, 2019 at 11:04 PM David Howells wrote:
>
> Kairui Song wrote:
>
> > +extern const struct key* __init integrity_get_platform_keyring(void);
>
> This should really be in keys/system_keyring.h and probably shouldn't be
> exposed directly if it can be avoided.
>
> David
Thanks for
Kairui Song wrote:
> +extern const struct key* __init integrity_get_platform_keyring(void);
This should really be in keys/system_keyring.h and probably shouldn't be
exposed directly if it can be avoided.
David
On Wed, 2019-01-09 at 09:33 +0800, Dave Young wrote:
> CC kexec list
> On 01/08/19 at 10:18am, Mimi Zohar wrote:
> > [Cc'ing the LSM and integrity mailing lists]
> >
> > Repeating my comment on PATCH 0/1 here with the expanded set of
> > mailing lists.
> >
> > The builtin and secondary keyrings
Thanks for the explanation Dave, my second thought is to let kexec use
the platform keyring directly, that is let kexec verify the image with
secondary/builtin keyring first then try platform keyring. And better
to make platform keyring independent of integrity subsystem, so kexec
could verify the
CC kexec list
On 01/08/19 at 10:18am, Mimi Zohar wrote:
> [Cc'ing the LSM and integrity mailing lists]
>
> Repeating my comment on PATCH 0/1 here with the expanded set of
> mailing lists.
>
> The builtin and secondary keyrings have a signature change of trust
> rooted in the signed kernel image.
[Cc'ing the LSM and integrity mailing lists]
Repeating my comment on PATCH 0/1 here with the expanded set of
mailing lists.
The builtin and secondary keyrings have a signature change of trust
rooted in the signed kernel image. Adding the pre-boot keys to the
secondary keyring breaks that
Currently kexec may need to verify the kerne image, and the kernel image
could be signed with third part keys which are provided by paltform or
firmware (eg. stored in MokListRT EFI variable). And the same time,
kexec_file_load will only verify the image agains .builtin_trusted_keys
or
7 matches
Mail list logo
