> On Nov 24, 2015, at 2:13 AM, Nico Williams wrote:
>
> If the OpenSSL team finally decides to do something about sane locking
> by default, then it will be a huge improvement. If this thread provides
> the impetus, so much the better.
I hope that happens. It would certainly make a big contri
On Tue, Nov 24, 2015 at 11:32:32AM +1000, Peter Waltenberg wrote:
> I wasn't saying there was anything wrong with mmap(), just that guard pages
> only work if you can guarantee your overrun hits the guard page (and
> doesn't just step over it). Large stack allocations increase the odds of
> 'steppi
On Tue, Nov 24, 2015 at 11:32:32AM +1000, Peter Waltenberg wrote:
> As for fibre's, I doubt it'll work in general, the issue there is simply
> the range of OS's OpenSSL supports. If you wire it in you still have to run
> with man+dog+world in the process, that's a hard ask. One of the good
> point
I wasn't saying there was anything wrong with mmap(), just that guard pages
only work if you can guarantee your overrun hits the guard page (and
doesn't just step over it). Large stack allocations increase the odds of
'stepping over' the guard pages. It's still better than not having guard
pages,
? It does, but it also requires code changes in a few places. probable_prime()
in bn_prime.c being far and away the worst offender.
This is fixed in master which uses malloc and free. Actually, I think all
egregious stack consumption has been fixed in master.
___
On Mon, Nov 23, 2015 at 09:53:15PM +1000, Peter Waltenberg wrote:
>
> "
> Please do. It will make this much safer. Also, you might want to run
> some experiments to find the best stack size on each platform. The
> smaller the stack you can get away with, the better.
> "
>
> It does, but it als
On Mon, Nov 23, 2015 at 05:28:18PM -0600, Nico Williams wrote:
> It may be a good idea to rethink locking completely.
There is some glimmer of hope in that as various libcrypto structures
become opaque, the locking moves from application code into the
library. For example, we now have (yet to be
"
Please do. It will make this much safer. Also, you might want to run
some experiments to find the best stack size on each platform. The
smaller the stack you can get away with, the better.
"
It does, but it also requires code changes in a few places. probable_prime
() in bn_prime.c being far
On Mon, Nov 23, 2015 at 10:18:27PM +, Matt Caswell wrote:
> On 23/11/15 21:56, Paul Dale wrote:
> > Somewhat tangentially related to this is the how thread locking in
> > OpenSSL is slowing things up.
>
> Alessandro has submitted an interesting patch to provide a much better
> threading API. S
On Tue, Nov 24, 2015 at 07:56:15am +1000, Paul Dale wrote:
> Somewhat tangentially related to this is the how thread locking in OpenSSL is
> slowing things up.
>
> We've been doing some connection establishment performance analysis recently
> and have discovered a lot of waiting on locks is occurr
Thanks for the quick reply. That patch looks much improved on this front.
We'll wait for the changes and then retest performance.
Thanks again,
Pauli
On Mon, 23 Nov 2015 10:18:27 PM Matt Caswell wrote:
>
> On 23/11/15 21:56, Paul Dale wrote:
> > Somewhat tangentially related to this is the h
> https://github.com/openssl/openssl/pull/451
> I'm not sure what the current status of this is though.
I've made several comments I think need to be addressed before we should merge
it.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.o
On 23/11/15 21:56, Paul Dale wrote:
> Somewhat tangentially related to this is the how thread locking in
> OpenSSL is slowing things up.
Alessandro has submitted an interesting patch to provide a much better
threading API. See:
https://github.com/openssl/openssl/pull/451
I'm not sure what the
On Mon, Nov 23, 2015 at 02:48:25PM -0600, Nico Williams wrote:
>
> I use this in an autoconf project (I know, OpenSSL doesn't use autoconf):
>
> dnl Thread local storage
> have___thread=no
> AC_MSG_CHECKING(for thread-local storage)
> AC_LINK_IFELSE([AC_LANG_SOURCE([
> static __thread i
Somewhat tangentially related to this is the how thread locking in OpenSSL is
slowing things up.
We've been doing some connection establishment performance analysis recently
and have discovered a lot of waiting on locks is occurring. By far the worst
culprit is CRYPTO_LOCK_EVP_PKEY in CRYPTO_a
On Mon, Nov 23, 2015 at 08:34:29PM +, Matt Caswell wrote:
> On 23/11/15 17:49, Nico Williams wrote:
> > On a slightly related note, I asked and Viktor tells me that fiber
> > stacks are allocated with malloc(). I would prefer that they were
> > allocated with mmap(), because then you get a gua
Dear Andy,
On Fri, Nov 20, 2015 at 10:45 PM, Andy Polyakov wrote:
>
> > The test example was provide by the authors of specification. There are
> > also examples in the document. May be it will be useful.
>
> We are apparently talking about slightly different things. Well, they
> are somewhat re
On 23/11/15 17:49, Nico Williams wrote:
> [Resend, with slight edits.]
>
> [Viktor asked me for my advice on this issue and bounced me the post
> that I'm following up to. -Nico]
>
> The summary of what I've to say is that making libcrypto and libssl need
> -lpthread is something that does re
On Mon, Nov 23, 2015 at 01:53:47AM +, Viktor Dukhovni wrote:
[NetBSD header commentary extracts:]
> /*
> * Use macros to rename many pthread functions to the corresponding
> * libc symbols which are either trivial/no-op stubs or the real
No renaming is necessary if one's link-editor and RT
[Resend, with slight edits.]
[Viktor asked me for my advice on this issue and bounced me the post
that I'm following up to. -Nico]
The summary of what I've to say is that making libcrypto and libssl need
-lpthread is something that does require discussion, as it will have
detrimental effects on
[Viktor asked me for my advice on this issue and bounced me the post
that I'm following up to. -Nico]
The summary of what I've to say is that making libcrypto and libssl need
-lpthread is something that does require discussion, as it will have
detrimental effects on some users. Personally, I th
I suspect that most “users” of OpenSSL are doing it indirectly through other
applications that use TLS (or crypto) functionality. Example: the Cisco
AnyConnect client is reportedly one of the most installed pieces of software
regardless of platform; it uses OpenSSL for TLS.
Taking those indirec
> ... Either way, we seem to
> agree that *replacing* sun with __sun is not right thing to do in SunOS
> 4 context. One can argue for sun || __sun, or one can argue in favour of
> reverting. My vote goes for latter, because original conditions [in
> e_os.h] do work adequately.
After closer look I
>> If you want distinguish Solaris, yes. But if you want to distinguish
>> specifically SunOS 4, 'sun' is guaranteed to do the job. Because
>> compiler that targets SunOS 4 *has to* have it. Either way, we seem to
>> agree that *replacing* sun with __sun is not right thing to do in SunOS
>> 4 conte
24 matches
Mail list logo
