kernel RNG and its secrets

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect memory cleansing against things like dead store optimization:

    void memzero_explicit(void *s, size_t count)
    {
            memset(s, 0, count);
            OPTIMIZER_HIDE_VAR(s);
    }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq against timing analysis, is defined when using gcc as:

    #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0" (var))

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

    __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

    and

    __asm__ __volatile__("": : :"memory")

The first is OPTIMIZER_HIDE_VAR plus a volatile qualifier and the second is barrier() [as defined when using gcc].

I propose memzero_explicit use barrier().

lib/string.c +1 -1

@@ -616,7 +616,7 @@ EXPORT_SYMBOL(memset);
  void memzero_explicit(void *s, size_t count)
  {
         memset(s, 0, count);
-       OPTIMIZER_HIDE_VAR(s);
+       barrier();
  }
  EXPORT_SYMBOL(memzero_explicit);
 

For any attribution deemed necessary, please use "mancha security". Please CC me on replies.

--mancha

PS CC'ing Herbert Xu in case this impacts crypto_memneq.

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect memory cleansing against things like dead store optimization:

   void memzero_explicit(void *s, size_t count)
   {
           memset(s, 0, count);
           OPTIMIZER_HIDE_VAR(s);
   }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq against timing analysis, is defined when using gcc as:

   #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0" (var))

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

   __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

Quoted 14 lines · mancha

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect memory cleansing against things like dead store optimization:

    void memzero_explicit(void *s, size_t count)
    {
            memset(s, 0, count);
            OPTIMIZER_HIDE_VAR(s);
    }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq against timing analysis, is defined when using gcc as:

Quoted 8 lines

    #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0" (var))

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

    __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is allowed to check if it is needed and may remove the asm statement. Another option would be to just use var as an input variable - asm blocks without output variables are always considered being volatile by gcc.

Can you send a patch?

I don't think it is security critical, as Daniel pointed out, the call will happen because the function is an external call to the crypto functions, thus the compiler has to flush memory on return.

Quoted 34 lines · mancha

Quoted 17 lines

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect

memory cleansing against things like dead store optimization:

    void memzero_explicit(void *s, size_t count)
    {
    
            memset(s, 0, count);
            OPTIMIZER_HIDE_VAR(s);
    
    }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq>>
against timing analysis, is defined when using gcc as:

Quoted 8 lines

    #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0"
    (var))

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

    __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is allowed to check if it is needed and may remove the asm statement. Another option would be to just use var as an input variable - asm blocks without output variables are always considered being volatile by gcc.

Quoted 6 lines

Can you send a patch?

I don't think it is security critical, as Daniel pointed out, the call
will happen because the function is an external call to the crypto functions, thus the compiler has to flush memory on return.

Just had a look.

$ gdb vmlinux
(gdb) disassemble memzero_explicit
Dump of assembler code for function memzero_explicit:
   0xffffffff813a18b0 <+0>:	push   %rbp
   0xffffffff813a18b1 <+1>:	mov    %rsi,%rdx
   0xffffffff813a18b4 <+4>:	xor    %esi,%esi
   0xffffffff813a18b6 <+6>:	mov    %rsp,%rbp
   0xffffffff813a18b9 <+9>:	callq  0xffffffff813a7120 <memset>
   0xffffffff813a18be <+14>:	pop    %rbp
   0xffffffff813a18bf <+15>:	retq
End of assembler dump.

(gdb) disassemble extract_entropy
[...]
0xffffffff814a5000 <+304>: sub %r15,%rbx
0xffffffff814a5003 <+307>: jne 0xffffffff814a4f80
<extract_entropy+176> 0xffffffff814a5009 <+313>: mov %r12,%rdi
0xffffffff814a500c <+316>: mov $0xa,%esi
0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0
<memzero_explicit> 0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax
[...]

I would be fine with __volatile__.

Thanks a lot mancha, could you send a patch?

Best,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:

Quoted 66 lines · Hannes Frederic Sowa

Quoted 34 lines · mancha

Quoted 17 lines

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect

memory cleansing against things like dead store optimization:

    void memzero_explicit(void *s, size_t count)
    {
    
            memset(s, 0, count);
            OPTIMIZER_HIDE_VAR(s);
    
    }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq>>
against timing analysis, is defined when using gcc as:

Quoted 8 lines

    #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0"
    (var))

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

    __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is allowed to check if it is needed and may remove the asm statement. Another option would be to just use var as an input variable - asm blocks without output variables are always considered being volatile by gcc.

Quoted 6 lines

Can you send a patch?

I don't think it is security critical, as Daniel pointed out, the call
will happen because the function is an external call to the crypto functions, thus the compiler has to flush memory on return.

Just had a look.

$ gdb vmlinux
(gdb) disassemble memzero_explicit
Dump of assembler code for function memzero_explicit:
   0xffffffff813a18b0 <+0>:	push   %rbp
   0xffffffff813a18b1 <+1>:	mov    %rsi,%rdx
   0xffffffff813a18b4 <+4>:	xor    %esi,%esi
   0xffffffff813a18b6 <+6>:	mov    %rsp,%rbp
   0xffffffff813a18b9 <+9>:	callq  0xffffffff813a7120 <memset>
   0xffffffff813a18be <+14>:	pop    %rbp
   0xffffffff813a18bf <+15>:	retq
End of assembler dump.

(gdb) disassemble extract_entropy
[...]
0xffffffff814a5000 <+304>: sub %r15,%rbx
0xffffffff814a5003 <+307>: jne 0xffffffff814a4f80
<extract_entropy+176> 0xffffffff814a5009 <+313>: mov %r12,%rdi
0xffffffff814a500c <+316>: mov $0xa,%esi
0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0
<memzero_explicit> 0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax
[...]

Quoted 1 line

I would be fine with __volatile__.

Are we sure that simply adding a __volatile__ works in any case? I just did a test with a simple user space app:

static inline void memset_secure(void *s, int c, size_t n)

{
        memset(s, c, n);
        //__asm__ __volatile__("": : :"memory");
        __asm__ __volatile__("" : "=r" (s) : "0" (s));
}

Quoted 52 lines

Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:

Quoted 51 lines · Hannes Frederic Sowa

Quoted 38 lines · mancha

Quoted 22 lines

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect

memory cleansing against things like dead store optimization:

    void memzero_explicit(void *s, size_t count)
    {
    
            memset(s, 0, count);
            OPTIMIZER_HIDE_VAR(s);
    
    }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq>>

against timing analysis, is defined when using gcc as:

    #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) :
    "0"
    (var))

Quoted 6 lines

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc
from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

    __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is allowed to check if it is needed and may remove the asm statement. Another option would be to just use var as an input variable - asm blocks without output variables are always considered being volatile
by gcc.

Quoted 6 lines

Can you send a patch?

I don't think it is security critical, as Daniel pointed out, the call
will happen because the function is an external call to the crypto functions, thus the compiler has to flush memory on return.

Just had a look.

$ gdb vmlinux
(gdb) disassemble memzero_explicit

Quoted 6 lines

Quoted 6 lines

Dump of assembler code for function memzero_explicit:

   0xffffffff813a18b0 <+0>:	push   %rbp
   0xffffffff813a18b1 <+1>:	mov    %rsi,%rdx
   0xffffffff813a18b4 <+4>:	xor    %esi,%esi
   0xffffffff813a18b6 <+6>:	mov    %rsp,%rbp
   0xffffffff813a18b9 <+9>:	callq  0xffffffff813a7120 

Quoted 25 lines

Quoted 13 lines

   0xffffffff813a18be <+14>:	pop    %rbp
   0xffffffff813a18bf <+15>:	retq

End of assembler dump.

(gdb) disassemble extract_entropy
[...]

   0xffffffff814a5000 <+304>:	sub    %r15,%rbx
   0xffffffff814a5003 <+307>:	jne    0xffffffff814a4f80

<extract_entropy+176> 0xffffffff814a5009 <+313>: mov %r12,%rdi

Quoted 8 lines

   0xffffffff814a500c <+316>:	mov    $0xa,%esi
   0xffffffff814a5011 <+321>:	callq  0xffffffff813a18b0

<memzero_explicit> 0xffffffff814a5016 <+326>: mov
-0x48(%rbp),%rax
[...]

I would be fine with __volatile__.

Are we sure that simply adding a __volatile__ works in any case? I just did a test with a simple user space app:

Quoted 8 lines

static inline void memset_secure(void *s, int c, size_t n) {

        memset(s, c, n);
        //__asm__ __volatile__("": : :"memory");
        __asm__ __volatile__("" : "=r" (s) : "0" (s));

}

Good point, thanks!

Of course an input or output of s does not force the memory pointed to by s being flushed.

My proposal would be to add a

#define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" : : "m"( ({ struct { u8 b[len]; } *p = (void *)ptr ; *p; }) )

and use this in the code function.

This is documented in gcc manual 6.43.2.5.

Bye,
Hannes

Am Mittwoch, 18. März 2015, 13:02:12 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 53 lines · Stephan Mueller

Quoted 52 lines

Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:

Quoted 51 lines · Hannes Frederic Sowa

Quoted 38 lines · mancha

Quoted 22 lines

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect

memory cleansing against things like dead store optimization:

    void memzero_explicit(void *s, size_t count)
    {
    
            memset(s, 0, count);
            OPTIMIZER_HIDE_VAR(s);
    
    }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq>>

against timing analysis, is defined when using gcc as:

    #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) :
    "0"
    (var))

Quoted 6 lines

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc
from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

    __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is allowed to check if it is needed and may remove the asm statement. Another option would be to just use var as an input variable - asm blocks without output variables are always considered being volatile
by gcc.

Quoted 6 lines

Can you send a patch?

I don't think it is security critical, as Daniel pointed out, the call
will happen because the function is an external call to the crypto functions, thus the compiler has to flush memory on return.

Just had a look.

$ gdb vmlinux
(gdb) disassemble memzero_explicit

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Dump of assembler code for function memzero_explicit:

   0xffffffff813a18b0 <+0>:	push   %rbp
   0xffffffff813a18b1 <+1>:	mov    %rsi,%rdx
   0xffffffff813a18b4 <+4>:	xor    %esi,%esi
   0xffffffff813a18b6 <+6>:	mov    %rsp,%rbp
   0xffffffff813a18b9 <+9>:	callq  0xffffffff813a7120 

<memset>

Quoted 40 lines

Quoted 25 lines

Quoted 13 lines

   0xffffffff813a18be <+14>:	pop    %rbp
   0xffffffff813a18bf <+15>:	retq

End of assembler dump.

(gdb) disassemble extract_entropy
[...]

   0xffffffff814a5000 <+304>:	sub    %r15,%rbx
   0xffffffff814a5003 <+307>:	jne    0xffffffff814a4f80

<extract_entropy+176> 0xffffffff814a5009 <+313>: mov %r12,%rdi

