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

[Gonglei (Arei)]

> From: Markus Armbruster [mailto:address@hidden
> Subject: Re: [Qemu-devel] [PATCH v10 07/12] virtio-crypto: set capacity of
> algorithms supported
> 
> 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?
> 
Nope. crypto_cfg.reserve is an unused field, so I didn't notice it.

Let me fix it, thanks.

Regards,
-Gonglei

> *** 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);
> >  }
> >
> [...]