Re: [PATCH 3/3] hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger

[Dragan Simic]

Hello Herbert,

On 2025-02-09 10:15, Herbert Xu wrote:
> On Wed, Jan 15, 2025 at 02:07:02PM +0100, Dragan Simic wrote:
> > Since the commit 72d3e093afae (um: random: Register random as 
> > hwrng-core
> > device), selecting the UML_RANDOM option may result in various 
> > HW_RANDOM_*
> > options becoming selected as well, which doesn't make much sense for 
> > UML
> > that obviously cannot use any of those HWRNG devices.
> >
> > Let's have the HW_RANDOM_* options selected by default only when 
> > UML_RANDOM
> > actually isn't already selected.  With that in place, selecting 
> > UML_RANDOM
> > no longer "triggers" the selection of various HW_RANDOM_* options.
> >
> > Fixes: 72d3e093afae (um: random: Register random as hwrng-core device)
> > Reported-by: Diederik de Haas <didi.debian@xxxxxxxxx>
> > Signed-off-by: Dragan Simic <dsimic@xxxxxxxxxxx>
> > ---
> >  drivers/char/hw_random/Kconfig | 76 
> > +++++++++++++++++-----------------
> >  1 file changed, 38 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/char/hw_random/Kconfig 
> > b/drivers/char/hw_random/Kconfig
> > index e84c7f431840..283aba711af5 100644
> > --- a/drivers/char/hw_random/Kconfig
> > +++ b/drivers/char/hw_random/Kconfig
> > @@ -38,47 +38,47 @@ config HW_RANDOM_TIMERIOMEM
> >  config HW_RANDOM_INTEL
> >  	tristate "Intel HW Random Number Generator support"
> >  	depends on (X86 || COMPILE_TEST) && PCI
> > -	default HW_RANDOM
> > +	default HW_RANDOM if !UML_RANDOM
>
> This is disgusting.  Just remove all the defaults, and we can
> add back the ones actually needed.  Just remember to set the
> default to something sane like HW_RANDOM && dependencies.

Could you, please, clarify why we need(ed) the defaults at all?
Also, I'm a bit puzzled about what would be the defaults that are
actually needed?  Are you actually referring to what I proposed
in my earlier response? [1]  I'd appreciate a clarification.

As a note, I tried to kind of "fix" it in a least intrusive way,
but I'll gladly have it fixed properly in the v2.  To me, getting
rid of the defaults completely would be the proper way.

[1] 
https://lore.kernel.org/linux-crypto/78b97c27314bfa1c7f0f17a90e623821@xxxxxxxxxxx/