Skip to content

L
linux
Switch branch/tag
  1. 31 Mar, 2015 6 commits
  3. 24 Mar, 2015 1 commit
  5. 23 Mar, 2015 6 commits
  7. 19 Mar, 2015 1 commit
    • mancha security's avatar
      lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR · 0b053c95
      mancha security authored 
      OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to
ensure protection from dead store optimization.

For the random driver and crypto drivers, calls are emitted ...

  $ 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
  [...]
    0xffffffff814a5009 <+313>:	mov    %r12,%rdi
    0xffffffff814a500c <+316>:	mov    $0xa,%esi
    0xffffffff814a5011 <+321>:	callq  0xffffffff813a18b0 <memzero_explicit>
    0xffffffff814a5016 <+326>:	mov    -0x48(%rbp),%rax
  [...]

... but in case in future we might use facilities such as LTO, then
OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible
eviction of the memset(). We have to use a compiler barrier instead.

Minimal test example when we assume memzero_explicit() would *not* be
a call, but would have been *inlined* instead:

  static inline void memzero_explicit(void *s, size_t count)
  {
    memset(s, 0, count);
    <foo>
  }

  int main(void)
  {
    char buff[20];

    snprintf(buff, sizeof(buff) - 1, "test");
    printf("%s", buff);

    memzero_explicit(buff, sizeof(buff));
    return 0;
  }

With <foo> := OPTIMIZER_HIDE_VAR():

  (gdb) disassemble main
  Dump of assembler code for function main:
  [...]
   0x0000000000400464 <+36>:	callq  0x400410 <printf@plt>
   0x0000000000400469 <+41>:	xor    %eax,%eax
   0x000000000040046b <+43>:	add    $0x28,%rsp
   0x000000000040046f <+47>:	retq
  End of assembler dump.

With <foo> := barrier():

  (gdb) disassemble main
  Dump of assembler code for function main:
  [...]
   0x0000000000400464 <+36>:	callq  0x400410 <printf@plt>
   0x0000000000400469 <+41>:	movq   $0x0,(%rsp)
   0x0000000000400471 <+49>:	movq   $0x0,0x8(%rsp)
   0x000000000040047a <+58>:	movl   $0x0,0x10(%rsp)
   0x0000000000400482 <+66>:	xor    %eax,%eax
   0x0000000000400484 <+68>:	add    $0x28,%rsp
   0x0000000000400488 <+72>:	retq
  End of assembler dump.

As can be seen, movq, movq, movl are being emitted inlined
via memset().

Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/
Fixes: d4c5efdb ("random: add and use memzero_explicit() for clearing data")
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: default avatarmancha security <mancha1@zoho.com>
Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: default avatarStephan Mueller <smueller@chronox.de>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      0b053c95
  9. 18 Mar, 2015 1 commit
  11. 17 Mar, 2015 3 commits
    • Herbert Xu's avatar
      linux-next: build failure after merge of the crypto tree · 7094e8ea
      Herbert Xu authored 
      crypto: img-hash - Add missing semicolon to fix build error

There is a missing semicolon after MODULE_DEVICE_TABLE.
Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7094e8ea
    • Andre Wolokita's avatar
      hwrng: omap - Change RNG_CONFIG_REG to RNG_CONTROL_REG in init · 656d7e7e
      Andre Wolokita authored 
      omap4_rng_init() checks bit 10 of the RNG_CONFIG_REG to determine whether
the RNG is already running before performing any initiliasation. This is not
the correct register to check, as the enable bit is in RNG_CONFIG_CONTROL.
Read from RNG_CONTROL_REG instead.
Signed-off-by: default avatarAndre Wolokita <Andre.Wolokita@analog.com>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      656d7e7e
    • Andre Wolokita's avatar
      hwrng: omap - Change RNG_CONFIG_REG to RNG_CONTROL_REG when checking and disabling TRNG · 1a5addfe
      Andre Wolokita authored 
      In omap4_rng_init(), a check of bit 10 of the RNG_CONFIG_REG is done to determine
whether the RNG is running. This is suspicious firstly due to the use of
RNG_CONTROL_ENABLE_TRNG_MASK and secondly because the same mask is written to
RNG_CONTROL_REG after configuration of the FROs. Similar suspicious logic is
repeated in omap4_rng_cleanup() when RNG_CONTROL_REG masked with
RNG_CONTROL_ENABLE_TRNG_MASK is read, the same mask bit is cleared, and then
written to RNG_CONFIG_REG. Unless the TRNG is enabled with one bit in RNG_CONTROL
and disabled with another in RNG_CONFIG and these bits are mirrored in some way,
I believe that the TRNG is not really shutting off.

Apart from the strange logic, I have reason to suspect that the OMAP4 related
code in this driver is driving an Inside Secure IP hardware RNG and strongly
suspect that bit 10 of RNG_CONFIG_REG is one of the bits configuring the
sampling rate of the FROs. This option is by default set to 0 and is not being
set anywhere in omap-rng.c. Reading this bit during omap4_rng_init() will
always return 0. It will remain 0 because ~(value of TRNG_MASK in control) will
always be 0, because the TRNG is never shut off. This is of course presuming
that the OMAP4 features the Inside Secure IP.

I'm interested in knowing what the guys at TI think about this, as only they
can confirm or deny the detailed structure of these registers.
Signed-off-by: default avatarAndre Wolokita <Andre.Wolokita@analog.com>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1a5addfe
  13. 16 Mar, 2015 10 commits
  15. 13 Mar, 2015 2 commits
  17. 12 Mar, 2015 7 commits
  19. 11 Mar, 2015 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7