summaryrefslogtreecommitdiffstats
path: root/qapi/crypto.json
Commit message (Collapse)AuthorAgeFilesLines
* qapi: crypto-akcipher: Introduce akcipher types to qapiLei He2022-05-261-0/+64
| | | | | | | | Introduce akcipher types, also include RSA related types. Signed-off-by: Lei He <helei.sig11@bytedance.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* qapi: Stop using whitespace for alignment in commentsAndrea Bolognani2022-05-161-21/+21
| | | | | | | | | | | | | | | | Perfectly aligned things look pretty, but keeping them that way as the schema evolves requires churn, and in some cases newly-added lines are not aligned properly. Overall, trying to align things is just not worth the trouble. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Message-Id: <20220503073737.84223-8-abologna@redhat.com> Message-Id: <20220503073737.84223-9-abologna@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Two patches squashed together] Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Drop unnecessary empty lines outside of commentsAndrea Bolognani2022-05-161-12/+0Star
| | | | | | | | Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220503073737.84223-6-abologna@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Add missing separators between sectionsAndrea Bolognani2022-05-161-0/+7
| | | | | | | | | | | This only affects readability. The generated documentation doesn't change. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220503073737.84223-4-abologna@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi: Fix malformed "Since:" section tagsMarkus Armbruster2022-05-161-2/+1Star
| | | | | | | | | | "Since X.Y" is not recognized as a tagged section, and therefore not formatted as such in generated documentation. Fix by adding the required colon. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220422132807.1704411-1-armbru@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
* crypto: replace 'des-rfb' cipher with 'des'Daniel P. Berrangé2021-07-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the crypto layer exposes support for a 'des-rfb' algorithm which is just normal single-DES, with the bits in each key byte reversed. This special key munging is required by the RFB protocol password authentication mechanism. Since the crypto layer is generic shared code, it makes more sense to do the key byte munging in the VNC server code, and expose normal single-DES support. Replacing cipher 'des-rfb' by 'des' looks like an incompatible interface change, but it doesn't matter. While the QMP schema allows any QCryptoCipherAlgorithm for the 'cipher-alg' field in QCryptoBlockCreateOptionsLUKS, the code restricts what can be used at runtime. Thus the only effect is a change in error message. Original behaviour: $ qemu-img create -f luks --object secret,id=sec0,data=123 -o cipher-alg=des-rfb,key-secret=sec0 demo.luks 1G Formatting 'demo.luks', fmt=luks size=1073741824 key-secret=sec0 cipher-alg=des-rfb qemu-img: demo.luks: Algorithm 'des-rfb' not supported New behaviour: $ qemu-img create -f luks --object secret,id=sec0,data=123 -o cipher-alg=des-rfb,key-secret=sec0 demo.luks 1G Formatting 'demo.luks', fmt=luks size=1073741824 key-secret=sec0 cipher-alg=des-fish qemu-img: demo.luks: Invalid parameter 'des-rfb' Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* qapi/qom: Add ObjectOptions for tls-*, deprecate 'loaded'Kevin Wolf2021-03-191-0/+98
| | | | | | | | | | | | | | | | | | This adds a QAPI schema for the properties of the tls-* objects. The 'loaded' property doesn't seem to make sense as an external interface: It is automatically set to true in ucc->complete, and explicitly setting it to true earlier just means that additional options will be silently ignored. In other words, the 'loaded' property is useless. Mark it as deprecated in the schema from the start. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi/qom: Add ObjectOptions for secret*, deprecate 'loaded'Kevin Wolf2021-03-191-0/+61
| | | | | | | | | | | | | | | | | | This adds a QAPI schema for the properties of the secret* objects. The 'loaded' property doesn't seem to make sense as an external interface: It is automatically set to true in ucc->complete, and explicitly setting it to true earlier just means that additional options will be silently ignored. In other words, the 'loaded' property is useless. Mark it as deprecated in the schema from the start. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* qapi/: fix some comment spelling errorszhaolichang2020-09-171-2/+2
| | | | | | | | | | | I found that there are many spelling errors in the comments of qemu, so I used the spellcheck tool to check the spelling errors and finally found some spelling errors in the qapi folder. Signed-off-by: zhaolichang <zhaolichang@huawei.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200917075029.313-10-zhaolichang@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
* schemas: Add vim modelineAndrea Bolognani2020-08-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | The various schemas included in QEMU use a JSON-based format which is, however, strictly speaking not valid JSON. As a consequence, when vim tries to apply syntax highlight rules for JSON (as guessed from the file name), the result is an unreadable mess which mostly consist of red markers pointing out supposed errors in, well, pretty much everything. Using Python syntax highlighting produces much better results, and in fact these files already start with specially-formatted comments that instruct Emacs to process them as if they were Python files. This commit adds the equivalent special comments for vim. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Message-Id: <20200729185024.121766-1-abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qcrypto/luks: implement encryption key managementMaxim Levitsky2020-07-061-2/+57
| | | | | | | | | 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>
* qcrypto/core: add generic infrastructure for crypto options amendmentMaxim Levitsky2020-07-061-0/+16
| | | | | | | | | | | | This will be used first to implement luks keyslot management. block_crypto_amend_opts_init will be used to convert qemu-img cmdline to QCryptoBlockAmendOptions Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200608094030.670121-2-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
* crypto: Fix defaults in QCryptoBlockCreateOptionsLUKSAlberto Garcia2018-12-121-3/+3
| | | | | | | | The values specified in the documentation don't match the actual defaults set in qcrypto_block_luks_create(). Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* qapi: remove empty flat union branches and typesAnton Nefedov2018-06-221-12/+1Star
| | | | | | | | | | Flat unions may now have uncovered branches, so it is possible to get rid of empty types defined for that purpose only. Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1529311206-76847-3-git-send-email-anton.nefedov@virtuozzo.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* qapi-schema: Improve section headingsMarkus Armbruster2017-09-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The generated QEMU QMP reference is now structured as follows: 1.1 Introduction 1.2 Stability Considerations 1.3 Common data types 1.4 Socket data types 1.5 VM run state 1.6 Cryptography 1.7 Block devices 1.7.1 Block core (VM unrelated) 1.7.2 QAPI block definitions (vm unrelated) 1.8 Character devices 1.9 Net devices 1.10 Rocker switch device 1.11 TPM (trusted platform module) devices 1.12 Remote desktop 1.12.1 Spice 1.12.2 VNC 1.13 Input 1.14 Migration 1.15 Transactions 1.16 Tracing 1.17 QMP introspection 1.18 Miscellanea Section "1.18 Miscellanea" is still too big: it documents 134 symbols. Section "1.7.1 Block core (VM unrelated)" is also rather big: 128 symbols. All the others are of reasonable size. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-17-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* qapi: The #optional tag is redundant, dropMarkus Armbruster2017-03-161-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | We traditionally mark optional members #optional in the doc comment. Before commit 3313b61, this was entirely manual. Commit 3313b61 added some automation because its qapi2texi.py relied on #optional to determine whether a member is optional. This is no longer the case since the previous commit: the only thing qapi2texi.py still does with #optional is stripping it out. We still reject bogus qapi-schema.json and six places for qga/qapi-schema.json. Thus, you can't actually rely on #optional to see whether something is optional. Yet we still make people add it manually. That's just busy-work. Drop the code to check, fix up and strip out #optional, along with all instances of #optional. To keep it out, add code to reject it, to be dropped again once the dust settles. No change to generated documentation. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1489582656-31133-18-git-send-email-armbru@redhat.com>
* qapi: add some sections in docsMarc-André Lureau2017-01-161-1/+4
| | | | | | | | | | Add some more section titles to organize the documentation we're going to generate. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20170113144135.5150-10-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* crypto: add 3des-ede support when using libgcrypt/nettleLongpeng(Mike)2016-12-211-1/+2
| | | | | | | | | Libgcrypt and nettle support 3des-ede, so this patch add 3des-ede support when using libgcrypt or nettle. Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* qapi: fix missing symbol @prefixMarc-André Lureau2016-12-051-18/+18
| | | | | | | | Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20161117155504.21843-6-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* crypto: add CTR mode supportGonglei2016-10-191-1/+2
| | | | | | | | | | | | | | Introduce CTR mode support for the cipher APIs. CTR mode uses a counter rather than a traditional IV. The counter has additional properties, including a nonce and initial counter block. We reuse the ctx->iv as the counter for conveniences. Both libgcrypt and nettle are support CTR mode, the cipher-builtin doesn't support yet. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: increase default pbkdf2 time for luks to 2 secondsDaniel P. Berrange2016-09-191-1/+1
| | | | | | | | | | cryptsetup recently increased the default pbkdf2 time to 2 seconds to partially mitigate improvements in hardware performance wrt brute-forcing the pbkdf algorithm. This updates QEMU defaults to match. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: make PBKDF iterations configurable for LUKS formatDaniel P. Berrange2016-09-191-1/+5
| | | | | | | | | | | | | | As protection against bruteforcing passphrases, the PBKDF algorithm is tuned by counting the number of iterations needed to produce 1 second of running time. If the machine that the image will be used on is much faster than the machine where the image is created, it can be desirable to raise the number of iterations. This change adds a new 'iter-time' property that allows the user to choose the iteration wallclock time. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: add support for querying parameters for block encryptionDaniel P. Berrange2016-07-261-0/+87
| | | | | | | | | | | | | When creating new block encryption volumes, we accept a list of parameters to control the formatting process. It is useful to be able to query what those parameters were for existing block devices. Add a qcrypto_block_get_info() method which returns a QCryptoBlockInfo instance to report this data. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1469192015-16487-2-git-send-email-berrange@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
* crypto: implement sha224, sha384, sha512 and ripemd160 hashesDaniel P. Berrange2016-07-041-1/+5
| | | | | | | Wire up the nettle and gcrypt hash backends so that they can support the sha224, sha384, sha512 and ripemd160 hash algorithms. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: implement the LUKS block encryption formatDaniel P. Berrange2016-03-171-3/+46
| | | | | | | | | | | | | | | | Provide a block encryption implementation that follows the LUKS/dm-crypt specification. This supports all combinations of hash, cipher algorithm, cipher mode and iv generator that are implemented by the current crypto layer. There is support for opening existing volumes formatted by dm-crypt, and for formatting new volumes. In the latter case it will only use key slot 0. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: add block encryption frameworkDaniel P. Berrange2016-03-171-0/+68
| | | | | | | | | | | | | | | | | Add a generic framework for supporting different block encryption formats. Upon instantiating a QCryptoBlock object, it will read the encryption header and extract the encryption keys. It is then possible to call methods to encrypt/decrypt data buffers. There is also a mode whereby it will create/initialize a new encryption header on a previously unformatted volume. The initial framework comes with support for the legacy QCow AES based encryption. This enables code in the QCow driver to be consolidated later. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: wire up XTS mode for cipher APIsDaniel P. Berrange2016-03-171-1/+2
| | | | | | | | | | | Introduce 'XTS' as a permitted mode for the cipher APIs. With XTS the key provided must be twice the size of the key normally required for any given algorithm. This is because the key will be split into two pieces for use in XTS mode. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: add support for the twofish cipher algorithmDaniel P. Berrange2016-03-171-1/+5
| | | | | | | | | | | | | | | New cipher algorithms 'twofish-128', 'twofish-192' and 'twofish-256' are defined for the Twofish algorithm. The gcrypt backend does not support 'twofish-192'. The nettle and gcrypt cipher backends are updated to support the new cipher and a test vector added to the cipher test suite. The new algorithm is enabled in the LUKS block encryption driver. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: add support for the serpent cipher algorithmDaniel P. Berrange2016-03-171-1/+5
| | | | | | | | | | | | | | New cipher algorithms 'serpent-128', 'serpent-192' and 'serpent-256' are defined for the Serpent algorithm. The nettle and gcrypt cipher backends are updated to support the new cipher and a test vector added to the cipher test suite. The new algorithm is enabled in the LUKS block encryption driver. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: add support for the cast5-128 cipher algorithmDaniel P. Berrange2016-03-171-1/+4
| | | | | | | | | | | | | | | | A new cipher algorithm 'cast-5-128' is defined for the Cast-5 algorithm with 128 bit key size. Smaller key sizes are supported by Cast-5, but nothing in QEMU should use them, so only 128 bit keys are permitted. The nettle and gcrypt cipher backends are updated to support the new cipher and a test vector added to the cipher test suite. The new algorithm is enabled in the LUKS block encryption driver. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: add support for generating initialization vectorsDaniel P. Berrange2016-03-171-0/+19
| | | | | | | | | | | | | | There are a number of different algorithms that can be used to generate initialization vectors for disk encryption. This introduces a simple internal QCryptoBlockIV object to provide a consistent internal API to the different algorithms. The initially implemented algorithms are 'plain', 'plain64' and 'essiv', each matching the same named algorithm provided by the Linux kernel dm-crypt driver. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: move QCryptoCipherAlgorithm/Mode enum definitions into QAPIDaniel P. Berrange2015-12-231-0/+30
| | | | | | | | | | The QCryptoCipherAlgorithm and QCryptoCipherMode enums are defined in the crypto/cipher.h header. In the future some QAPI types will want to reference the hash enums, so move the enum definition into QAPI too. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: move QCryptoHashAlgorithm enum definition into QAPIDaniel P. Berrange2015-12-231-0/+15
| | | | | | | | | The QCryptoHashAlgorithm enum is defined in the crypto/hash.h header. In the future some QAPI types will want to reference the hash enums, so move the enum definition into QAPI too. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: add QCryptoSecret object class for password/key handlingDaniel P. Berrange2015-12-181-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* crypto: introduce new base module for TLS credentialsDaniel P. Berrange2015-09-151-0/+21
Introduce a QCryptoTLSCreds class to act as the base class for storing TLS credentials. This will be later subclassed to provide handling of anonymous and x509 credential types. The subclasses will be user creatable objects, so instances can be created & deleted via 'object-add' and 'object-del' QMP commands respectively, or via the -object command line arg. If the credentials cannot be initialized an error will be reported as a QMP reply, or on stderr respectively. The idea is to make it possible to represent and manage TLS credentials independently of the network service that is using them. This will enable multiple services to use the same set of credentials and minimize code duplication. A later patch will convert the current VNC server TLS code over to use this object. The representation of credentials will be functionally equivalent to that currently implemented in the VNC server with one exception. The new code has the ability to (optionally) load a pre-generated set of diffie-hellman parameters, if the file dh-params.pem exists, whereas the current VNC server will always generate them on startup. This is beneficial for admins who wish to avoid the (small) time sink of generating DH parameters at startup and/or avoid depleting entropy. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-12-05 04:16:25 +0100