linux-kernel - Re: [PATCH] crypto: ccree - avoid implicit enum conversion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKwvOdkUnpxJe+zXMWDHsfozi9D-TpPZgmasciRU-nkCA9xOGg@mail.gmail.com>
Date:   Thu, 11 Oct 2018 13:50:31 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Gilad Ben-Yossef <gilad@...yossef.com>
Cc:     Nathan Chancellor <natechancellor@...il.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        linux-crypto@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] crypto: ccree - avoid implicit enum conversion

On Thu, Oct 11, 2018 at 12:47 AM Gilad Ben-Yossef <gilad@...yossef.com> wrote:
>
> Hi Nick,
>
> On Thu, Oct 11, 2018 at 2:49 AM Nick Desaulniers
> <ndesaulniers@...gle.com> wrote:
> >
> > $ grep -r set_cipher_config0 -n
> >
> > shows a healthy mix of DESC_DIRECTION_ENCRYPT_ENCRYPT,
> > HASH_DIGEST_RESULT_LITTLE_ENDIAN, and DRV_CRYPTO_DIRECTION_ENCRYPT
> > (all enumeration values of different enums).
> >
> > >
> > > drivers/crypto/ccree/cc_aead.c:1643:30: warning: implicit conversion
> > > from enumeration type 'enum drv_hash_hw_mode' to different enumeration
> > > type 'enum drv_cipher_mode' [-Wenum-conversion]
> > >         set_cipher_mode(&desc[idx], DRV_HASH_HW_GHASH);
> >
> > Looks like a lot fewer call sites using DRV_HASH_HW_GHASH; same value
> > as DRV_CIPHER_OFB (different enum), but can a block cipher mode and a
> > hash be valid values for pdesc->word[4]?
> >
> > >
> > > Since this fundamentally isn't a problem because these values just
> > > represent simple integers for a shift operation, make it clear to Clang
> > > that this is okay by making the mode parameter in both functions an int.
> >
> > This also looks like the simplest fix to me, assuming the values of
> > all of these enums are valid for whatever pdesc->word[4] is.  Can the
> > maintainers explain what is CC7x-DESC what the comment makes reference
> > to?
>
> They indeed are. CC7x-DESC is a shorthand for "CryptoCell 7xx
> Descriptor" used in the hardware documents.
> These descriptors are comprised of fields with context sensitive
> meaning, hence this "overloading".
>
> Given this overloading of meaning an  "int" type is indeed a better
> suited type here.

Sounds like they're valid values then.  Thanks for the info.
Reviewed-by: Nick Desaulniers <ndesaulniers@...gle.com>

>
> Thanks,
> Gilad
> --
> Gilad Ben-Yossef
> Chief Coffee Drinker
>
> values of β will give rise to dom!



-- 
Thanks,
~Nick Desaulniers