aboutsummaryrefslogtreecommitdiff
path: root/crypto/block-luks.c
AgeCommit message (Collapse)AuthorFilesLines
2024-09-10qapi/crypto: Rename QCryptoIVGenAlgorithm to *Algo, and drop prefixMarkus Armbruster1-8/+8
QAPI's 'prefix' feature can make the connection between enumeration type and its constants less than obvious. It's best used with restraint. QCryptoIVGenAlgorithm has a 'prefix' that overrides the generated enumeration constants' prefix to QCRYPTO_IVGEN_ALG. We could simply drop 'prefix', but then the prefix becomes QCRYPTO_IV_GEN_ALGORITHM, which is rather long. We could additionally rename the type to QCryptoIVGenAlg, but I think the abbreviation "alg" is less than clear. Rename the type to QCryptoIVGenAlgo instead. The prefix becomes QCRYPTO_IV_GEN_ALGO. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20240904111836.3273842-14-armbru@redhat.com>
2024-09-10qapi/crypto: Rename QCryptoCipherAlgorithm to *Algo, and drop prefixMarkus Armbruster1-46/+46
QAPI's 'prefix' feature can make the connection between enumeration type and its constants less than obvious. It's best used with restraint. QCryptoCipherAlgorithm has a 'prefix' that overrides the generated enumeration constants' prefix to QCRYPTO_CIPHER_ALG. We could simply drop 'prefix', but then the prefix becomes QCRYPTO_CIPHER_ALGORITHM, which is rather long. We could additionally rename the type to QCryptoCipherAlg, but I think the abbreviation "alg" is less than clear. Rename the type to QCryptoCipherAlgo instead. The prefix becomes QCRYPTO_CIPHER_ALGO. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20240904111836.3273842-13-armbru@redhat.com>
2024-09-10qapi/crypto: Rename QCryptoHashAlgorithm to *Algo, and drop prefixMarkus Armbruster1-8/+8
QAPI's 'prefix' feature can make the connection between enumeration type and its constants less than obvious. It's best used with restraint. QCryptoHashAlgorithm has a 'prefix' that overrides the generated enumeration constants' prefix to QCRYPTO_HASH_ALG. We could simply drop 'prefix', but then the prefix becomes QCRYPTO_HASH_ALGORITHM, which is rather long. We could additionally rename the type to QCryptoHashAlg, but I think the abbreviation "alg" is less than clear. Rename the type to QCryptoHashAlgo instead. The prefix becomes to QCRYPTO_HASH_ALGO. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20240904111836.3273842-12-armbru@redhat.com> [Conflicts with merge commit 7bbadc60b58b resolved]
2024-09-10qapi/crypto: Drop temporary 'prefix'Markus Armbruster1-2/+2
Recent commit "qapi: Smarter camel_to_upper() to reduce need for 'prefix'" added two temporary 'prefix' to delay changing the generated code. Revert them. This improves QCryptoBlockFormat's generated enumeration constant prefix from Q_CRYPTO_BLOCK_FORMAT to QCRYPTO_BLOCK_FORMAT, and QCryptoBlockLUKSKeyslotState's from Q_CRYPTO_BLOCKLUKS_KEYSLOT_STATE to QCRYPTO_BLOCK_LUKS_KEYSLOT_STATE. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20240904111836.3273842-6-armbru@redhat.com>
2024-07-23crypto/block-luks: make range overlap check more readableYao Xingtao1-1/+2
use ranges_overlap() instead of open-coding the overlap check to improve the readability of the code. Signed-off-by: Yao Xingtao <yaoxt.fnst@fujitsu.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20240722040742.11513-12-yaoxt.fnst@fujitsu.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-06-10crypto/block: drop qcrypto_block_open() n_threads argumentStefan Hajnoczi1-1/+0
The n_threads argument is no longer used since the previous commit. Remove it. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240527155851.892885-3-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2024-06-10block/crypto: create ciphers on demandStefan Hajnoczi1-2/+1
Ciphers are pre-allocated by qcrypto_block_init_cipher() depending on the given number of threads. The -device virtio-blk-pci,iothread-vq-mapping= feature allows users to assign multiple IOThreads to a virtio-blk device, but the association between the virtio-blk device and the block driver happens after the block driver is already open. When the number of threads given to qcrypto_block_init_cipher() is smaller than the actual number of threads at runtime, the block->n_free_ciphers > 0 assertion in qcrypto_block_pop_cipher() can fail. Get rid of qcrypto_block_init_cipher() n_thread's argument and allocate ciphers on demand. Reported-by: Qing Wang <qinwang@redhat.com> Buglink: https://issues.redhat.com/browse/RHEL-36159 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240527155851.892885-2-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2024-02-09crypto: Introduce 'detached-header' field in QCryptoBlockInfoLUKSHyman Huang1-0/+2
When querying the LUKS disk with the qemu-img tool or other APIs, add information about whether the LUKS header is detached. Additionally, update the test case with the appropriate modification. Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2024-02-09crypto: Modify the qcrypto_block_create to support creation flagsHyman Huang1-7/+21
Expand the signature of qcrypto_block_create to enable the formation of LUKS volumes with detachable headers. To accomplish that, introduce QCryptoBlockCreateFlags to instruct the creation process to set the payload_offset_sector to 0. Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2024-02-09crypto: Support LUKS volume with detached headerHyman Huang1-4/+7
By enhancing the LUKS driver, it is possible to implement the LUKS volume with a detached header. Normally a LUKS volume has a layout: disk: | header | key material | disk payload data | With a detached LUKS header, you need 2 disks so getting: disk1: | header | key material | disk2: | disk payload data | There are a variety of benefits to doing this: * Secrecy - the disk2 cannot be identified as containing LUKS volume since there's no header * Control - if access to the disk1 is restricted, then even if someone has access to disk2 they can't unlock it. Might be useful if you have disks on NFS but want to restrict which host can launch a VM instance from it, by dynamically providing access to the header to a designated host * Flexibility - your application data volume may be a given size and it is inconvenient to resize it to add encryption.You can store the LUKS header separately and use the existing storage volume for payload * Recovery - corruption of a bit in the header may make the entire payload inaccessible. It might be convenient to take backups of the header. If your primary disk header becomes corrupt, you can unlock the data still by pointing to the backup detached header Take the raw-format image as an example to introduce the usage of the LUKS volume with a detached header: 1. prepare detached LUKS header images $ dd if=/dev/zero of=test-header.img bs=1M count=32 $ dd if=/dev/zero of=test-payload.img bs=1M count=1000 $ cryptsetup luksFormat --header test-header.img test-payload.img > --force-password --type luks1 2. block-add a protocol blockdev node of payload image $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments":{"node-name":"libvirt-1-storage", "driver":"file", > "filename":"test-payload.img"}}' 3. block-add a protocol blockdev node of LUKS header as above. $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments":{"node-name":"libvirt-2-storage", "driver":"file", > "filename": "test-header.img" }}' 4. object-add the secret for decrypting the cipher stored in LUKS header above $ virsh qemu-monitor-command vm '{"execute":"object-add", > "arguments":{"qom-type":"secret", "id": > "libvirt-2-storage-secret0", "data":"abc123"}}' 5. block-add the raw-drived blockdev format node $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments":{"node-name":"libvirt-1-format", "driver":"raw", > "file":"libvirt-1-storage"}}' 6. block-add the luks-drived blockdev to link the raw disk with the LUKS header by specifying the field "header" $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments":{"node-name":"libvirt-2-format", "driver":"luks", > "file":"libvirt-1-format", "header":"libvirt-2-storage", > "key-secret":"libvirt-2-format-secret0"}}' 7. hot-plug the virtio-blk device finally $ virsh qemu-monitor-command vm '{"execute":"device_add", > "arguments": {"num-queues":"1", "driver":"virtio-blk-pci", > "drive": "libvirt-2-format", "id":"virtio-disk2"}}' Starting a VM with a LUKS volume with detached header is somewhat similar to hot-plug in that both maintaining the same json command while the starting VM changes the "blockdev-add/device_add" parameters to "blockdev/device". Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2024-02-09crypto: Introduce SM4 symmetric cipher algorithmHyman Huang1-0/+11
Introduce the SM4 cipher algorithms (OSCCA GB/T 32907-2016). SM4 (GBT.32907-2016) is a cryptographic standard issued by the Organization of State Commercial Administration of China (OSCCA) as an authorized cryptographic algorithms for the use within China. Detect the SM4 cipher algorithms and enable the feature silently if it is available. Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-08misc/other: spelling fixesMichael Tokarev1-3/+3
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Eric Blake <eblake@redhat.com>
2023-07-25crypto: Always initialize splitkeylenAkihiko Odaki1-2/+2
When _FORTIFY_SOURCE=2, glibc version is 2.35, and GCC version is 12.1.0, the compiler complains as follows: In file included from /usr/include/string.h:535, from /home/alarm/q/var/qemu/include/qemu/osdep.h:99, from ../crypto/block-luks.c:21: In function 'memset', inlined from 'qcrypto_block_luks_store_key' at ../crypto/block-luks.c:843:9: /usr/include/bits/string_fortified.h:59:10: error: 'splitkeylen' may be used uninitialized [-Werror=maybe-uninitialized] 59 | return __builtin___memset_chk (__dest, __ch, __len, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 60 | __glibc_objsize0 (__dest)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ ../crypto/block-luks.c: In function 'qcrypto_block_luks_store_key': ../crypto/block-luks.c:699:12: note: 'splitkeylen' was declared here 699 | size_t splitkeylen; | ^~~~~~~~~~~ It seems the compiler cannot see that splitkeylen will not be used when splitkey is NULL. Suppress the warning by initializing splitkeylen even when splitkey stays NULL. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2023-01-19coroutine: Clean up superfluous inclusion of qemu/coroutine.hMarkus Armbruster1-1/+0
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20221221131435.3851212-2-armbru@redhat.com>
2022-12-14qapi crypto: Elide redundant has_FOO in generated CMarkus Armbruster1-8/+8
The has_FOO for pointer-valued FOO are redundant, except for arrays. They are also a nuisance to work with. Recent commit "qapi: Start to elide redundant has_FOO in generated C" provided the means to elide them step by step. This is the step for qapi/crypto.json. Said commit explains the transformation in more detail. The invariant violations mentioned there do not occur here. Cc: Daniel P. Berrangé" <berrange@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221104160712.3005652-13-armbru@redhat.com>
2022-10-27crypto: quote algorithm names in error messagesDaniel P. Berrangé1-3/+3
If given a malformed LUKS header, it is possible that the algorithm names end up being an empty string. This leads to confusing error messages unless quoting is used to highlight where the empty string is subsituted in the error message. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-10-27crypto: split off helpers for converting LUKS header endianessDaniel P. Berrangé1-32/+47
The unit test suite is shortly going to want to convert header endianness separately from the main I/O functions. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-10-27crypto: split LUKS header definitions off into fileDaniel P. Berrangé1-93/+1
This will allow unit testing code to use the structs. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-10-27crypto: check that LUKS PBKDF2 iterations count is non-zeroDaniel P. Berrangé1-0/+11
Both the master key and key slot passphrases are run through the PBKDF2 algorithm. The iterations count is expected to be generally very large (many 10's or 100's of 1000s). It is hard to define a low level cutoff, but we can certainly say that iterations count should be non-zero. A zero count likely indicates an initialization mistake so reject it. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-10-27crypto: strengthen the check for key slots overlapping with LUKS headerDaniel P. Berrangé1-1/+1
The LUKS header data on disk is a fixed size, however, there's expected to be a gap between the end of the header and the first key slot to get alignment with the 2nd sector on 4k drives. This wasn't originally part of the LUKS spec, but was always part of the reference implementation, so it is worth validating this. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-10-27crypto: validate that LUKS payload doesn't overlap with headerDaniel P. Berrangé1-0/+7
We already validate that LUKS keyslots don't overlap with the header, or with each other. This closes the remaining hole in validation of LUKS file regions. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-10-27crypto: enforce that key material doesn't overlap with LUKS headerDaniel P. Berrangé1-0/+8
We already check that key material doesn't overlap between key slots, and that it doesn't overlap with the payload. We didn't check for overlap with the LUKS header. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-10-27crypto: enforce that LUKS stripes is always a fixed valueDaniel P. Berrangé1-2/+3
Although the LUKS stripes are encoded in the keyslot header and so potentially configurable, in pratice the cryptsetup impl mandates this has the fixed value 4000. To avoid incompatibility apply the same enforcement in QEMU too. This also caps the memory usage for key material when QEMU tries to open a LUKS volume. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-10-27crypto: sanity check that LUKS header strings are NUL-terminatedDaniel P. Berrangé1-0/+18
The LUKS spec requires that header strings are NUL-terminated, and our code relies on that. Protect against maliciously crafted headers by adding validation. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-07-12crypto: Make block callbacks return 0 on successAlberto Faria1-4/+4
They currently return the value of their headerlen/buflen parameter on success. Returning 0 instead makes it clear that short reads/writes are not possible. Signed-off-by: Alberto Faria <afaria@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20220609152744.3891847-5-afaria@redhat.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2021-01-28qapi: Use QAPI_LIST_APPEND in trivial casesEric Blake1-6/+3
The easiest spots to use QAPI_LIST_APPEND are where we already have an obvious pointer to the tail of a list. While at it, consistently use the variable name 'tail' for that purpose. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210113221013.390592-5-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2020-07-06qcrypto/luks: implement encryption key managementMaxim Levitsky1-4/+412
Next few patches will expose that functionality to the user. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200608094030.670121-3-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-09-26qcrypto-luks: more rigorous header checkingMaxim Levitsky1-0/+52
Check that keyslots don't overlap with the data, and check that keyslots don't overlap with each other. (this is done using naive O(n^2) nested loops, but since there are just 8 keyslots, this doesn't really matter. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: simplify the math used for keyslot locationsMaxim Levitsky1-23/+40
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: extract store key functionMaxim Levitsky1-123/+181
This function will be used later to store new keys to the luks metadata Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: extract check and parse headerMaxim Levitsky1-98/+125
This is just to make qcrypto_block_luks_open more reasonable in size. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: extract store and load headerMaxim Levitsky1-62/+93
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: purge unused error codes from open callbackMaxim Levitsky1-32/+13
These values are not used by generic crypto code anyway Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: use the parsed encryption settings in QCryptoBlockLUKSMaxim Levitsky1-90/+79
Prior to that patch, the parsed encryption settings were already stored into the QCryptoBlockLUKS but not used anywhere but in qcrypto_block_luks_get_info Using them simplifies the code Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: pass keyslot index rather that pointer to the keyslotMaxim Levitsky1-3/+3
Another minor refactoring Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: simplify masterkey and masterkey lengthMaxim Levitsky1-23/+21
Let the caller allocate masterkey Always use master key len from the header Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: don't overwrite cipher_mode in headerMaxim Levitsky1-3/+6
This way we can store the header we loaded, which will be used in key management code Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: rename some fields in QCryptoBlockLUKSHeaderMaxim Levitsky1-44/+47
* key_bytes -> master_key_len * payload_offset = payload_offset_sector (to emphasise that this isn't byte offset) * key_offset -> key_offset_sector - same as above for luks slots Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-22crypto: use auto cleanup for many stack variablesDaniel P. Berrangé1-52/+22
Simplify cleanup paths by using glib's auto cleanup macros for stack variables, allowing several goto jumps / labels to be eliminated. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-19crypto: Fix LGPL information in the file headersThomas Huth1-1/+1
It's either "GNU *Library* General Public License version 2" or "GNU Lesser General Public License version *2.1*", but there was no "version 2.0" of the "Lesser" license. So assume that version 2.1 is meant here. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-21crypto/block: remove redundant struct packing to fix build with gcc 9Greg Kurz1-2/+2
Build fails with gcc 9: crypto/block-luks.c:689:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 689 | be32_to_cpus(&luks->header.payload_offset); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ crypto/block-luks.c:690:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 690 | be32_to_cpus(&luks->header.key_bytes); | ^~~~~~~~~~~~~~~~~~~~~~~ crypto/block-luks.c:691:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 691 | be32_to_cpus(&luks->header.master_key_iterations); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... a bunch of similar errors... crypto/block-luks.c:1288:22: error: taking address of packed member of ‘struct QCryptoBlockLUKSKeySlot’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 1288 | be32_to_cpus(&luks->header.key_slots[i].stripes); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors All members of the QCryptoBlockLUKSKeySlot and QCryptoBlockLUKSHeader are naturally aligned and we already check at build time there isn't any unwanted padding. Drop the QEMU_PACKED attribute. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-12crypto: support multiple threads accessing one QCryptoBlockVladimir Sementsov-Ogievskiy1-12/+10
The two thing that should be handled are cipher and ivgen. For ivgen the solution is just mutex, as iv calculations should not be long in comparison with encryption/decryption. And for cipher let's just keep per-thread ciphers. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-12crypto/block: introduce qcrypto_block_*crypt_helper functionsVladimir Sementsov-Ogievskiy1-8/+6
Introduce QCryptoBlock-based functions and use them where possible. This is needed to implement thread-safe encrypt/decrypt operations. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-12crypto/block: rename qcrypto_block_*crypt_helperVladimir Sementsov-Ogievskiy1-22/+22
Rename qcrypto_block_*crypt_helper to qcrypto_block_cipher_*crypt_helper, as it's not about QCryptoBlock. This is needed to introduce qcrypto_block_*crypt_helper in the next commit, which will have QCryptoBlock pointer and than will be able to use additional fields of it, which in turn will be used to implement thread-safe QCryptoBlock operations. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-12crypto/block-luks: fix memory leak in qcrypto_block_luks_createVladimir Sementsov-Ogievskiy1-0/+3
Free block->cipher and block->ivgen on error path. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-06-01crypto: use local path for local headersMichael S. Tsirkin1-1/+1
When pulling in headers that are in the same directory as the C file (as opposed to one in include/), we should use its relative path, without a directory. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Daniel P. Berrangé <berrange@redhat.com>
2017-10-06block: convert qcrypto_block_encrypt|decrypt to take bytes offsetDaniel P. Berrange1-4/+8
Instead of sector offset, take the bytes offset when encrypting or decrypting data. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170927125340.12360-6-berrange@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-10-06crypto: expose encryption sector size in APIsDaniel P. Berrange1-2/+4
While current encryption schemes all have a fixed sector size of 512 bytes, this is not guaranteed to be the case in future. Expose the sector size in the APIs so the block layer can remove assumptions about fixed 512 byte sectors. Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170927125340.12360-3-berrange@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-09-04qapi: Change data type of the FOO_lookup generated for enum FOOMarc-André Lureau1-4/+4
Currently, a FOO_lookup is an array of strings terminated by a NULL sentinel. A future patch will generate enums with "holes". NULL-termination will cease to work then. To prepare for that, store the length in the FOO_lookup by wrapping it in a struct and adding a member for the length. The sentinel will be dropped next. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20170822132255.23945-13-marcandre.lureau@redhat.com> [Basically redone] Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503564371-26090-16-git-send-email-armbru@redhat.com> [Rebased]
2017-09-04qapi: Mechanically convert FOO_lookup[...] to FOO_str(...)Markus Armbruster1-6/+6
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503564371-26090-14-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
generated by cgit v1.1 at 2025-02-14 18:35:47 +0000