linux-kernel - Re: [PATCH v3] crypto: more robust crypto

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]

Date:	Tue, 26 Nov 2013 19:44:32 -0200
From:	Cesar Eduardo Barros <cesarb@...arb.eti.br>
To:	Daniel Borkmann <dborkman@...hat.com>
CC:	linux-crypto@...r.kernel.org,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	"David S. Miller" <davem@...emloft.net>,
	James Yonan <james@...nvpn.net>,
	Florian Weimer <fw@...eb.enyo.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] crypto: more robust crypto_memneq

Em 26-11-2013 17:27, Daniel Borkmann escreveu:
> On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote:
>> Compile-tested on x86_64.
>
> Actually with yet another version, I hoped that the "compile-tested"-only
> statement would eventually disappear, ohh well. ;)

I did compile test each version ;-) including verifying (with "make 
crypto/memneq.i") that the macro was really generating the expected 
inline assembly (with these #ifdef chains, one has to be careful with 
typos).

(Actually, I compile tested with "make crypto/memneq.o crypto/memneq.s 
crypto/memneq.i". I took a peek at the assembly to see if it made sense.)

> Resolving the OPTIMIZER_HIDE_VAR() macro for others than GCC jnto a
> barrier() seems a bit suboptimal, but assuming 99% of people will use
> GCC anyway, then for the minority of the remaining, they will worst case
> have a clever compiler and eventually mimic memcmp() in some situations,
> or have a not-so-clever compiler and execute the full code as is.

I do not think any compiler other than gcc and icc can compile 
unmodified upstream kernel code. LLVM's clang would be the one which 
comes closest, but it has gcc-compatible inline assembly, as does icc AFAIK.

The #define to barrier() within compiler-intel.h is for some compiler 
called ECC (not icc). From what I could find about it on a quick search, 
it appears to be some kind of Itanium compiler.

That part of the header was added back in 2003, and I do not believe it 
is still relevant. A comment within that #ifdef block says "Intel ECC 
compiler doesn't support gcc specific asm stmts", but there are many 
uses of unprotected inline assembly all over the kernel (including on 
the ia64 headers), so if that comment is true, the kernel will not 
compile with that compiler. It is probably a piece of leftover dead 
code. I only added to it because I am following RELOC_HIDE's example, 
and RELOC_HIDE is there.

> Anyway, I think still better than the rather ugly Makefile workaround
> imho, so I'm generally fine with this.

-- 
Cesar Eduardo Barros
cesarb@...arb.eti.br
--
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/