linux-kernel - Re: [PATCH] treewide: Remove direct uses of SHA_WORKSPACE

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+55aFz7UaD+FiWg1XDDWVmZwijX_hhHEMvVp9k6gViLNr4Kiw@mail.gmail.com>
Date:	Sun, 7 Aug 2011 14:41:14 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Joachim Eastwood <manabian@...il.com>,
	Andreas Schwab <schwab@...ux-m68k.org>,
	Nicolas Pitre <nico@...xnic.net>,
	Mandeep Singh Baines <msb@...omium.org>,
	linux-kernel@...r.kernel.org,
	Ramsay Jones <ramsay@...say1.demon.co.uk>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	"David S. Miller" <davem@...emloft.net>,
	linux-crypto@...r.kernel.org, linux@....linux.org.uk
Subject: Re: [PATCH] treewide: Remove direct uses of SHA_WORKSPACE_WORDS

On Sun, Aug 7, 2011 at 2:29 PM, Joe Perches <joe@...ches.com> wrote:
> While not connected to ARM's implementation of sha_transform,
> maybe this might make code a bit clearer.
>
> Remove need to know the size and type of SHA_WORKSPACE_WORDS.
> Introduce and use opaque struct sha_workspace instead.

The thing is, that workspace thing is likely just broken, and should be removed.

On machines with sufficient registers, we can keep the workspace in
the register set, and setting it up on stack and passing it in as a
buffer is just bad.

On x86 and arm it doesn't matter, but on ppc it likely pessimizes the
code by resulting in pointless writebacks to that stack buffer.

So the right thing to do is probably to just remove it entirely, and
just make the sha_transform() thing allocate it on the stack as
needed. The only issue then is whether you really want the stackspace
cleared afterwards. My personal guess is that it really doesn't
matter: if you leak stack space anywhere, you are seriously screwed
from a security standpoint anyway, so..

But in the meantime, I don't want to add this kind of abstraction for
something that I suspect is just fundamentally broken.

                            Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/