linux-kernel - Re: [PATCH RESEND] crypto: make sure *blkcipher_walk

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] [day] [month] [year] [list]

Date:	Mon, 11 Nov 2013 12:26:38 +0100
From:	Michal Nazarewicz <mina86@...a86.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	"David S. Miller" <davem@...emloft.net>,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] crypto: make sure *blkcipher_walk_init properly initialises walk

On Mon, Nov 11 2013, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> Nack.  The field flags is used as a bit-field and all bits other
> than those initialised that you see are used internally by the
> walker function and will be initialised on demand.
>
> Please do not just rely on tools such as coverity and actually
> read the code when submitting patches.

I have read the code which is why I concluded that it is safe to replace
the bit operations with a simple assignment.  Since, as you described,
all other bit fields are initialised on demand anyway, there is no harm
in setting them to zero here.  Especially since I see no advantages of
the current approach, but instead see two disadvantages: longer machine
code (load-modiy-store vs. store) and confusion of tools such as
Coverity.

But of course, if you want it as it is, I won't be bothering you.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@...gle.com>--<xmpp:mina86@...ber.org>--ooO--(_)--Ooo--

Download attachment "signature.asc" of type "application/pgp-signature" (836 bytes)