mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Stephan Mueller <smueller@chronox.de>
Cc: Daniel Borkmann <daniel@iogearbox.net>, mancha <mancha1@zoho.com>,
	tytso@mit.edu, linux-kernel@vger.kernel.org,
	linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au,
	dborkman@redhat.com
Subject: Re: [BUG/PATCH] kernel RNG and its secrets
Date: Fri, 10 Apr 2015 16:45:55 +0200	[thread overview]
Message-ID: <1428677155.3377.17.camel@stressinduktion.org> (raw)
In-Reply-To: <2115964.QxtQ6rHSkc@tauon>

On Fr, 2015-04-10 at 16:36 +0200, Stephan Mueller wrote:
> Am Freitag, 10. April 2015, 16:26:00 schrieb Hannes Frederic Sowa:
> 
> Hi Hannes,
> 
> >On Fr, 2015-04-10 at 16:09 +0200, Stephan Mueller wrote:
> >> Am Freitag, 10. April 2015, 16:00:03 schrieb Hannes Frederic Sowa:
> >> 
> >> Hi Hannes,
> >> 
> >> >On Fr, 2015-04-10 at 15:25 +0200, Stephan Mueller wrote:
> >> >> 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");
> >> >
> >> >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
> >
> >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? 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.

Clang docs state that they want to be highly compatible with gcc inline
asm. Also, kernel code also uses barrier() in other places and in my
opinion, the compiler cannot make any assumptions about memory and
registers when using volatile asm with memory clobbers. But somehow
clang+llvm seems it does, no?

Thanks,
Hannes



  reply	other threads:[~2015-04-10 14:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18  9:53 mancha
2015-03-18 10:30 ` Daniel Borkmann
2015-03-18 10:50 ` Hannes Frederic Sowa
2015-03-18 10:56   ` Daniel Borkmann
2015-03-18 11:09     ` Stephan Mueller
2015-03-18 12:02       ` Hannes Frederic Sowa
2015-03-18 12:14         ` Stephan Mueller
2015-03-18 12:19           ` Hannes Frederic Sowa
2015-03-18 12:20             ` Stephan Mueller
2015-03-18 12:42               ` Daniel Borkmann
2015-03-18 15:09                 ` Hannes Frederic Sowa
2015-03-18 16:02                   ` Stephan Mueller
2015-03-18 17:14                     ` mancha
2015-03-18 17:49                       ` Daniel Borkmann
2015-03-18 19:09                         ` mancha
2015-03-18 23:53                       ` Cesar Eduardo Barros
2015-03-18 17:41                   ` Theodore Ts'o
2015-03-18 17:56                     ` Hannes Frederic Sowa
2015-03-18 17:58                       ` Theodore Ts'o
2015-03-18 12:58         ` mancha
2015-04-10 13:25       ` Stephan Mueller
2015-04-10 14:00         ` Hannes Frederic Sowa
2015-04-10 14:09           ` Stephan Mueller
2015-04-10 14:22             ` mancha security
2015-04-10 14:33               ` Stephan Mueller
2015-04-10 20:09                 ` mancha security
2015-04-10 14:26             ` Hannes Frederic Sowa
2015-04-10 14:36               ` Stephan Mueller
2015-04-10 14:45                 ` Hannes Frederic Sowa [this message]
2015-04-10 14:46                 ` Daniel Borkmann
2015-04-10 14:50                   ` Stephan Mueller
2015-04-10 14:54                     ` Daniel Borkmann
2015-04-27 19:10                     ` Stephan Mueller
2015-04-27 20:34                       ` Daniel Borkmann
2015-04-27 20:41                         ` Stephan Mueller
2015-04-27 20:53                           ` Daniel Borkmann

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=1428677155.3377.17.camel@stressinduktion.org \
    --to=hannes@stressinduktion.org \
    --cc=daniel@iogearbox.net \
    --cc=dborkman@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mancha1@zoho.com \
    --cc=smueller@chronox.de \
    --cc=tytso@mit.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®