linux-kernel - Re: [PATCH] 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]

Message-ID: <5293C79A.1070808@cesarb.eti.br>
Date:	Mon, 25 Nov 2013 19:56:42 -0200
From:	Cesar Eduardo Barros <cesarb@...arb.eti.br>
To:	James Yonan <james@...nvpn.net>, linux-crypto@...r.kernel.org
CC:	Herbert Xu <herbert@...dor.apana.org.au>,
	"David S. Miller" <davem@...emloft.net>,
	Daniel Borkmann <dborkman@...hat.com>,
	Florian Weimer <fw@...eb.enyo.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: more robust crypto_memneq

Em 25-11-2013 13:59, James Yonan escreveu:
> On 24/11/2013 14:12, Cesar Eduardo Barros wrote:
>> Disabling compiler optimizations can be fragile, since a new
>> optimization could be added to -O0 or -Os that breaks the assumptions
>> the code is making.
>>
>> Instead of disabling compiler optimizations, use a dummy inline assembly
>> (based on RELOC_HIDE) to block the problematic kinds of optimization,
>> while still allowing other optimizations to be applied to the code.
>>
>> The dummy inline assembly is added after every OR, and has the
>> accumulator variable as its input and output. The compiler is forced to
>> assume that the dummy inline assembly could both depend on the
>> accumulator variable and change the accumulator variable, so it is
>> forced to compute the value correctly before the inline assembly, and
>> cannot assume anything about its value after the inline assembly.
>>
>> This change should be enough to make crypto_memneq work correctly (with
>> data-independent timing) even if it is inlined at its call sites. That
>> can be done later in a followup patch.
>>
>> Compile-tested on x86_64.
>>
>> Signed-off-by: Cesar Eduardo Barros <cesarb@...arb.eti.br>
>
> This approach using __asm__ ("" : "=r" (var) : "0" (var)) to try to
> prevent compiler optimizations of var is interesting.

It is not novel; I copied it from RELOC_HIDE.

> I like the fact that it's finer-grained than -Os and doesn't preclude
> inlining.
>
> One concern would be that __asm__ could be optimized out unless
> __volatile__ is present.

It cannot be optimized out, because the __asm__'s output is used. Of 
course, if the __asm__ output is never used, it could be optimized out, 
but that is the desired result in this case (it means the result of 
crypto_memneq is being ignored, so the whole function should be elided).

AFAIK, __volatile__ also has the side effect that it forces ordering 
with everything (this fact is used in the definition of the barrier() 
macro). This level of barrier is not needed for crypto_memneq; ordering 
on "neq" is more than enough.

-- 
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/