Last Comment Bug 311432 - ECC's ECL_USE_FP code (for Linux x86) fails pairwise consistency test
: ECC's ECL_USE_FP code (for Linux x86) fails pairwise consistency test
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.11
: x86 Linux
P4 normal (vote)
: 3.12.1
Assigned To: Robert Relyea
Depends on:
  Show dependency treegraph
Reported: 2005-10-06 17:03 PDT by Wan-Teh Chang
Modified: 2008-10-14 15:04 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Work around the bug, plus cleanup (1.97 KB, patch)
2005-11-07 16:54 PST, Wan-Teh Chang
nelson: review+
Details | Diff | Splinter Review

Description User image Wan-Teh Chang 2005-10-06 17:03:46 PDT
I'm building the NSS tip (NSS 3.11 pre-release) on Red Hat
Enterprise Linux 4 (very close to Fedora Core 3) on x86 with

When I run, certutil fails because the new EC key pair
fails the pairwise consistency test; we use the new key pair
to sign and then verify the signature; the signature verification
fails. passes on Windows.

I looked at nss/lib/freebl/Makefile for anything that's specific
to Linux, and found this block of code:

ifeq ($(OS_TARGET),Linux)
ifeq ($(CPU_ARCH),x86_64)
    ASFILES  = arcfour-amd64-gas.s mpi_amd64_gas.s
    ASFLAGS += -march=opteron -m64 -fPIC
    MPI_SRCS += mpi_amd64.c mp_comba.c
ifeq ($(CPU_ARCH),x86)
    ASFILES  = mpi_x86.s
    USE_FP_CODE = 1
    ifdef USE_FP_CODE
        #enable floating point ECC code
        DEFINES  += -DECL_USE_FP
        ECL_SRCS += ecp_fp160.c ecp_fp192.c ecp_fp224.c ecp_fp.c
        ECL_HDRS += ecp_fp.h
endif # Linux

If I comment out the "USE_FP_CODE = 1" statement, passes.