Quoted 8 lines

   0xffffffff814a500c <+316>:	mov    $0xa,%esi
   0xffffffff814a5011 <+321>:	callq  0xffffffff813a18b0

<memzero_explicit> 0xffffffff814a5016 <+326>: mov
-0x48(%rbp),%rax
[...]

I would be fine with __volatile__.

Are we sure that simply adding a __volatile__ works in any case? I just did a test with a simple user space app:

Quoted 8 lines

static inline void memset_secure(void *s, int c, size_t n) {

        memset(s, c, n);
        //__asm__ __volatile__("": : :"memory");
        __asm__ __volatile__("" : "=r" (s) : "0" (s));

}

Good point, thanks!

Of course an input or output of s does not force the memory pointed to by s being flushed.

Quoted 8 lines

My proposal would be to add a

#define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" : : "m"( ({ struct { u8 b[len]; } *p = (void *)ptr ; *p; }) )

and use this in the code function.

This is documented in gcc manual 6.43.2.5.

That one adds the zeroization instructuctions. But now there are much more than with the barrier.

  400469:       48 c7 04 24 00 00 00    movq   $0x0,(%rsp)
  400470:       00 
  400471:       48 c7 44 24 08 00 00    movq   $0x0,0x8(%rsp)
  400478:       00 00 
  40047a:       c7 44 24 10 00 00 00    movl   $0x0,0x10(%rsp)
  400481:       00 
  400482:       48 c7 44 24 20 00 00    movq   $0x0,0x20(%rsp)
  400489:       00 00 
  40048b:       48 c7 44 24 28 00 00    movq   $0x0,0x28(%rsp)
  400492:       00 00 
  400494:       c7 44 24 30 00 00 00    movl   $0x0,0x30(%rsp)
  40049b:       00

Any ideas?

Quoted 138 lines

Am Mittwoch, 18. März 2015, 13:02:12 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 58 lines · Stephan Mueller

Quoted 57 lines

Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:

Quoted 56 lines · Hannes Frederic Sowa

Quoted 41 lines · mancha

Quoted 22 lines

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect

memory cleansing against things like dead store optimization:

    void memzero_explicit(void *s, size_t count)
    {
    
            memset(s, 0, count);
            OPTIMIZER_HIDE_VAR(s);
    
    }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq>>

against timing analysis, is defined when using gcc as:

    #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) :
    "0"
    (var))

Quoted 6 lines

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc
from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

    __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is
allowed to check if it is needed and may remove the asm statement.
Another option would be to just use var as an input variable - asm
blocks without output variables are always considered being volatile
by gcc.

Quoted 8 lines

Can you send a patch?

I don't think it is security critical, as Daniel pointed out, the
call
will happen because the function is an external call to the crypto
functions, thus the compiler has to flush memory on return.

Just had a look.

$ gdb vmlinux
(gdb) disassemble memzero_explicit

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Dump of assembler code for function memzero_explicit:

   0xffffffff813a18b0 <+0>:	push   %rbp
   0xffffffff813a18b1 <+1>:	mov    %rsi,%rdx
   0xffffffff813a18b4 <+4>:	xor    %esi,%esi
   0xffffffff813a18b6 <+6>:	mov    %rsp,%rbp
   0xffffffff813a18b9 <+9>:	callq  0xffffffff813a7120

<memset>

Quoted 43 lines

Quoted 25 lines

Quoted 13 lines

   0xffffffff813a18be <+14>:	pop    %rbp
   0xffffffff813a18bf <+15>:	retq

End of assembler dump.

(gdb) disassemble extract_entropy
[...]

   0xffffffff814a5000 <+304>:	sub    %r15,%rbx
   0xffffffff814a5003 <+307>:	jne    0xffffffff814a4f80

<extract_entropy+176> 0xffffffff814a5009 <+313>: mov %r12,%rdi

Quoted 8 lines

   0xffffffff814a500c <+316>:	mov    $0xa,%esi
   0xffffffff814a5011 <+321>:	callq  0xffffffff813a18b0

<memzero_explicit> 0xffffffff814a5016 <+326>: mov
-0x48(%rbp),%rax
[...]

I would be fine with __volatile__.

Are we sure that simply adding a __volatile__ works in any case? I just did a test with a simple user space app:

Quoted 8 lines

static inline void memset_secure(void *s, int c, size_t n) {

        memset(s, c, n);
        //__asm__ __volatile__("": : :"memory");
        __asm__ __volatile__("" : "=r" (s) : "0" (s));

}

Good point, thanks!

Of course an input or output of s does not force the memory pointed to
by s being flushed.

My proposal would be to add a

Quoted 7 lines

#define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" : :
"m"(
({ struct { u8 b[len]; } *p = (void *)ptr ; *p; }) )

and use this in the code function.

This is documented in gcc manual 6.43.2.5.

That one adds the zeroization instructuctions. But now there are much more than with the barrier.

  400469:       48 c7 04 24 00 00 00    movq   $0x0,(%rsp)
  400470:       00
  400471:       48 c7 44 24 08 00 00    movq   $0x0,0x8(%rsp)
  400478:       00 00
  40047a:       c7 44 24 10 00 00 00    movl   $0x0,0x10(%rsp)
  400481:       00
  400482:       48 c7 44 24 20 00 00    movq   $0x0,0x20(%rsp)
  400489:       00 00
  40048b:       48 c7 44 24 28 00 00    movq   $0x0,0x28(%rsp)
  400492:       00 00
  400494:       c7 44 24 30 00 00 00    movl   $0x0,0x30(%rsp)
  40049b:       00

Quoted 1 line

Any ideas?

Hmm, correct definition of u8?

Which version of gcc do you use? I can't see any difference if I compile your example at -O2.

Bye,
Hannes

Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 141 lines · Stephan Mueller

Quoted 139 lines

Am Mittwoch, 18. März 2015, 13:02:12 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 58 lines · Stephan Mueller

Quoted 57 lines

Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:

Quoted 56 lines · Hannes Frederic Sowa

Quoted 41 lines · mancha

Quoted 22 lines

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect

memory cleansing against things like dead store optimization:

     void memzero_explicit(void *s, size_t count)
     {

             memset(s, 0, count);
             OPTIMIZER_HIDE_VAR(s);

     }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq>>

against timing analysis, is defined when using gcc as:

     #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) :
     "0"
     (var))

Quoted 6 lines

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc
from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

     __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is
allowed to check if it is needed and may remove the asm statement.
Another option would be to just use var as an input variable - asm
blocks without output variables are always considered being volatile
by gcc.

Quoted 8 lines

Can you send a patch?

I don't think it is security critical, as Daniel pointed out, the
call
will happen because the function is an external call to the crypto
functions, thus the compiler has to flush memory on return.

Just had a look.

$ gdb vmlinux
(gdb) disassemble memzero_explicit

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Dump of assembler code for function memzero_explicit:

    0xffffffff813a18b0 <+0>:	push   %rbp
    0xffffffff813a18b1 <+1>:	mov    %rsi,%rdx
    0xffffffff813a18b4 <+4>:	xor    %esi,%esi
    0xffffffff813a18b6 <+6>:	mov    %rsp,%rbp
    0xffffffff813a18b9 <+9>:	callq  0xffffffff813a7120

<memset>

Quoted 43 lines

Quoted 25 lines

Quoted 13 lines

    0xffffffff813a18be <+14>:	pop    %rbp
    0xffffffff813a18bf <+15>:	retq

End of assembler dump.

(gdb) disassemble extract_entropy
[...]

    0xffffffff814a5000 <+304>:	sub    %r15,%rbx
    0xffffffff814a5003 <+307>:	jne    0xffffffff814a4f80

<extract_entropy+176> 0xffffffff814a5009 <+313>: mov %r12,%rdi

Quoted 8 lines

    0xffffffff814a500c <+316>:	mov    $0xa,%esi
    0xffffffff814a5011 <+321>:	callq  0xffffffff813a18b0

<memzero_explicit> 0xffffffff814a5016 <+326>: mov
-0x48(%rbp),%rax
[...]

I would be fine with __volatile__.

Are we sure that simply adding a __volatile__ works in any case? I just did a test with a simple user space app:

Quoted 8 lines

static inline void memset_secure(void *s, int c, size_t n) {

         memset(s, c, n);
         //__asm__ __volatile__("": : :"memory");
         __asm__ __volatile__("" : "=r" (s) : "0" (s));

}

Good point, thanks!

Of course an input or output of s does not force the memory pointed to
by s being flushed.

My proposal would be to add a

Quoted 7 lines

#define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" : :
"m"(
({ struct { u8 b[len]; } *p = (void *)ptr ; *p; }) )

and use this in the code function.

This is documented in gcc manual 6.43.2.5.

That one adds the zeroization instructuctions. But now there are much more than with the barrier.

   400469:       48 c7 04 24 00 00 00    movq   $0x0,(%rsp)
   400470:       00
   400471:       48 c7 44 24 08 00 00    movq   $0x0,0x8(%rsp)
   400478:       00 00
   40047a:       c7 44 24 10 00 00 00    movl   $0x0,0x10(%rsp)
   400481:       00
   400482:       48 c7 44 24 20 00 00    movq   $0x0,0x20(%rsp)
   400489:       00 00
   40048b:       48 c7 44 24 28 00 00    movq   $0x0,0x28(%rsp)
   400492:       00 00
   400494:       c7 44 24 30 00 00 00    movl   $0x0,0x30(%rsp)
   40049b:       00

Any ideas?

Quoted 1 line

Hmm, correct definition of u8?

I use unsigned char

Quoted 3 lines

Which version of gcc do you use? I can't see any difference if I compile your example at -O2.

gcc-Version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)

Quoted 29 lines · Stephan Mueller

Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:

Quoted 28 lines

Quoted 27 lines

Quoted 9 lines

My proposal would be to add a

#define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" : :
"m"(
({ struct { u8 b[len]; } *p = (void *)ptr ; *p; }) )

and use this in the code function.

This is documented in gcc manual 6.43.2.5.

That one adds the zeroization instructuctions. But now there are much more than with the barrier.

   400469:       48 c7 04 24 00 00 00    movq   $0x0,(%rsp)
   400470:       00
   400471:       48 c7 44 24 08 00 00    movq   $0x0,0x8(%rsp)
   400478:       00 00
   40047a:       c7 44 24 10 00 00 00    movl   $0x0,0x10(%rsp)
   400481:       00
   400482:       48 c7 44 24 20 00 00    movq   $0x0,0x20(%rsp)
   400489:       00 00
   40048b:       48 c7 44 24 28 00 00    movq   $0x0,0x28(%rsp)
   400492:       00 00
   400494:       c7 44 24 30 00 00 00    movl   $0x0,0x30(%rsp)
   40049b:       00

Any ideas?

Quoted 8 lines

Quoted 1 line

Hmm, correct definition of u8?

