All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: James Yonan <james@openvpn.net>
Cc: Cesar Eduardo Barros <cesarb@cesarb.eti.br>,
	linux-crypto@vger.kernel.org,
	Herbert Xu <herbert@gondor.hengli.com.au>,
	"David S. Miller" <davem@davemloft.net>,
	Florian Weimer <fw@deneb.enyo.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] crypto: more robust crypto_memneq
Date: Mon, 25 Nov 2013 17:26:57 +0100	[thread overview]
Message-ID: <52937A51.6070603@redhat.com> (raw)
In-Reply-To: <529373C7.10201@openvpn.net>

On 11/25/2013 04:59 PM, James Yonan wrote:
> 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@cesarb.eti.br>
>
> This approach using __asm__ ("" : "=r" (var) : "0" (var)) to try to prevent compiler optimizations of var is interesting.
>
> I like the fact that it's finer-grained than -Os and doesn't preclude inlining.

Agreed. This looks much better than the Makefile workaround. Do we have
a hard guarantee that in future, this will not be detected and optimized
away by the compiler?

Otherwise, works fine, e.g.:
int main(void)
{
         int foo = 5;
         __asm__ __volatile__ ("" : "=r" (foo) : "0" (foo));
         if (foo == 5)
                 return 1;
         else
                 return 0;
}

gcc -O2 -Wall foo.c, w/ asm code:
Dump of assembler code for function main:
    0x0000000000400390 <+0>:	mov    $0x5,%eax
    0x0000000000400395 <+5>:	cmp    $0x5,%eax
    0x0000000000400398 <+8>:	sete   %al
    0x000000000040039b <+11>:	movzbl %al,%eax
    0x000000000040039e <+14>:	retq

gcc -O2 -Wall foo.c, w/o asm code:
Dump of assembler code for function main:
    0x0000000000400390 <+0>:	mov    $0x1,%eax
    0x0000000000400395 <+5>:	retq

> One concern would be that __asm__ could be optimized out unless __volatile__ is present.
>
> James

  reply	other threads:[~2013-11-25 16:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-24 21:12 [PATCH] crypto: more robust crypto_memneq Cesar Eduardo Barros
2013-11-24 21:12 ` Cesar Eduardo Barros
2013-11-25 15:59 ` James Yonan
2013-11-25 15:59   ` James Yonan
2013-11-25 16:26   ` Daniel Borkmann [this message]
2013-11-25 22:00     ` Cesar Eduardo Barros
2013-11-25 21:56   ` Cesar Eduardo Barros
2013-11-25 21:56     ` Cesar Eduardo Barros

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52937A51.6070603@redhat.com \
    --to=dborkman@redhat.com \
    --cc=cesarb@cesarb.eti.br \
    --cc=davem@davemloft.net \
    --cc=fw@deneb.enyo.de \
    --cc=herbert@gondor.hengli.com.au \
    --cc=james@openvpn.net \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.