Vipul, Douglas, what is this floating point ECC code, and why is
it only used on Linux x86?  Do you remember when you last tested
it?  Any idea why it doesn't work now?
Comment 1 User image Douglas Stebila 2005-10-07 09:55:40 PDT
(In reply to comment #0)
> Vipul, Douglas, what is this floating point ECC code, and why is
> it only used on Linux x86?  Do you remember when you last tested
> it?  Any idea why it doesn't work now?

The floating point ECC code is described in the file freebl/ecl/README.FP.  It
represents field elements using arrays of double instead of int because the
floating point unit on some platforms (notably, UltraSPARC) is much faster than
the integer unit.  

I know we tested it and it worked on Solaris/UltraSPARC, but I don't remember
how much testing was done on Linux/x86.  

Could you try running the self-contained floating point code tests and let me
know the result?  That could help diagnose the problem.  To do so, do the following:
1. export TARGET=x86LINUX
2. cd .../freebl/mpi
3. make libmpi.a
4. cd .../freebl/ecl
5. make tests
6. ./ecp_fpt
This should give some indication as to where the problem lies.
Comment 2 User image Wan-Teh Chang 2005-10-07 15:22:45 PDT
Douglas: the ECL_USE_FP code is used not only on Linux x86
but also on Solaris SPARC, as you said.

I just followed your instructions on Red Hat Enterprise Linux
(RHEL) 4 x96 to build the ecp_fpt test.  The test has unresolved
references to ec_GFp_pt_mul_jac:

ecp_fpt.o(.text+0x2b59): In function `testPointMulRandom':
: undefined reference to `ec_GFp_pt_mul_jac'
ecp_fpt.o(.text+0x30b0): In function `testPointMulTime':
: undefined reference to `ec_GFp_pt_mul_jac'
collect2: ld returned 1 exit status

This is because that function is inside an ifdef in ecp_jac.c:

/* by default, this routine is unused and thus doesn't need to be compiled */
/* Computes R = nP where R is (rx, ry) and P is (px, py). The parameters
 * a, b and p are the elliptic curve coefficients and the prime that
 * determines the field GFp.  Elliptic curve points P and R can be
 * identical.  Uses mixed Jacobian-affine coordinates. Assumes input is
 * already field-encoded using field_enc, and returns output that is still
 * field-encoded. Uses 4-bit window method. */
ec_GFp_pt_mul_jac(const mp_int *n, const mp_int *px, const mp_int *py,
                                  mp_int *rx, mp_int *ry, const ECGroup *group)'

If I remove the ifdef, the ecp_fpt can be built successfully.
When I run it, I get this failure:

Testing SECG-160R1 using specific floating point implementation...
  Error: Jacobian Floating Point Incorrect.
floating point result
rx    8CEF852E1242A7A780B439BB1D1FA3AD846B5C2F
ry    70D5F73A40657E3276EBA46CF886932BB15740E6
integer result
x   DF389CD53604A97D308C056A38FA8ACB222BE7C5
y   7CCB6AC9F683B820FA8BD44631ABADF3DC05D213
TEST FAILED - Point Addition - Jacobian & Affine
Error: exiting with error value -1

Comment 3 User image Wan-Teh Chang 2005-10-07 16:01:03 PDT
On Solaris 9 UltraSPARC (I had to remove the same ifdef to get
the ecp_fpt test to link):

Test passed

Test passed

Test passed

Comment 4 User image Wan-Teh Chang 2005-11-07 16:54:28 PST
Created attachment 202178 [details] [diff] [review]
Work around the bug, plus cleanup

This patch works around the floating point ECC code bug
on Linux x86 by disabling it.  It also contains some code
cleanup changes.  Here is a summary of the changes.

1. Rename the USE_FP_CODE variable as ECL_USE_FP, which is
the variable used in the standalone makefiles in lib/freebl/ecl.

2. Comment out ECL_USE_FP = 1 for Linux x86 to work around this

3. Share the common makefile code for ECL_USE_FP between Linux x86
and Solaris SPARC.

4. Move the dependency rule for $(OBJDIR)/sysrand$(OBJ_SUFFIX) to
the appropriate section of the makefile.
Comment 5 User image Nelson Bolyard (seldom reads bugmail) 2005-11-07 20:52:59 PST
Comment on attachment 202178 [details] [diff] [review]
Work around the bug, plus cleanup

Comment 6 User image Wan-Teh Chang 2005-11-08 14:03:54 PST
Comment on attachment 202178 [details] [diff] [review]
Work around the bug, plus cleanup

I checked in this patch on the NSS trunk for NSS 3.11.

Checking in Makefile;
/cvsroot/mozilla/security/nss/lib/freebl/Makefile,v  <--  Makefile
new revision: 1.68; previous revision: 1.67
Comment 7 User image Nelson Bolyard (seldom reads bugmail) 2006-02-27 12:02:33 PST
Douglas, Do you know this code?

Are either of the other contributors, Stephen Fung <> and
Nils Gura <>, available to look at it?  

There is an interesting comment in README.FP, which says:

   Some platforms, notably x86 Linux, may use an extended-precision floating
   point representation that has a 64-bit mantissa.  [6]  Although this
   implementation is optimized for the IEEE standard 53-bit mantissa,
   it should work with the 64-bit mantissa.  A check is done at run-time
   in the function ec_set_fp_precision that detects if the precision is
   greater than 53 bits, and runs code for the 64-bit mantissa accordingly.

Seems to me that the ability to represent an "extended" 64-bit mantissa 
would be a property of the hardware more than of the OS (x86 Linux).
Anyway, I wonder if the code to detect the extended precision ability is 
not working properly.
Comment 8 User image Julien Pierre 2006-02-27 16:55:44 PST
Per our meeting, reassigning to Bob.
1) is FP really a win over integer on x86 ? If not, we should not enable it on any x86 OS .
2) why is this only set for Linux x86 and not other x86 OSes (eg. Solaris x86, Windows). We should do all or none.
Comment 9 User image Julien Pierre 2006-06-20 16:31:29 PDT
Retargetting all P2s to 3.11.3 .
Comment 10 User image Wan-Teh Chang 2006-06-20 17:54:19 PDT
We need to freeze the lib/freebl code on the NSS_3_11_BRANCH
because we have finished the FIPS algorithm testing.  Moved
the target milestone to NSS 3.12.
Comment 11 User image Robert Relyea 2007-11-09 13:50:40 PST
patch in hand, going ahead and bumping for the bug council.


Note You need to log in before you can comment on or make changes to this bug.