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
next prev parent 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®