Fix spelling errors in comments
This patch simply corrects some spelling / grammar errors in the QAT and encryption code comments. No functional changes Reviewed-by: George Melikov <mail@gmelikov.ru> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Giuseppe Di Natale <dinatale2@llnl.gov> Signed-off-by: Tom Caputi <tcaputi@datto.com> Closes #7319
This commit is contained in:
parent
c66e54e9dc
commit
8d9e7c8fbe
|
@ -46,96 +46,97 @@ typedef enum qat_encrypt_dir {
|
|||
#define QAT_TIMEOUT_MS 500
|
||||
|
||||
/*
|
||||
* The minimal and maximal buffer size, which are not restricted
|
||||
* The minimal and maximal buffer size which are not restricted
|
||||
* in the QAT hardware, but with the input buffer size between 4KB
|
||||
* and 128KB, the hardware can provide the optimal performance.
|
||||
* and 128KB the hardware can provide the optimal performance.
|
||||
*/
|
||||
#define QAT_MIN_BUF_SIZE (4*1024)
|
||||
#define QAT_MAX_BUF_SIZE (128*1024)
|
||||
|
||||
/*
|
||||
* Used for qat kstat.
|
||||
* Used for QAT kstat.
|
||||
*/
|
||||
typedef struct qat_stats {
|
||||
/*
|
||||
* Number of jobs submitted to qat compression engine.
|
||||
* Number of jobs submitted to QAT compression engine.
|
||||
*/
|
||||
kstat_named_t comp_requests;
|
||||
/*
|
||||
* Total bytes sent to qat compression engine.
|
||||
* Total bytes sent to QAT compression engine.
|
||||
*/
|
||||
kstat_named_t comp_total_in_bytes;
|
||||
/*
|
||||
* Total bytes output from qat compression engine.
|
||||
* Total bytes output from QAT compression engine.
|
||||
*/
|
||||
kstat_named_t comp_total_out_bytes;
|
||||
/*
|
||||
* Number of jobs submitted to qat de-compression engine.
|
||||
* Number of jobs submitted to QAT de-compression engine.
|
||||
*/
|
||||
kstat_named_t decomp_requests;
|
||||
/*
|
||||
* Total bytes sent to qat de-compression engine.
|
||||
* Total bytes sent to QAT de-compression engine.
|
||||
*/
|
||||
kstat_named_t decomp_total_in_bytes;
|
||||
/*
|
||||
* Total bytes output from qat de-compression engine.
|
||||
* Total bytes output from QAT de-compression engine.
|
||||
*/
|
||||
kstat_named_t decomp_total_out_bytes;
|
||||
/*
|
||||
* Number of fails in the qat compression / decompression engine.
|
||||
* Note: when qat fail happens, it doesn't mean a critical hardware
|
||||
* issue. Sometimes it is because the output buffer is not big enough.
|
||||
* The compression job will be transfered to gzip software
|
||||
* implementation, so the functionality of ZFS is not impacted.
|
||||
* Number of fails in the QAT compression / decompression engine.
|
||||
* Note: when a QAT error happens, it doesn't necessarily indicate a
|
||||
* critical hardware issue. Sometimes it is because the output buffer
|
||||
* is not big enough. The compression job will be transfered to the
|
||||
* gzip software implementation so the functionality of ZFS is not
|
||||
* impacted.
|
||||
*/
|
||||
kstat_named_t dc_fails;
|
||||
|
||||
/*
|
||||
* Number of jobs submitted to qat encryption engine.
|
||||
* Number of jobs submitted to QAT encryption engine.
|
||||
*/
|
||||
kstat_named_t encrypt_requests;
|
||||
/*
|
||||
* Total bytes sent to qat encryption engine.
|
||||
* Total bytes sent to QAT encryption engine.
|
||||
*/
|
||||
kstat_named_t encrypt_total_in_bytes;
|
||||
/*
|
||||
* Total bytes output from qat encryption engine.
|
||||
* Total bytes output from QAT encryption engine.
|
||||
*/
|
||||
kstat_named_t encrypt_total_out_bytes;
|
||||
/*
|
||||
* Number of jobs submitted to qat decryption engine.
|
||||
* Number of jobs submitted to QAT decryption engine.
|
||||
*/
|
||||
kstat_named_t decrypt_requests;
|
||||
/*
|
||||
* Total bytes sent to qat decryption engine.
|
||||
* Total bytes sent to QAT decryption engine.
|
||||
*/
|
||||
kstat_named_t decrypt_total_in_bytes;
|
||||
/*
|
||||
* Total bytes output from qat decryption engine.
|
||||
* Total bytes output from QAT decryption engine.
|
||||
*/
|
||||
kstat_named_t decrypt_total_out_bytes;
|
||||
/*
|
||||
* Number of fails in the qat encryption / decryption engine.
|
||||
* Note: when qat fail happens, it doesn't mean a critical hardware
|
||||
* issue. Sometimes it is because the output buffer is not big enough.
|
||||
* The encryption job will be transfered to the software implementation,
|
||||
* so the functionality of ZFS is not impacted.
|
||||
* Number of fails in the QAT encryption / decryption engine.
|
||||
* Note: when a QAT error happens, it doesn't necessarily indicate a
|
||||
* critical hardware issue. The encryption job will be transfered
|
||||
* to the software implementation so the functionality of ZFS is
|
||||
* not impacted.
|
||||
*/
|
||||
kstat_named_t crypt_fails;
|
||||
|
||||
/*
|
||||
* Number of jobs submitted to qat checksum engine.
|
||||
* Number of jobs submitted to QAT checksum engine.
|
||||
*/
|
||||
kstat_named_t cksum_requests;
|
||||
/*
|
||||
* Total bytes sent to qat checksum engine.
|
||||
* Total bytes sent to QAT checksum engine.
|
||||
*/
|
||||
kstat_named_t cksum_total_in_bytes;
|
||||
/*
|
||||
* Number of fails in the qat checksum engine.
|
||||
* Note: when qat fail happens, it doesn't mean a critical hardware
|
||||
* issue. The checksum job will be transfered to the software
|
||||
* implementation, so the functionality of ZFS is not impacted.
|
||||
* Number of fails in the QAT checksum engine.
|
||||
* Note: when a QAT error happens, it doesn't necessarily indicate a
|
||||
* critical hardware issue. The checksum job will be transfered to the
|
||||
* software implementation so the functionality of ZFS is not impacted.
|
||||
*/
|
||||
kstat_named_t cksum_fails;
|
||||
} qat_stats_t;
|
||||
|
|
|
@ -28,10 +28,10 @@
|
|||
#include "qat.h"
|
||||
|
||||
/*
|
||||
* Max instances in QAT device, each instance is a channel to submit
|
||||
* jobs to QAT hardware, this is only for pre-allocating instance,
|
||||
* and session arrays, the actual number of instances are defined in
|
||||
* the QAT driver's configure file.
|
||||
* Max instances in a QAT device, each instance is a channel to submit
|
||||
* jobs to QAT hardware, this is only for pre-allocating instance and
|
||||
* session arrays; the actual number of instances are defined in the
|
||||
* QAT driver's configuration file.
|
||||
*/
|
||||
#define QAT_DC_MAX_INSTANCES 48
|
||||
|
||||
|
@ -386,7 +386,7 @@ qat_compress(qat_compress_dir_t dir, char *src, int src_len,
|
|||
/* move to the last page */
|
||||
flat_buf_dst += (compressed_sz + hdr_sz) >> PAGE_SHIFT;
|
||||
|
||||
/* no space for gzip foot in the last page */
|
||||
/* no space for gzip footer in the last page */
|
||||
if (((compressed_sz + hdr_sz) % PAGE_SIZE)
|
||||
+ ZLIB_FOOT_SZ > PAGE_SIZE)
|
||||
goto fail;
|
||||
|
|
|
@ -38,9 +38,9 @@
|
|||
#include "qat.h"
|
||||
|
||||
/*
|
||||
* Max instances in QAT device, each instance is a channel to submit
|
||||
* jobs to QAT hardware, this is only for pre-allocating instance,
|
||||
* and session arrays, the actual number of instances are defined in
|
||||
* Max instances in a QAT device, each instance is a channel to submit
|
||||
* jobs to QAT hardware, this is only for pre-allocating instances
|
||||
* and session arrays; the actual number of instances are defined in
|
||||
* the QAT driver's configure file.
|
||||
*/
|
||||
#define QAT_CRYPT_MAX_INSTANCES 48
|
||||
|
|
|
@ -81,7 +81,7 @@
|
|||
* A secret binary key, generated from an HKDF function used to encrypt and
|
||||
* decrypt data.
|
||||
*
|
||||
* Message Authenication Code (MAC)
|
||||
* Message Authentication Code (MAC)
|
||||
* The MAC is an output of authenticated encryption modes such as AES-GCM and
|
||||
* AES-CCM. Its purpose is to ensure that an attacker cannot modify encrypted
|
||||
* data on disk and return garbage to the application. Effectively, it is a
|
||||
|
@ -121,7 +121,7 @@
|
|||
* OBJECT SET AUTHENTICATION:
|
||||
* Up to this point, everything we have encrypted and authenticated has been
|
||||
* at level 0 (or -2 for the ZIL). If we did not do any further work the
|
||||
* on-disk format would be susceptible to attacks that deleted or rearrannged
|
||||
* on-disk format would be susceptible to attacks that deleted or rearranged
|
||||
* the order of level 0 blocks. Ideally, the cleanest solution would be to
|
||||
* maintain a tree of authentication MACs going up the bp tree. However, this
|
||||
* presents a problem for raw sends. Send files do not send information about
|
||||
|
@ -131,11 +131,11 @@
|
|||
* for the indirect levels of the bp tree, we use a regular SHA512 of the MACs
|
||||
* from the level below. We also include some portable fields from blk_prop such
|
||||
* as the lsize and compression algorithm to prevent the data from being
|
||||
* misinterpretted.
|
||||
* misinterpreted.
|
||||
*
|
||||
* At the objset level, we maintain 2 seperate 256 bit MACs in the
|
||||
* At the objset level, we maintain 2 separate 256 bit MACs in the
|
||||
* objset_phys_t. The first one is "portable" and is the logical root of the
|
||||
* MAC tree maintianed in the metadnode's bps. The second, is "local" and is
|
||||
* MAC tree maintained in the metadnode's bps. The second, is "local" and is
|
||||
* used as the root MAC for the user accounting objects, which are also not
|
||||
* transferred via "zfs send". The portable MAC is sent in the DRR_BEGIN payload
|
||||
* of the send file. The useraccounting code ensures that the useraccounting
|
||||
|
@ -148,13 +148,13 @@
|
|||
* need to use the same IV and encryption key, so that they will have the same
|
||||
* ciphertext. Normally, one should never reuse an IV with the same encryption
|
||||
* key or else AES-GCM and AES-CCM can both actually leak the plaintext of both
|
||||
* blocks. In this case, however, since we are using the same plaindata as
|
||||
* blocks. In this case, however, since we are using the same plaintext as
|
||||
* well all that we end up with is a duplicate of the original ciphertext we
|
||||
* already had. As a result, an attacker with read access to the raw disk will
|
||||
* be able to tell which blocks are the same but this information is given away
|
||||
* by dedup anyway. In order to get the same IVs and encryption keys for
|
||||
* equivalent blocks of data we use an HMAC of the plaindata. We use an HMAC
|
||||
* here so that a reproducible checksum of the plaindata is never available to
|
||||
* equivalent blocks of data we use an HMAC of the plaintext. We use an HMAC
|
||||
* here so that a reproducible checksum of the plaintext is never available to
|
||||
* the attacker. The HMAC key is kept alongside the master key, encrypted on
|
||||
* disk. The first 64 bits of the HMAC are used in place of the random salt, and
|
||||
* the next 96 bits are used as the IV. As a result of this mechanism, dedup
|
||||
|
|
Loading…
Reference in New Issue