I use unsigned char

Quoted 3 lines

Which version of gcc do you use? I can't see any difference if I compile your example at -O2.

gcc-Version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)

I can see the same with the gcc version I previously posted. So it clears the 20 bytes from your example (movq, movq, movl) at two locations, presumably buf[] and b[].

Quoted 32 lines · Stephan Mueller

Quoted 31 lines

Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:

Quoted 30 lines

Quoted 29 lines

Quoted 10 lines

My proposal would be to add a

#define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" :
:
"m"(
({ struct { u8 b[len]; } *p = (void *)ptr ; *p; }) )

and use this in the code function.

This is documented in gcc manual 6.43.2.5.

That one adds the zeroization instructuctions. But now there are much
more than with the barrier.

   400469:       48 c7 04 24 00 00 00    movq   $0x0,(%rsp)
   400470:       00
   400471:       48 c7 44 24 08 00 00    movq   $0x0,0x8(%rsp)
   400478:       00 00
   40047a:       c7 44 24 10 00 00 00    movl   $0x0,0x10(%rsp)
   400481:       00
   400482:       48 c7 44 24 20 00 00    movq   $0x0,0x20(%rsp)
   400489:       00 00
   40048b:       48 c7 44 24 28 00 00    movq   $0x0,0x28(%rsp)
   400492:       00 00
   400494:       c7 44 24 30 00 00 00    movl   $0x0,0x30(%rsp)
   40049b:       00

Any ideas?

Quoted 8 lines

Quoted 8 lines

Quoted 1 line

Hmm, correct definition of u8?

I use unsigned char

Quoted 2 lines

Which version of gcc do you use? I can't see any difference if I compile your example at -O2.

gcc-Version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)

Well, was an error on my side, I see the same behavior.

Quoted 3 lines

I can see the same with the gcc version I previously posted. So it clears the 20 bytes from your example (movq, movq, movl) at two locations, presumably buf[] and b[].

Yes, it looks like that. The reservation on the stack changes, too.

Seems like just using barrier() is the best and easiest option.

Thanks,
Hannes

Am Mittwoch, 18. März 2015, 16:09:34 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 44 lines · Daniel Borkmann

Quoted 32 lines · Stephan Mueller

Quoted 31 lines

Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa:

Quoted 30 lines

Quoted 29 lines

Quoted 10 lines

My proposal would be to add a

#define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" :
:
"m"(
({ struct { u8 b[len]; } *p = (void *)ptr ; *p; }) )

and use this in the code function.

This is documented in gcc manual 6.43.2.5.

That one adds the zeroization instructuctions. But now there are much
more than with the barrier.

   400469:       48 c7 04 24 00 00 00    movq   $0x0,(%rsp)
   400470:       00
   400471:       48 c7 44 24 08 00 00    movq   $0x0,0x8(%rsp)
   400478:       00 00
   40047a:       c7 44 24 10 00 00 00    movl   $0x0,0x10(%rsp)
   400481:       00
   400482:       48 c7 44 24 20 00 00    movq   $0x0,0x20(%rsp)
   400489:       00 00
   40048b:       48 c7 44 24 28 00 00    movq   $0x0,0x28(%rsp)
   400492:       00 00
   400494:       c7 44 24 30 00 00 00    movl   $0x0,0x30(%rsp)
   40049b:       00

Any ideas?

Quoted 8 lines

Quoted 8 lines

Quoted 1 line

Hmm, correct definition of u8?

I use unsigned char

Quoted 2 lines

Which version of gcc do you use? I can't see any difference if I compile your example at -O2.

gcc-Version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)

Well, was an error on my side, I see the same behavior.

Quoted 7 lines

Quoted 3 lines

I can see the same with the gcc version I previously posted. So it clears the 20 bytes from your example (movq, movq, movl) at two locations, presumably buf[] and b[].

Yes, it looks like that. The reservation on the stack changes, too.

Seems like just using barrier() is the best and easiest option.

Would you prepare a patch for that?

Quoted 3 lines

Thanks,
Hannes

Ciao
Stephan

Patch 0001 fixes the dead store issue in memzero_explicit().

On 03/18/2015 06:14 PM, mancha wrote:
...

Quoted 1 line

Patch 0001 fixes the dead store issue in memzero_explicit().

Thanks! I have issued the fix for the memzero bug to Herbert in your authorship as discussed, also giving some more context.

For the 2nd issue, lets wait for Cesar.

Thanks again!

Quoted 2 lines · Stephan Mueller

Am Mittwoch, 18. März 2015, 16:09:34 schrieb Hannes Frederic Sowa:

Quoted 1 line

Seems like just using barrier() is the best and easiest option.

However, if the idea is to use barrier() instead of OPTIMIZER_HIDE_VAR() in crypto_memneq() as well, then patch 0002 is the one to use. Please review and keep in mind my analysis was limited to memzero_explicit().

Cesar, were there reasons you didn't use the gcc version of barrier() for crypto_memneq()?

Maybe we should add a kernel self-test that automatically checks whether or not memset_explicit() gets optimized away? Otherwise we might not notice when gcc or how we implement barrier() or whatever else we end up using ends up changing.

It shold be something that is really fast, so it might be a good idea to simply automatically run it as part of an __initcall() unconditionally. We can debate where the __initcall() lives, but I'd prefer that it be run even if the crypto layer isn't configured for some reason. Hopefully such an self-test is small enough that the kernel bloat people won't complain. :-)

-Ted

Maybe a BUILD_BUGON: ;)

__label__ l1, l2;
char buffer[1024];
l1:

    memset(buffer, 0, 1024);

l2:
BUILD_BUGON(&&l1 == &&l2);

Quoted 72 lines · Stephan Mueller

Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:

Quoted 66 lines · Hannes Frederic Sowa

Quoted 34 lines · mancha

Quoted 17 lines

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect

memory cleansing against things like dead store optimization:

    void memzero_explicit(void *s, size_t count)
    {
    
            memset(s, 0, count);
            OPTIMIZER_HIDE_VAR(s);
    
    }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq>>
against timing analysis, is defined when using gcc as:

Quoted 8 lines

    #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0"
    (var))

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

    __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is allowed to check if it is needed and may remove the asm statement. Another option would be to just use var as an input variable - asm blocks without output variables are always considered being volatile by gcc.

Quoted 6 lines

Can you send a patch?

I don't think it is security critical, as Daniel pointed out, the call
will happen because the function is an external call to the crypto functions, thus the compiler has to flush memory on return.

Just had a look.

$ gdb vmlinux
(gdb) disassemble memzero_explicit
Dump of assembler code for function memzero_explicit:
   0xffffffff813a18b0 <+0>:	push   %rbp
   0xffffffff813a18b1 <+1>:	mov    %rsi,%rdx
   0xffffffff813a18b4 <+4>:	xor    %esi,%esi
   0xffffffff813a18b6 <+6>:	mov    %rsp,%rbp
   0xffffffff813a18b9 <+9>:	callq  0xffffffff813a7120 <memset>
   0xffffffff813a18be <+14>:	pop    %rbp
   0xffffffff813a18bf <+15>:	retq
End of assembler dump.

(gdb) disassemble extract_entropy
[...]
0xffffffff814a5000 <+304>: sub %r15,%rbx
0xffffffff814a5003 <+307>: jne 0xffffffff814a4f80
<extract_entropy+176> 0xffffffff814a5009 <+313>: mov %r12,%rdi
0xffffffff814a500c <+316>: mov $0xa,%esi
0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0
<memzero_explicit> 0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax
[...]

Quoted 1 line

I would be fine with __volatile__.

Are we sure that simply adding a __volatile__ works in any case? I just did a test with a simple user space app:

Quoted 7 lines

static inline void memset_secure(void *s, int c, size_t n)

{
        memset(s, c, n);
        //__asm__ __volatile__("": : :"memory");
        __asm__ __volatile__("" : "=r" (s) : "0" (s));
}

Good point, thanks!

Of course an input or output of s does not force the memory pointed to by s being flushed.

My proposal would be to add a

#define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" : : "m"( ({ struct { u8 b[len]; } *p = (void *)ptr ; *p; }) )

and use this in the code function.

This is documented in gcc manual 6.43.2.5.

Bye,
Hannes

Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:

Hi Daniel,

Quoted 67 lines · Hannes Frederic Sowa

Quoted 35 lines · mancha

Quoted 18 lines

Hi.

The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect

memory cleansing against things like dead store optimization:

    void memzero_explicit(void *s, size_t count)
    {
    
            memset(s, 0, count);
            OPTIMIZER_HIDE_VAR(s);
    
    }

OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq>>

against timing analysis, is defined when using gcc as:

Quoted 8 lines

    #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0"
    (var))

My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc from optimizing out memset (i.e. secrets remain in memory).

Two things that do work:

    __asm__ __volatile__ ("" : "=r" (var) : "0" (var))

You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is allowed to check if it is needed and may remove the asm statement. Another option would be to just use var as an input variable - asm blocks without output variables are always considered being volatile by gcc.

Quoted 6 lines

Can you send a patch?

I don't think it is security critical, as Daniel pointed out, the call
will happen because the function is an external call to the crypto functions, thus the compiler has to flush memory on return.

Just had a look.

$ gdb vmlinux
(gdb) disassemble memzero_explicit

Dump of assembler code for function memzero_explicit:

   0xffffffff813a18b0 <+0>:	push   %rbp
   0xffffffff813a18b1 <+1>:	mov    %rsi,%rdx
   0xffffffff813a18b4 <+4>:	xor    %esi,%esi
   0xffffffff813a18b6 <+6>:	mov    %rsp,%rbp
   0xffffffff813a18b9 <+9>:	callq  0xffffffff813a7120 <memset>

0xffffffff813a18be <+14>: pop %rbp
0xffffffff813a18bf <+15>: retq

End of assembler dump.

(gdb) disassemble extract_entropy
[...]

   0xffffffff814a5000 <+304>:	sub    %r15,%rbx
   0xffffffff814a5003 <+307>:	jne    0xffffffff814a4f80

<extract_entropy+176> 0xffffffff814a5009 <+313>: mov %r12,%rdi

Quoted 7 lines

   0xffffffff814a500c <+316>:	mov    $0xa,%esi
   0xffffffff814a5011 <+321>:	callq  0xffffffff813a18b0

<memzero_explicit> 0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax
[...]

I would be fine with __volatile__.

Are we sure that simply adding a __volatile__ works in any case? I just did a test with a simple user space app:

static inline void memset_secure(void *s, int c, size_t n)

{
       memset(s, c, n);
       //__asm__ __volatile__("": : :"memory");
       __asm__ __volatile__("" : "=r" (s) : "0" (s));
}

int main(int argc, char *argv[])
{

#define BUFLEN 20
       char buf[BUFLEN];

       snprintf(buf, (BUFLEN - 1), "teststring\n");
       printf("%s", buf);

       memset_secure(buf, 0, BUFLEN);
}

