Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

From: Yannik Sembritzki <yannik@sembritzki.me>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	David Howells <dhowells@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Peter Anvin <hpa@zytor.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>,
	"Justin M. Forbes" <jforbes@redhat.com>,
	Peter Jones <pjones@redhat.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Matthew Garrett <mjg59@google.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot
Date: Wed, 15 Aug 2018 21:06:13 +0200	[thread overview]
Message-ID: <b2649b70-37b6-3929-a9d0-3d82033b2686@sembritzki.me> (raw)
In-Reply-To: <20180815185812.GC29541@redhat.com>

> I am wondering why did we have to split this keyring to begin with. 
> So there are use cases where we want to trust builtin keys but
> not the ones which came from other places (UEFI secure boot db, or
> user loaded one)?
>
"User loaded ones" should not be trusted in general to prevent rootkits
and similar from modifying the kernel (even if they have root).

According to the patch which introduced the secondary keyring (the one
you mentioned), the requirements for adding keys to the secondary
keyring are as follows:
"Add a secondary system keyring that can be added to by root whilst the
system is running - provided the key being added is vouched for by a key
built into the kernel or already added to the secondary keyring."

I personally don't see a reason for this split, as the requirements for
the secondary keyring are as strict as it can get. However, I'm new to
this, so feel free to correct me.

Yannik