Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

[Andy Polyakov via RT]

> Two more observations.
> 
> OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not 
> fitting into the expected integer size being zeroed. I do not know if it is 
> practically relevant, but it is strange that a read has side effects. It 
> would be a good reason for dedicated, architecture independent setters and 
> getters.
> 
> The documentation 
> (https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap.html)
>  says:
> unsigned int *OPENSSL_ia32cap_loc(void)
> it should say:
> unsigned long *OPENSSL_ia32cap_loc(void)
> like in openssl-1.0.2h/crypto/crypto.h

No. It was 'int' upon initial release of 1.0.0 and has to remain same
throughout all 1.0.x releases. Mentioned zeroing also has everything to
do with it, i.e. with maintaining backward compatible behaviour within
line of binary compatible releases. Rationale is that application should
be given same control throughout *all* 1.0.x releases. Or in other words
*if* application chooses to manipulate capability vector it will have
same granularity as in 1.0.0.

Note that in master branch words beyond 1st are not zeroed, don't have
to. One can argue that it could be re-declared as long in master. Well,
that declaration is shared between 32- and 64-bit builds, and having
long would introduce ambiguity. Yes, one can argue that it's already
ambiguous since OPENSSL_ia32cap.pod effectively describes 64-bit values.
One has to recognize that original reason for exposing
OPENSS_ia32cap_loc() was that binary *could* end up in situation when
processor capability vector doesn't match OS capability. More
specifically cpuid could say "this is SSE2-capable processor" but
attempt to perform SSE2 operation on %xmm register could trigger invalid
instruction exception nevertheless. Note that this can't happen with
later register extensions like %ymm and %zmm, because one can detect
even OS support. But back to OPENSSL_ia32cap_loc in master context.
Actually one can as well proclaim that such old systems are no longer
supported and omit OPENSSL_ia32cap_loc altogether. Naturally leaving
setting environment variable alone as the only way to affect result of
capability detection. This is really meant to be used for overly
specific testing and debugging. And for this reason it doesn't really
have to be pretty...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

[Andy Polyakov via RT]

> Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is
> hidden, I still have to try over environment variables, which are not
> as flexible for arm as for x86).
> 
> 
> Anyway, it would be helpful to exclude hardware aes instructions at
> compile-time:
> 
> 1) Runtime checking is error prone (openssl and code using openssl
> evolve)

How is it error-prone? Or more specifically have you ever ran into
situation when it was *detected* incorrectly so that it resulted in
application *crash*?

> 2) Proving to a customer (or convincing myself) that no such
> instructions will ever be used is much easier if such instructions
> are not even compiled

Then why just aes instructions? There is a number of code-paths that are
selected at run-time that are dependent on processor capability
detection. If aes instructions are considered "too fancy", there is no
reason to consider *any* alternative code path as less "fancy".

> I guess that some of the already existing no-xxx configuration
> options have been introduced for similar reasons.

no-asm.

I'd argue that this ticket can be closed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends

[Matt Caswell via RT]

On 14/06/16 21:30, David Benjamin via RT wrote:
> For OpenSSL master, I believe it'd also work to add an s->rbio != s->wbio
> check to SSL_set_rbio, but I think those are worse semantics for
> SSL_set_{rbio,wbio}. They are new APIs, so, before it's too late, give them
> clear semantics like "SSL_set_rbio takes ownership of its argument",
> consistent with "set0" functions, rather than a mix of "set0" and "set1".

These look like good changes. I'm wondering whether we should actually
rename SSL_set_rbio() and SSL_set_wbio() to SSL_set0_rbio() and
SSL_set0_wbio() - especially since they are new to 1.1.0 so not released
yet.

*Possibly* we could also rename SSL_set_bio() to SSL_set0_bio() with a
deprecated compatibility macro.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4456] Fedora 1, i386: error: field `next_timeout` has incomplete type

[Matt Caswell via RT]