When using the discussed code of __asm__ __volatile__("" : "=r" (s) :
"0" (s)); I do not find the code implementing memset(0) in objdump. Only when I enable the memory barrier, I see the following (when compiling with -O2):

objdump -d memset_secure:
...
0000000000400440 <main>:
...

 400469:       48 c7 04 24 00 00 00    movq   $0x0,(%rsp)
 400470:       00
 400471:       48 c7 44 24 08 00 00    movq   $0x0,0x8(%rsp)
 400478:       00 00
 40047a:       c7 44 24 10 00 00 00    movl   $0x0,0x10(%rsp)
 400481:       00

...

I would like to bring up that topic again as I did some more analyses:

For testing I used the following code:

static inline void memset_secure(void *s, int c, size_t n)

{
        memset(s, c, n);
	BARRIER
}

where BARRIER is defined as:

(1) __asm__ __volatile__("" : "=r" (s) : "0" (s));

(2) __asm__ __volatile__("": : :"memory");

(3) __asm__ __volatile__("" : "=r" (s) : "0" (s) : "memory");

Quoted 19 lines

I would like to bring up that topic again as I did some more analyses:

For testing I used the following code:

static inline void memset_secure(void *s, int c, size_t n) {

        memset(s, c, n);
	
	BARRIER

}

where BARRIER is defined as:

(1) __asm__ __volatile__("" : "=r" (s) : "0" (s));

(2) __asm__ __volatile__("": : :"memory");

Quoted 1 line

(3) __asm__ __volatile__("" : "=r" (s) : "0" (s) : "memory");

Hm, I wonder a little bit...

Could you quickly test if you replace (s) with (n) just for the fun of it? I don't know if we should ask clang people about that, at least it is their goal to be as highly compatible with gcc inline asm.

Thanks for looking into this!

Bye,
Hannes

Am Freitag, 10. April 2015, 16:00:03 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 20 lines · Stephan Mueller

Quoted 19 lines

I would like to bring up that topic again as I did some more analyses:

For testing I used the following code:

static inline void memset_secure(void *s, int c, size_t n) {

        memset(s, c, n);
	
	BARRIER

}

where BARRIER is defined as:

(1) __asm__ __volatile__("" : "=r" (s) : "0" (s));

(2) __asm__ __volatile__("": : :"memory");

Quoted 7 lines

Quoted 1 line

(3) __asm__ __volatile__("" : "=r" (s) : "0" (s) : "memory");

Hm, I wonder a little bit...

Could you quickly test if you replace (s) with (n) just for the fun of it? I don't know if we should ask clang people about that, at least it is their goal to be as highly compatible with gcc inline asm.

Using

__asm__ __volatile__("" : "=r" (n) : "0" (n) : "memory");

clang O2/3: no mov

gcc O2/3: mov present

==> not good

Using
__asm__ __volatile__("" : "=r" (n) : "0" (n));

clang O2/3: no mov

gcc O2/3: no mov

==> not good

What do you expect that change shall do?

Quoted 1 line

Quoted 4 lines

Thanks for looking into this!

Bye,
Hannes

Ciao
Stephan

__asm__ __volatile__("": :"r"(p) :"memory")

Am Freitag, 10. April 2015, 14:22:08 schrieb mancha security:

Hi mancha,

Quoted 1 line

__asm__ __volatile__("": :"r"(p) :"memory")

gcc -O2/3: mov present

clang -O2/3: mov present

==> approach would be good too.

Note, the assembly code does not seem to change whether to use this approach or the one I initially tested.

Ciao
Stephan

Am Freitag, 10. April 2015, 16:00:03 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 20 lines · Stephan Mueller

Quoted 19 lines

I would like to bring up that topic again as I did some more analyses:

For testing I used the following code:

static inline void memset_secure(void *s, int c, size_t n) {

        memset(s, c, n);
	
	BARRIER

}

where BARRIER is defined as:

(1) __asm__ __volatile__("" : "=r" (s) : "0" (s));

(2) __asm__ __volatile__("": : :"memory");

Quoted 7 lines

Quoted 1 line

(3) __asm__ __volatile__("" : "=r" (s) : "0" (s) : "memory");

Hm, I wonder a little bit...

Could you quickly test if you replace (s) with (n) just for the fun of it? I don't know if we should ask clang people about that, at least it is their goal to be as highly compatible with gcc inline asm.

Using

__asm__ __volatile__("" : "=r" (n) : "0" (n) : "memory");

clang O2/3: no mov

gcc O2/3: mov present

==> not good

Quoted 40 lines

Am Freitag, 10. April 2015, 16:00:03 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 20 lines · Stephan Mueller

Quoted 19 lines

I would like to bring up that topic again as I did some more analyses:

For testing I used the following code:

static inline void memset_secure(void *s, int c, size_t n) {

        memset(s, c, n);
	
	BARRIER

}

where BARRIER is defined as:

(1) __asm__ __volatile__("" : "=r" (s) : "0" (s));

(2) __asm__ __volatile__("": : :"memory");

Quoted 7 lines

Quoted 1 line

(3) __asm__ __volatile__("" : "=r" (s) : "0" (s) : "memory");

Hm, I wonder a little bit...

Could you quickly test if you replace (s) with (n) just for the fun of it? I don't know if we should ask clang people about that, at least it is their goal to be as highly compatible with gcc inline asm.

Using

__asm__ __volatile__("" : "=r" (n) : "0" (n) : "memory");

