Does BIO_read() behave differently on diff architectures?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Does BIO_read() behave differently on diff architectures?

OpenSSL - User mailing list
Hi Experts,

I am using openssl 1.0.2 

I recently moved my app from a PPC to x86 platform (application is compiled on the respective platform) where I met an issue with BIO_read(). 

I read a 20bytes of data using BIO_read like following..

int    res = BIO_read(bio, buf, 20);
char *ptr = buf;

The content that I send as input is a signed file content that I get from a different source. The issue is that the output 'buf' is not as expected on my x86. The behavior is different on different architectures. 

For e.g. on intel x86 platform I get the following output with additional 0xffffff padded.>> For me this is not the expected result. 
22,ffffff82,2b,28,06,09,2a,ffffff86,48,ffffff86,fffffff7,0d,02,09,02,ffffffa0,ffffff82,3b,12,30

This is what I was getting on my PPC platform which is as expected with the same app code.
22,82,2b,28,06,09,2a,86,48,86,f7,0d,02,09,02,a0,82,3b,12,30

Ofcourse, I need to further check on the source where/how the signed file was generated, but does anyone have any idea if BIO_read() has any specific handling with repsect to architectures?. I'd rule out the endianess factor as I would expect the entire byte order to be reversed if so. 

I print the above output using the following code. 
INFO( STR(" ..> Header@%02d: %02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,"
                                    "%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x",
                     ptr-buf, *(ptr+0),*(ptr+1),*(ptr+2),*(ptr+3),*(ptr+4),
                              *(ptr+5),*(ptr+6),*(ptr+7),*(ptr+8),*(ptr+9),
                              *(ptr+10),*(ptr+11),*(ptr+12),*(ptr+13),*(ptr+14),
                              *(ptr+15),*(ptr+16),*(ptr+17),*(ptr+18),*(ptr+19))); 


Reply | Threaded
Open this post in threaded view
|

RE: Does BIO_read() behave differently on diff architectures?

Lynch, Andrew

Hi,

 

Your issue is not with BIO_read(), but with the differing signedness of the char type on your two platforms.

 

On your PPC platform the char type defaults to unsigned, on your x86 platform it is signed.  The %x format expects an unsigned int, so on x86 the signed char values are being sign-extended to int which adds the ffffff to any values where the high bit is set (i.e. seen as negative).

 

One possible fix:  Change "char *ptr = buf;" to "unsigned char *ptr = buf;", then you should get the expected output.

Regards,

Andrew.

 

From: openssl-users [mailto:[hidden email]] On Behalf Of Venkata Veldanda via openssl-users
Sent: Friday, August 09, 2019 11:20 AM
To: [hidden email]
Subject: Does BIO_read() behave differently on diff architectures?

 

Hi Experts,

 

I am using openssl 1.0.2 

 

I recently moved my app from a PPC to x86 platform (application is compiled on the respective platform) where I met an issue with BIO_read(). 

 

I read a 20bytes of data using BIO_read like following..

 

int    res = BIO_read(bio, buf, 20);

char *ptr = buf;

 

The content that I send as input is a signed file content that I get from a different source. The issue is that the output 'buf' is not as expected on my x86. The behavior is different on different architectures. 

 

For e.g. on intel x86 platform I get the following output with additional 0xffffff padded.>> For me this is not the expected result. 

22,ffffff82,2b,28,06,09,2a,ffffff86,48,ffffff86,fffffff7,0d,02,09,02,ffffffa0,ffffff82,3b,12,30

 

This is what I was getting on my PPC platform which is as expected with the same app code.

22,82,2b,28,06,09,2a,86,48,86,f7,0d,02,09,02,a0,82,3b,12,30

 

Ofcourse, I need to further check on the source where/how the signed file was generated, but does anyone have any idea if BIO_read() has any specific handling with repsect to architectures?. I'd rule out the endianess factor as I would expect the entire byte order to be reversed if so. 

 

I print the above output using the following code. 

INFO( STR(" ..> Header@%02d: %02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,"

                                    "%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x",

                     ptr-buf, *(ptr+0),*(ptr+1),*(ptr+2),*(ptr+3),*(ptr+4),

                              *(ptr+5),*(ptr+6),*(ptr+7),*(ptr+8),*(ptr+9),

                              *(ptr+10),*(ptr+11),*(ptr+12),*(ptr+13),*(ptr+14),

                              *(ptr+15),*(ptr+16),*(ptr+17),*(ptr+18),*(ptr+19))); 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Does BIO_read() behave differently on diff architectures?

OpenSSL - User mailing list
@Andrew - Thanks for pointing that out. Indeed, that was the issue.




On Fri, Aug 9, 2019 at 6:18 PM +0530, "Lynch, Andrew" <[hidden email]> wrote:

Hi,

 

Your issue is not with BIO_read(), but with the differing signedness of the char type on your two platforms.

 

On your PPC platform the char type defaults to unsigned, on your x86 platform it is signed.  The %x format expects an unsigned int, so on x86 the signed char values are being sign-extended to int which adds the ffffff to any values where the high bit is set (i.e. seen as negative).

 

One possible fix:  Change "char *ptr = buf;" to "unsigned char *ptr = buf;", then you should get the expected output.

Regards,

Andrew.

 

From: openssl-users [mailto:[hidden email]] On Behalf Of Venkata Veldanda via openssl-users
Sent: Friday, August 09, 2019 11:20 AM
To: [hidden email]
Subject: Does BIO_read() behave differently on diff architectures?

 

Hi Experts,

 

I am using openssl 1.0.2 

 

I recently moved my app from a PPC to x86 platform (application is compiled on the respective platform) where I met an issue with BIO_read(). 

 

I read a 20bytes of data using BIO_read like following..

 

int    res = BIO_read(bio, buf, 20);

char *ptr = buf;

 

The content that I send as input is a signed file content that I get from a different source. The issue is that the output 'buf' is not as expected on my x86. The behavior is different on different architectures. 

 

For e.g. on intel x86 platform I get the following output with additional 0xffffff padded.>> For me this is not the expected result. 

22,ffffff82,2b,28,06,09,2a,ffffff86,48,ffffff86,fffffff7,0d,02,09,02,ffffffa0,ffffff82,3b,12,30

 

This is what I was getting on my PPC platform which is as expected with the same app code.

22,82,2b,28,06,09,2a,86,48,86,f7,0d,02,09,02,a0,82,3b,12,30

 

Ofcourse, I need to further check on the source where/how the signed file was generated, but does anyone have any idea if BIO_read() has any specific handling with repsect to architectures?. I'd rule out the endianess factor as I would expect the entire byte order to be reversed if so. 

 

I print the above output using the following code. 

INFO( STR(" ..> Header@%02d: %02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,"

                                    "%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x",

                     ptr-buf, *(ptr+0),*(ptr+1),*(ptr+2),*(ptr+3),*(ptr+4),

                              *(ptr+5),*(ptr+6),*(ptr+7),*(ptr+8),*(ptr+9),

                              *(ptr+10),*(ptr+11),*(ptr+12),*(ptr+13),*(ptr+14),

                              *(ptr+15),*(ptr+16),*(ptr+17),*(ptr+18),*(ptr+19)));