Jeff has confirmed that this issue has been fixed in latest master. Closing
this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4456
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4565] Fatal error: Command failed for target `link_shlib.solaris'

[Matt Caswell via RT]

This is fixed in latest master. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4565
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

[Loic Etienne via RT]

Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is hidden, I 
still have to try over environment variables, which are not as flexible for arm 
as for x86).


Anyway, it would be helpful to exclude hardware aes instructions at 
compile-time:

1) Runtime checking is error prone (openssl and code using openssl evolve)

2) Proving to a customer (or convincing myself) that no such instructions will 
ever be used is much easier if such instructions are not even compiled


I guess that some of the already existing no-xxx configuration options have 
been introduced for similar reasons.





From: Rich Salz via RT 
Sent: Thursday, June 16, 2016 8:15:48 PM
To: Loic Etienne
Cc: openssl-dev@openssl.org
Subject: [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

On Tue Jun 14 15:43:26 2016, loic.etie...@qnective.com wrote:
> Define a configuration option no-hw-aes.
> No aes processor instruction should be compiled if one of the
> configuration options no-hw or no-hw-aes is given.

Why doesn't existing run-time checking work for you?

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Mick Saxton via RT]

Perhaps we should consider if there are any negative consequences to my 
solution?
It does work.

I am trying really hard to get contention but I am only seeing this problem in 
about 1 out of 100,000 successful TLSv1.2 connections
On a heavily congested network.
I require three machines to just to run the test that causes the failure.

All we are trying to do is get a random number – surely getting a slightly less 
random number is better than crashing?
It could be that the problematic instances were going to disconnect anyway due 
to TCP/IP problems.



Rather than my previous suggestion – I am now suggesting:-

So in ssleay_rand_add

If ( j-k>0 ) MD_Update(, &(state[st_idx]), j – k);

And a similar fix in ssleay_rand_bytes


This also avoids adding zero bytes to the hash – which it does quite often.




From: Salz, Rich via RT [mailto:r...@openssl.org]
Sent: 17 June 2016 18:39
To: Mick Saxton
Cc: openssl-dev@openssl.org
Subject: RE: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

Sending mail re-opens the ticket.

Rats, wish it was fixed. Going to need something to more easily reproduce it, I 
guess.

--
Ticket here: 
http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted




Legal Notice: This email is intended only for the person(s) to whom it is 
addressed. If you are not an intended recipient and have received this message 
in error, please notify the sender immediately by replying to this email or 
calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any 
attachments may be privileged and/or confidential. The unauthorized use, 
disclosure, copying or printing of any information it contains is strictly 
prohibited. The opinions expressed in this email are those of the author and do 
not necessarily represent the views of 1E Ltd. Nothing in this email will 
operate to bind 1E to any order or other contract.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Salz, Rich via RT]

Sending mail re-opens the ticket.

Rats, wish it was fixed.  Going to need something to more easily reproduce it, 
I guess. 

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Matt Caswell via RT]

On 17/06/16 19:43, Mick Saxton via RT wrote:
> Perhaps we should consider if there are any negative consequences to my 
> solution?
> It does work.
> 
> I am trying really hard to get contention but I am only seeing this problem 
> in about 1 out of 100,000 successful TLSv1.2 connections
> On a heavily congested network.
> I require three machines to just to run the test that causes the failure.
> 
> All we are trying to do is get a random number – surely getting a slightly 
> less random number is better than crashing?
> It could be that the problematic instances were going to disconnect anyway 
> due to TCP/IP problems.
> 

I think we need to try instrumenting the code to see if we can get some
more information out. I will try and pull something together - but it
might be Monday before I get the opportunity.

Matt


> 
> 
> Rather than my previous suggestion – I am now suggesting:-
> 
> So in ssleay_rand_add
> 
> If ( j-k>0 ) MD_Update(, &(state[st_idx]), j – k);
> 
> And a similar fix in ssleay_rand_bytes
> 
> 
> This also avoids adding zero bytes to the hash – which it does quite often.
> 
> 
> 
> 
> From: Salz, Rich via RT [mailto:r...@openssl.org]
> Sent: 17 June 2016 18:39
> To: Mick Saxton
> Cc: openssl-dev@openssl.org
> Subject: RE: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
> 
> Sending mail re-opens the ticket.
> 
> Rats, wish it was fixed. Going to need something to more easily reproduce it, 
> I guess.
> 
> --
> Ticket here: 
> http://rt.openssl.org/Ticket/Display.html?id=4545
> Please log in as guest with password guest if prompted
> 
> 
> 
> 
> Legal Notice: This email is intended only for the person(s) to whom it is 
> addressed. If you are not an intended recipient and have received this 
> message in error, please notify the sender immediately by replying to this 
> email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email 
> and any attachments may be privileged and/or confidential. The unauthorized 
> use, disclosure, copying or printing of any information it contains is 
> strictly prohibited. The opinions expressed in this email are those of the 
> author and do not necessarily represent the views of 1E Ltd. Nothing in this 
> email will operate to bind 1E to any order or other contract.
> 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Mick Saxton via RT]

Hi Rich

Many thanks for doing that – unfortunately it is not the whole fix.
I checked out the latest v1.0.2i-dev and built that but I still get the crash.
I know the ticket is now “closed” – do you need me to reopen it?

I am still convinced that I don’t get it with the “master” build – but that is 
v1.1 and even the build process is significantly different on Windows.
One thing that I did notice is that CPU load seems lower on the v1.1 build 
which would be really great/
.. but it may be making this problem less obvious (frequent).

Thanks Mick

From: Rich Salz via RT [mailto:r...@openssl.org]
Sent: 16 June 2016 19:41
To: Mick Saxton
Cc: openssl-dev@openssl.org
Subject: [openssl.org #4545] Crash in crypto/rand/md_rand.c

commit d0a2bb1f94e26c2e7b44676e9b739c23ad763a79 just pushed to 1.0.2
closing ticket.

--
Ticket here: 
http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted




Legal Notice: This email is intended only for the person(s) to whom it is 
addressed. If you are not an intended recipient and have received this message 
in error, please notify the sender immediately by replying to this email or 
calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any 
attachments may be privileged and/or confidential. The unauthorized use, 
disclosure, copying or printing of any information it contains is strictly 
prohibited. The opinions expressed in this email are those of the author and do 
not necessarily represent the views of 1E Ltd. Nothing in this email will 
operate to bind 1E to any order or other contract.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Matt Caswell via RT]

On 17/06/16 20:56, Matt Caswell via RT wrote:
> 
> 
> On 17/06/16 19:43, Mick Saxton via RT wrote:
>> Perhaps we should consider if there are any negative consequences to my 
>> solution?
>> It does work.
>>
>> I am trying really hard to get contention but I am only seeing this problem 
>> in about 1 out of 100,000 successful TLSv1.2 connections
>> On a heavily congested network.
>> I require three machines to just to run the test that causes the failure.
>>
>> All we are trying to do is get a random number – surely getting a slightly 
>> less random number is better than crashing?
>> It could be that the problematic instances were going to disconnect anyway 
>> due to TCP/IP problems.
>>
> 
> I think we need to try instrumenting the code to see if we can get some
> more information out. I will try and pull something together - but it
> might be Monday before I get the opportunity.

I got to it quicker than I thought. Please see attached patch. Can you
apply it to the latest git 1.0.2 version and re-run your test (capture
stderr output). I'd like to see what we get.

Also is this 32-bit or 64-bit Windows? Are you able to share your
locking callback implementation?

Thanks

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

>From 71bec261502b5ad7ad3bb8ad39b069c49d42da5f Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Fri, 17 Jun 2016 23:57:13 +0100
Subject: [PATCH] Add some instrumentation to md_rand.c

---
 crypto/rand/md_rand.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/crypto/rand/md_rand.c b/crypto/rand/md_rand.c
index bd76e23..7c2931e 100644
--- a/crypto/rand/md_rand.c
+++ b/crypto/rand/md_rand.c
@@ -270,6 +270,19 @@ static void ssleay_rand_add(const void *buf, int num, double add)
 MD_Update(, local_md, MD_DIGEST_LENGTH);
 k = (st_idx + j) - STATE_SIZE;
 if (k > 0) {
+if (j - k < 0) {
+CRYPTO_THREADID thisthreadid;
+CRYPTO_THREADID_current();
+fprintf(stderr, "MD_RAND ERROR: ssleay_rand_add: k == %d, "
+"j == %d, st_idx == %d, state_num == %ld, do_not_lock %d, "
+"crypto_lock_rand == %d, locking_threadid == %lu, "
+"thisthreadid == %lu\n",
+k, j, st_idx, state_num, do_not_lock, crypto_lock_rand,
+CRYPTO_THREADID_hash(_threadid),
+CRYPTO_THREADID_hash());
+fflush(stderr);
+abort();
+}
 MD_Update(, &(state[st_idx]), j - k);
 MD_Update(, &(state[0]), k);
 } else
@@ -492,6 +505,19 @@ int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo, int lock)
 
 k = (st_idx + MD_DIGEST_LENGTH / 2) - st_num;
 if (k > 0) {
+if (MD_DIGEST_LENGTH / 2 - k < 0) {
+CRYPTO_THREADID thisthreadid;
+CRYPTO_THREADID_current();
+fprintf(stderr, "MD_RAND ERROR: ssleay_rand_bytes: k == %d, "
+"st_idx == %ld, st_num == %ld, lock %d, "
+"crypto_lock_rand == %d, locking_threadid == %lu, "
+"thisthreadid == %lu\n",
+k, st_idx, st_num, lock, crypto_lock_rand,
+CRYPTO_THREADID_hash(_threadid),
+CRYPTO_THREADID_hash());
+fflush(stderr);
+abort();
+}
 MD_Update(, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k);
 MD_Update(, &(state[0]), k);
 } else
-- 
2.7.4

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends

[David Benjamin via RT]

On Fri, Jun 17, 2016 at 8:48 AM Matt Caswell via RT  wrote:

>
>
> On 14/06/16 21:30, David Benjamin via RT wrote:
> > For OpenSSL master, I believe it'd also work to add an s->rbio != s->wbio
> > check to SSL_set_rbio, but I think those are worse semantics for
> > SSL_set_{rbio,wbio}. They are new APIs, so, before it's too late, give
> them
> > clear semantics like "SSL_set_rbio takes ownership of its argument",
> > consistent with "set0" functions, rather than a mix of "set0" and "set1".
>
> These look like good changes. I'm wondering whether we should actually
> rename SSL_set_rbio() and SSL_set_wbio() to SSL_set0_rbio() and
> SSL_set0_wbio() - especially since they are new to 1.1.0 so not released
> yet.
>

Sounds good to me.


> *Possibly* we could also rename SSL_set_bio() to SSL_set0_bio() with a
> deprecated compatibility macro.
>

I dunno, SSL_set_bio is kind of weird all around. :-) I suppose it is
closer to a set0 than a set1, but set0 doesn't typically have all these
no-op cases around taking ownership and such.


> Matt
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

[Andy Polyakov via RT]

> Thanks for the explanations.
> 
> In the code I am working with, I see:
> $ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c
> unsigned long *OPENSSL_ia32cap_loc(void)
> 
> You may want to verify it.

Right! Sorry about confusion, my bad! It was long in 1.0.x and in became
int in master. Anyway, point that it can't be changed in last-digit
release remains, as well as reason for zeroing of most significant
word[s] upon reference to OPENSSL_ia32cap_loc in 1.0.x. Yes, it's a bug
in 1.0.2 OPENSSL_ia32cap.pod.

> I happen to be using features introduced for testing and debugging,
> without knowing it. For debatable reasons, but it is my assignment to
> avoid aes-ni instructions. Maybe I will have to adapt openssl
> slightly, for instance making the capability vectors global (instead
> of hidden); or not to use the EVP interfaces.

I suppose reply in RT#4570 applies even here.

And just to clarify, "meant to be used for overly specific testing and
debugging [hence doesn't have to be pretty]" naturally applies to all
platforms with run-time switches.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Latest Open SSL and old FIP module

[Steve Marquess]

On 06/17/2016 07:48 AM, Alibek Joraev wrote:
> Currently, I use 1.0.1 series (with current one being 1.0.1t) of OpenSSL
> with OpenSSL FIPS module version 2.0.2.
> as 1.0.1 version nears its long term support, I would like to upgrade to
> OpenSSL 1.0.2h, but keep existing 2.0.2 FIPS module.
> 
> I can see that latest OpenSSL 1.0.2h is posted together with FIPS module
> 2.0.12.
> 
> is OpenSSL 1.0.2h compatible with older FIPS modules? or do I also have
> to upgrade to newest FIPS module?
> 
> ...

All revisions of OpenSSL 1.0.2 are compatible with all revisions of the
OpenSSL FIPS Object Module 2.0. So you can keep your existing 2.0.2 FIPS
module and upgrade from 1.0.1 to 1.0.2.

Note that in general there is no advantage to upgrading to newer FIPS
module revisions (e.g. from 2.0.2 to 2.0.12) as in general we're not
allowed to do bugfixes or feature enhancements; the newer revisions are
not "better" in the sense usually expected for open source software. The
exception to that statement is a feature enhancement of sorts, the
removal of Dual EC DRBG that occurred at 2.0.6. If completely removing
Dual EC DRBG matters to you[1] then you can upgrade to any revision
2.0.6+, all of which will work for any platform supported by 2.0.2. If
you're upgrading you might as well go straight to 2.0.12[2], while
realizing you'll always be a revision or three behind (2.0.13 is in the
works).

Also please note that at some point you'll want or need to upgrade to
OpenSSL 1.1, for which no FIPS 140 support is currently available or
planned at anything beyond the wistful thinking stage.

-Steve M.

[1] why you might: http://veridicalsystems.com/blog/immutability-of-fips/

[2] Unless, sigh, your platform(s) of interest are listed only for the
#1747 or #2473 validations which stop at revision 2.0.10, in which case
that's the newest FIPS module revision with the magical pixie dust of
FIPS righteousness, even though the latest revision (2.0.12)
functionally supports all platforms for all validations.


-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

[Loic Etienne via RT]

Thanks for the explanations.

In the code I am working with, I see:
$ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c
unsigned long *OPENSSL_ia32cap_loc(void)

You may want to verify it.

I happen to be using features introduced for testing and debugging, without 
knowing it. For debatable reasons, but it is my assignment to avoid aes-ni 
instructions. Maybe I will have to adapt openssl slightly, for instance making 
the capability vectors global (instead of hidden); or not to use the EVP 
interfaces.




From: Andy Polyakov via RT 
Sent: Friday, June 17, 2016 3:32:19 PM
To: Loic Etienne
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability 
vector accessor function for arm and ppc

> Two more observations.
>
> OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not 
> fitting into the expected integer size being zeroed. I do not know if it is 
> practically relevant, but it is strange that a read has side effects. It 
> would be a good reason for dedicated, architecture independent setters and 
> getters.
>
> The documentation 
> (https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap.html)
>  says:
> unsigned int *OPENSSL_ia32cap_loc(void)
> it should say:
> unsigned long *OPENSSL_ia32cap_loc(void)
> like in openssl-1.0.2h/crypto/crypto.h

No. It was 'int' upon initial release of 1.0.0 and has to remain same
throughout all 1.0.x releases. Mentioned zeroing also has everything to
do with it, i.e. with maintaining backward compatible behaviour within
line of binary compatible releases. Rationale is that application should
be given same control throughout *all* 1.0.x releases. Or in other words
*if* application chooses to manipulate capability vector it will have
same granularity as in 1.0.0.

Note that in master branch words beyond 1st are not zeroed, don't have
to. One can argue that it could be re-declared as long in master. Well,
that declaration is shared between 32- and 64-bit builds, and having
long would introduce ambiguity. Yes, one can argue that it's already
ambiguous since OPENSSL_ia32cap.pod effectively describes 64-bit values.
One has to recognize that original reason for exposing
OPENSS_ia32cap_loc() was that binary *could* end up in situation when
processor capability vector doesn't match OS capability. More
specifically cpuid could say "this is SSE2-capable processor" but
attempt to perform SSE2 operation on %xmm register could trigger invalid
instruction exception nevertheless. Note that this can't happen with
later register extensions like %ymm and %zmm, because one can detect
even OS support. But back to OPENSSL_ia32cap_loc in master context.
Actually one can as well proclaim that such old systems are no longer
supported and omit OPENSSL_ia32cap_loc altogether. Naturally leaving
setting environment variable alone as the only way to affect result of
capability detection. This is really meant to be used for overly
specific testing and debugging. And for this reason it doesn't really
have to be pretty...


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

[Loic Etienne via RT]

Your technical arguments are sound, indeed.


From: Andy Polyakov via RT 
Sent: Friday, June 17, 2016 5:13:50 PM
To: Loic Etienne
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4570] Enhancement request: 
Configuration option no-hw-aes

> 1) Openssl works correctly (no crash, correct detection), as far as I
> can judge. By error-prone I mean, very defensively, that I (or
> others) could make a mistake, or that future versions of openssl
> could not work exactly the same way.

Well, this is effectively argument in favour of denying the control over
capability vector[s]. I mean following this logic you should have no way
to affect the outcome, not programmatically nor through environment
variable. Because user can screw it up :-)

> 2) I would agree with your argumentation. But some customers want
> this anti-feature (no aes-ni), arguing that exactly those instruction
> are not trustworthy. And the customer is always right.

And following this logic no instruction is trustworthy, be it aesenc or
any other, say pshufb used in bsaes, or even better example
multiplication used in e.g. RSA. There is exactly as much proof of
correctness of either. If you are concerned about using any specific
instruction you should have bigger concern about using that processor at
all. Or in other words if trusting a processor manufacturer is
problematic, then you should manufacture own processor, with or without
AES-NI, which OpenSSL will dutifully detect and abstain from calling
procedures that would crash...

I'd argue that even this ticket can be closed with "use no-asm" resolution.


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

[Loic Etienne via RT]

1) Openssl works correctly (no crash, correct detection), as far as I can 
judge. By error-prone I mean, very defensively, that I (or others) could make a 
mistake, or that future versions of openssl could not work exactly the same way.


2) I would agree with your argumentation. But some customers want this 
anti-feature (no aes-ni), arguing that exactly those instruction are not 
trustworthy. And the customer is always right.


There are already two similar options (which inspired the suggested no-hw-aes): 
no-hw, no-engines. But none of them excludes aes instructions, which is a bit 
misleading. Perhaps the documentation could be more explicit about that.


no-asm is a possibility, indeed. At the price of the bit-slicing aes 
implementation and perhaps of some performance. A trade-off.


But I understand that openssl cannot consider each and every wish. Such a 
no-hw-aes configuration option may be useful (at least for selling) to many 
other people, or not. Up to your judgment.


Thanks for your attention anyway.



From: Andy Polyakov via RT 
Sent: Friday, June 17, 2016 2:46:41 PM
To: Loic Etienne
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4570] Enhancement request: 
Configuration option no-hw-aes

> Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is
> hidden, I still have to try over environment variables, which are not
> as flexible for arm as for x86).
>
>
> Anyway, it would be helpful to exclude hardware aes instructions at
> compile-time:
>
> 1) Runtime checking is error prone (openssl and code using openssl
> evolve)

How is it error-prone? Or more specifically have you ever ran into
situation when it was *detected* incorrectly so that it resulted in
application *crash*?

> 2) Proving to a customer (or convincing myself) that no such
> instructions will ever be used is much easier if such instructions
> are not even compiled

Then why just aes instructions? There is a number of code-paths that are
selected at run-time that are dependent on processor capability
detection. If aes instructions are considered "too fancy", there is no
reason to consider *any* alternative code path as less "fancy".

> I guess that some of the already existing no-xxx configuration
> options have been introduced for similar reasons.

no-asm.

I'd argue that this ticket can be closed.


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

[Andy Polyakov via RT]

> 1) Openssl works correctly (no crash, correct detection), as far as I
> can judge. By error-prone I mean, very defensively, that I (or
> others) could make a mistake, or that future versions of openssl
> could not work exactly the same way.

Well, this is effectively argument in favour of denying the control over
capability vector[s]. I mean following this logic you should have no way
to affect the outcome, not programmatically nor through environment
variable. Because user can screw it up :-)

> 2) I would agree with your argumentation. But some customers want
> this anti-feature (no aes-ni), arguing that exactly those instruction
> are not trustworthy. And the customer is always right.

And following this logic no instruction is trustworthy, be it aesenc or
any other, say pshufb used in bsaes, or even better example
multiplication used in e.g. RSA. There is exactly as much proof of
correctness of either. If you are concerned about using any specific
instruction you should have bigger concern about using that processor at
all. Or in other words if trusting a processor manufacturer is
problematic, then you should manufacture own processor, with or without
AES-NI, which OpenSSL will dutifully detect and abstain from calling
procedures that would crash...

I'd argue that even this ticket can be closed with "use no-asm" resolution.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev