Arm CryptoCell driver -- default Y, even on machines where it is obviously useless
Hi!
I'm configuring kernel for x86, and I get offered HW_RANDOM_CCTRNG with default=Y, and help text suggesting I should enable it.
That's... two wrong suggestions, right?
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi Pavel,
I think you got it right..
Indeed, Arm CryptoCell CCTRNG driver couldn't be used and obviously useless if the Arm CryptoCell HW does not exist in the system. BR,
Hadar
Quoted 21 lines
-----Original Message-----
From: Pavel Machek <[email protected]>
Sent: Saturday, 18 April 2020 13:44
To: kernel list <[email protected]>; Hadar Gat <[email protected]>; [email protected]
Subject: Arm CryptoCell driver -- default Y, even on machines where it is obviously uselessHi!
I'm configuring kernel for x86, and I get offered
HW_RANDOM_CCTRNGwith default=Y, and help text suggesting I should enable it.That's... two wrong suggestions, right?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
A message that is not in the archive (sent off-list or not yet received): VI1PR08MB3584451F0B0B21E00ACF56A7FED70@VI1PR08MB3584.eurprd08.prod.outlook.com
Quoted 17 lines
Quoted 17 lines
-----Original Message-----
From: Pavel Machek <[email protected]>
Sent: Saturday, 18 April 2020 13:44
To: kernel list <[email protected]>; Hadar Gat <[email protected]>; [email protected]
Subject: Arm CryptoCell driver -- default Y, even on machines where it is obviously uselessHi!
I'm configuring kernel for x86, and I get offered
HW_RANDOM_CCTRNGwith default=Y, and help text suggesting I should enable it.That's... two wrong suggestions, right?
Best regards,
Pavel
...
Quoted 10 lines
________________________________________
From: Hadar Gat <[email protected]>
Sent: Saturday, April 18, 2020 11:31 PM
To: Pavel Machek; kernel list; [email protected]
Cc: Ofir Drang; Gilad Ben Yossef; nd
Subject: RE: Arm CryptoCell driver -- default Y, even on machines where it is obviously uselessHi Pavel,
I think you got it right..
Indeed, Arm CryptoCell CCTRNG driver couldn't be used and obviously useless if the Arm CryptoCell HW does not exist in the system.
There's a delicate point here though - CryptoCell is an independent hardware block, it is not tied to a particular CPU architecture. There are SoCs with none-Arm architecture CPU using it.
So I would say whatever the answer is, it should be the same for any generic embedded style HW block.
And the help text is not architecture specific anyway, is it not..?
Gilad
Signature · 4 lines
Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
Quoted 30 lines · Gilad Ben-Yossef
Quoted 18 lines
Quoted 18 lines
-----Original Message-----
From: Pavel Machek <[email protected]>
Sent: Saturday, 18 April 2020 13:44
To: kernel list <[email protected]>; Hadar Gat <[email protected]>; [email protected]
Subject: Arm CryptoCell driver -- default Y, even on machines where it is obviously uselessHi!
I'm configuring kernel for x86, and I get offered
HW_RANDOM_CCTRNGwith default=Y, and help text suggesting I should enable it.That's... two wrong suggestions, right?
Best regards,
Pavel...
Quoted 10 lines
________________________________________
From: Hadar Gat <[email protected]>
Sent: Saturday, April 18, 2020 11:31 PM
To: Pavel Machek; kernel list; [email protected]
Cc: Ofir Drang; Gilad Ben Yossef; nd
Subject: RE: Arm CryptoCell driver -- default Y, even on machines where it is obviously uselessHi Pavel,
I think you got it right..
Indeed, Arm CryptoCell CCTRNG driver couldn't be used and obviously useless if the Arm CryptoCell HW does not exist in the system.
Quoted 9 lines
There's a delicate point here though - CryptoCell is an independent hardware block, it is not tied to a particular CPU architecture. There are SoCs with none-Arm architecture CPU using it.
So I would say whatever the answer is, it should be the same for any generic embedded style HW block.
And the help text is not architecture specific anyway, is it not..?
Both the default y and and the help text are indeed incorrect. This should be fixed. We don't enable device drivers by default, and definitely not as as builtins. A conditional default m could be acceptable if the condition is sufficiently narrow.
While at it, could we add a depends on CONFIG_OF since this code is definitely unusable on non-DT systems.
Hi Ard,
Quoted 35 lines
-----Original Message-----
From: Ard Biesheuvel <[email protected]>
Sent: Sunday, 19 April 2020 11:55Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Pavel Machek <[email protected]>
Sent: Saturday, 18 April 2020 13:44Hi!
I'm configuring kernel for x86, and I get offered
HW_RANDOM_CCTRNGQuoted 6 lines
Quoted 6 lines
Quoted 6 lines
with default=Y, and help text suggesting I should enable it.
That's... two wrong suggestions, right?
Best regards,
PavelQuoted 8 lines
...
Quoted 7 lines
________________________________________
From: Hadar Gat <[email protected]>
Sent: Saturday, April 18, 2020 11:31 PMHi Pavel,
I think you got it right..
Indeed, Arm CryptoCell CCTRNG driver couldn't be used and obviouslyuseless if the Arm CryptoCell HW does not exist in the system.
Quoted 8 lines
There's a delicate point here though - CryptoCell is an independent hardware block, it is not tied to a particular CPU architecture. There are SoCs with none-Arm architecture CPU using it.
So I would say whatever the answer is, it should be the same for any generic embedded style HW block.
Quoted 7 lines
Quoted 2 lines
And the help text is not architecture specific anyway, is it not..?
Both the default y and and the help text are indeed incorrect. This should be fixed. We don't enable device drivers by default, and definitely not as as builtins. A conditional default m could be acceptable if the condition is sufficiently narrow.
On one hand I totally agree with that and think the default should be N.
On the other hand, most of the HW_RANDOM drivers set the default to HW_RANDOM
and it doesn't make sense to me to do something different than almost every other HW RANDOM device. Do I miss something here?
Quoted 3 lines
While at it, could we add a depends on
CONFIG_OFsince this code is definitely unusable on non-DT systems.
Quoted 46 lines · Hadar Gat
Hi Ard,
Quoted 35 lines
-----Original Message-----
From: Ard Biesheuvel <[email protected]>
Sent: Sunday, 19 April 2020 11:55Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Pavel Machek <[email protected]>
Sent: Saturday, 18 April 2020 13:44Hi!
I'm configuring kernel for x86, and I get offered
HW_RANDOM_CCTRNGQuoted 6 lines
Quoted 6 lines
Quoted 6 lines
with default=Y, and help text suggesting I should enable it.
That's... two wrong suggestions, right?
Best regards,
PavelQuoted 8 lines
...
Quoted 7 lines
________________________________________
From: Hadar Gat <[email protected]>
Sent: Saturday, April 18, 2020 11:31 PMHi Pavel,
I think you got it right..
Indeed, Arm CryptoCell CCTRNG driver couldn't be used and obviouslyuseless if the Arm CryptoCell HW does not exist in the system.
Quoted 8 lines
There's a delicate point here though - CryptoCell is an independent hardware block, it is not tied to a particular CPU architecture. There are SoCs with none-Arm architecture CPU using it.
So I would say whatever the answer is, it should be the same for any generic embedded style HW block.
Quoted 7 lines
Quoted 2 lines
And the help text is not architecture specific anyway, is it not..?
Both the default y and and the help text are indeed incorrect. This should be fixed. We don't enable device drivers by default, and definitely not as as builtins. A conditional default m could be acceptable if the condition is sufficiently narrow.
Quoted 5 lines
On one hand I totally agree with that and think the default should be N.
On the other hand, most of theHW_RANDOMdrivers set the default toHW_RANDOM
and it doesn't make sense to me to do something different than almost every other HW RANDOM device. Do I miss something here?
Yes. First of all, using 'default HW_RANDOM' everywhere makes no sense at all, but that is not your fault.
If you look at drivers/char/hw_random/Kconfig, you will see that most drivers have additional depends lines, which means that 'default m' (or 'default y' in case CONFIG_HW_RANDOM=y) will only take affect if the dependency is fulfilled.
It makes no sense to enable this driver on *every* single Linux system, right? Especially given that many architectures do not even support device tree, which is a prerequisite to be able to even probe.
drivers/char/hw_random/Kconfig-config HW_RANDOM_INTEL drivers/char/hw_random/Kconfig- depends on (X86 || IA64) && PCI --drivers/char/hw_random/Kconfig-config HW_RANDOM_AMD drivers/char/hw_random/Kconfig- depends on (X86 || PPC_MAPLE) && PCI --drivers/char/hw_random/Kconfig-config HW_RANDOM_ATMEL drivers/char/hw_random/Kconfig- depends on ARCH_AT91 && HAVE_CLK && OF --drivers/char/hw_random/Kconfig-config HW_RANDOM_BCM2835 drivers/char/hw_random/Kconfig- depends on ARCH_BCM2835 || ARCH_BCM_NSP || ARCH_BCM_5301X || \
--drivers/char/hw_random/Kconfig-config HW_RANDOM_IPROC_RNG200 drivers/char/hw_random/Kconfig- depends on ARCH_BCM_IPROC || ARCH_BCM2835 || ARCH_BRCMSTB
--drivers/char/hw_random/Kconfig-config HW_RANDOM_GEODE drivers/char/hw_random/Kconfig- depends on X86_32 && PCI
--drivers/char/hw_random/Kconfig-config HW_RANDOM_N2RNG drivers/char/hw_random/Kconfig- depends on SPARC64
--drivers/char/hw_random/Kconfig-config HW_RANDOM_VIA drivers/char/hw_random/Kconfig- depends on X86
--drivers/char/hw_random/Kconfig-config HW_RANDOM_IXP4XX drivers/char/hw_random/Kconfig- depends on ARCH_IXP4XX
--drivers/char/hw_random/Kconfig-config HW_RANDOM_OMAP drivers/char/hw_random/Kconfig- depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || ARCH_MVEBU
--drivers/char/hw_random/Kconfig-config HW_RANDOM_OMAP3_ROM drivers/char/hw_random/Kconfig- depends on ARCH_OMAP3
--drivers/char/hw_random/Kconfig-config HW_RANDOM_OCTEON drivers/char/hw_random/Kconfig- depends on CAVIUM_OCTEON_SOC --drivers/char/hw_random/Kconfig-config HW_RANDOM_PASEMI drivers/char/hw_random/Kconfig- depends on PPC_PASEMI
--drivers/char/hw_random/Kconfig-config HW_RANDOM_VIRTIO drivers/char/hw_random/Kconfig- depends on VIRTIO
--drivers/char/hw_random/Kconfig-config HW_RANDOM_TX4939 drivers/char/hw_random/Kconfig- depends on SOC_TX4939
--drivers/char/hw_random/Kconfig-config HW_RANDOM_MXC_RNGA drivers/char/hw_random/Kconfig- depends on SOC_IMX31
--drivers/char/hw_random/Kconfig-config HW_RANDOM_IMX_RNGC drivers/char/hw_random/Kconfig- depends on HAS_IOMEM && HAVE_CLK --drivers/char/hw_random/Kconfig-config HW_RANDOM_NOMADIK drivers/char/hw_random/Kconfig- depends on ARCH_NOMADIK
--drivers/char/hw_random/Kconfig-config HW_RANDOM_PSERIES drivers/char/hw_random/Kconfig- depends on PPC64 && IBMVIO --drivers/char/hw_random/Kconfig-config HW_RANDOM_POWERNV drivers/char/hw_random/Kconfig- depends on PPC_POWERNV
--drivers/char/hw_random/Kconfig-config HW_RANDOM_HISI drivers/char/hw_random/Kconfig- depends on HW_RANDOM && ARCH_HISI --drivers/char/hw_random/Kconfig-config HW_RANDOM_HISI_V2 drivers/char/hw_random/Kconfig- depends on HW_RANDOM && ARM64 && ACPI --drivers/char/hw_random/Kconfig-config HW_RANDOM_ST drivers/char/hw_random/Kconfig- depends on HW_RANDOM && ARCH_STI --drivers/char/hw_random/Kconfig-config HW_RANDOM_XGENE drivers/char/hw_random/Kconfig- depends on HW_RANDOM && ARCH_XGENE --drivers/char/hw_random/Kconfig-config HW_RANDOM_STM32 drivers/char/hw_random/Kconfig- depends on HW_RANDOM && (ARCH_STM32 || COMPILE_TEST)
--drivers/char/hw_random/Kconfig-config HW_RANDOM_PIC32 drivers/char/hw_random/Kconfig- depends on HW_RANDOM && MACH_PIC32 --drivers/char/hw_random/Kconfig-config HW_RANDOM_MESON drivers/char/hw_random/Kconfig- depends on HW_RANDOM
--drivers/char/hw_random/Kconfig-config HW_RANDOM_CAVIUM drivers/char/hw_random/Kconfig- depends on HW_RANDOM && PCI && (ARM64 || (COMPILE_TEST && 64BIT))
--drivers/char/hw_random/Kconfig-config HW_RANDOM_MTK drivers/char/hw_random/Kconfig- depends on HW_RANDOM
--drivers/char/hw_random/Kconfig-config HW_RANDOM_S390 drivers/char/hw_random/Kconfig- depends on S390
--drivers/char/hw_random/Kconfig-config HW_RANDOM_EXYNOS drivers/char/hw_random/Kconfig- depends on ARCH_EXYNOS || COMPILE_TEST --drivers/char/hw_random/Kconfig-config HW_RANDOM_OPTEE drivers/char/hw_random/Kconfig- depends on OPTEE
--drivers/char/hw_random/Kconfig-config HW_RANDOM_NPCM drivers/char/hw_random/Kconfig- depends on ARCH_NPCM || COMPILE_TEST
Quoted 20 lines
Quoted 5 lines
Quoted 5 lines
-----Original Message-----
From: Ard Biesheuvel <[email protected]>
Sent: Sunday, 19 April 2020 11:55Quoted 8 lines
Quoted 4 lines
Both the default y and and the help text are indeed incorrect. This should be fixed. We don't enable device drivers by default, and definitely not as as builtins. A conditional default m could be acceptable if the condition is sufficiently narrow.
On one hand I totally agree with that and think the default should be N. On the other hand, most of the
HW_RANDOMdrivers set the default toHW_RANDOMand it doesn't make sense to me to do something differentthan almost every other HW RANDOM device.
Quoted 2 lines
Do I miss something here?
Yes. First of all, using 'default
HW_RANDOM' everywhere makes no sense at all, but that is not your fault.
Quoted 9 lines
If you look at
drivers/char/hw_random/Kconfig, you will see that most drivers have additional depends lines, which means that 'default m' (or 'default y' in caseCONFIG_HW_RANDOM=y) will only take affect if the dependency is fulfilled.It makes no sense to enable this driver on *every* single Linux system, right? Especially given that many architectures do not even support device tree, which is a prerequisite to be able to even probe.
Thanks you Ard for clearing it up for me.
I'll fix that shortly.
Hadar
Quoted 115 lines
drivers/char/hw_random/Kconfig-configHW_RANDOM_INTELdrivers/char/hw_random/Kconfig-depends on (X86 || IA64) && PCI --drivers/char/hw_random/Kconfig-configHW_RANDOM_AMDdrivers/char/hw_random/Kconfig-depends on (X86 ||PPC_MAPLE) && PCI --drivers/char/hw_random/Kconfig-configHW_RANDOM_ATMELdrivers/char/hw_random/Kconfig-depends onARCH_AT91&&HAVE_CLK&& OF
--drivers/char/hw_random/Kconfig-configHW_RANDOM_BCM2835drivers/char/hw_random/Kconfig-depends onARCH_BCM2835||ARCH_BCM_NSP||ARCH_BCM_5301X|| \
--drivers/char/hw_random/Kconfig-configHW_RANDOM_IPROC_RNG200drivers/char/hw_random/Kconfig-depends onARCH_BCM_IPROC||ARCH_BCM2835||ARCH_BRCMSTB
--drivers/char/hw_random/Kconfig-configHW_RANDOM_GEODEdrivers/char/hw_random/Kconfig-depends onX86_32&& PCI --drivers/char/hw_random/Kconfig-configHW_RANDOM_N2RNGdrivers/char/hw_random/Kconfig-depends on SPARC64
--drivers/char/hw_random/Kconfig-configHW_RANDOM_VIAdrivers/char/hw_random/Kconfig-depends on X86
--drivers/char/hw_random/Kconfig-configHW_RANDOM_IXP4XXdrivers/char/hw_random/Kconfig-depends onARCH_IXP4XX
--drivers/char/hw_random/Kconfig-configHW_RANDOM_OMAPdrivers/char/hw_random/Kconfig-depends onARCH_OMAP16XX||ARCH_OMAP2PLUS||ARCH_MVEBU
--drivers/char/hw_random/Kconfig-configHW_RANDOM_OMAP3_ROMdrivers/char/hw_random/Kconfig-depends onARCH_OMAP3
--drivers/char/hw_random/Kconfig-configHW_RANDOM_OCTEONdrivers/char/hw_random/Kconfig-depends onCAVIUM_OCTEON_SOC--drivers/char/hw_random/Kconfig-configHW_RANDOM_PASEMIdrivers/char/hw_random/Kconfig-depends onPPC_PASEMI
--drivers/char/hw_random/Kconfig-configHW_RANDOM_VIRTIOdrivers/char/hw_random/Kconfig-depends on VIRTIO
--drivers/char/hw_random/Kconfig-configHW_RANDOM_TX4939drivers/char/hw_random/Kconfig-depends onSOC_TX4939
--drivers/char/hw_random/Kconfig-configHW_RANDOM_MXC_RNGAdrivers/char/hw_random/Kconfig-depends onSOC_IMX31
--drivers/char/hw_random/Kconfig-configHW_RANDOM_IMX_RNGCdrivers/char/hw_random/Kconfig-depends onHAS_IOMEM&&HAVE_CLK--drivers/char/hw_random/Kconfig-configHW_RANDOM_NOMADIKdrivers/char/hw_random/Kconfig-depends onARCH_NOMADIK--drivers/char/hw_random/Kconfig-configHW_RANDOM_PSERIESdrivers/char/hw_random/Kconfig-depends on PPC64 && IBMVIO --drivers/char/hw_random/Kconfig-configHW_RANDOM_POWERNVdrivers/char/hw_random/Kconfig-depends onPPC_POWERNV
--drivers/char/hw_random/Kconfig-configHW_RANDOM_HISIdrivers/char/hw_random/Kconfig-depends onHW_RANDOM&&ARCH_HISI
--drivers/char/hw_random/Kconfig-configHW_RANDOM_HISI_V2drivers/char/hw_random/Kconfig-depends onHW_RANDOM&& ARM64 && ACPI
--drivers/char/hw_random/Kconfig-configHW_RANDOM_STdrivers/char/hw_random/Kconfig-depends onHW_RANDOM&&ARCH_STI--drivers/char/hw_random/Kconfig-configHW_RANDOM_XGENEdrivers/char/hw_random/Kconfig-depends onHW_RANDOM&&ARCH_XGENE
--drivers/char/hw_random/Kconfig-configHW_RANDOM_STM32drivers/char/hw_random/Kconfig-depends onHW_RANDOM&& (ARCH_STM32||COMPILE_TEST)
--drivers/char/hw_random/Kconfig-configHW_RANDOM_PIC32drivers/char/hw_random/Kconfig-depends onHW_RANDOM&&MACH_PIC32
--drivers/char/hw_random/Kconfig-configHW_RANDOM_MESONdrivers/char/hw_random/Kconfig-depends onHW_RANDOM
--drivers/char/hw_random/Kconfig-configHW_RANDOM_CAVIUMdrivers/char/hw_random/Kconfig-depends onHW_RANDOM&& PCI && (ARM64
|| (COMPILE_TEST&& 64BIT))
--drivers/char/hw_random/Kconfig-configHW_RANDOM_MTKdrivers/char/hw_random/Kconfig-depends onHW_RANDOM
--drivers/char/hw_random/Kconfig-configHW_RANDOM_S390drivers/char/hw_random/Kconfig-depends on S390
--drivers/char/hw_random/Kconfig-configHW_RANDOM_EXYNOSdrivers/char/hw_random/Kconfig-depends onARCH_EXYNOS||COMPILE_TEST
--drivers/char/hw_random/Kconfig-configHW_RANDOM_OPTEEdrivers/char/hw_random/Kconfig-depends on OPTEE
--drivers/char/hw_random/Kconfig-configHW_RANDOM_NPCMdrivers/char/hw_random/Kconfig-depends onARCH_NPCM||COMPILE_TEST
Quoted 3 lines · Hadar Gat
Hi Pavel,
I think you got it right..
Indeed, Arm CryptoCell CCTRNG driver couldn't be used and obviously
useless if the Arm CryptoCell HW does not exist in the system.
Yup.. So.. can authors fix it somehow?
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 5 lines
-----Original Message-----
From: Pavel Machek <[email protected]>
Sent: Sunday, 26 April 2020 0:18
Quoted 8 lines
Quoted 3 lines · Hadar Gat
Hi Pavel,
I think you got it right..
Indeed, Arm CryptoCell CCTRNG driver couldn't be used and obviouslyuseless if the Arm CryptoCell HW does not exist in the system.
Yup.. So.. can authors fix it somehow?
Yes. I'm on it.