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

2016-06-17 Thread 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] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

2016-06-17 Thread 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 <r...@openssl.org>
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<https://www.openssl.org/docs/manmaster/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 #4568] Enhancement request: Capability vector accessor function for arm and ppc

2016-06-17 Thread 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 #4568] Enhancement request: Capability vector accessor function for arm and ppc

2016-06-15 Thread Loic Etienne 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<https://www.openssl.org/docs/manmaster/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




From: Loic Etienne
Sent: Wednesday, June 15, 2016 10:17:17 AM
To: r...@openssl.org
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability 
vector accessor function for arm and ppc


Identifying the bits relevant to openssl for each architecture and making them 
available through architecture-independent functions (getter and setters) would 
be very convenient, indeed. At the risk that future architectures do not fit 
into the pattern defined today.


If this approach is implemented, I suggest a copy of original capability vector 
to be kept, for the setter to fail if a bit is tentatively set on an unsuitable 
processor (otherwise, subsequent cryptographic operations affected by the bit 
in question would fail anyway). Thus a setter could return the previous value 
(0 or 1) on success, and -1 on failure.


I think that implementing the architecture specific functions suggested in this 
ticket is easy and already useful. Defining architecture-independent functions 
probably requires more hard thinking, and could be done in a later step.


From: Salz, Rich via RT <r...@openssl.org>
Sent: Tuesday, June 14, 2016 6:41:02 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

Doesn't it make more sense to have a single API that returns the 
platform-specific flags?


--
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 #4568] Enhancement request: Capability vector accessor function for arm and ppc

2016-06-15 Thread Loic Etienne via RT 
Identifying the bits relevant to openssl for each architecture and making them 
available through architecture-independent functions (getter and setters) would 
be very convenient, indeed. At the risk that future architectures do not fit 
into the pattern defined today.


If this approach is implemented, I suggest a copy of original capability vector 
to be kept, for the setter to fail if a bit is tentatively set on an unsuitable 
processor (otherwise, subsequent cryptographic operations affected by the bit 
in question would fail anyway). Thus a setter could return the previous value 
(0 or 1) on success, and -1 on failure.


I think that implementing the architecture specific functions suggested in this 
ticket is easy and already useful. Defining architecture-independent functions 
probably requires more hard thinking, and could be done in a later step.


From: Salz, Rich via RT <r...@openssl.org>
Sent: Tuesday, June 14, 2016 6:41:02 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

Doesn't it make more sense to have a single API that returns the 
platform-specific flags?


--
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 #4568] Enhancement request: Capability vector accessor function for arm and ppc

2016-06-14 Thread Salz, Rich via RT 
Doesn't it make more sense to have a single API that returns the 
platform-specific flags?


-- 
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