Hi Ahmad, On Tue, May 17, 2022 at 07:52:51PM +0200, Ahmad Fatoum wrote: > Hello Jason, > > On 17.05.22 19:27, Jason A. Donenfeld wrote: > > On Fri, May 13, 2022 at 04:57:00PM +0200, Ahmad Fatoum wrote: > >> + trusted.rng= [KEYS] > >> + Format: <string> > >> + The RNG used to generate key material for trusted keys. > >> + Can be one of: > >> + - "kernel" > >> + - the same value as trusted.source: "tpm" or "tee" > >> + - "default" > >> + If not specified, "default" is used. In this case, > >> + the RNG's choice is left to each individual trust source. > >> + > > > > As a general mechanism, I object to this. The kernel's RNG must be > > trusted in the first place for key material. That's the whole point of > > it. > > > > However, it sounds like you're not proposing a general mechanism, but > > just something particular to this "trusted keys" business. > > The two currently upstream trust sources (trusted key backends) each provide > their own RNG callback. This series adds a third backend that uses kernel RNG > and additionally provides users of the two existing trust sources the option > to benefit from kernel RNG as well. > > > this should be a module flag, and thus not documented here, but rather > > some place namespaced to your trusted keys stuff. "trusted_keys.preferred_rng={whatever}" > > The trusted keys module is trusted.ko and directly before my added lines is > the trusted.source= documentation, so I think this is already at the correct place. My apologies; I should have looked at the file itself instead of just relying on git line context. You're right, the module itself is called trusted.ko. This is confusing (shouldn't it be trusted_keys or something?) , but what you propose sounds consistent from a namespacing perspective with what's already there. Jason