linux-kernel - Re: Crypto Fixes for 4.12

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: <CA+55aFwU1ZvJZK8x9QQtROjOVHG_ks-H3XpU+hjuf8BTxndN3g@mail.gmail.com>
Date:   Thu, 15 Jun 2017 18:04:44 +0900
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Crypto Fixes for 4.12

On Thu, Jun 15, 2017 at 9:54 AM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> This push fixes a bug on sparc where we may dereference freed stack
> memory.

Ugh, that's a particularly ugly fix for a random gcc bug on a random
architecture that almost nobody tests.

In other words, it's nasty. It's nasty because nobody sane will ever
realize this pattern, and the code will either bit-rot or just happen
again somewhere else.

I'd have been *much* happier if this had been some nicer abstraction
that is built up around the use of SHASH_DESC_ON_STACK(), and just
have some rule that "SHASH_DESC_ON_STACK()" needs to be paired with
retrieving the final value and then a SHASH_DESC_DEALLOC() or
whatever.

Then you *could* implement SHASH_DESC_ON_STACK() as a kmalloc, and
SHASH_DESC_DEALLOC() would be a kfree - but with an alloca()-like
allocation the SHASH_DESC_DEALLOC() would be that "barrier_data()".

At that point the interface would make _sense_ at some conceptual
level, rather than being a random hack for a small collection of
random users of this thing.

There's a fair number of SHASH_DESC_ON_STACK users, are all the others
safe for some random reason that just happens to be about code
generation? Did people actually verify that?

                Linus