riscv/qemu - qemu - Gitea: Git with a cup of tea

Commit Graph

Author	SHA1	Message	Date
Markus Armbruster	f5cf31c575	qapi-schema: Improve section headings 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>	9 years ago
Markus Armbruster	1d8bda128d	qapi: The #optional tag is redundant, drop 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>	9 years ago
Marc-André Lureau	d3a48372a4	qapi: add some sections in docs 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>	9 years ago
Longpeng(Mike)	ffb7bf452a	crypto: add 3des-ede support when using libgcrypt/nettle 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>	10 years ago
Marc-André Lureau	c5927e7abf	qapi: fix missing symbol @prefix 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>	10 years ago
Gonglei	3c28292f39	crypto: add CTR mode support 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>	10 years ago
Daniel P. Berrange	2ab66cd577	crypto: increase default pbkdf2 time for luks to 2 seconds 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>	10 years ago
Daniel P. Berrange	3bd18890ca	crypto: make PBKDF iterations configurable for LUKS format 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>	10 years ago
Daniel P. Berrange	40c8502822	crypto: add support for querying parameters for block encryption 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>	10 years ago
Daniel P. Berrange	9164b89762	crypto: implement sha224, sha384, sha512 and ripemd160 hashes 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>	10 years ago
Daniel P. Berrange	3e308f20ed	crypto: implement the LUKS block encryption format 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>	11 years ago
Daniel P. Berrange	7d9690148a	crypto: add block encryption framework 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>	11 years ago
Daniel P. Berrange	eaec903c5b	crypto: wire up XTS mode for cipher APIs 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>	10 years ago
Daniel P. Berrange	50f6753e27	crypto: add support for the twofish cipher algorithm 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>	10 years ago
Daniel P. Berrange	94318522ed	crypto: add support for the serpent cipher algorithm 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>	10 years ago
Daniel P. Berrange	084a85eedd	crypto: add support for the cast5-128 cipher algorithm 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>	10 years ago
Daniel P. Berrange	cb730894ae	crypto: add support for generating initialization vectors 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>	11 years ago
Daniel P. Berrange	d8c02bcc94	crypto: move QCryptoCipherAlgorithm/Mode enum definitions into QAPI 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>	11 years ago
Daniel P. Berrange	d84b79d358	crypto: move QCryptoHashAlgorithm enum definition into QAPI 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>	11 years ago
Daniel P. Berrange	ac1d887849	crypto: add QCryptoSecret object class for password/key handling 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>	11 years ago
Daniel P. Berrange	a090187de1	crypto: introduce new base module for TLS credentials 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>	11 years ago

21 Commits (71dc578e116599ea73c8a2a4e693134702ec0e83)