headers
Kyle Hamilton | 1 Dec 2007 02:21
Picon

Re: OpenSSL FIPS Object Module v1.2

On Nov 30, 2007 11:33 AM, Steve Marquess <marquess <at> oss-institute.org> wrote:
> Brad House wrote:
> >> Brad, sorry, I didn't mean to come across as negative.  The point I was
> >> trying to make is that once a validation starts I can't afford to delay
> >> it to deal with problems that are discovered in the already frozen
> >> baseline, unless those problems are critical to the requirements of the
> >> paying sponsors.  Hence we don't solicit general public input for
> >> in-process validations.  ...
> > Yes, that is understandable.  Any code going through validation at that
> > time cannot be touched.  I think what Kyle asked for was prior to the
> > next validation starting, a 2-week window where people could provide
> > patches.  Basically a 'last-call', or at least some projected timelines
> > for when it would be submitted so we know if the code is 'close-to-final'
> > before we try to provide patches (at least portability patches as is
> > my selfish concern).

...basically, yes.  I don't particularly want in-validation input
capability, since (as Steve M points out) it's pointless.  However, I
am honestly annoyed that there have been two validation cycles past
without (still!) a working FIPS-validated module for the Intel Mac.  I
know that at least HPUX64 had the same issue (I know I've got the tag
wrong, but you know to which I refer).  This... well, honestly
violates my sensibilities.

I just want to have the opportunity to know that what is submitted
will actually run on the platform I must use.

> Well, a single two-week window is reasonable.  In thinking through the
> issue more I realize there is another reason I've not been anxious to
> solicit patches form the whole world.  The deadlines in the validation
(Continue reading)

Permalink | Reply | 9 comments |
headers
Guenter Knauf via RT | 1 Dec 2007 02:26
Picon
Favicon

Re: [openssl.org #1611] [PATCH] NetWare platform OpenSSL 0.9.8g

Hi,
I've now updated the patch to apply cleanly against recent code:
openssl-0.9.8-stable-SNAP-20071130.tar.gz

I will also try to follow the dev list if any questions regarding
this patch may come up...

The new patch can be found here (also attached):
http://194.242.35.79/downloads/openssl/netware-openssl-0.9.8-stable-SNAP-20071130.diff

thanks!

Guenter.
Attachment (netware-openssl-0.9.8-stable-SNAP-20071130.diff): application/octet-stream, 62 KiB
Permalink | Reply | 0 comments |
headers
Guenter Knauf | 1 Dec 2007 22:57
Picon

Re: [PATCH] NetWare platform

Hi all,
>> but when using the CodeWarrior assembler then there's still one file
>> broken:

>> mwasmnlm -maxerrors 20 -o crypto/rc4/asm/r4-nw.o crypto/rc4/asm/r4-nw.asm
>> ### mwasmnlm Assembler:
>> #    File: crypto\rc4\asm\r4-nw.asm
>> # ---------------------------------
>> #     112:  lea esi,BYTE PTR [1+esi]
>> #   Error:          ^^^^^^^^^^^^^^^^
>> #   Invalid operand size
>> ### mwasmnlm Driver Error:
>> #   The tool did not produce any output while compiling the file
>> #   'crypto\rc4\asm\r4-nw.asm'

>> Errors caused tool to abort.
> ok, I think I found the place were to fix this:

> --- rc4-586.pl.orig	Thu Apr 26 22:00:56 2007
> +++ rc4-586.pl	Mon Nov 26 21:56:37 2007
>  <at>  <at>  -143,7 +143,7  <at>  <at> 
>  		&movz	($ty,&BP(0,$dat,$ty));
>  		&add	(&LB($xx),1);
>  		&xor	(&LB($ty),&BP(0,$inp));
> -		&lea	($inp,&BP(1,$inp));
> +		&lea	($inp,&DWP(1,$inp));
>  		&movz	($tx,&BP(0,$dat,$xx));
>  		&cmp	($inp,&wparam(1));
>  		&mov	(&BP(-1,$out,$inp),&LB($ty));
(Continue reading)

Permalink | Reply | 13 comments |
headers
Andy Polyakov | 2 Dec 2007 17:27
Picon
Picon

Re: [PATCH] NetWare platform

> I've still another problem with CodeWarrior Assembler in the ripemd asm code;
> with the tests it crashes while executing the command:
> openssl2 verify -CAfile \openssl\test_out\cert.tmp /openssl/certs/RegTP-5R.pem

Could you define "crashes"? Does application exit with an error code or
does application abnormally terminate so that OS offers to or does
create a core dump (or whatever it's called in NetWare)?

> When I compile with nasm all works fine....

Does it mean that the C code in these two cases is compiled with same
compiler and same compiler flags? In other words can you confirm that
replacing single object file, one compiled with nasm with one compiled
with metrowerks, triggers the fault?

> here are the asm files which get generated from the perlasm stuff:
> 
> asm code for NASM (working):
> http://www.gknw.net/test/openssl/0.9.8-stable/nasm/rm-nw.asm
> object code disassembled with ndisasm:

Output seems to be 16-bit and cover whole file (as opposite to
disassembling executable segment only). In other words it's pretty
worthless. Could you see you ndisasm manual and look for 32-bit flag and
"disassemble code only." Former is absolutely crucial to use, presuming
that it will synchronize at same instruction early enough. Please
regenerate disassembler listings. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
(Continue reading)

Permalink | Reply | 12 comments |
headers
Andy Polyakov | 2 Dec 2007 21:29
Picon
Picon

Re: [PATCH] NetWare platform

>> I've still another problem with CodeWarrior Assembler in the ripemd asm code;
>> with the tests it crashes while executing the command:
>> openssl2 verify -CAfile \openssl\test_out\cert.tmp /openssl/certs/RegTP-5R.pem
> 
> Could you define "crashes"? Does application exit with an error code or
> does application abnormally terminate so that OS offers to or does
> create a core dump (or whatever it's called in NetWare)?

I assume ABEND.LOG is answer to this question...

>> When I compile with nasm all works fine....
> 
> Does it mean that the C code in these two cases is compiled with same
> compiler and same compiler flags? In other words can you confirm that
> replacing single object file, one compiled with nasm with one compiled
> with metrowerks, triggers the fault?

But you still have to confirm that the fault is actually triggered by
metrowerks assembler module. Trouble is that given the crash dump one
would rather suspect compiler bug than module in question.

On related note question is what prevents you from always using nasm? Or
rather do we actually need to support for metrowerks assembler?
Basically if there is one working configuration for netware, what do we
need second one for?

Furthermore. Most recent assembler modules detect CPU capabilities and
pick most optimal code path. It's appropriate to enable support for this
too. And given above question wouldn't it be easier to tinker with
single target;-)
(Continue reading)

Permalink | Reply | 7 comments |
headers
Andy Polyakov | 2 Dec 2007 22:26
Picon
Picon

Re: OpenSSL FIPS Object Module v1.2

> However, I
> am honestly annoyed that there have been two validation cycles past
> without (still!) a working FIPS-validated module for the Intel Mac.

What is this statement based on? Intel Mac support was added and tested
 prior second submission. Though it's limited to 32 bits... Because
64-bit capable hardware was not available at that point... A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 1 comment |
headers
Brad House | 2 Dec 2007 23:34
Favicon

Re: OpenSSL FIPS Object Module v1.2

>> However, I
>> am honestly annoyed that there have been two validation cycles past
>> without (still!) a working FIPS-validated module for the Intel Mac.
> 
> What is this statement based on? Intel Mac support was added and tested
>  prior second submission. Though it's limited to 32 bits... Because
> 64-bit capable hardware was not available at that point... A.

I know where he's coming from on that one, I couldn't get fips-1.1.1
to work on Intel Mac...  I think the first issue was that it was setting
-DB_ENDIAN in the cflags when you run ./config fips:
$ ./config fips
Operating system: i386-apple-darwinDarwin Kernel Version 9.1.0: Wed Oct
31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386
Configuring for darwin-i386-cc
Configuring for darwin-i386-cc
IsWindows=0
CC            =cc
CFLAG         =-DOPENSSL_SYSNAME_MACOSX -DOPENSSL_THREADS -D_REENTRANT
-DOPENSSL_NO_KRB5 -O3 -fomit-frame-pointer -fno-common -DB_ENDIAN

That's obviously not right for i386 and _does_ cause tests to fail.

Then, when you "illegally" fix that in Configure, the make install
fails (at least on Leopard with XCode 3) starting with:
make[3]: Nothing to be done for `all'.
exdel=""; \
        for i in ../crypto/aes/aes_cbc.o ../crypto/aes/aes_cfb.o
../crypto/aes/aes_ecb.o ../crypto/aes/aes_ofb.o
../crypto/asn1/a_bitstr.o ../crypto/asn1/a_bytes.o
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Marquess | 3 Dec 2007 01:31
Favicon

Re: OpenSSL FIPS Object Module v1.2

Kyle Hamilton wrote:
> ...
>>> Yes, that is understandable.  Any code going through validation at that
>>> time cannot be touched.  I think what Kyle asked for was prior to the
>>> next validation starting, a 2-week window where people could provide
>>> patches.  Basically a 'last-call', or at least some projected timelines
>>> for when it would be submitted so we know if the code is 'close-to-final'
>>> before we try to provide patches (at least portability patches as is
>>> my selfish concern).
>>>       
>
> ...basically, yes.  I don't particularly want in-validation input
> capability, since (as Steve M points out) it's pointless.  However, I
> am honestly annoyed that there have been two validation cycles past
> without (still!) a working FIPS-validated module for the Intel Mac.  I
> know that at least HPUX64 had the same issue (I know I've got the tag
> wrong, but you know to which I refer).  This... well, honestly
> violates my sensibilities.
>   
I know that feeling well.  My sensibilities are regularly violated when
working FIPS 140 issues :-)
> I just want to have the opportunity to know that what is submitted
> will actually run on the platform I must use.
>   
You best approach is to report problems (or provide patches) for the
head of OpenSSL-fips-0_9_8-stable.  That's where we'll start from when
and it there's another validation.
> ...
>
> Huh.  You've just basically admitted that you have given up having any
(Continue reading)

Permalink | Reply | 6 comments |
headers
Guenter Knauf | 3 Dec 2007 03:16
Picon

Re: [PATCH] NetWare platform

Hi Andy,
> Could you define "crashes"? Does application exit with an error code or
> does application abnormally terminate so that OS offers to or does
> create a core dump (or whatever it's called in NetWare)?
core dump.

> Does it mean that the C code in these two cases is compiled with same
> compiler and same compiler flags? In other words can you confirm that
> replacing single object file, one compiled with nasm with one compiled
> with metrowerks, triggers the fault?
yes.

> Output seems to be 16-bit and cover whole file (as opposite to
> disassembling executable segment only). In other words it's pretty
> worthless. Could you see you ndisasm manual and look for 32-bit flag and
> "disassemble code only." Former is absolutely crucial to use, presuming
> that it will synchronize at same instruction early enough. Please
> regenerate disassembler listings. A.
done; and I believe the issue shows already up in the first lines at 00000014:
Metrowerks:
http://www.gknw.net/test/openssl/0.9.8-stable/mwasm/rm-nw.dis
NASM:
http://www.gknw.net/test/openssl/0.9.8-stable/nasm/rm-nw.dis

the asm code is:
	sub	esp,		108

NASM produces for that:
00000014  81EC6C000000      sub esp,0x6c
(Continue reading)

Permalink | Reply | 3 comments |
headers
Guenter Knauf | 3 Dec 2007 03:29
Picon

Re: [PATCH] NetWare platform

Hi Andy,
> I assume ABEND.LOG is answer to this question...
yup.

> But you still have to confirm that the fault is actually triggered by
> metrowerks assembler module.
see my other post I just sent.

> On related note question is what prevents you from always using nasm? Or
> rather do we actually need to support for metrowerks assembler?
> Basically if there is one working configuration for netware, what do we
> need second one for?
well, that wasnt my idea, but it was 'historically'. I guess The Novell folks who did the initial OpenSSL
port just started with the Metrowerks Assembler since its part of the Compiler package, and developers
got this package delivered; probably also for debugging reasons since Metrowerks CodeWarrior comes
with an IDE with source-level debugger; though at the moment I dont have that IDE installed, but use
commandline tools only which is far more flexible reagrding path settings etc.

> Bottom line. I'd rather consider omitting metrowerks assembler support. A.
probably if there's no way to work around the issue; 
but currently it seems that only 2 out of the 13 asm files are affected - that are ripemd and aes (the rc4 fix I
recently posted seems to work - and the aes code wasnt used at all up to now).

BTW. can you tell me for what the CPUID asm code is good for? Well, I can imagine what it does, but I'm curious
for what its used....

thanks for your replies!

Guenter.
(Continue reading)

Permalink | Reply | 6 comments |

Gmane