Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg <eric.snowberg@oracle.com>]

> On Mar 21, 2025, at 2:53 PM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> On Fri, 2025-03-21 at 20:15 +0000, Eric Snowberg wrote:
>>> On Mar 21, 2025, at 10:55 AM, James Bottomley
>>> <James.Bottomley@HansenPartnership.com> wrote:
> [...]
>>>>   Hopefully that is not the case, since the public  key ships on
>>>> just about every single PC built.
>>> 
>>> I don't understand why Microsoft no-longer owning the private key
>>> is a problem?  Only the public key ships on PCs and that hasn't
>>> changed (at least not yet, it might have to for NIST requirements
>>> since RSA2048 is being deprecated).
>> 
>> A couple concerns come to mind.  First, the vetting process being
>> done for individuals that have signing authority with the HSM outside
>> of Microsoft.
> 
> I'm not aware UEFI has published any information on this.  I think the
> shim-review repo predates UEFI ownership, but I'm sure the maintainers
> of the repository can answer how they came to be trusted ...

Thanks for clarifying, I didn’t realize there were copies of the private key 
outside of Microsoft.

>> Another would be access control of the HSM.  Especially if it is not
>> within Microsoft's possession.
> 
> ... and how they handle the HSM.
> 
> However, if you're worried about risks to the integrity of secure boot,
> I'd be much more concerned about the number of ODM motherboard
> manufacturers who seem to have managed to lose their PK private keys,
> or keys they placed into db, somehow ...

That’s precisely the protection Clavis offers. It begins immediately after 
ExitBootServices and continues through all kexecs. Once the kernel starts, 
the end-user is in control of all system kernel keys.  Obviously some type 
of precaution must be taken to get into the first kernel.  The Clavis key 
belongs to the end-user, and they have the freedom to determine which 
kernel keys perform specific tasks within the system. This level of protection 
wouldn’t be feasible with the proposed named kernel keyring approach.  
With the named kernel keyring approach, it could be defeated with kexec.
When you have hardware vendors shipping systems in the past with test/demo 
DB/KEK/PK keys, or other companies that allow their signing key to be used 
by others, this level of protection is sought after by some users.