30 Nov, 2016
1 commit
-
When using SGs, only heap memory (memory that is valid as per
virt_addr_valid) is allowed to be referenced. The CTR DRBG used to
reference the caller-provided memory directly in an SG. In case the
caller provided stack memory pointers, the SG mapping is not considered
to be valid. In some cases, this would even cause a paging fault.The change adds a new scratch buffer that is used unconditionally to
catch the cases where the caller-provided buffer is not suitable for
use in an SG. The crypto operation of the CTR DRBG produces its output
with that scratch buffer and finally copies the content of the
scratch buffer to the caller's buffer.The scratch buffer is allocated during allocation time of the CTR DRBG
as its access is protected with the DRBG mutex.Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
15 Jun, 2016
2 commits
-
Hardware cipher implementation may require aligned buffers. All buffers
that potentially are processed with a cipher are now aligned.Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu -
The CTR DRBG derives its random data from the CTR that is encrypted with
AES.This patch now changes the CTR DRBG implementation such that the
CTR AES mode is employed. This allows the use of steamlined CTR AES
implementation such as ctr-aes-aesni.Unfortunately there are the following subtile changes we need to apply
when using the CTR AES mode:- the CTR mode increments the counter after the cipher operation, but
the CTR DRBG requires the increment before the cipher op. Hence, the
crypto_inc is applied to the counter (drbg->V) once it is
recalculated.- the CTR mode wants to encrypt data, but the CTR DRBG is interested in
the encrypted counter only. The full CTR mode is the XOR of the
encrypted counter with the plaintext data. To access the encrypted
counter, the patch uses a NULL data vector as plaintext to be
"encrypted".Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
25 Jan, 2016
1 commit
-
The newly released FIPS 140-2 IG 9.8 specifies that for SP800-90A
compliant DRBGs, the FIPS 140-2 continuous random number generator test
is not required any more.This patch removes the test and all associated data structures.
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
10 Jun, 2015
2 commits
-
As required by SP800-90A, the DRBG implements are reseeding threshold.
This threshold is at 2**48 (64 bit) and 2**32 bit (32 bit) as
implemented in drbg_max_requests.With the recently introduced changes, the DRBG is now always used as a
stdrng which is initialized very early in the boot cycle. To ensure that
sufficient entropy is present, the Jitter RNG is added to even provide
entropy at early boot time.However, the 2nd seed source, the nonblocking pool, is usually
degraded at that time. Therefore, the DRBG is seeded with the Jitter RNG
(which I believe contains good entropy, which however is questioned by
others) and is seeded with a degradded nonblocking pool. This seed is
now used for quasi the lifetime of the system (2**48 requests is a lot).The patch now changes the reseed threshold as follows: up until the time
the DRBG obtains a seed from a fully iniitialized nonblocking pool, the
reseeding threshold is lowered such that the DRBG is forced to reseed
itself resonably often. Once it obtains the seed from a fully
initialized nonblocking pool, the reseed threshold is set to the value
required by SP800-90A.Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu -
The get_blocking_random_bytes API is broken because the wait can
be arbitrarily long (potentially forever) so there is no safe way
of calling it from within the kernel.This patch replaces it with the new callback API which does not
have this problem.The patch also removes the entropy buffer registered with the DRBG
handle in favor of stack variables to hold the seed data.Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
27 May, 2015
3 commits
-
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now the seed for the DRBG.Written differently, the initial seed of the DRBG is now:
get_random_bytes(entropy/nonce) || jitterentropy (entropy/nonce)
If the Jitter RNG is not available, the DRBG only seeds from
get_random_bytes.CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu -
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the actual seeding of the DRBG.CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu -
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for the initial seeding operation as well as by the
asynchronous seeding call. The memory must be zeroized every time the
DRBG seeding call succeeds to avoid entropy data lingering in memory.CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
22 Apr, 2015
1 commit
-
This patch converts the DRBG implementation to the new low-level
rng interface.This allows us to get rid of struct drbg_gen by using the new RNG
API instead.Signed-off-by: Herbert Xu
Acked-by: Stephan Mueller
21 Apr, 2015
1 commit
-
The creation of a shadow copy is intended to only hold a short term
lock. But the drawback is that parallel users have a very similar DRBG
state which only differs by a high-resolution time stamp.The DRBG will now hold a long term lock. Therefore, the lock is changed
to a mutex which implies that the DRBG can only be used in process
context.The lock now guards the instantiation as well as the entire DRBG
generation operation. Therefore, multiple callers are fully serialized
when generating a random number.As the locking is changed to use a long-term lock to avoid such similar
DRBG states, the entire creation and maintenance of a shadow copy can be
removed.Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
26 Aug, 2014
1 commit
-
The maximum values for additional input string or generated blocks is
larger than 1<
Reported-by: kbuild test robot
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
25 Aug, 2014
1 commit
-
SP800-90A mandates several hard-coded values. The old drbg_cores allows
the setting of these values per DRBG implementation. However, due to the
hard requirement of SP800-90A, these values are now returned globally
for each DRBG.The ability to set such values per DRBG is therefore removed.
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
08 Jul, 2014
1 commit
-
The current locking approach of the DRBG tries to keep the protected
code paths very minimal. It is therefore possible that two threads query
one DRBG instance at the same time. When thread A requests random
numbers, a shadow copy of the DRBG state is created upon which the
request for A is processed. After finishing the state for A's request is
merged back into the DRBG state. If now thread B requests random numbers
from the same DRBG after the request for thread A is received, but
before A's shadow state is merged back, the random numbers for B will be
identical to the ones for A. Please note that the time window is very
small for this scenario.To prevent that there is even a theoretical chance for thread A and B
having the same DRBG state, the current time stamp is provided as
additional information string for each new request.The addition of the time stamp as additional information string implies
that now all generate functions must be capable to process a linked
list with additional information strings instead of a scalar.CC: Rafael Aquini
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
04 Jul, 2014
1 commit
-
The DRBG-style linked list to manage input data that is fed into the
cipher invocations is replaced with the kernel linked list
implementation.The change is transparent to users of the interfaces offered by the
DRBG. Therefore, no changes to the testmgr code is needed.Reported-by: kbuild test robot
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
20 Jun, 2014
1 commit
-
The header file includes the definition of:
* DRBG data structures with
- struct drbg_state as main structure
- struct drbg_core referencing the backend ciphers
- struct drbg_state_ops callbach handlers for specific code
supporting the Hash, HMAC, CTR DRBG implementations
- struct drbg_conc defining a linked list for input data
- struct drbg_test_data holding the test "entropy" data for CAVS
testing and testmgr.c
- struct drbg_gen allowing test data, additional information
string and personalization string data to be funneled through
the kernel crypto API -- the DRBG requires additional
parameters when invoking the reset and random number
generation requests than intended by the kernel crypto API* wrapper function to the kernel crypto API functions using struct
drbg_gen to pass through all data needed for DRBG* wrapper functions to kernel crypto API functions usable for testing
code to inject test_data into the DRBG as needed by CAVS testing and
testmgr.c.* DRBG flags required for the operation of the DRBG and for selecting
the particular DRBG type and backend cipher* getter functions for data from struct drbg_core
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu