- 26 Nov, 2021 37 commits
-
-
Kai Ye authored
Modify the value of type rate from new QM spec. Signed-off-by:
Kai Ye <yekai13@huawei.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Stephan Müller authored
The kernel crypto API provides the SP800-108 counter KDF implementation. Thus, the separate implementation provided as part of the keys subsystem can be replaced with calls to the KDF offered by the kernel crypto API. The keys subsystem uses the counter KDF with a hash primitive. Thus, it only uses the call to crypto_kdf108_ctr_generate. Signed-off-by:
Stephan Mueller <smueller@chronox.de> Acked-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Stephan Müller authored
Remove the specific code that adds a zero padding that was intended to be invoked when the DH operation result was smaller than the modulus. However, this cannot occur any more these days because the function mpi_write_to_sgl is used in the code path that calculates the shared secret in dh_compute_value. This MPI service function guarantees that leading zeros are introduced as needed to ensure the resulting data is exactly as long as the modulus. This implies that the specific code to add zero padding is dead code which can be safely removed. Signed-off-by:
-
Stephan Müller authored
SP800-108 defines three KDFs - this patch provides the counter KDF implementation. The KDF is implemented as a service function where the caller has to maintain the hash / HMAC state. Apart from this hash/HMAC state, no additional state is required to be maintained by either the caller or the KDF implementation. The key for the KDF is set with the crypto_kdf108_setkey function which is intended to be invoked before the caller requests a key derivation operation via crypto_kdf108_ctr_generate. SP800-108 allows the use of either a HMAC or a hash as crypto primitive for the KDF. When a HMAC primtive is intended to be used, crypto_kdf108_setkey must be used to set the HMAC key. Otherwise, for a hash crypto primitve crypto_kdf108_ctr_generate can be used immediately after allocating the hash handle. Signed-off-by:
-
Stephan Müller authored
As a preparation to add the key derivation implementations, the self-test data structure definition and the common test code is made available. The test framework follows the testing applied by the NIST CAVP test approach. The structure of the test code follows the implementations found in crypto/testmgr.c|h. In case the KDF implementations will be made available via a kernel crypto API templates, the test code is intended to be merged into testmgr.c|h. Signed-off-by:
-
Corentin Labbe authored
The Allwinner D1 SoC has a crypto engine compatible with sun8i-ce. Add support for it. Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
-
Marco Chiappero authored
Improve and simplify logging of PFVF messages. Signed-off-by:
Marco Chiappero <marco.chiappero@intel.com> Reviewed-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by:
-
Marco Chiappero authored
PFVF debug messages use a mix of zero and one based VF IDs. Switch to zero based VF numbers in all log messages. Signed-off-by:
-
Marco Chiappero authored
Remove min_iov_compat_ver field as for now all versions are compatible. Compatibility is determined by a series of rules and dynamic conditions such as specific configurations. In any case the minimum version requirement for compatibility is an inadequate and obsolete approach which should be removed. At this time compatibility can be assured across the currently available versions. Signed-off-by:
-
Marco Chiappero authored
Refactor version handling logic for ADF_VF2PF_MSGTYPE_COMPAT_VER_REQ and ADF_VF2PF_MSGTYPE_VERSION_REQ on the PF. Response messages are now filled only after fully parsing the request, in a consisted way with the rest of the PFVF codebase. This patch also fixes a harmless double setting for VERSION in the response for ADF_VF2PF_MSGTYPE_VERSION_REQ. Signed-off-by:
-
Marco Chiappero authored
Currently, any PF response to a VF request is fully parsed during the interrupt handling. This way the individual response values are stored into the accel_dev structure, preventing the caller to access and decode the full response message itself. Change this behavior, by letting the API return back the entire message to the caller, in order to: - keep correlated code together, that is, the (building of the) request and the (decoding of the) response; - avoid polluting the accel_dev data structure with unnecessary and at times temporary values; only the entire message is stored in a temporary buffer. Signed-off-by: -
Marco Chiappero authored
Replace PFVF constants with enumerations for valid protocol codes. Signed-off-by:
-
Marco Chiappero authored
Organize PFVF protocol definitions by type rather than direction, by keeping related fields close. Also, make sure the order is consistent for both PF and VF definitions. Signed-off-by:
-
Marco Chiappero authored
Reorganize the structure of the PFVF code by moving the content of adf_pf2vf_msg.c and adf_vf2pf_msg.c. The logic that handles high level messages has been moved to adf_pfvf_pf_msg.c and adf_pfvf_vf_msg.c. The implementation of low level communication primitives and the protocol is now included in adf_pfvf_pf_proto.c and adf_pfvf_vf_proto.c. In addition, the file adf_pf2vf_msg.h has been renamed in adf_pfvf_msg.h since it common to PF and VF and the copyright date for the touched files has been updated. Signed-off-by:
-
Giovanni Cabiddu authored
Refactor the PFVF receive logic so it is common between PF and VF and make it device specific. This is in preparation for the introduction of PFVF support in the qat_4xxx driver since the receive logic differs between QAT GEN2 and QAT GEN4 devices. Signed-off-by:
-
Marco Chiappero authored
Make the PFVF send function device specific. This is in preparation for the introduction of PFVF support in the qat_4xxx driver since the send logic differs between QAT GEN2 and QAT GEN4 devices. Signed-off-by:
-
Marco Chiappero authored
Add the function get_vf2pf_offset() to adf_pfvf_ops to differentiate the CSRs used for pf2vf and vf2pf. Offsets may or may not be direction specific depending on QAT generation. Since in QAT GEN2 the CSR is not direction specific, i.e. there is a single mailbox register shared for pf2vf and vf2pf, both get_vf2pf_offset() and get_vf2pf_offset() will return the same offset. This change is to make the direction explicit, so it is easier to understand and debug and also in preparation for the introduction of PFVF support in the qat_4xxx driver since QAT GEN4 devices have a separate CSR for pf2vf and vf2pf communications. Signed-off-by:
-
Marco Chiappero authored
Add pfvf_ops structure to isolate PFVF related functions inside the adf_hw_device_data structure. For GEN2, the structure is populated using one of the two helper functions, adf_gen2_init_pf_pfvf_ops() or adf_gen2_init_vf_pfvf_ops(), for the PF and VF driver respectively. For the DH895XCC PF driver, the structure is populated using adf_gen2_init_pf_pfvf_ops() but some of the functions are then overwritten. Signed-off-by:
-
Giovanni Cabiddu authored
Move the function pfvf_comms_disabled() from the qat_4xxx module to intel_qat as it will be used by other components to keep the PFVF feature disabled. Signed-off-by:
-
Marco Chiappero authored
Move device specific PFVF logic related to the VF to the newly created adf_gen2_pfvf.c. This refactory is done to isolate the GEN2 PFVF code into its own file in preparation for the introduction of support for PFVF for GEN4 devices. Signed-off-by:
-
Marco Chiappero authored
Move device specific PFVF logic related to the PF to the newly created adf_gen2_pfvf.c. This refactory is done to isolate the GEN2 PFVF code into its own file in preparation for the introduction of support for PFVF for GEN4 devices. In addition the PFVF PF logic for dh895xcc has been isolated to adf_dh895xcc_hw_data.c. Signed-off-by:
-
Marco Chiappero authored
Rework __adf_iov_putmsg() to handle retries due to collisions internally, removing the need for an external retry loop. The functions __adf_iov_putmsg() and adf_iov_putmsg() have been merged together maintaining the adf_iov_putmsg() name. This will allow to use this function only for GEN2 devices, since collision are peculiar of this generation and therefore should be confined to the actual implementation of the transport/medium access. Note that now adf_iov_putmsg() will retry to send a message only in case of collisions and will now fail if an ACK is not received from the remote function. Signed-off-by:
-
Marco Chiappero authored
Refactor the receive and handle logic to separate the parsing and handling of the PFVF message from the initial retrieval and ACK. This is to allow the intoduction of the recv function in a subsequent patch. Signed-off-by:
-
Giovanni Cabiddu authored
If a PFVF message with MSGORIGIN_SYSTEM not set is received, re-enable interrupts allowing the processing of new messages. This is to simplify the refactoring of the recv function in a subsequent patch. Signed-off-by:
-
Giovanni Cabiddu authored
Change the PFVF receipt flow on the VF side to read, ack and handle the message instead of read, handle and ack. This is done for (1) consistency with the PF side, see the function adf_recv_and_handle_vf2pf_msg() in adf_pf2vf_msg.c, and (2) performance reasons, to avoid keeping the CSR busy while parsing the message. In addition, do not ACK PFVF legacy messages, as this driver is not capable of handling PFVF legacy messages. If a PFVF message with MSGORIGIN not set is received, do nothing. Signed-off-by:
-
Marco Chiappero authored
Move the interrupt handling call from the PF specific protocol file, adf_pf2vf_msg.c, to adf_sriov.c to maintain the PFVF files focused on the protocol handling. The function adf_vf2pf_req_hndl() has been renamed as adf_recv_and_handle_vf2pf_msg() to reflect its actual purpose and maintain consistency with the VF side. This function now returns a boolean indicating to the caller if interrupts need to be re-enabled or not. Signed-off-by:
-
Marco Chiappero authored
Move the reading and parsing of a PF2VF message from the bottom half function in adf_vf_isr.c, adf_pf2vf_bh_handler(), to the PFVF protocol file adf_vf2pf_msg.c, for better code organization. The receive and handle logic has been moved to a new function called adf_recv_and_handle_pf2vf_msg() which returns a boolean indicating if interrupts need to be re-enabled or not. A slight refactoring has been done to avoid calculating the PF2VF CSR offset twice and repeating the clearing of the PF2VFINT bit. The "PF restarting" logic, now defined in the function adf_pf2vf_handle_pf_restaring(), has been kept in adf_vf_isr.c due to the dependencies with the adf_vf_stop_wq workqueue. Signed-off-by:
-
Giovanni Cabiddu authored
Move vf2pf interrupt enable and disable functions from adf_pf2vf_msg.c to adf_isr.c This it to separate the interrupt related code from the PFVF protocol logic. With this change, the function adf_disable_vf2pf_interrupts_irq() is only called from adf_isr.c and it has been marked as static. Signed-off-by:
-
Marco Chiappero authored
Move logic associated to handling VF2PF interrupt to its own function. This will simplify the handling of multiple interrupt sources in the function adf_msix_isr_ae() in the future. Signed-off-by:
-
Giovanni Cabiddu authored
If the remote function did not ACK the reception of a message, the function __adf_iov_putmsg() could detect it as a collision. This was due to the fact that the collision and the timeout checks after the ACK loop were in the wrong order. The timeout must be checked at the end of the loop, so fix by swapping the order of the two checks. Fixes: 9b768e8a ("crypto: qat - detect PFVF collision after ACK") Signed-off-by:
-
Giovanni Cabiddu authored
The QAT driver does not have support for PFVF interrupts for GEN4 devices, therefore report the vf2pf sources as 0. This prevents a NULL pointer dereference in the function adf_msix_isr_ae() if the device triggers a spurious interrupt. Fixes: 993161d3 ("crypto: qat - fix handling of VF to PF interrupts") Reported-by:
Adam Guerin <adam.guerin@intel.com> Signed-off-by:
-
Nicolai Stange authored
In contrast to the fully prediction resistant 'pr' DRBGs, the 'nopr' variants get seeded once at boot and reseeded only rarely thereafter, namely only after 2^20 requests have been served each. AFAICT, this reseeding based on the number of requests served is primarily motivated by information theoretic considerations, c.f. NIST SP800-90Ar1, sec. 8.6.8 ("Reseeding"). However, given the relatively large seed lifetime of 2^20 requests, the 'nopr' DRBGs can hardly be considered to provide any prediction resistance whatsoever, i.e. to protect against threats like side channel leaks of the internal DRBG state (think e.g. leaked VM snapshots). This is expected and completely in line with the 'nopr' naming, but as e.g. the "drbg_nopr_hmac_sha512" implementation is potentially being used for providing the "stdrng" and thus, the crypto_default_rng serving the in-kernel crypto, it would certainly be desirable to achieve at least the same level of prediction resistance as get_random_bytes() does. Note that the chacha20 rngs underlying get_random_bytes() get reseeded every CRNG_RESEED_INTERVAL == 5min: the secondary, per-NUMA node rngs from the primary one and the primary rng in turn from the entropy pool, provided sufficient entropy is available. The 'nopr' DRBGs do draw randomness from get_random_bytes() for their initial seed already, so making them to reseed themselves periodically from get_random_bytes() in order to let them benefit from the latter's prediction resistance is not such a big change conceptually. In principle, it would have been also possible to make the 'nopr' DRBGs to periodically invoke a full reseeding operation, i.e. to also consider the jitterentropy source (if enabled) in addition to get_random_bytes() for the seed value. However, get_random_bytes() is relatively lightweight as compared to the jitterentropy generation process and thus, even though the 'nopr' reseeding is supposed to get invoked infrequently, it's IMO still worthwhile to avoid occasional latency spikes for drbg_generate() and stick to get_random_bytes() only. As an additional remark, note that drawing randomness from the non-SP800-90B-conforming get_random_bytes() only won't adversely affect SP800-90A conformance either: the very same is being done during boot via drbg_seed_from_random() already once rng_is_initialized() flips to true and it follows that if the DRBG implementation does conform to SP800-90A now, it will continue to do so. Make the 'nopr' DRBGs to reseed themselves periodically from get_random_bytes() every CRNG_RESEED_INTERVAL == 5min. More specifically, introduce a new member ->last_seed_time to struct drbg_state for recording in units of jiffies when the last seeding operation had taken place. Make __drbg_seed() maintain it and let drbg_generate() invoke a reseed from get_random_bytes() via drbg_seed_from_random() if more than 5min have passed by since the last seeding operation. Be careful to not to reseed if in testing mode though, or otherwise the drbg related tests in crypto/testmgr.c would fail to reproduce the expected output. In order to keep the formatting clean in drbg_generate() wrap the logic for deciding whether or not a reseed is due in a new helper, drbg_nopr_reseed_interval_elapsed(). Signed-off-by:Nicolai Stange <nstange@suse.de> Reviewed-by:
-
Nicolai Stange authored
Now that drbg_prepare_hrng() doesn't do anything but to instantiate a jitterentropy crypto_rng instance, it looks a little odd to have the related error handling at its only caller, drbg_instantiate(). Move the handling of jitterentropy allocation failures from drbg_instantiate() close to the allocation itself in drbg_prepare_hrng(). There is no change in behaviour. Signed-off-by:
-
Nicolai Stange authored
get_random_bytes() usually hasn't full entropy available by the time DRBG instances are first getting seeded from it during boot. Thus, the DRBG implementation registers random_ready_callbacks which would in turn schedule some work for reseeding the DRBGs once get_random_bytes() has sufficient entropy available. For reference, the relevant history around handling DRBG (re)seeding in the context of a not yet fully seeded get_random_bytes() is: commit 16b369a9 ("random: Blocking API for accessing nonblocking_pool") commit 4c787990 ("crypto: drbg - add async seeding operation") commit 205a525c ("random: Add callback API for random pool readiness") commit 57225e67 ("crypto: drbg - Use callback API for random readiness") commit c2719503 ("random: Remove kernel blocking API") However, some time later, the initialization state of get_random_bytes() has been made queryable via rng_is_initialized() introduced with commit 9a47249d ("random: Make crng state queryable"). This primitive now allows for streamlining the DRBG reseeding from get_random_bytes() by replacing that aforementioned asynchronous work scheduling from random_ready_callbacks with some simpler, synchronous code in drbg_generate() next to the related logic already present therein. Apart from improving overall code readability, this change will also enable DRBG users to rely on wait_for_random_bytes() for ensuring that the initial seeding has completed, if desired. The previous patches already laid the grounds by making drbg_seed() to record at each DRBG instance whether it was being seeded at a time when rng_is_initialized() still had been false as indicated by ->seeded == DRBG_SEED_STATE_PARTIAL. All that remains to be done now is to make drbg_generate() check for this condition, determine whether rng_is_initialized() has flipped to true in the meanwhile and invoke a reseed from get_random_bytes() if so. Make this move: - rename the former drbg_async_seed() work handler, i.e. the one in charge of reseeding a DRBG instance from get_random_bytes(), to "drbg_seed_from_random()", - change its signature as appropriate, i.e. make it take a struct drbg_state rather than a work_struct and change its return type from "void" to "int" in order to allow for passing error information from e.g. its __drbg_seed() invocation onwards to callers, - make drbg_generate() invoke this drbg_seed_from_random() once it encounters a DRBG instance with ->seeded == DRBG_SEED_STATE_PARTIAL by the time rng_is_initialized() has flipped to true and - prune everything related to the former, random_ready_callback based mechanism. As drbg_seed_from_random() is now getting invoked from drbg_generate() with the ->drbg_mutex being held, it must not attempt to recursively grab it once again. Remove the corresponding mutex operations from what is now drbg_seed_from_random(). Furthermore, as drbg_seed_from_random() can now report errors directly to its caller, there's no need for it to temporarily switch the DRBG's ->seeded state to DRBG_SEED_STATE_UNSEEDED so that a failure of the subsequently invoked __drbg_seed() will get signaled to drbg_generate(). Don't do it then. Signed-off-by:
-
Nicolai Stange authored
Since commit 42ea507f ("crypto: drbg - reseed often if seedsource is degraded"), the maximum seed lifetime represented by ->reseed_threshold gets temporarily lowered if the get_random_bytes() source cannot provide sufficient entropy yet, as is common during boot, and restored back to the original value again once that has changed. More specifically, if the add_random_ready_callback() invoked from drbg_prepare_hrng() in the course of DRBG instantiation does not return -EALREADY, that is, if get_random_bytes() has not been fully initialized at this point yet, drbg_prepare_hrng() will lower ->reseed_threshold to a value of 50. The drbg_async_seed() scheduled from said random_ready_callback will eventually restore the original value. A future patch will replace the random_ready_callback based notification mechanism and thus, there will be no add_random_ready_callback() return value anymore which could get compared to -EALREADY. However, there's __drbg_seed() which gets invoked in the course of both, the DRBG instantiation as well as the eventual reseeding from get_random_bytes() in aforementioned drbg_async_seed(), if any. Moreover, it knows about the get_random_bytes() initialization state by the time the seed data had been obtained from it: the new_seed_state argument introduced with the previous patch would get set to DRBG_SEED_STATE_PARTIAL in case get_random_bytes() had not been fully initialized yet and to DRBG_SEED_STATE_FULL otherwise. Thus, __drbg_seed() provides a convenient alternative for managing that ->reseed_threshold lowering and restoring at a central place. Move all ->reseed_threshold adjustment code from drbg_prepare_hrng() and drbg_async_seed() respectively to __drbg_seed(). Make __drbg_seed() lower the ->reseed_threshold to 50 in case its new_seed_state argument equals DRBG_SEED_STATE_PARTIAL and let it restore the original value otherwise. There is no change in behaviour. Signed-off-by:
-
Nicolai Stange authored
Currently, the DRBG implementation schedules asynchronous works from random_ready_callbacks for reseeding the DRBG instances with output from get_random_bytes() once the latter has sufficient entropy available. However, as the get_random_bytes() initialization state can get queried by means of rng_is_initialized() now, there is no real need for this asynchronous reseeding logic anymore and it's better to keep things simple by doing it synchronously when needed instead, i.e. from drbg_generate() once rng_is_initialized() has flipped to true. Of course, for this to work, drbg_generate() would need some means by which it can tell whether or not rng_is_initialized() has flipped to true since the last seeding from get_random_bytes(). Or equivalently, whether or not the last seed from get_random_bytes() has happened when rng_is_initialized() was still evaluating to false. As it currently stands, enum drbg_seed_state allows for the representation of two different DRBG seeding states: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. The former makes drbg_generate() to invoke a full reseeding operation involving both, the rather expensive jitterentropy as well as the get_random_bytes() randomness sources. The DRBG_SEED_STATE_FULL state on the other hand implies that no reseeding at all is required for a !->pr DRBG variant. Introduce the new DRBG_SEED_STATE_PARTIAL state to enum drbg_seed_state for representing the condition that a DRBG was being seeded when rng_is_initialized() had still been false. In particular, this new state implies that - the given DRBG instance has been fully seeded from the jitterentropy source (if enabled) - and drbg_generate() is supposed to reseed from get_random_bytes() *only* once rng_is_initialized() turns to true. Up to now, the __drbg_seed() helper used to set the given DRBG instance's ->seeded state to constant DRBG_SEED_STATE_FULL. Introduce a new argument allowing for the specification of the to be written ->seeded value instead. Make the first of its two callers, drbg_seed(), determine the appropriate value based on rng_is_initialized(). The remaining caller, drbg_async_seed(), is known to get invoked only once rng_is_initialized() is true, hence let it pass constant DRBG_SEED_STATE_FULL for the new argument to __drbg_seed(). There is no change in behaviour, except for that the pr_devel() in drbg_generate() would now report "unseeded" for ->pr DRBG instances which had last been seeded when rng_is_initialized() was still evaluating to false. Signed-off-by:
-
Nicolai Stange authored
There are two different randomness sources the DRBGs are getting seeded from, namely the jitterentropy source (if enabled) and get_random_bytes(). At initial DRBG seeding time during boot, the latter might not have collected sufficient entropy for seeding itself yet and thus, the DRBG implementation schedules a reseed work from a random_ready_callback once that has happened. This is particularly important for the !->pr DRBG instances, for which (almost) no further reseeds are getting triggered during their lifetime. Because collecting data from the jitterentropy source is a rather expensive operation, the aforementioned asynchronously scheduled reseed work restricts itself to get_random_bytes() only. That is, it in some sense amends the initial DRBG seed derived from jitterentropy output at full (estimated) entropy with fresh randomness obtained from get_random_bytes() once that has been seeded with sufficient entropy itself. With the advent of rng_is_initialized(), there is no real need for doing the reseed operation from an asynchronously scheduled work anymore and a subsequent patch will make it synchronous by moving it next to related logic already present in drbg_generate(). However, for tracking whether a full reseed including the jitterentropy source is required or a "partial" reseed involving only get_random_bytes() would be sufficient already, the boolean struct drbg_state's ->seeded member must become a tristate value. Prepare for this by introducing the new enum drbg_seed_state and change struct drbg_state's ->seeded member's type from bool to that type. For facilitating review, enum drbg_seed_state is made to only contain two members corresponding to the former ->seeded values of false and true resp. at this point: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. A third one for tracking the intermediate state of "seeded from jitterentropy only" will be introduced with a subsequent patch. There is no change in behaviour at this point. Signed-off-by:
-
- 20 Nov, 2021 3 commits
-
-
Jason Wang authored
Static variables do not need to be initialized to 0. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Signed-off-by:
-
Christophe JAILLET authored
'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Cristian Marussi <cristian.marussi@arm.com> Acked-by:
Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
-
chiminghao authored
Fix the following coccicheck REVIEW: ./drivers/crypto/marvell/octeontx2/otx2_cptvf_algs.c:1688:16-17 use swap() to make code cleaner Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
chiminghao <chi.minghao@zte.com.cn> Signed-off-by:
-