clang O2/3: no mov

gcc O2/3: mov present

Quoted 1 line

==> not good

I suspected a problem in how volatile with non-present output args could be different, but this seems not to be the case.

I would contact llvm/clang mailing list and ask. Maybe there is a problem? It seems kind of strange to me...

Thanks,
Hannes

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Am Freitag, 10. April 2015, 16:26:00 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 46 lines · Stephan Mueller

Quoted 34 lines

Am Freitag, 10. April 2015, 16:00:03 schrieb Hannes Frederic Sowa:

Hi Hannes,

Quoted 20 lines · Stephan Mueller

Quoted 19 lines

I would like to bring up that topic again as I did some more analyses:

For testing I used the following code:

static inline void memset_secure(void *s, int c, size_t n) {

        memset(s, c, n);
	
	BARRIER

}

where BARRIER is defined as:

(1) __asm__ __volatile__("" : "=r" (s) : "0" (s));

(2) __asm__ __volatile__("": : :"memory");

Quoted 7 lines

Quoted 1 line

(3) __asm__ __volatile__("" : "=r" (s) : "0" (s) : "memory");

Hm, I wonder a little bit...

Could you quickly test if you replace (s) with (n) just for the fun of it? I don't know if we should ask clang people about that, at least it is their goal to be as highly compatible with gcc inline asm.

Using

Quoted 7 lines

__asm__ __volatile__("" : "=r" (n) : "0" (n) : "memory");

clang O2/3: no mov

gcc O2/3: mov present

==> not good

I suspected a problem in how volatile with non-present output args could be different, but this seems not to be the case.

Quoted 2 lines

I would contact llvm/clang mailing list and ask. Maybe there is a problem? It seems kind of strange to me...

Do you really think this is a compiler issue? I would rather think it is how to interpret the pure "memory" asm option. Thus, I would rather think that both, gcc and clang are right and we just need to use the code that fits both.

Am Freitag, 10. April 2015, 16:26:00 schrieb Hannes Frederic Sowa:

Quoted 5 lines

I suspected a problem in how volatile with non-present output args could be different, but this seems not to be the case.

I would contact llvm/clang mailing list and ask. Maybe there is a problem? It seems kind of strange to me...

Do you really think this is a compiler issue?

Quoted 1 line

Am Freitag, 10. April 2015, 16:26:00 schrieb Hannes Frederic Sowa:

...

Quoted 5 lines

Quoted 5 lines

I suspected a problem in how volatile with non-present output args could be different, but this seems not to be the case.

I would contact llvm/clang mailing list and ask. Maybe there is a problem? It seems kind of strange to me...

+1

Quoted 1 line

Do you really think this is a compiler issue?

If clang/LLVM advertises "GCC compatibility", then this would certainly be a different behavior.

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Am Freitag, 10. April 2015, 16:46:04 schrieb Daniel Borkmann:

Hi Daniel,

Quoted 12 lines · Stephan Mueller

Quoted 1 line

Am Freitag, 10. April 2015, 16:26:00 schrieb Hannes Frederic Sowa:

...

Quoted 5 lines

Quoted 5 lines

I suspected a problem in how volatile with non-present output args could be different, but this seems not to be the case.

I would contact llvm/clang mailing list and ask. Maybe there is a problem? It seems kind of strange to me...

+1

Quoted 4 lines

Quoted 1 line

Do you really think this is a compiler issue?

If clang/LLVM advertises "GCC compatibility", then this would certainly be a different behavior.

As you wish. I will contact the clang folks. As the proposed fix is not super urgend, I think we can leave it until I got word from clang.

Am Freitag, 10. April 2015, 16:46:04 schrieb Daniel Borkmann:

Hi Daniel,

Quoted 12 lines · Stephan Mueller

Quoted 1 line

Am Freitag, 10. April 2015, 16:26:00 schrieb Hannes Frederic Sowa:

...

Quoted 5 lines

Quoted 5 lines

I suspected a problem in how volatile with non-present output args could be different, but this seems not to be the case.

I would contact llvm/clang mailing list and ask. Maybe there is a problem? It seems kind of strange to me...

+1

Quoted 4 lines

Quoted 1 line

Do you really think this is a compiler issue?

If clang/LLVM advertises "GCC compatibility", then this would certainly be a different behavior.

As you wish. I will contact the clang folks. As the proposed fix is not super urgend, I think we can leave it until I got word from clang.

I posted the issue on the clang mailing list on April 10 -- no word so far. I would interpret this as a sign that it is a no-issue for them.

...

Quoted 2 lines

I posted the issue on the clang mailing list on April 10 -- no word so far. I would interpret this as a sign that it is a no-issue for them.

Hm. ;)

Here's a bug report on the topic, gcc vs llvm:

   https://llvm.org/bugs/show_bug.cgi?id=15495

Lets add a new barrier macro to linux/compiler{,-gcc}.h, f.e.

   #define barrier_data(ptr) __asm__ __volatile__("" : : "r" (ptr) :

"memory")

or the version Mancha proposed. You could wrap that ...

   #define OPTIMIZER_HIDE(ptr)   barrier_data(ptr)

... and use that one for memzero_explicit() instead:

   void memzero_explicit(void *s, size_t count)
   {
      memset(s, 0, count);
      OPTIMIZER_HIDE(s);
   }

It certainly needs comments explaining in what situations to use which OPTIMIZER_HIDE* variants, etc.

Do you want to send a patch?

It seems you have the code already in mind, so please if you could write it :-)