qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v10 07/12] virtio-crypto: set capacity of algori


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v10 07/12] virtio-crypto: set capacity of algorithms supported
Date: Fri, 25 Nov 2016 16:04:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Gonglei <address@hidden> writes:

> Expose the capacity of algorithms supported by
> virtio crypto device to the frontend driver using
> pci configuration space.
>
> Signed-off-by: Gonglei <address@hidden>
> ---
>  hw/virtio/virtio-crypto.c         | 43 
> +++++++++++++++++++++++++++++++++++++++
>  include/hw/virtio/virtio-crypto.h | 18 ++++++++++++++++
>  2 files changed, 61 insertions(+)
>
> diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
> index 109a504..4ded704 100644
> --- a/hw/virtio/virtio-crypto.c
> +++ b/hw/virtio/virtio-crypto.c
[...]
> @@ -100,7 +123,27 @@ static Property virtio_crypto_properties[] = {
>  
>  static void virtio_crypto_get_config(VirtIODevice *vdev, uint8_t *config)
>  {
> +    VirtIOCrypto *c = VIRTIO_CRYPTO(vdev);
> +    struct virtio_crypto_config crypto_cfg;
>  
> +    /*
> +     * Virtio-crypto device conforms to VIRTIO 1.0 which is always LE,
> +     * so we can use LE accessors directly.
> +     */
> +    stl_le_p(&crypto_cfg.status, c->status);
> +    stl_le_p(&crypto_cfg.max_dataqueues, c->max_queues);
> +    stl_le_p(&crypto_cfg.crypto_services, c->conf.crypto_services);
> +    stl_le_p(&crypto_cfg.cipher_algo_l, c->conf.cipher_algo_l);
> +    stl_le_p(&crypto_cfg.cipher_algo_h, c->conf.cipher_algo_h);
> +    stl_le_p(&crypto_cfg.hash_algo, c->conf.hash_algo);
> +    stl_le_p(&crypto_cfg.mac_algo_l, c->conf.mac_algo_l);
> +    stl_le_p(&crypto_cfg.mac_algo_h, c->conf.mac_algo_h);
> +    stl_le_p(&crypto_cfg.aead_algo, c->conf.aead_algo);
> +    stl_le_p(&crypto_cfg.max_cipher_key_len, c->conf.max_cipher_key_len);
> +    stl_le_p(&crypto_cfg.max_auth_key_len, c->conf.max_auth_key_len);
> +    stq_le_p(&crypto_cfg.max_size, c->conf.max_size);

Coverity points out that you leave crypto_cfg.reserve uninitialized.
Intentional?

*** CID 1365923:  Uninitialized variables  (UNINIT)
/hw/virtio/virtio-crypto.c: 851 in virtio_crypto_get_config()
845         stl_le_p(&crypto_cfg.mac_algo_h, c->conf.mac_algo_h);
846         stl_le_p(&crypto_cfg.aead_algo, c->conf.aead_algo);
847         stl_le_p(&crypto_cfg.max_cipher_key_len, 
c->conf.max_cipher_key_len);
848         stl_le_p(&crypto_cfg.max_auth_key_len, c->conf.max_auth_key_len);
849         stq_le_p(&crypto_cfg.max_size, c->conf.max_size);
850     
>>>     CID 1365923:  Uninitialized variables  (UNINIT)
>>>     Using uninitialized value "crypto_cfg". Field "crypto_cfg.reserve" is 
>>> uninitialized when calling "memcpy". [Note: The source code implementation 
>>> of the function has been overridden by a builtin model.]
851         memcpy(config, &crypto_cfg, c->config_size);
852     }
853     
854     static void virtio_crypto_class_init(ObjectClass *klass, void *data)
855     {
856         DeviceClass *dc = DEVICE_CLASS(klass);

> +
> +    memcpy(config, &crypto_cfg, c->config_size);
>  }
>  
[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]