Correct Mutex ctr_lock defination as the wrong defination lead to
sysworkq task not acquiring this mutex during bt init, which lead to
BLE didn't work as described in issue https://github.com/zephyrproject-rtos/zephyr/issues/86444
Signed-off-by: Ying Zhang <ying.zhang_2@nxp.com>
This is based on the introduction of a helper Kconfig symbol in
"subsys/random/Kconfig" which is named CSPRNG_AVAILABLE. When this is
enabled it means that there is a "zephyr,entropy" property defined in the
device-tree, therefore Mbed TLS can select ENTROPY_GENERATOR to allow
the platform specific driver to be included into the build.
This commit also changes other locations where CSPRNG_ENABLED was used
moving it to CSPRNG_AVAILABLE in order to solve dependency loop
build failures.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Following the deprecation of TinyCrypt (#79566) we remove
TinyCrypt usage in random generators. This basically only affects
the CTR-DRBG random generator which from now only will only make
use of Mbed TLS.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
When non-random number generation is allowed via
`TEST_RANDOM_GENERATOR`, enable an implementation for `sys_csrand_get`
that stubs out to `sys_rand_get`. This enables libraries that request
CS random numbers to be tested in CI, even if the results are not CS in
that context.
The documentation for `TEST_RANDOM_GENERATOR` is explicit enough about
the dangers of enabling this in production.
Signed-off-by: Jordan Yates <jordan@embeint.com>
PR #72475 disabled default enabling of many Mbed TLS features
including AES. This means that now it must be explicitly added
when required.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Namespaced the generated headers with `zephyr` to prevent
potential conflict with other headers.
Introduce a temporary Kconfig `LEGACY_GENERATED_INCLUDE_PATH`
that is enabled by default. This allows the developers to
continue the use of the old include paths for the time being
until it is deprecated and eventually removed. The Kconfig will
generate a build-time warning message, similar to the
`CONFIG_TIMER_RANDOM_GENERATOR`.
Updated the includes path of in-tree sources accordingly.
Most of the changes here are scripted, check the PR for more
info.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
All implementations of random number generator where duplicating logic
for sys_rand32_get. Since this subsystem already has a logic to
generate random values of arbitrary size, we can generically implement
sys_rand32_get on top of that.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Move the syscall_handler.h header, used internally only to a dedicated
internal folder that should not be used outside of Zephyr.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a build option to allow changing the initial state used
in the timer based random generator and by the kernel in the
early random number generator.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
rand32.h does not make much sense, since the random subsystem
provides more APIs than just getting a random 32 bits value.
Rename it to random.h and get consistently with other
subsystems.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Code using sys_csrand_get should depend on CONFIG_CSPRNG_ENABLED symbol
and not in ENTROPY_HAS_DRIVER since they are not using the entropy
device directly.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
irq_lock() does not make this this csprng api thread safe
in SMP systems. Change it to use a mutex.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
This adds a few line use zephyr_syscall_header() to include
headers containing syscall function prototypes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
I get a high failure rate for tests/kernel/mem_protect/stack_random
because the default rand32_timer used with QEMU is just too mediocre.
Make it more random looking.
Reference: https://nuclear.llnl.gov/CNP/rng/rngman/node4.html
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The old random timer test was not random-looking
enough on some platforms.
Replace with new test which is psuedo-xoshiro.
The generator is still deterministic
and does not depend on entropy at all,
but should look more random for testing.
Change name of generator tree-wide also.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
The `TEST_RANDOM_GENERATOR` symbol in itself does not imply that a
non-random number generator is selected -- that is indicated by the
`RNG_GENERATOR_CHOICE` choices, of which only `TIMER_RANDOM_GENERATOR`
is a non-random generator.
This commit updates the Random subsystem to print the "non-random
number generator usage warning" when `TIMER_RANDOM_GENERATOR` is
selected, as opposed to when `TEST_RANDOM_GENERATOR` is selected.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
The `TEST_RANDOM_GENERATOR` Kconfig symbol indicates that a non-random
number generator (i.e. a random number generator that is not truly
random) is _allowed_ to be used for testing purposes, and not
necessarily that a non-random number generator is _selected_ -- that is
indicated by the `RNG_GENERATOR_CHOICE` choices that depend on
`TEST_RANDOM_GENERATOR` (i.e. only `TIMER_RANDOM_GENERATOR` as of now).
This commit updates the `TEST_RANDOM_GENERATOR` Kconfig symbol
description to reflect and clarify that.
It also removes the `TEST_RANDOM_GENERATOR`'s dependency on
`ENTROPY_HAS_DRIVER` because the act of _allowing_ a non-random number
generator to be used does not depend on the availability of an entropy
driver -- when an entropy driver is available, by default, the
`ENTROPY_DEVICE_RANDOM_GENERATOR` will be selected; otherwise,
`TIMER_RANDOM_GENERATOR`, a non-random generator, will be selected.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Bug introduced that prevented the logic from initializing the
context structure. Without this initialization, the application
will crash on repeated request for ctr_drbg random data.
Fixes: #44092
Signed-off-by: David Leach <david.leach@nxp.com>
With f44b3dc4df statically initializing
the entropy_dev variable, `ctr_drbg_initialize` was not being run on
the first call to `z_impl_sys_csrand_get`. Use a dedicated static bool
to track whether the init needs to be run.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
When requesting seed entropy data fails, reseed the PRNG state with
runtime data. This is a minimal effort to ensure that random data
requested before a backing entropy device is ready does not result in
repeatable data on each boot.
The random XOR integers are selected from the CRC32 algorithm.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Defer the state initialization of the xoshiro algorithm until the first
time a random number is requested. This allows the PRNG algorithm to be
used with entropy sources which may not be available at boot, i.e
Bluetooth HCI.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
The entropy device reference can be obtained at compile time. Adjust
error code to -ENODEV.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
THe entropy device can be ontained at compile time. Simplify some
logs/code as a result. Also adjusted "entropy_driver" name to
"entropy_dev", since it holds a "device", not a "driver".
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The entropy device can be obtained at compile time. Adjusted the
assertion message slightly, as it no longer uses the entropy macro
label. Also adjusted the entropy_driver variable to entropy_dev, since
it does not hold a "driver" but a "device".
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
z_impl_sys_csrand_get is implement if the system is build with either
CONFIG_CTR_DRBG_CSPRNG_GENERATOR or CONFIG_HARDWARE_DEVICE_CS_GENERATOR.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
PR #36996 disabled running mem_protect/stack_random test on qemu_riscv32
platform because of this test consistently failing on said platform.
This test starts new threads in equal time intervals, and because of
that we get repeating values after performing the modulus operation when
calculating the stack pointer address.
This can be solved by changing the value of the _RAND32_INC constant
that is used to increase the value returned by the timer-based PRNG.
This commit decreases the value of the mentioned constant from
1000000013U to 1000000003U.
Fixes#37006.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Deprecate the xoroshiro128+ PRNG algorithm in favour of xoshiro128++.
xoshiro128++ is a drop-in replacement which is invisible from the user
perspective.
xoroshiro128+ is unsuitable because it is explicitly a floating-point
PRNG, not a general-purpose PRNG. This means that the lower 4 bits of
the output are actually linear, not random (from the designers,
https://prng.di.unimi.it/). This means 1/8th of the generated data is
not random.
Additionally, xoroshiro128+ is not a 32bit algorithm, it operates on
64bit numbers. For the vast majority of Zephyr devices, this makes the
PRNG slower than it needs to be. The replacement (xoshiro128++) is
32bit, with no loss in state space (still 128 bit).
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Adds an implementation of xoshiro128++ as a pseudo random number
generator from https://prng.di.unimi.it/ that operates on 32bit words.
The algorithm postfix signifies the main operation in the generation
function. Therefore xoshiro++ is chosen over xoshiro** as we would
prefer to do 2 additions isntead of 2 multiplications on embedded
hardware. The quality of the generators appears to be the same in all
other respects.
xoshiro+ is not chosen despite being faster as it generates random
floating-point values, not general purpose random values (The lower 4
bits are linear).
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
The previous implementation assumed that the dst pointer was always
aligned to a 4-byte boundary in platforms that require alignment for
storage of 32-bit integers. Since this is required for certain platforms
(eg. Arm Cortex-M0), use memcpy() instead, which always takes
alignment into account.
Fixes#33969.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
When ctr_drbg_initialize fails the function returns without unlock irq
that was previously locked.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
entropy_get_entropy return is not being checked what may result in a
vulnerability because tc_ctr_prng_reseed will not get proper entropy
data.
Fixes#29869
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
If rand32_xoroshiro128::z_impl_sys_rand_get is called with outlen
not divisible by 4, it will overflow the dst buffer. This happens
because blocksize is not changed from 4 to the difference between
outlen and len. If outlen is < 4, z_impl_sys_rand_get will be stuck
in an infinite loop that keeps writing random bytes outside the buffer.
If outlen is > 4, z_impl_sys_rand_get returns after the correct number
of loops, but it writes every byte to the buffer, not just outlen number
of bytes. This causes the buffer to be overflowed with up to and
including 3 bytes.
Signed-off-by: Didrik Rokhaug <didrik.rokhaug@gmail.com>
Generates a warning message when building with
CONFIG_TEST_RANDOM_GENERATOR. The purpose is inform that this is not
secure and should not used in production.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Both operands of an operator in the arithmetic conversions
performed shall have the same essential type category.
Changes are related to converting the integer constants to the
unsigned integer constants
Signed-off-by: Aastha Grover <aastha.grover@intel.com>
