On 10/27/2026 1:12 PM, Manuel Huber wrote: > On Mon, Oct 19, 2026 at 04:15:57PM -0700, Fan Wu wrote: >> I would prefer a Kconfig CONFIG_SECURITY_IPE_KEYRING default to N instead, >> like the fsverity keyring. In the kconfig you can also describe in which >> cases should this option be turned on. > > Thanks to everyone for the discussion. Some of the points raised are > actionable, but two review questions still seem to be open: > > 1. Whether to use CONFIG_SECURITY_IPE_KEYRING or the 'per-boot > provisioning' pattern with a kernel command-line parameter > 2. Whether IPE should accept any irreversible keyring restriction or > specifically mandate restrict_link_reject. > > I want to remain completely neutral here because I am only a potential > first-time contributor, and because the scenario I elaborated on can be > realized with either resolution. Fan, would you prefer that I: > > a. move forward with a non-RFC v2 incorporating your initial > suggestions; > b. revise the suggestions given the subsequent discussion; or > c. wait for more input before making a decision? > > Apologies if this follow-up causes unnecessary churn and turnovers. If > the thread remains quiet, I will proceed with (a).
I would prefer using a Kconfig option to enable the keyring itself. If you want a kernel command-line parameter, please gate it behind a separate Kconfig option and document the detailed scenario for how you intend to use it. The same applies to the keyring restriction check. I also suggest adding a dedicated threat model discussion in your next version. The proposed model drifts significantly from IPE's current threat model, where the root of trust comes from the kernel image or firmware, and please also address the kexec interaction that Luca pointed out. Fan
