valgrind and openssl - Openssl

This is a discussion on valgrind and openssl - Openssl ; -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik de Castro Lopo schrieb: | Theodore Tso wrote: | |> On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote: |>> What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 74

Thread: valgrind and openssl

  1. Re: valgrind and openssl

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Erik de Castro Lopo schrieb:
    | Theodore Tso wrote:
    |
    |> On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote:
    |>> What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the
    |>> default, but wouldn't reduce the keyspace either.
    |> -DPURIFY *does* do what you want.
    |
    | But thats a compile time option. I would prefer not to have to compile
    | my own version of OpenSSL just to be able to valgrind my program which
    | links against openssl.

    Then configure your valgrind to ignore this uninitialized use of data.

    Normally usage of uninitialized data is an oversight done by
    the programmer that may cause unintended consequences.
    Because of that valgrind complains about them.

    But here the use of this uninitialized data is intentional
    and the programmer are very well aware of what they did.


    Perhaps it would be a good idea to add a README.valgrind containing
    a description of what happens and how to configure valgrind to ignore
    the uninitialized reads ?
    (Perhaps people that won't read the FAQ will read that)

    Goetz

    - --
    DMCA: The greed of the few outweighs the freedom of the many
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.4-svn0 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFILKt52iGqZUF3qPYRAtkIAJ47deAtIXtN0DKJGN61Ct ZyimI3jACfUPDJ
    ddRbnQn5NF5h0Y6P6pLUHP4=
    =8wkC
    -----END PGP SIGNATURE-----
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Re: valgrind and openssl

    Geoff Thorpe wrote:

    > Then tell your linux distribution to use -DPURIFY.


    Hangon, I've got a better idea. How about the OpenSSL develoeprs
    fix their library so that the standard version that they ship is
    valgrind clean. Then the distributions won't need to do anything
    other than compile it.

    Erik
    --
    -----------------------------------------------------------------
    Erik de Castro Lopo
    -----------------------------------------------------------------
    The difference between genius and stupidity is that
    genius has its limits.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: valgrind and openssl

    Goetz Babin-Ebell wrote:

    > But here the use of this uninitialized data is intentional
    > and the programmer are very well aware of what they did.


    The use of unititialized data in this case is stupid because the
    entropy of this random data is close to zero.

    The only sane way to deal with this it to either make it zero
    or make it truely random.

    Erik
    --
    -----------------------------------------------------------------
    Erik de Castro Lopo
    -----------------------------------------------------------------
    "I would buy a Mac today if I was not working at Microsoft."
    -- Senior Microsoft exective Jim Allchin in a 200 email to Bill
    Gates : http://www.iowaconsumercase.org/010807/PLEX_7264.pdf
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: valgrind and openssl

    On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo
    wrote:
    > Goetz Babin-Ebell wrote:


    >> But here the use of this uninitialized data is intentional
    >> and the programmer are very well aware of what they did.


    > The use of unititialized data in this case is stupid because the
    > entropy of this random data is close to zero.


    It may be zero, but it may be more, depending on what happened earlier
    in the program if the same memory locations have been in use before.
    This may very well include data that would be unpredictable to
    adversaries -- i.e., entropy; that's the point here.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  5. Re: valgrind and openssl

    Bodo Moeller wrote:

    > It may be zero, but it may be more, depending on what happened earlier
    > in the program if the same memory locations have been in use before.
    > This may very well include data that would be unpredictable to
    > adversaries -- i.e., entropy; that's the point here.


    Do you know its unpredicatable or are you only guessing?

    Can a bad guy force it to be predicatable?

    How much entropy is actually there? Has anyone actually measured it?

    Erik
    --
    -----------------------------------------------------------------
    Erik de Castro Lopo
    -----------------------------------------------------------------
    "Using Java as a general purpose application development language
    is like going big game hunting armed with Nerf weapons."
    -- Author Unknown
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  6. Re: valgrind and openssl

    On Thu, May 15, 2008 at 4:41 PM, Erik de Castro Lopo
    wrote:
    > Goetz Babin-Ebell wrote:
    >
    >> But here the use of this uninitialized data is intentional
    >> and the programmer are very well aware of what they did.

    >
    > The use of unititialized data in this case is stupid because the
    > entropy of this random data is close to zero.
    >
    > The only sane way to deal with this it to either make it zero
    > or make it truely random.
    >
    > Erik


    I disagree. If there's a performance cost to making openssl happy
    with valgrind, I'd rather have there be an option that defaults to
    optimize security and performance at the expense of debugging
    capability. Debugging is the infrequent case.

    Although I disagree, I understand your argument. However, you weaken
    your position by using the words "stupid" and "sane;" they make you
    seem disrespectful.

    -JP
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  7. Re: valgrind and openssl

    On Thursday 15 May 2008 17:31:45 Erik de Castro Lopo wrote:
    > Geoff Thorpe wrote:
    > > Then tell your linux distribution to use -DPURIFY.

    >
    > Hangon, I've got a better idea. How about the OpenSSL develoeprs
    > fix their library so that the standard version that they ship is
    > valgrind clean. Then the distributions won't need to do anything
    > other than compile it.


    What, you mean like how the standard version we ship has a good PRNG, so that
    the distributions don't need to do anything about that either? Funny, that
    doesn't work so well in the real world.

    Distributions always do something before compiling packages, as debian has so
    succinctly and spectacularly demonstrated. They pick target architecture
    settings for the distribution that are independent of the build host (eg.
    cross-compilation for non-x86 hosts, etc) and another other configuration
    options they think useful/necessary. Eg. static/dynamic, PIC or not, symbols
    or not, installation paths, optional features (and dependencies),
    documentation, [...]. Sometimes they even throw in patches, which is where
    they diverge dangerously from what we provide. If it is the distribution's
    preference to have openssl unnecessarily memset and/or unnecessarily restrict
    its seeding to pander to an unmodified and unconfigured valgrind, be that in
    the standard package or any other debug package, then that is their choice.
    We provide a (supported) method for doing this, it's called -DPURIFY. It
    doesn't require *any* source-code patching. .

    Valgrind is a great tool and no doubt many non-noobs put it to good use on a
    daily basis. It helps find non-deterministic behaviour. That it finds
    non-deterministic behaviour in our PRNG should not be cause for
    basement-dwellers the world over to rise up against common-sense. We have a
    FAQ in case you get confused, and valgrind can also be "taught" to work
    around such cases as this. And again, you can build openssl to side-step the
    false-positives for a very small overhead. Just what level of base,
    ill-informed, and incompetent debugging "help" do we need to cater to? And to
    what non-technical extents are we prepared to go for it?

    Cheers,
    Geoff

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  8. Re: valgrind and openssl

    On Thu, May 15, 2008 at 11:51 PM, Erik de Castro Lopo
    wrote:
    > Bodo Moeller wrote:


    >> It may be zero, but it may be more, depending on what happened earlier
    >> in the program if the same memory locations have been in use before.
    >> This may very well include data that would be unpredictable to
    >> adversaries -- i.e., entropy; that's the point here.


    > Do you know its unpredicatable or are you only guessing?
    >
    > Can a bad guy force it to be predicatable?
    >
    > How much entropy is actually there? Has anyone actually measured it?


    All this depends on the specific application. For many, there almost
    certainly won't be any unpredictable data. For others, in particular
    long-running interactive software, there certainly will be at least
    some information that is unpredictable to at least some adversaries.
    Even if it's just return addresses on the stack, the specific pattern
    will depend on the program's past, some aspects of which may be
    unknown to adversaries.

    We don't care if anyone can force this to be predictable, because
    we're in no way relying on it to deliver more than zero bits of
    entropy. We're just hoping there might be some entropy in there
    sometimes.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  9. RE: valgrind and openssl


    > Geoff Thorpe wrote:
    >
    > > Then tell your linux distribution to use -DPURIFY.

    >
    > Hangon, I've got a better idea. How about the OpenSSL develoeprs
    > fix their library so that the standard version that they ship is
    > valgrind clean. Then the distributions won't need to do anything
    > other than compile it.
    >
    > Erik


    Umm, why?

    1) This is an unusual use case.

    2) Zeroing memory that doesn't need to be zeroed has a performance cost.

    3) It's very easy to recompile a debug build for debugging.

    IMO, the default build should always be a release build with release
    optimizations and tradeoffs. A debug build should be the exception.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  10. Re: valgrind and openssl

    Bodo Moeller wrote:

    > We don't care if anyone can force this to be predictable, because
    > we're in no way relying on it to deliver more than zero bits of
    > entropy.


    So it might end up being zero just by chance right?

    > We're just hoping there might be some entropy in there
    > sometimes.


    In the practice of engineering, we should try to avoid 'hoping'
    about anything.

    Erik
    --
    -----------------------------------------------------------------
    Erik de Castro Lopo
    -----------------------------------------------------------------
    "Every method you use to prevent or find bugs leaves a residue of
    subtler bugs against which those methods are ineffectual."
    -- Bruce Beizer's Pesticide Paradox
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  11. Re: valgrind and openssl

    David Schwartz wrote:

    > Umm, why?
    >
    > 1) This is an unusual use case.


    This is not an unusual case. I'm a developer and I valgrind my
    code all the time because fixing problems shown up by valgrind
    makes my code better.

    My code is targeting an embedded Linux box and I try to ensure
    that the system I develop and test on is as close as possible
    to the embedded target. Using a different version of openssl
    sort of defeats that aim.

    > 2) Zeroing memory that doesn't need to be zeroed has a performance cost.


    Yep, I agree, for code that doesn't give valgrind warnings.

    A couple of years ago I attended a very interesting presentation
    by Andrew Tridgel of the Samba project. He explained that they
    avoided zeroing memory wherever possible. However, they used
    valgrind and had a rigorous policy of fixing all valgrind
    warnings. Tridge's claim was that doing this maximized performace
    and guarded against information leakage onto the wire.

    > 3) It's very easy to recompile a debug build for debugging.


    But if I do that, my test system is no longer the same as my
    target.

    > IMO, the default build should always be a release build with release
    > optimizations and tradeoffs. A debug build should be the exception.


    I'm not asking for all uses of malloc to be replaced with calloc,
    I'm asking for the very small number of areas that produce valgrind
    warnings to be fixed. Since they are small in number it is unlikely
    that any performance decrease can even be measureed.

    Erik
    --
    -----------------------------------------------------------------
    Erik de Castro Lopo
    -----------------------------------------------------------------
    The Earth is around 70% water. Fish rule the seas.
    Humans are over 90% water. It's only a matter of time.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  12. RE: valgrind and openssl


    > David Schwartz wrote:
    >
    > > Umm, why?
    > >
    > > 1) This is an unusual use case.


    > This is not an unusual case. I'm a developer and I valgrind my
    > code all the time because fixing problems shown up by valgrind
    > makes my code better.


    I didn't say it was an unusual use case for you. It's an unusual use case
    for OpenSSL.

    > My code is targeting an embedded Linux box and I try to ensure
    > that the system I develop and test on is as close as possible
    > to the embedded target. Using a different version of openssl
    > sort of defeats that aim.


    Then you have to make a tradeoff. You can either debug in a release build
    and suffer the added complexity or you can release a debug build and suffer
    the performance loss. But others don't have to make that tradeoff, and
    there's no reason your problem should force them to.

    > > 2) Zeroing memory that doesn't need to be zeroed has a performance cost.


    > Yep, I agree, for code that doesn't give valgrind warnings.
    >
    > A couple of years ago I attended a very interesting presentation
    > by Andrew Tridgel of the Samba project. He explained that they
    > avoided zeroing memory wherever possible. However, they used
    > valgrind and had a rigorous policy of fixing all valgrind
    > warnings. Tridge's claim was that doing this maximized performace
    > and guarded against information leakage onto the wire.


    He's absolutely right. Here, Tridge's argument works the other way. We
    *want* as much information as possible to "leak" into the PRNG.

    > > 3) It's very easy to recompile a debug build for debugging.


    > But if I do that, my test system is no longer the same as my
    > target.


    Then you are welcome to ship a debug build with your target. That's your
    tradeoff to make. The vast majority of people don't have such a tradeoff, so
    it's kind of silly that they should suffer its costs just because you have
    to.

    > > IMO, the default build should always be a release build with release
    > > optimizations and tradeoffs. A debug build should be the exception.


    > I'm not asking for all uses of malloc to be replaced with calloc,
    > I'm asking for the very small number of areas that produce valgrind
    > warnings to be fixed. Since they are small in number it is unlikely
    > that any performance decrease can even be measureed.


    Then you are welcome to compile with -DPURIFY even in your release build.
    That does exactly what you ask for. I've already explained why that's not
    the default -- your case is unusual and so it should *not* be the default. A
    single extra flag is an extremely minimal cost.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  13. RE: valgrind and openssl

    Would a runtime flag for "don't seed with uninitialized memory", rather
    than (or in addition to) -DPURIFY, satisfy everybody?

    John
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  14. Re: valgrind and openssl

    > In the practice of engineering, we should try to avoid 'hoping'
    > about anything.


    Don't know much about cryptography, do you?

    /r$

    --
    STSM, DataPower Chief Programmer
    WebSphere DataPower SOA Appliances
    http://www.ibm.com/software/integration/datapower/


  15. RE: valgrind and openssl

    > Would a runtime flag for "don't seed with uninitialized memory", rather
    > than (or in addition to) -DPURIFY, satisfy everybody?


    Everybody?

    It seems to me that only one or two people who don't really understand
    what's going on are complaining.
    OpenSSL should stay as it is. A contributed valgrind suppressions file
    would be useful.

    /r$

    --
    STSM, DataPower Chief Programmer
    WebSphere DataPower SOA Appliances
    http://www.ibm.com/software/integration/datapower/


  16. RE: valgrind and openssl


    > Would a runtime flag for "don't seed with uninitialized memory", rather
    > than (or in addition to) -DPURIFY, satisfy everybody?
    >
    > John


    I don't think it's necessary, since compiling with '-DPURIFY' is so
    ridiculously easy, but I have no objection to it. An evironment variable
    would probably be the easiest way to do it.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  17. RE: valgrind and openssl

    > Everybody?
    >
    > It seems to me that only one or two people who don't really
    > understand what's going on are complaining.


    Wanting to get accurate runtime analysis results with a release build is
    not an unreasonable request.

    > OpenSSL should stay as it is. A contributed valgrind
    > suppressions file would be useful.


    It certainly would, but Valgrind isn't the only analysis tool people
    might want to use. A runtime flag provides a means of obtaining accurate
    results with any tool.

    John
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  18. Re: valgrind and openssl

    On Fri, May 16, 2008 at 12:39 AM, David Schwartz wrote:

    > 2) Zeroing memory that doesn't need to be zeroed has a performance cost.


    This particular argument doesn't actually apply here. We wouldn't
    have to zeroize any memory, we just wouldn't feed those bytes that are
    not known to have been initialized into RAND_add(). The cost of
    RAND_add() is a lot higher than that of memset(), so we'd even gain
    some performance. But we'd lose the randomness that is available when
    the bytes not currently known to have been initialized have in fact
    been previously initialized in a way not known by an attacker.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  19. Re: valgrind and openssl

    On Thu, May 15, 2008 at 06:17:03PM -0400, Geoff Thorpe wrote:
    > On Thursday 15 May 2008 17:31:45 Erik de Castro Lopo wrote:
    > > Geoff Thorpe wrote:
    > > > Then tell your linux distribution to use -DPURIFY.

    > >
    > > Hangon, I've got a better idea. How about the OpenSSL develoeprs
    > > fix their library so that the standard version that they ship is
    > > valgrind clean. Then the distributions won't need to do anything
    > > other than compile it.

    >
    > What, you mean like how the standard version we ship has a good PRNG, so that
    > the distributions don't need to do anything about that either? Funny, that
    > doesn't work so well in the real world.


    I do have to question whether mixing in predictable data from the stack
    at RNG initialization time is such a great idea.

    Thor
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  20. Re: valgrind and openssl

    On Thu, May 15, 2008 at 11:45:14PM +0200, Bodo Moeller wrote:
    > On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo
    > wrote:
    > > Goetz Babin-Ebell wrote:

    >
    > >> But here the use of this uninitialized data is intentional
    > >> and the programmer are very well aware of what they did.

    >
    > > The use of unititialized data in this case is stupid because the
    > > entropy of this random data is close to zero.

    >
    > It may be zero, but it may be more, depending on what happened earlier
    > in the program if the same memory locations have been in use before.
    > This may very well include data that would be unpredictable to
    > adversaries -- i.e., entropy; that's the point here.


    Unfortunately, it may also very well include data that would be
    highly predictable to adversaries.

    I am aware that this is an area without a lot of good theoretical
    signposts, but I am just not very comfortable feeding arbitrary
    amounts of possibly-known data into a PRNG.

    Thor
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast