Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Create syscalls to make possible using random APIs from user mode
threads. These APIs can have different implementations, like using
entropy driver or Xoroshiro128. Some of these implementations also have
some globals to preserve state between calls.
Make it run entire in user space would require user adding these globals
to their memeory domains and/or grant access to entropy device. Syscalls
simplify its usage.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
In sys_rand_get() if the entropy hardware unlikely return error, the
fallgback is using the system timer to and fill the given buffer with
that data.
The problem what that k_cycle_get_32() returns a four bytes integer and
depending the sizeof of the buffer we need copy the right amount of
data. That was not being done properly leading to invalid read/write
memory access.
Fixes#26435
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Replace CONFIG_ENTROPY_NAME with DT_CHOSEN_ZEPHYR_ENTROPY_LABEL. We now
set zephyr,entropy in the chosen node of the device tree to the entropy
device.
This allows us to remove CONFIG_ENTROPY_NAME from dts_fixup.h. Also
remove any other stale ENTROPY related defines in dts_fixup.h files.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Propagate driver error when getting entropy data when calling a
cryptographically secure random generator.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
When using LLVM/Clang, it complains about memcpy() being
casted to (void *):
warning: expression result unused; should this cast be to 'void'? [-Wunused-value]
So change those to (void) instead as the return of memcpy()
is not used anyway.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
1) Add cryptographically secure random functions to provide
FIPS 140-2 compliant random functions.
2) Add name to random function choice selectors to ease
selection in SOC .defconfig files
3) Add bulk fill random functions.
Signed-off-by: David Leach <david.leach@nxp.com>
move entropy.h to drivers/entropy.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move atomic.h to sys/atomic.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
There is no reason for storing a pointer into an atomic_t variable here.
Not only because this requires a dubious double cast that breaks on
64-bit builds as atomic_t is a 32-bit type, but also because the comment
in the code already admits that the whole operation isn't atomic anyway
and that it is fine. So let's keep things simple.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
If there is a build setup problem where a device driver has not been
setup for the entropy driver then the call to device_get_binding()
will return a NULL value and the code will continue to use this NULL
value. The result is a hard fault later in code execution.
Note that CONFIG_ASSERT is by default off so one has to turn this
configuration on to catch this problem.
Signed-off-by: David Leach <david.leach@nxp.com>
Instead of every hardware number generator driver providing an
implementation of this function, use the random device API to
centralize the implementation of this function.
This is a very simplistic function that can be seen as a stepping stone
to refactor the random number generation in Zephyr.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Tomasz Bursztyka